From nobody Tue Jan 10 01:15:40 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B6C129B8E for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 01:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Odsayr_Jlj0x for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 01:15:36 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B4C129B94 for <6lo@ietf.org>; Tue, 10 Jan 2017 01:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26160; q=dns/txt; s=iport; t=1484039736; x=1485249336; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=VfLkj7de/oWfCFW2n93iZhKkMXbrSv2SNuS4pzN2P1o=; b=IBA1gUsNkpPl+2Vdd7McNPYsblMjYEKvI8atCiaL45xKVSnVQTmvMaJK 0qB4fMWsZvhfITeY6tPRyBo3feyRKBJ3sTTa4Km4TbxIRVFPI3OojmlY3 T/T520Fg9WlKyPPhVTeYkKz4TyP5qT0PjpQNHE2Kt1VURP9fULE3flhAS 8=; X-Files: image001.jpg : 1478 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCopXRY/4QNJK1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJxSQEBAQEBH1+BDAeNUJIolSeCCyyFdgKBcT8UAQIBAQEBAQE?= =?us-ascii?q?BYyiEaAEBAQQFIAgBWwIBCBEBAwEBBgEBAQoOBwcCBRABDAIMFAMGCAEBBAEJC?= =?us-ascii?q?AEGAgaIYg6yX4omAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhkWEYYMJgRkyCQo?= =?us-ascii?q?VBA2FHwWPGT+FSYNTA4IqAYVlAXQwgmWHWYIAhQkOiVGID4Y7hBEBHziBQBUYh?= =?us-ascii?q?Bo1AxyBX3MBhiiBMIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,343,1477958400"; d="jpg'145?scan'145,208,217,145";a="369245250" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2017 09:15:34 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v0A9FY9n031369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2017 09:15:34 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 10 Jan 2017 03:15:33 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 10 Jan 2017 03:15:33 -0600 From: "Pascal Thubert (pthubert)" To: Michel Veillette , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [I-D.-thubert-6lo-forwarding-fragments] review Thread-Index: AdJcdeg2iHq+fbx+TGGB6C8TpoYUCgA1HudQA3XPbuA= Date: Tue, 10 Jan 2017 09:15:09 +0000 Deferred-Delivery: Tue, 10 Jan 2017 09:14:32 +0000 Message-ID: <7a7c4f5f9b044118a50e9960b462e208@XCH-RCD-001.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/related; boundary="_004_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:15:39 -0000 --_004_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_" --_000_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Michel I published a 04 addressing your comments. Please let us know if you find m= ore improvements to be made on the draft. A new version of I-D, draft-thubert-6lo-forwarding-fragments-04.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-thubert-6lo-forwarding-fragments Revision: 04 Title: LLN Fragment Forwarding and Recovery Document date: 2017-01-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-thubert-6lo-forw= arding-fragments-04.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-forwardi= ng-fragments/ Htmlized: https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fr= agments-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-forwa= rding-fragments-04 Abstract: In order to be routed, a fragmented 6LoWPAN packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints Happy new year! Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthube= rt) Sent: vendredi 23 d=E9cembre 2016 19:34 To: Michel Veillette ; 6lo@ietf.org Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Thanks a bunch for your review, Michel! I'll update the doc accordingly early next year. The fragmentation and the forwarding of fragments are finally getting a hot= topic, and was discussed at the last 6TiSCH interim. I'll probably present on the draft and the rationale behind some of the tec= hnical choices therein at the next interim on Jan 6th, 7AM pacific, if you = can attend? Take care, Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette Sent: jeudi 22 d=E9cembre 2016 18:21 To: 6lo@ietf.org Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fr= agments] is very appreciated. This draft addresses multiple issues associated to the transfer of large pa= yloads. - Minimize frame overhead. - Increase efficiency and reduce latency compared to a reassembly at each r= outer. - Complementary to the concept of TSCH tracks. - Guaranty a fix routing during the transfer which often result in a more d= eterministic performance. The following properties defined in this draft are important to us and need= to be preserved. - End to end transfer of 6lo fragment without reassembly at each router - Optional use of acknowledgment and retries - Support of multiple fragments in transit - Label based routing These are my comments on the current version. 1) datagram tag I recommend that you globally replace "datagram tag" with a space by "datag= ram_tag" with an underscore to clearly indicate that you refer to the field within RFRAG. 2) Typo Section 8.1, second line, replace "adnd" by "and" 3) Reference to ND In section 8.1, I recommend that you remove the reference to ND in "a ND re= solution to get the MAC address associated to IP_nxt". Some stacks don't use ND to perform this function. 4) label routing Is it possible to extend the concept of label based routing to subsequent I= P packets part of the same flow in both directions (upstream and downstream)? The issue I want to resolve is the following. In an RPL non storing mode ne= twork, the 6LBR can create an alternate source route to go around a non functional router. This approach forces a r= oute downstream, but not upstream unless the source route is replayed on the reverse direction. Can we define a new field (label), distinct from the datagram_tag, with a l= ifespan longer than a single IP packet transfer and used to perform this label based routing? Any suggestions to resolve this issue is appreciated. Regards, [cid:image001.jpg@01C868D8.BF0BB7E0] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 --_000_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Michel

 

I published a 04 addre= ssing your comments. Please let us know if you find more improvements to be= made on the draft.

 

 

A new version of I-D, draft-thubert-6lo-forwardin= g-fragments-04.txt

has been successfully submitted by Pascal Thubert= and posted to the IETF repository.

 

Name:       &n= bsp;          draft-thubert-6l= o-forwarding-fragments

Revision:      &nbs= p;       04

Title:       &= nbsp;           &nbs= p; LLN Fragment Forwarding and Recovery

Document date:      = ;         2017-01-10

Group:       &= nbsp;          Individual Subm= ission

Pages:       &= nbsp;          16

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fra= gments-04.txt

Status:       =   https://datatracker= .ietf.org/doc/draft-thubert-6lo-forwarding-fragments/

Htmlized:       https://tools.ietf.org/html/draf= t-thubert-6lo-forwarding-fragments-04

Diff:       &n= bsp;   http= s://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-forwarding-fragments-04

 

Abstract:

   In order to be routed, a fragmented = 6LoWPAN packet must be

   reassembled at every hop of a multih= op link where lower layer

   fragmentation occurs.  Consider= ing that the IPv6 minimum MTU is 1280

   bytes and that an an 802.15.4 frame = can have a payload limited to 74

   bytes in the worst case, a packet mi= ght end up fragmented into as

   many as 18 fragments at the 6LoWPAN = shim layer.  If a single one of

   those fragments is lost in transmiss= ion, all fragments must be

   resent, further contributing to the = congestion that might have caused

   the initial packet loss.  This = draft introduces a simple protocol to

   forward and recover individual fragm= ents that might be lost over

   multiple hops between 6LoWPAN endpoints=

 

Happy new year!

 

Pascal

 

From: 6lo [mailt= o:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 23 d=E9cembre 2016 19:34
To: Michel Veillette <Michel.Veillette@trilliantinc.com>; 6lo@= ietf.org
Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

Thanks a bunch for your review, Michel!

 

I’ll update the doc accordingly early next year.

 

The fragmentation and the forwarding of fragments are finally gettin= g a hot topic, and was discussed at the last 6TiSCH interim.

I’ll probably present on the draft and the rationale behind so= me of the technical choices therein at the next interim on Jan 6th, 7AM pacific, if you can attend?

 

Take care,

 

Pascal

 

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette
Sent: jeudi 22 d=E9cembre 2016 18:21
To: 6lo@ietf.org
Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

Hi= Pascal

 

Fi= rst, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-frag= ments] is very appreciated.

Th= is draft addresses multiple issues associated to the transfer of large payl= oads.

- = Minimize frame overhead.

- = Increase efficiency and reduce latency compared to a reassembly at each rou= ter.

- = Complementary to the concept of TSCH tracks.

- = Guaranty a fix routing during the transfer which often result in a more det= erministic performance.

 

Th= e following properties defined in this draft are important to us and need t= o be preserved.

- = End to end transfer of 6lo fragment without reassembly at each router<= /o:p>

- = Optional use of acknowledgment and retries

- = Support of multiple fragments in transit

- = Label based routing

 

Th= ese are my comments on the current version.

 

1)= datagram tag

I = recommend that you globally replace "datagram tag" with a space b= y "datagram_tag" with an underscore

to= clearly indicate that you refer to the field within RFRAG.

 

2)= Typo

Se= ction 8.1, second line, replace "adnd" by "and"

 

3)= Reference to ND

In= section 8.1, I recommend that you remove the reference to ND in "a ND= resolution to get the MAC address

as= sociated to IP_nxt".  Some stacks don't use ND to perform this fu= nction.

 

4)=   label routing

Is= it possible to extend the concept of label based routing to subsequent IP = packets part of the same flow

in= both directions (upstream and downstream)?

Th= e issue I want to resolve is the following. In an RPL non storing mode netw= ork, the 6LBR can create an alternate

so= urce route to go around a non functional router. This approach forces a rou= te downstream, but not upstream

un= less the source route is replayed on the reverse direction.

Ca= n we define a new field (label), distinct from the datagram_tag, with a lif= espan longer than a single IP packet

tr= ansfer and used to perform this label based routing?

An= y suggestions to resolve this issue is appreciated.

 

Re= gards,

 

3D"cid:image001.jpg@=

Michel Veill= ette
System Architecture Director

Trilliant In= c.
Tel: 450-531-3109

 

 

--_000_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_-- --_004_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1478; creation-date="Tue, 10 Jan 2017 09:15:08 GMT"; modification-date="Tue, 10 Jan 2017 09:15:08 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAASAGADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0nWda ktpTa2hVZFAaaZl3CIHoAP4nPYVEJni0syCSRZJHAEsku9wexYDjGcAgdAaddpZW1wUmDvKzNLt4 UuW43LnqQOMDmmtNbataCzVPIkTOxMEZ4IwMgEVHU4JOTk7vXohLyHUPEWk2k2l6i2myBj52F3cj gr+Brj9HPiPWNdvtMXxBPE1pnMhGQ2DjpXoek25toZ0IIBuHYZ9Ca4nwaf8AivPEHPZ//Q67cPN+ zl5LsVKLbhzbvc2bDxppVo1tpdxqEl5eqVheZYjtd84zn61g3WuXkPh3Wp7XW7i5mhukQMY9hhGT 8oz1/wDrVY+F8MUh1d3jRmW4XaxUEj73Suaj/wCRW8S/9f0f/oTV0RpwU2l0a/FkSqTcE31udNBr Wot4t0O2a9l8ifT0klTjDMVYlj78Ve8P+I4LLQr2/wBQ1ae/hiuAhkaEqUz0AHesOA/8Vr4e/wCw Wn/oD1R0fVrjR/A+pXFqiNI1+se51DBARnOD9MfjRKkpK1u35sUaji737/kjs4viR4ellWP7RKm4 43PEQB9TVzV/Gej6JdrbXkz+aUD4SMsMHpzXmmv3813pSibW7G7G4N5MMGxgfXOB0rodPAk+I+kB 8NnS4zzzn92aiWGglza9fw+RccRNu3p+PzOp0vxrourzNFa3LeaqltjoVJAGTj1rntK+Iiz+JriG 6l/4l0hCWoWH5txIAz+tP8RRRxfE3w+Y0VS6/NtGM8tVLSr3T9M+Jmri9McaSHy4QUyN5K4xxxSj Sp8raV7q/wCI5VJ8yTezt+B32pwRT2EyzRJIoXIDqCAfWvOtIvroakIhcziPf9wSHHX0oorzZfEY Yn+Oj09e9UbWztob+aWK3iSSQHe6oAW57nvRRXRD4ZHoS3iFhaW9oZvs0EUO85by0C5PqcVCum2X 2aeP7Hb7JHDOvlLhj6kY5oorVfG/kZfZXzJPsVqLqCUW0PmRx7UfyxlRg8A9hSQadZpZTQraW4ic 5ZBGNrH3GKKKHt936iXX5lY6LpmD/wAS6z/78L/hVpbO2S/imW3iEqJsVwg3BcdAfSiirq7fJkU9 /uJLm1t5dRgmkgiaWMfI7ICy/Q9qjudOs5r1J5bS3ebg+Y0aluDxziiis6e69P1NJ9fU/9k= --_004_7a7c4f5f9b044118a50e9960b462e208XCHRCD001ciscocom_-- From nobody Tue Jan 10 07:30:12 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C68129CF5 for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 07:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=trilliant.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIfPmlBVGOtx for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 07:30:08 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0095.outbound.protection.outlook.com [104.47.36.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC76129521 for <6lo@ietf.org>; Tue, 10 Jan 2017 07:30:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Trilliant.onmicrosoft.com; s=selector1-trilliantinc-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Qy1w3JuYOkYd5PYkt4S4lxgbVm9tdKVgo8RVrv3diYs=; b=TEjE51/86w61MHP5WWJTXxgaLUq9oTHPQEGIGUbCs6f3VjSBv87WrU1DMt1hsEUbA0COUjK2WPunZqKVGXeJChZRMpsLc5Idxuv4u5ySFp5GEKJHikuF5UKSYg/y2uSeOeQBKejwGH41kN4kWQ4nnapTVxwIj7N5tKrrV1ZUiTA= Received: from BN6PR06MB2308.namprd06.prod.outlook.com (10.173.19.139) by BN6PR06MB2307.namprd06.prod.outlook.com (10.173.19.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Tue, 10 Jan 2017 15:30:06 +0000 Received: from BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) by BN6PR06MB2308.namprd06.prod.outlook.com ([10.173.19.139]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 15:30:05 +0000 From: Michel Veillette To: "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [I-D.-thubert-6lo-forwarding-fragments] review Thread-Index: AdJcdeg2iHq+fbx+TGGB6C8TpoYUCgA1HudQA3XPbuAADGcHQA== Date: Tue, 10 Jan 2017 15:30:05 +0000 Message-ID: References: <7a7c4f5f9b044118a50e9960b462e208@XCH-RCD-001.cisco.com> In-Reply-To: <7a7c4f5f9b044118a50e9960b462e208@XCH-RCD-001.cisco.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michel.Veillette@trilliantinc.com; x-originating-ip: [207.96.192.122] x-ms-office365-filtering-correlation-id: 280b2850-d350-4a5a-1f69-08d4396d8dcf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR06MB2307; x-microsoft-exchange-diagnostics: 1; BN6PR06MB2307; 7:Z/01Gr5ccyGCGZ/IRFirQ6vhzV+aKW+23v0FucvB2Adv2hmozWvsMMvlHe27HeQUTpKbQbaNmt+Dv5lVb0fzfk/yY2z3RYWgmAK/V3ogTELYVfMWZx8HkZOpWR1lpiolaBQsncO5EtZFVGpB+QrJMM386VcvFpjcvuyqNEa3SzZ5xVsNMl2D2Sqq+ZOoJD5MJrkgnYhXjSqhjM70eWVho5r7F/3GG+WKd0vOv6ImWVA75ugp7OJwTa1mt9OQz2s/WRpA/d7h3ZlvwIGT+sKWW0KxlxO+WqZiGGdLMXTy7aVdFkkWspD1gGF02M5fGr3uRG38gn75mZWXRmy1+HISe3IAQ/CZke1s7RJRaxnVAymEzF0GQngyXJ5RflRDZx6dB27f5xvUcE7GG0vDCU8UTx3cMfrwZidPzL4Jdwnk6bZbV7XqvUx/JKV8Ee/0T9OTJ70Dl6Ddtq9kH2tZXr+XoA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(788757137089)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN6PR06MB2307; BCL:0; PCL:0; RULEID:; SRVR:BN6PR06MB2307; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39840400002)(39410400002)(199003)(43544003)(189002)(51914003)(377454003)(377424004)(92566002)(2900100001)(7696004)(2501003)(106356001)(230783001)(33656002)(105586002)(2906002)(7906003)(66066001)(7736002)(229853002)(189998001)(236005)(86362001)(74316002)(6506006)(606005)(3280700002)(55016002)(102836003)(6116002)(3846002)(6436002)(8936002)(790700001)(8676002)(50986999)(76176999)(54356999)(733005)(107886002)(5001770100001)(9686003)(99286003)(2950100002)(3660700001)(25786008)(122556002)(68736007)(6306002)(81166006)(97736004)(81156014)(54896002)(54556002)(77096006)(101416001)(99936001)(38730400001)(5660300001)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR06MB2307; H:BN6PR06MB2308.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: trilliantinc.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_004_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: trilliantinc.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 15:30:05.8531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f6fbd13-0dfb-4150-85c3-d43260c04309 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2307 Archived-At: Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:30:10 -0000 --_004_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_ Content-Type: multipart/alternative; boundary="_000_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_" --_000_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal About my last topic (how to extend the use of label routing for subsequent = downstream or upstream IP packets), do you have an approach to propose? Thi= s solution can be within the context of this draft or an existing RFC. Is t= here a synergy possible between the need to maintain a route during the tra= nsfer of a fragmented IP packet, the need to maintain a route during an int= eraction between two nodes, the notion of TSCH track? Thanks for the draft update. Regards Michel From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Tuesday, January 10, 2017 4:15 AM To: Michel Veillette ; 6lo@ietf.org Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review Hello Michel I published a 04 addressing your comments. Please let us know if you find m= ore improvements to be made on the draft. A new version of I-D, draft-thubert-6lo-forwarding-fragments-04.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-thubert-6lo-forwarding-fragments Revision: 04 Title: LLN Fragment Forwarding and Recovery Document date: 2017-01-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-thubert-6lo-forw= arding-fragments-04.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-forwardi= ng-fragments/ Htmlized: https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fr= agments-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-forwa= rding-fragments-04 Abstract: In order to be routed, a fragmented 6LoWPAN packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints Happy new year! Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthube= rt) Sent: vendredi 23 d=E9cembre 2016 19:34 To: Michel Veillette >; 6lo@ietf.org Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Thanks a bunch for your review, Michel! I'll update the doc accordingly early next year. The fragmentation and the forwarding of fragments are finally getting a hot= topic, and was discussed at the last 6TiSCH interim. I'll probably present on the draft and the rationale behind some of the tec= hnical choices therein at the next interim on Jan 6th, 7AM pacific, if you = can attend? Take care, Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette Sent: jeudi 22 d=E9cembre 2016 18:21 To: 6lo@ietf.org Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fr= agments] is very appreciated. This draft addresses multiple issues associated to the transfer of large pa= yloads. - Minimize frame overhead. - Increase efficiency and reduce latency compared to a reassembly at each r= outer. - Complementary to the concept of TSCH tracks. - Guaranty a fix routing during the transfer which often result in a more d= eterministic performance. The following properties defined in this draft are important to us and need= to be preserved. - End to end transfer of 6lo fragment without reassembly at each router - Optional use of acknowledgment and retries - Support of multiple fragments in transit - Label based routing These are my comments on the current version. 1) datagram tag I recommend that you globally replace "datagram tag" with a space by "datag= ram_tag" with an underscore to clearly indicate that you refer to the field within RFRAG. 2) Typo Section 8.1, second line, replace "adnd" by "and" 3) Reference to ND In section 8.1, I recommend that you remove the reference to ND in "a ND re= solution to get the MAC address associated to IP_nxt". Some stacks don't use ND to perform this function. 4) label routing Is it possible to extend the concept of label based routing to subsequent I= P packets part of the same flow in both directions (upstream and downstream)? The issue I want to resolve is the following. In an RPL non storing mode ne= twork, the 6LBR can create an alternate source route to go around a non functional router. This approach forces a r= oute downstream, but not upstream unless the source route is replayed on the reverse direction. Can we define a new field (label), distinct from the datagram_tag, with a l= ifespan longer than a single IP packet transfer and used to perform this label based routing? Any suggestions to resolve this issue is appreciated. Regards, [cid:image001.jpg@01C868D8.BF0BB7E0] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 --_000_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Pascal

 

About my last topic (how to ext= end the use of label routing for subsequent downstream or upstream IP packe= ts), do you have an approach to propose? This solution can be within the co= ntext of this draft or an existing RFC. Is there a synergy possible between the need to maintain a route during th= e transfer of a fragmented IP packet, the need to maintain a route during a= n interaction between two nodes, the notion of TSCH track?

 

Thanks for the draft update.

 

Regards

Michel

 

 

From: Pascal Thubert (pthubert) [mailto:pthub= ert@cisco.com]
Sent: Tuesday, January 10, 2017 4:15 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>; 6lo@= ietf.org
Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review

 

Hello Michel

 

I published a 04 addre= ssing your comments. Please let us know if you find more improvements to be= made on the draft.

 

 

A new version of I-D, draft-thubert-6lo-forwardin= g-fragments-04.txt

has been successfully submitted by Pascal Thubert= and posted to the IETF repository.

 

Name:       &n= bsp;          draft-thubert-6l= o-forwarding-fragments

Revision:      &nbs= p;       04

Title:       &= nbsp;           &nbs= p; LLN Fragment Forwarding and Recovery

Document date:      = ;         2017-01-10

Group:       &= nbsp;          Individual Subm= ission

Pages:       &= nbsp;          16

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fra= gments-04.txt

Status:       =   https://datatracker= .ietf.org/doc/draft-thubert-6lo-forwarding-fragments/

Htmlized:       https://tools.ietf.org/html/draf= t-thubert-6lo-forwarding-fragments-04

Diff:       &n= bsp;   http= s://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-forwarding-fragments-04

 

Abstract:

   In order to be routed, a fragmented = 6LoWPAN packet must be

   reassembled at every hop of a multih= op link where lower layer

   fragmentation occurs.  Consider= ing that the IPv6 minimum MTU is 1280

   bytes and that an an 802.15.4 frame = can have a payload limited to 74

   bytes in the worst case, a packet mi= ght end up fragmented into as

   many as 18 fragments at the 6LoWPAN = shim layer.  If a single one of

   those fragments is lost in transmiss= ion, all fragments must be

   resent, further contributing to the = congestion that might have caused

   the initial packet loss.  This = draft introduces a simple protocol to

   forward and recover individual fragm= ents that might be lost over

   multiple hops between 6LoWPAN endpoints=

 

Happy new year!

 

Pascal

 

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 23 d=E9cembre 2016 19:34
To: Michel Veillette <Michel.Veillette@trilliantinc.com>; 6lo@ietf.org
Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

Thanks a bunch for your review, Michel!

 

I’ll update the doc accordingly early next year.

 

The fragmentation and the forwarding of fragments are finally getting = a hot topic, and was discussed at the last 6TiSCH interim.

I’ll probably present on the draft and the rationale behind some= of the technical choices therein at the next interim on Jan 6th= , 7AM pacific, if you can attend?

 

Take care,

 

Pascal

 

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette
Sent: jeudi 22 d=E9cembre 2016 18:21
To: 6lo@ietf.org
Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

Hi = Pascal

 

Fir= st, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fragm= ents] is very appreciated.

Thi= s draft addresses multiple issues associated to the transfer of large paylo= ads.

- M= inimize frame overhead.

- I= ncrease efficiency and reduce latency compared to a reassembly at each rout= er.

- C= omplementary to the concept of TSCH tracks.

- G= uaranty a fix routing during the transfer which often result in a more dete= rministic performance.

 

The= following properties defined in this draft are important to us and need to= be preserved.

- E= nd to end transfer of 6lo fragment without reassembly at each router

- O= ptional use of acknowledgment and retries

- S= upport of multiple fragments in transit

- L= abel based routing

 

The= se are my comments on the current version.

 

1) = datagram tag

I r= ecommend that you globally replace "datagram tag" with a space by= "datagram_tag" with an underscore

to = clearly indicate that you refer to the field within RFRAG.

 

2) = Typo

Sec= tion 8.1, second line, replace "adnd" by "and"

 

3) = Reference to ND

In = section 8.1, I recommend that you remove the reference to ND in "a ND = resolution to get the MAC address

ass= ociated to IP_nxt".  Some stacks don't use ND to perform this fun= ction.

 

4)&= nbsp; label routing

Is = it possible to extend the concept of label based routing to subsequent IP p= ackets part of the same flow

in = both directions (upstream and downstream)?

The= issue I want to resolve is the following. In an RPL non storing mode netwo= rk, the 6LBR can create an alternate

sou= rce route to go around a non functional router. This approach forces a rout= e downstream, but not upstream

unl= ess the source route is replayed on the reverse direction.

Can= we define a new field (label), distinct from the datagram_tag, with a life= span longer than a single IP packet

tra= nsfer and used to perform this label based routing?

Any= suggestions to resolve this issue is appreciated.

 

Reg= ards,

 

3D"cid:image001.jpg@=

Michel Veill= ette
System Architecture Director

Trilliant In= c.
Tel: 450-531-3109

 

 

--_000_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_-- --_004_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1478; creation-date="Tue, 10 Jan 2017 15:30:05 GMT"; modification-date="Tue, 10 Jan 2017 15:30:05 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAASAGADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0nWda ktpTa2hVZFAaaZl3CIHoAP4nPYVEJni0syCSRZJHAEsku9wexYDjGcAgdAaddpZW1wUmDvKzNLt4 UuW43LnqQOMDmmtNbataCzVPIkTOxMEZ4IwMgEVHU4JOTk7vXohLyHUPEWk2k2l6i2myBj52F3cj gr+Brj9HPiPWNdvtMXxBPE1pnMhGQ2DjpXoek25toZ0IIBuHYZ9Ca4nwaf8AivPEHPZ//Q67cPN+ zl5LsVKLbhzbvc2bDxppVo1tpdxqEl5eqVheZYjtd84zn61g3WuXkPh3Wp7XW7i5mhukQMY9hhGT 8oz1/wDrVY+F8MUh1d3jRmW4XaxUEj73Suaj/wCRW8S/9f0f/oTV0RpwU2l0a/FkSqTcE31udNBr Wot4t0O2a9l8ifT0klTjDMVYlj78Ve8P+I4LLQr2/wBQ1ae/hiuAhkaEqUz0AHesOA/8Vr4e/wCw Wn/oD1R0fVrjR/A+pXFqiNI1+se51DBARnOD9MfjRKkpK1u35sUaji737/kjs4viR4ellWP7RKm4 43PEQB9TVzV/Gej6JdrbXkz+aUD4SMsMHpzXmmv3813pSibW7G7G4N5MMGxgfXOB0rodPAk+I+kB 8NnS4zzzn92aiWGglza9fw+RccRNu3p+PzOp0vxrourzNFa3LeaqltjoVJAGTj1rntK+Iiz+JriG 6l/4l0hCWoWH5txIAz+tP8RRRxfE3w+Y0VS6/NtGM8tVLSr3T9M+Jmri9McaSHy4QUyN5K4xxxSj Sp8raV7q/wCI5VJ8yTezt+B32pwRT2EyzRJIoXIDqCAfWvOtIvroakIhcziPf9wSHHX0oorzZfEY Yn+Oj09e9UbWztob+aWK3iSSQHe6oAW57nvRRXRD4ZHoS3iFhaW9oZvs0EUO85by0C5PqcVCum2X 2aeP7Hb7JHDOvlLhj6kY5oorVfG/kZfZXzJPsVqLqCUW0PmRx7UfyxlRg8A9hSQadZpZTQraW4ic 5ZBGNrH3GKKKHt936iXX5lY6LpmD/wAS6z/78L/hVpbO2S/imW3iEqJsVwg3BcdAfSiirq7fJkU9 /uJLm1t5dRgmkgiaWMfI7ICy/Q9qjudOs5r1J5bS3ebg+Y0aluDxziiis6e69P1NJ9fU/9k= --_004_BN6PR06MB2308B5772DF346143871D4FBFE670BN6PR06MB2308namp_-- From nobody Tue Jan 10 07:37:15 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725DB129504 for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 07:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSEUycTG8NSj for <6lo@ietfa.amsl.com>; Tue, 10 Jan 2017 07:37:10 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670FA12946E for <6lo@ietf.org>; Tue, 10 Jan 2017 07:37:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33302; q=dns/txt; s=iport; t=1484062630; x=1485272230; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=RKsm/gwPhCYTgEprK08YLGlbV6FIPwo6OqFEOS0b99c=; b=LQwfhUZHX23zDMWVtG2/CWA/dp8UAM4riSS0ZIDm8AxW9cKK3l7zBdb/ qetU9Y49Z6+h8Z/g1BKwuoWseZCw4asZoKrOiK4/o+sfShSrvnNmiekp6 wRKU8t9NlG5rUm/Sr72oqzP1/GT4rHoJfD3kNQk9+fP/kYH6rg4IkO1f0 I=; X-Files: image001.jpg : 1478 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCD/nRY/4UNJK1TBwMZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCcUkBAQEBAR9fgQ0HjVCSJ5UnggsshXYCggI/FAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEEBSAIAVsCAQgRAQMBAQYBAQEKDgEGBwIFEAEMAgwUAwYIAQEEA?= =?us-ascii?q?QkIAQYCBg2IVQ6yXIokAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhkWEYYMJgRU?= =?us-ascii?q?EMgkKFQQNhR8Fjxo/hUqDUwOCKgGFZQF0MIJlh1mCAIULDolRiBCGO4QSAR84g?= =?us-ascii?q?UAVGIRPAxyBX3MBhiiBMIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="jpg'145?scan'145,208,217,145";a="370758158" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Jan 2017 15:37:08 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0AFb859012102 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Jan 2017 15:37:08 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 10 Jan 2017 09:37:07 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 10 Jan 2017 09:37:07 -0600 From: "Pascal Thubert (pthubert)" To: Michel Veillette , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [I-D.-thubert-6lo-forwarding-fragments] review Thread-Index: AdJcdeg2iHq+fbx+TGGB6C8TpoYUCgA1HudQA3XPbuAADGcHQAAA2buA Date: Tue, 10 Jan 2017 15:36:49 +0000 Deferred-Delivery: Tue, 10 Jan 2017 15:36:39 +0000 Message-ID: References: <7a7c4f5f9b044118a50e9960b462e208@XCH-RCD-001.cisco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: multipart/related; boundary="_004_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:37:13 -0000 --_004_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_" --_000_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Michel : The 6TiSCH architecture suggests to identify flows by the source of destina= tion address, plus a local instance ID which is compressed by 6LoRH. When you use 6TiSCH tracks, the G-MPLS operation allows to forward fragment= s along a path without the need of the the datagram_tag switching that is p= resented in the draft, the whole track is indeed a tunnel that appears as o= ne hop for 6LoWPAN. Do we need to define something new/different? Take care, Pascal From: Michel Veillette [mailto:Michel.Veillette@trilliantinc.com] Sent: mardi 10 janvier 2017 16:30 To: Pascal Thubert (pthubert) ; 6lo@ietf.org Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal About my last topic (how to extend the use of label routing for subsequent = downstream or upstream IP packets), do you have an approach to propose? Thi= s solution can be within the context of this draft or an existing RFC. Is t= here a synergy possible between the need to maintain a route during the tra= nsfer of a fragmented IP packet, the need to maintain a route during an int= eraction between two nodes, the notion of TSCH track? Thanks for the draft update. Regards Michel From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Tuesday, January 10, 2017 4:15 AM To: Michel Veillette >; 6lo@ietf.org Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review Hello Michel I published a 04 addressing your comments. Please let us know if you find m= ore improvements to be made on the draft. A new version of I-D, draft-thubert-6lo-forwarding-fragments-04.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Name: draft-thubert-6lo-forwarding-fragments Revision: 04 Title: LLN Fragment Forwarding and Recovery Document date: 2017-01-10 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-thubert-6lo-forw= arding-fragments-04.txt Status: https://datatracker.ietf.org/doc/draft-thubert-6lo-forwardi= ng-fragments/ Htmlized: https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fr= agments-04 Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-6lo-forwa= rding-fragments-04 Abstract: In order to be routed, a fragmented 6LoWPAN packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints Happy new year! Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthube= rt) Sent: vendredi 23 d=E9cembre 2016 19:34 To: Michel Veillette >; 6lo@ietf.org Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Thanks a bunch for your review, Michel! I'll update the doc accordingly early next year. The fragmentation and the forwarding of fragments are finally getting a hot= topic, and was discussed at the last 6TiSCH interim. I'll probably present on the draft and the rationale behind some of the tec= hnical choices therein at the next interim on Jan 6th, 7AM pacific, if you = can attend? Take care, Pascal From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette Sent: jeudi 22 d=E9cembre 2016 18:21 To: 6lo@ietf.org Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review Hi Pascal First, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fr= agments] is very appreciated. This draft addresses multiple issues associated to the transfer of large pa= yloads. - Minimize frame overhead. - Increase efficiency and reduce latency compared to a reassembly at each r= outer. - Complementary to the concept of TSCH tracks. - Guaranty a fix routing during the transfer which often result in a more d= eterministic performance. The following properties defined in this draft are important to us and need= to be preserved. - End to end transfer of 6lo fragment without reassembly at each router - Optional use of acknowledgment and retries - Support of multiple fragments in transit - Label based routing These are my comments on the current version. 1) datagram tag I recommend that you globally replace "datagram tag" with a space by "datag= ram_tag" with an underscore to clearly indicate that you refer to the field within RFRAG. 2) Typo Section 8.1, second line, replace "adnd" by "and" 3) Reference to ND In section 8.1, I recommend that you remove the reference to ND in "a ND re= solution to get the MAC address associated to IP_nxt". Some stacks don't use ND to perform this function. 4) label routing Is it possible to extend the concept of label based routing to subsequent I= P packets part of the same flow in both directions (upstream and downstream)? The issue I want to resolve is the following. In an RPL non storing mode ne= twork, the 6LBR can create an alternate source route to go around a non functional router. This approach forces a r= oute downstream, but not upstream unless the source route is replayed on the reverse direction. Can we define a new field (label), distinct from the datagram_tag, with a l= ifespan longer than a single IP packet transfer and used to perform this label based routing? Any suggestions to resolve this issue is appreciated. Regards, [cid:image001.jpg@01C868D8.BF0BB7E0] Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-531-3109 --_000_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Michel :

 

The 6TiSCH architectur= e suggests to identify flows by the source of destination address, plus a l= ocal instance ID which is compressed by 6LoRH.

When you use 6TiSCH tr= acks, the G-MPLS operation allows to forward fragments along a path without= the need of the the datagram_tag switching that is presented in the draft,= the whole track is indeed a tunnel that appears as one hop for 6LoWPAN.

 

Do we need to define s= omething new/different?

 

Take care,<= /span>

 

Pascal

 

From: Michel Vei= llette [mailto:Michel.Veillette@trilliantinc.com]
Sent: mardi 10 janvier 2017 16:30
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; 6lo@ietf.o= rg
Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review

 

Hi= Pascal

 

Ab= out my last topic (how to extend the use of label routing for subsequent do= wnstream or upstream IP packets), do you have an approach to propose? This = solution can be within the context of this draft or an existing RFC. Is there a synergy possible between the nee= d to maintain a route during the transfer of a fragmented IP packet, the ne= ed to maintain a route during an interaction between two nodes, the notion = of TSCH track?

 

Th= anks for the draft update.

 

Re= gards

Mi= chel

 

 

From: Pascal Thu= bert (pthubert) [mailto:pthubert@cisc= o.com]
Sent: Tuesday, January 10, 2017 4:15 AM
To: Michel Veillette <Michel.Veillette@trilliantinc.com>; 6lo@ietf.org
Subject: RE: [I-D.-thubert-6lo-forwarding-fragments] review

 

Hello Michel

 

I published a 04 addressing your comments. Please let us know if you= find more improvements to be made on the draft.

 

 

A new version of I-D= , draft-thubert-6lo-forwarding-fragments-04.txt

has been successfull= y submitted by Pascal Thubert and posted to the IETF repository.=

 

Name:  &nb= sp;            =    draft-thubert-6lo-forwarding-fragments

Revision:  = ;            04=

Title:  &n= bsp;            = ;      LLN Fragment Forwarding and Recovery

Document date: =             &nb= sp; 2017-01-10

Group:  &n= bsp;            = ;   Individual Submission

Pages:  &n= bsp;            = ;   16

URL:  &nbs= p;         https://www.ietf.org/internet-draf= ts/draft-thubert-6lo-forwarding-fragments-04.txt

Status:  &= nbsp;      https://datatracker.ietf.org/doc/draft-thube= rt-6lo-forwarding-fragments/

Htmlized:  = ;     https://tools.ietf.org/html/draft-thubert-6lo-f= orwarding-fragments-04

Diff:  &nb= sp;        https://www.ietf.org/rfcdiff?url2=3Ddra= ft-thubert-6lo-forwarding-fragments-04

 

Abstract:=

   In orde= r to be routed, a fragmented 6LoWPAN packet must be

   reassem= bled at every hop of a multihop link where lower layer

   fragmen= tation occurs.  Considering that the IPv6 minimum MTU is 1280

   bytes a= nd that an an 802.15.4 frame can have a payload limited to 74

   bytes i= n the worst case, a packet might end up fragmented into as

   many as= 18 fragments at the 6LoWPAN shim layer.  If a single one of

   those f= ragments is lost in transmission, all fragments must be

   resent,= further contributing to the congestion that might have caused

   the ini= tial packet loss.  This draft introduces a simple protocol to

   forward= and recover individual fragments that might be lost over

   multiple h= ops between 6LoWPAN endpoints

 

Happy new year!

 

Pascal

 

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 23 d=E9cembre 2016 19:34
To: Michel Veillette <Michel.Veillette@trilliantinc.com>; 6lo@ietf.org
Subject: Re: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

Thanks a bunch for your review, Michel!

 

I’ll update the doc accordingly early next year.

 

The fragmentation and the forwarding of fragments are finally gettin= g a hot topic, and was discussed at the last 6TiSCH interim.

I’ll probably present on the draft and the rationale behind so= me of the technical choices therein at the next interim on Jan 6th, 7AM pacific, if you can attend?

 

Take care,

 

Pascal

 

From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Michel Veillette
Sent: jeudi 22 d=E9cembre 2016 18:21
To: 6lo@ietf.org
Subject: [6lo] [I-D.-thubert-6lo-forwarding-fragments] review

 

H= i Pascal

<= o:p> 

F= irst, I'll like to mention that your draft [I-D.-thubert-6lo-forwarding-fra= gments] is very appreciated.

T= his draft addresses multiple issues associated to the transfer of large pay= loads.

-= Minimize frame overhead.

-= Increase efficiency and reduce latency compared to a reassembly at each ro= uter.

-= Complementary to the concept of TSCH tracks.

-= Guaranty a fix routing during the transfer which often result in a more de= terministic performance.

<= o:p> 

T= he following properties defined in this draft are important to us and need = to be preserved.

-= End to end transfer of 6lo fragment without reassembly at each router=

-= Optional use of acknowledgment and retries

-= Support of multiple fragments in transit

-= Label based routing

<= o:p> 

T= hese are my comments on the current version.

<= o:p> 

1= ) datagram tag

I= recommend that you globally replace "datagram tag" with a space = by "datagram_tag" with an underscore

t= o clearly indicate that you refer to the field within RFRAG.

<= o:p> 

2= ) Typo

S= ection 8.1, second line, replace "adnd" by "and"

<= o:p> 

3= ) Reference to ND

I= n section 8.1, I recommend that you remove the reference to ND in "a N= D resolution to get the MAC address

a= ssociated to IP_nxt".  Some stacks don't use ND to perform this f= unction.

<= o:p> 

4= )  label routing

I= s it possible to extend the concept of label based routing to subsequent IP= packets part of the same flow

i= n both directions (upstream and downstream)?

T= he issue I want to resolve is the following. In an RPL non storing mode net= work, the 6LBR can create an alternate

s= ource route to go around a non functional router. This approach forces a ro= ute downstream, but not upstream

u= nless the source route is replayed on the reverse direction.

C= an we define a new field (label), distinct from the datagram_tag, with a li= fespan longer than a single IP packet

t= ransfer and used to perform this label based routing?

A= ny suggestions to resolve this issue is appreciated.

<= o:p> 

R= egards,

<= o:p> 

3D"cid:image001.jpg@=

Michel Veill= ette
System Architecture Director

Trilliant In= c.
Tel: 450-531-3109

<= o:p> 

<= o:p> 

--_000_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_-- --_004_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=1478; creation-date="Tue, 10 Jan 2017 15:36:48 GMT"; modification-date="Tue, 10 Jan 2017 15:36:48 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCAASAGADASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0nWda ktpTa2hVZFAaaZl3CIHoAP4nPYVEJni0syCSRZJHAEsku9wexYDjGcAgdAaddpZW1wUmDvKzNLt4 UuW43LnqQOMDmmtNbataCzVPIkTOxMEZ4IwMgEVHU4JOTk7vXohLyHUPEWk2k2l6i2myBj52F3cj gr+Brj9HPiPWNdvtMXxBPE1pnMhGQ2DjpXoek25toZ0IIBuHYZ9Ca4nwaf8AivPEHPZ//Q67cPN+ zl5LsVKLbhzbvc2bDxppVo1tpdxqEl5eqVheZYjtd84zn61g3WuXkPh3Wp7XW7i5mhukQMY9hhGT 8oz1/wDrVY+F8MUh1d3jRmW4XaxUEj73Suaj/wCRW8S/9f0f/oTV0RpwU2l0a/FkSqTcE31udNBr Wot4t0O2a9l8ifT0klTjDMVYlj78Ve8P+I4LLQr2/wBQ1ae/hiuAhkaEqUz0AHesOA/8Vr4e/wCw Wn/oD1R0fVrjR/A+pXFqiNI1+se51DBARnOD9MfjRKkpK1u35sUaji737/kjs4viR4ellWP7RKm4 43PEQB9TVzV/Gej6JdrbXkz+aUD4SMsMHpzXmmv3813pSibW7G7G4N5MMGxgfXOB0rodPAk+I+kB 8NnS4zzzn92aiWGglza9fw+RccRNu3p+PzOp0vxrourzNFa3LeaqltjoVJAGTj1rntK+Iiz+JriG 6l/4l0hCWoWH5txIAz+tP8RRRxfE3w+Y0VS6/NtGM8tVLSr3T9M+Jmri9McaSHy4QUyN5K4xxxSj Sp8raV7q/wCI5VJ8yTezt+B32pwRT2EyzRJIoXIDqCAfWvOtIvroakIhcziPf9wSHHX0oorzZfEY Yn+Oj09e9UbWztob+aWK3iSSQHe6oAW57nvRRXRD4ZHoS3iFhaW9oZvs0EUO85by0C5PqcVCum2X 2aeP7Hb7JHDOvlLhj6kY5oorVfG/kZfZXzJPsVqLqCUW0PmRx7UfyxlRg8A9hSQadZpZTQraW4ic 5ZBGNrH3GKKKHt936iXX5lY6LpmD/wAS6z/78L/hVpbO2S/imW3iEqJsVwg3BcdAfSiirq7fJkU9 /uJLm1t5dRgmkgiaWMfI7ICy/Q9qjudOs5r1J5bS3ebg+Y0aluDxziiis6e69P1NJ9fU/9k= --_004_a2c3dac6d88b4d20a82d29001c0aac27XCHRCD001ciscocom_-- From nobody Wed Jan 11 01:40:44 2017 Return-Path: X-Original-To: 6lo@ietf.org Delivered-To: 6lo@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D264A129AD9; Wed, 11 Jan 2017 01:40:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148412764285.10460.581915464135709250.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 01:40:42 -0800 Archived-At: Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-rfc6775-update-01.txt X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:40:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes of the IETF. Title : An Update to 6LoWPAN ND Authors : Pascal Thubert Erik Nordmark Samita Chakrabarti Filename : draft-ietf-6lo-rfc6775-update-01.txt Pages : 22 Date : 2017-01-11 Abstract: This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, and provide enhancements to the registration capabilities, in particular for the registration to a backbone router for proxy ND operations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6lo-rfc6775-update-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-rfc6775-update-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 03:00:41 2017 Return-Path: X-Original-To: 6lo@ietf.org Delivered-To: 6lo@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40145129B99; Wed, 11 Jan 2017 03:00:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148413243925.10381.982476500477319211.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 03:00:39 -0800 Archived-At: Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-backbone-router-03.txt X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:00:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes of the IETF. Title : IPv6 Backbone Router Author : Pascal Thubert Filename : draft-ietf-6lo-backbone-router-03.txt Pages : 29 Date : 2017-01-11 Abstract: This specification proposes an update to IPv6 Neighbor Discovery, to enhance the operation of IPv6 over wireless links that exhibit lossy multicast support, and enable a large degree of scalability by splitting the broadcast domains. A higher speed backbone federates multiple wireless links to form a large MultiLink Subnet. Backbone Routers acting as Layer-3 Access Point route packets to registered nodes, where an classical Layer-2 Access Point would bridge. Conversely, wireless nodes register or are proxy-registered to the Backbone Router to setup routing services in a fashion that is essentially similar to a classical Layer-2 association. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-backbone-router-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 03:03:55 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4142129B99 for <6lo@ietfa.amsl.com>; Wed, 11 Jan 2017 03:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z0nzBxc_nMA for <6lo@ietfa.amsl.com>; Wed, 11 Jan 2017 03:03:52 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652BB129B8B for <6lo@ietf.org>; Wed, 11 Jan 2017 03:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2262; q=dns/txt; s=iport; t=1484132632; x=1485342232; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TIRXTPabNWKJ3qcXRnqNbInypnBWLBosAPwK2UlIaJo=; b=jGZBS2Fk/IpxpQqCOEFKbbEL7zv0j+rpcaV1/9AwoJNgvFP3udodvUF+ cR79S+tvB1hvNam/acHTkMU/tFCjVpobg/cvyTKmClxT6WBSs5RrNpOe/ MXLVqWY11+iWFEF4Uve66OEsx+VlUCXJ0i3svTDp2fBCBPdPW1FvEEJ9I s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQCyEHZY/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAR9fgQ0HjVCSEpUnggsfC4V4AoFuPxQBAgEBAQEBAQF?= =?us-ascii?q?jHQuEaQEBAQQBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIiHgOsk+KFQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GRYRhgwmHIwWVJoYEAYZaim+CAFGEO4liiBGKTwE?= =?us-ascii?q?fOIFBFRgihi9zh1mBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,345,1477958400"; d="scan'208";a="196281000" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2017 11:03:51 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v0BB3pQR011998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6lo@ietf.org>; Wed, 11 Jan 2017 11:03:51 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 05:03:50 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 11 Jan 2017 05:03:50 -0600 From: "Pascal Thubert (pthubert)" To: "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [6lo] I-D Action: draft-ietf-6lo-backbone-router-03.txt Thread-Index: AQHSa/n37YUmi5AgoEqg7jy3VrLDtaEzHApw Date: Wed, 11 Jan 2017 11:03:28 +0000 Deferred-Delivery: Wed, 11 Jan 2017 11:03:09 +0000 Message-ID: <130d2a8963d4420f8342b31f5b699cc1@XCH-RCD-001.cisco.com> References: <148413243925.10381.982476500477319211.idtracker@ietfa.amsl.com> In-Reply-To: <148413243925.10381.982476500477319211.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.174.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [6lo] I-D Action: draft-ietf-6lo-backbone-router-03.txt X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:03:54 -0000 Dear all: As discussed at the WG meeting, I now removed the text that is duplicate fr= om RFC6775-update now that the latted is adopted. Happy new year! Pascal -----Original Message----- From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of internet-drafts@ietf.o= rg Sent: mercredi 11 janvier 2017 12:01 To: i-d-announce@ietf.org Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-backbone-router-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 over Networks of Resource-constrained= Nodes of the IETF. Title : IPv6 Backbone Router Author : Pascal Thubert Filename : draft-ietf-6lo-backbone-router-03.txt Pages : 29 Date : 2017-01-11 Abstract: This specification proposes an update to IPv6 Neighbor Discovery, to enhance the operation of IPv6 over wireless links that exhibit lossy multicast support, and enable a large degree of scalability by splitting the broadcast domains. A higher speed backbone federates multiple wireless links to form a large MultiLink Subnet. Backbone Routers acting as Layer-3 Access Point route packets to registered nodes, where an classical Layer-2 Access Point would bridge. Conversely, wireless nodes register or are proxy-registered to the Backbone Router to setup routing services in a fashion that is essentially similar to a classical Layer-2 association. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6lo-backbone-router-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo From nobody Tue Jan 17 18:12:23 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC5412961C; Tue, 17 Jan 2017 18:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pIlKEuSDn5g; Tue, 17 Jan 2017 18:12:07 -0800 (PST) Received: from mail-pg0-x244.google.com (mail-pg0-x244.google.com [IPv6:2607:f8b0:400e:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB881294D2; Tue, 17 Jan 2017 18:12:07 -0800 (PST) Received: by mail-pg0-x244.google.com with SMTP id 194so9398319pgd.0; Tue, 17 Jan 2017 18:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:cc:to:date:mime-version:message-id; bh=3qrWaRS5Zi8qal3pJUkiz30sMQ27KWlCn6C16dOEytQ=; b=JJCbkLI7Wipgk0+W0ImQ7cq+MVWv0UL7QKEywmfvLFYsonAIRoe0dQtX76w+NvbeDo sfq9L1NelbledYwWrVFmsSSpFAhlblbS9u9hLebtalvF/NwpaCicEWfPCDvRjxdTECwq nx1OHtRacbo6aERmihDB3oQcoUsD36koeoZKbZMFdfYIJxFwaoaDL1kxVhpvlYBSXXAL t2UBSX+/yb9RgDoW11xtCtOhchzaT/2aa91cnhGmcOesavD4W4fAc64Mww5qJ3IFTYAr TmPgsPik7HNFN1CFfaDZq3XYzgSWar7RoV61AqnuPDfFNmymV9Wm/RYavGRM2uOCNzdo 98fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:cc:to:date:mime-version:message-id; bh=3qrWaRS5Zi8qal3pJUkiz30sMQ27KWlCn6C16dOEytQ=; b=ZOOzqJEgBS9+reNl8NkDqWtEXAgMUTlk+i+sniRNGAgyfRY2B2GRwycNfcAueyder0 GqulK6RJqQT+h3Wy8RvkYhInGOiYMCt4QMLdcZ5Ty9X1vuRft/0ze4F8RQDjc8fAILn5 aD4GAXtBXWa5oiF0XnR0kUXLzZcKVEAQZkQ5kltDd0TO/NDF0U/q5odaSB/8CNOtidLu LpoVC44prOZiWretl3JNkieOPBBYF1DQVzCKaIosI2tilHHY5mgkjFN03IHtjYO8Z4Xt RtvfQojsjzYkh1ePbKzyWZnPLAV95Ri3Yc/DcoXPGXECY9cdGzT96MGCruYQNf/PtDuf +Fuw== X-Gm-Message-State: AIkVDXKh1jbRNGv65D8IP6YzMAs2DhALwviJbBlaAX8XFsFNJIl6GPD9NAyVgaTrSyBa+g== X-Received: by 10.98.29.195 with SMTP id d186mr967378pfd.144.1484705527264; Tue, 17 Jan 2017 18:12:07 -0800 (PST) Received: from localhost ([219.134.130.45]) by smtp.gmail.com with ESMTPSA id f5sm58984963pgg.5.2017.01.17.18.12.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 18:12:06 -0800 (PST) From: Rahul Jadhav To: "lwip@ietf.org" Date: Wed, 18 Jan 2017 10:12:05 +0800 MIME-Version: 1.0 X-Priority: 3 Message-ID: <1484704724587.sgha3fnghga14kekwefmbyoh@android.mail.163.com> X-CUSTOM-MAIL-MASTER-SENT-ID: MailMasterAndroid-23363-1484705523063-671b4bf3-7f13-42ff-9c1c-41fa2e3457c2 Content-Type: multipart/alternative; boundary="__MESSAGE_BODY_PART__1" Archived-At: Cc: tisch <6tisch@ietf.org>, Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Subject: [6lo] Fw: New Version Notification for draft-jadhav-lwig-nbr-mgmt-policy-00.txt X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 02:12:10 -0000 --__MESSAGE_BODY_PART__1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 RGVhciBhbGwsIEFzIHByZXNlbnRlZCBpbiBpZXRmOTcsIHRoZSBkcmFmdCBoYXMgYmVlbiB1cGxv YWRlZC4gU2luY2UgdGhlIHRvcGljIGlzIHJlbGV2YW50IHRvIDZsbywgcm9sbCwgYW5kIDZ0aXNj aCwgaGF2ZSBtYXJrZWQgdGhlc2UgZ3JvdXBzIGluIGNjLiBUaGUgcG9saWN5IGRlc2NyaWJlcyB0 aGUgY29uc2lkZXJhdGlvbnMgZm9yIG1hbmFnaW5nIHRoZSBuZWlnaGJvciBjYWNoZSBlc3BlY2lh bGx5IGluIGEgc2NlbmFyaW8gd2hlcmUgbmV0d29yayBkZW5zaXR5IGlzIGxhcmdlciB0aGFuIHRo ZSBuZWlnaGJvciBjYWNoZSBzaXplLiBBbHNvIGRvY3VtZW50ZWQgaXMgdGhlIHNpZ25hbGluZyBp bnZvbHZlZCBmb3IgbmVpZ2hib3IgZW50cmllcyBjcmVhdGlvbi91cGRhdGlvbiBpbiBzdG9yaW5n IGFuZCBub24gc3RvcmluZyBtb2RlIHNpbmNlIHdoaWxlIGRyYWZ0aW5nIHRoaXMgdHVybmVkIG91 dCB0byBiZSBhbiBpbXBvcnRhbnQgcG9pbnQgdG8gYmUgbWVudGlvbmVkLiBGZWVkYmFjayB3ZWxj b21lLiBUaGFua3MsIFJhaHVsIC0tLS0tLS0tLcKgRm9yd2FyZGVkIG1haWzCoC0tLS0tLS0tLSBG cm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgRGF0ZTogMDEvMTgvMjAxNyAwOTo1MiBUbzog UmFodWwgQXJ2aW5kIEphZGhhdixTaW1vbiBEdXF1ZW5ub3ksSm9ha2ltIEVyaWtzc29uLEpBREhB ViBSQUhVTCxSYWJpIFNhaG9vLFJhYmkgTmFyYXlhbiBTYWhvbyBDYzogU3ViamVjdDogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qYWRoYXYtbHdpZy1uYnItbWdtdC1wb2xpY3kt MDAudHh0IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1qYWRoYXYtbHdpZy1uYnItbWdtdC1w b2xpY3ktMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFodWwgQXJ2 aW5kIEphZGhhdiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuIE5hbWU6wqAgwqAg wqDCoCDCoCDCoGRyYWZ0LWphZGhhdi1sd2lnLW5ici1tZ210LXBvbGljeSBSZXZpc2lvbjrCoCDC oCDCoDAwIFRpdGxlOsKgIMKgIMKgwqAgwqAgwqBOZWlnaGJvciBNYW5hZ2VtZW50IFBvbGljeSBm b3IgNkxvV1BBTiBEb2N1bWVudCBkYXRlOsKgIMKgIMKgMjAxNy0wMS0xNyBHcm91cDrCoCDCoCDC oMKgIMKgIMKgSW5kaXZpZHVhbCBTdWJtaXNzaW9uIFBhZ2VzOsKgIMKgIMKgwqAgwqAgwqAxNyBV Ukw6IMKgIMKgIMKgIMKgIMKgIMKgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWphZGhhdi1sd2lnLW5ici1tZ210LXBvbGljeS0wMC50eHQgU3RhdHVzOiDCoCDCoCDC oCDCoCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qYWRoYXYtbHdpZy1u YnItbWdtdC1wb2xpY3kvIEh0bWxpemVkOiDCoCDCoCDCoCBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtamFkaGF2LWx3aWctbmJyLW1nbXQtcG9saWN5LTAwIEFic3RyYWN0OiDCoCBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcHJvYmxlbXMgYXNzb2NpYXRlZCB3aXRoIG5laWdo Ym9yIGNhY2hlIMKgIG1hbmFnZW1lbnQgaW4gY29uc3RyYWluZWQgbXVsdGlob3AgbmV0d29ya3Mg YW5kIGEgc2FtcGxlIG5laWdoYm9yIMKgIG1hbmFnZW1lbnQgcG9saWN5IHRvIGRlYWwgd2l0aCBp dC4gwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqAgwqAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLiBUaGUgSUVURiBTZWNy ZXRhcmlhdA== --__MESSAGE_BODY_PART__1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0nbGluZS1oZWlnaHQ6MS40Jz5EZWFyIGFsbCwgPGJyLz48YnIvPkFzIHByZXNl bnRlZCBpbiBpZXRmOTcsIHRoZSBkcmFmdCBoYXMgYmVlbiB1cGxvYWRlZC4gU2luY2UgdGhlIHRv cGljIGlzIHJlbGV2YW50IHRvIDZsbywgcm9sbCwgYW5kIDZ0aXNjaCwgaGF2ZSBtYXJrZWQgdGhl c2UgZ3JvdXBzIGluICZuYnNwO2NjLjxici8+PGJyLz5UaGUgcG9saWN5IGRlc2NyaWJlcyB0aGUg Y29uc2lkZXJhdGlvbnMgZm9yIG1hbmFnaW5nIHRoZSBuZWlnaGJvciBjYWNoZSBlc3BlY2lhbGx5 IGluIGEgc2NlbmFyaW8gd2hlcmUgbmV0d29yayBkZW5zaXR5IGlzIGxhcmdlciB0aGFuIHRoZSBu ZWlnaGJvciBjYWNoZSBzaXplLiAmbmJzcDtBbHNvIGRvY3VtZW50ZWQgaXMgdGhlIHNpZ25hbGlu ZyBpbnZvbHZlZCBmb3IgbmVpZ2hib3IgZW50cmllcyBjcmVhdGlvbi91cGRhdGlvbiBpbiBzdG9y aW5nIGFuZCBub24gc3RvcmluZyBtb2RlIHNpbmNlIHdoaWxlIGRyYWZ0aW5nIHRoaXMgdHVybmVk IG91dCB0byBiZSBhbiBpbXBvcnRhbnQgcG9pbnQgdG8gYmUgbWVudGlvbmVkLjxici8+PGJyLz5G ZWVkYmFjayB3ZWxjb21lLjxici8+VGhhbmtzLDxici8+UmFodWw8YnIvPjxici8+PGJyLz48YnIv PjwvZGl2PjxkaXYgY2xhc3M9J25lLXF1b3RlZCc+PGJsb2NrcXVvdGUgaWQ9J250ZXMtYW5kcmlv ZG1haWwtcXVvdGUnIHN0eWxlPSJtYXJnaW46MHB4ICFpbXBvcnRhbnQ7cGFkZGluZzowcHggIWlt cG9ydGFudDtib3JkZXI6IG5vbmUgIWltcG9ydGFudDsiPjxkaXYgY2xhc3M9IkotY2MiIHN0eWxl PSJjb2xvcjpibGFjazttYXJnaW4tdG9wOjQ1cHg7bWFyZ2luLWJvdHRvbToxMHB4O2ZvbnQtc2l6 ZToxNHB4OyI+DQogICAgPHAgc3R5bGU9ImNvbG9yOiAjODE4NThhO21hcmdpbjogMHB4IDAgMTIu NXB4IDA7Zm9udC1zaXplOiAxNHB4O2xpbmUtaGVpZ2h0OiAxO2ZvbnQtZmFtaWx5OiAtYXBwbGUt c3lzdGVtLCBQaW5nRmFuZyBTQywgSGlyYWdpbm8gU2FucyBHQiwgTWljcm9zb2Z0IFlhaGVpLCBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWYgIWltcG9ydGFudDsiPi0tLS0tLS0tLcKgRm9yd2FyZGVkIG1h aWzCoC0tLS0tLS0tLTwvcD4NCiAgICA8ZGl2IHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiNmMmYy ZjI7cGFkZGluZy10b3A6NnB4O3BhZGRpbmctYm90dG9tOjZweDtib3JkZXItcmFkaXVzOjNweDst bW96LWJvcmRlci1yYWRpdXM6IDNweDstd2Via2l0LWJvcmRlci1yYWRpdXM6IDNweDttYXJnaW4t Ym90dG9tOjIwcHg7bWFyZ2luLXRvcDo0cHg7d29yZC1icmVhazpicmVhay1hbGw7Ij4NCiAgICAg ICAgPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTBweDttYXJnaW4tcmlnaHQ6MTBweCI+DQogICAg ICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXNpemU6MTRweDtsaW5lLWhlaWdodDoxLjU7Ij4NCiAg ICAgICAgICAgICAgICA8c3BhbiBzdHlsZT0iY29sb3I6IzhiOGQ5NCI+RnJvbTogPC9zcGFuPg0K ICAgICAgICAgICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojOGI4ZDk0Ij48YSBjbGFzcz0ibWFp bC1mcm9tIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzJhOTdmZjsiIGhyZWY9 Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZzwvYT48L3NwYW4+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXYgc3R5bGU9 ImZvbnQtc2l6ZToxNHB4O2xpbmUtaGVpZ2h0OjEuNTsiPg0KICAgICAgICAgICAgICAgIDxzcGFu IHN0eWxlPSJjb2xvcjojOGI4ZDk0Ij5EYXRlOiA8L3NwYW4+DQogICAgICAgICAgICAgICAgPHNw YW4gY2xhc3M9Im1haWwtZGF0ZSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4wMS8xOC8yMDE3IDA5OjUy PC9zcGFuPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250 LXNpemU6MTRweDtsaW5lLWhlaWdodDoxLjU7Ij4NCiAgICAgICAgICAgICAgICA8c3BhbiBzdHls ZT0iY29sb3I6IzhiOGQ5NCI+VG86IDwvc3Bhbj4NCiAgICAgICAgICAgICAgICA8c3BhbiBzdHls ZT0iY29sb3I6IzhiOGQ5NCI+PGEgY2xhc3M9Im1haWwtdG8iIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZTtjb2xvcjojMmE5N2ZmOyIgaHJlZj0ibWFpbHRvOnJhaHVsLmlldGZAZ21haWwuY29t Ij5SYWh1bCBBcnZpbmQgSmFkaGF2PC9hPiw8YSBjbGFzcz0ibWFpbC10byIgc3R5bGU9InRleHQt ZGVjb3JhdGlvbjpub25lO2NvbG9yOiMyYTk3ZmY7IiBocmVmPSJtYWlsdG86c2ltb24uZHVxdWVu bm95QGlucmlhLmZyIj5TaW1vbiBEdXF1ZW5ub3k8L2E+LDxhIGNsYXNzPSJtYWlsLXRvIiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzJhOTdmZjsiIGhyZWY9Im1haWx0bzpqb2Fr aW1lQHNpY3Muc2UiPkpvYWtpbSBFcmlrc3NvbjwvYT4sPGEgY2xhc3M9Im1haWwtdG8iIHN0eWxl PSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMmE5N2ZmOyIgaHJlZj0ibWFpbHRvOnJhaHVs LmlldGZAZ21haWwuY29tIj5KQURIQVYgUkFIVUw8L2E+LDxhIGNsYXNzPSJtYWlsLXRvIiBzdHls ZT0idGV4dC1kZWNvcmF0aW9uOm5vbmU7Y29sb3I6IzJhOTdmZjsiIGhyZWY9Im1haWx0bzpyYWJp bmFyYXlhbnNAaHVhd2VpLmNvbSI+UmFiaSBTYWhvbzwvYT4sPGEgY2xhc3M9Im1haWwtdG8iIHN0 eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMmE5N2ZmOyIgaHJlZj0ibWFpbHRvOnJh YmluYXJheWFuc0BodWF3ZWkuY29tIj5SYWJpIE5hcmF5YW4gU2Fob288L2E+PC9zcGFuPg0KICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2IHN0eWxlPSJmb250LXNpemU6MTRweDts aW5lLWhlaWdodDoxLjU7ZGlzcGxheTpub25lOyI+DQogICAgICAgICAgICAgICAgPHNwYW4gc3R5 bGU9ImNvbG9yOiM4YjhkOTQiPkNjOiA8L3NwYW4+DQogICAgICAgICAgICAgICAgPHNwYW4gc3R5 bGU9ImNvbG9yOiM4YjhkOTQiPjwvc3Bhbj4NCiAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAg ICAgPGRpdiBzdHlsZT0iZm9udC1zaXplOjE0cHg7bGluZS1oZWlnaHQ6MThweDsiPg0KICAgICAg ICAgICAgICAgIDxzcGFuIHN0eWxlPSJjb2xvcjojOGI4ZDk0Ij5TdWJqZWN0OiA8L3NwYW4+DQog ICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Im1haWwtc3ViamVjdCIgc3R5bGU9ImNvbG9yOmJs YWNrIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWphZGhhdi1sd2lnLW5ici1t Z210LXBvbGljeS0wMC50eHQ8L3NwYW4+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgPC9k aXY+DQogICAgPC9kaXY+DQo8L2Rpdj4NPGJyLz5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt amFkaGF2LWx3aWctbmJyLW1nbXQtcG9saWN5LTAwLnR4dA08YnIvPmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgUmFodWwgQXJ2aW5kIEphZGhhdiBhbmQgcG9zdGVkIHRvIHRoZQ08 YnIvPklFVEYgcmVwb3NpdG9yeS4NPGJyLz4NPGJyLz5OYW1lOiZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1qYWRoYXYtbHdpZy1uYnItbWdtdC1wb2xpY3kNPGJy Lz5SZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOzAwDTxici8+VGl0bGU6Jm5ic3A7ICZuYnNw OyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwO05laWdoYm9yIE1hbmFnZW1lbnQgUG9saWN5IGZv ciA2TG9XUEFODTxici8+RG9jdW1lbnQgZGF0ZTombmJzcDsgJm5ic3A7ICZuYnNwOzIwMTctMDEt MTcNPGJyLz5Hcm91cDombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7SW5k aXZpZHVhbCBTdWJtaXNzaW9uDTxici8+UGFnZXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsg Jm5ic3A7ICZuYnNwOzE3DTxici8+VVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1qYWRoYXYtbHdpZy1uYnItbWdtdC1wb2xpY3ktMDAudHh0Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtamFkaGF2LWx3aWctbmJyLW1nbXQtcG9saWN5LTAw LnR4dDwvYT4NPGJyLz5TdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qYWRoYXYtbHdpZy1uYnIt bWdtdC1wb2xpY3kvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qYWRo YXYtbHdpZy1uYnItbWdtdC1wb2xpY3kvPC9hPg08YnIvPkh0bWxpemVkOiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamFkaGF2 LWx3aWctbmJyLW1nbXQtcG9saWN5LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtamFkaGF2LWx3aWctbmJyLW1nbXQtcG9saWN5LTAwPC9hPg08YnIvPg08YnIvPg08YnIvPkFi c3RyYWN0Og08YnIvPiAmbmJzcDsgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHByb2JsZW1z IGFzc29jaWF0ZWQgd2l0aCBuZWlnaGJvciBjYWNoZQ08YnIvPiAmbmJzcDsgbWFuYWdlbWVudCBp biBjb25zdHJhaW5lZCBtdWx0aWhvcCBuZXR3b3JrcyBhbmQgYSBzYW1wbGUgbmVpZ2hib3INPGJy Lz4gJm5ic3A7IG1hbmFnZW1lbnQgcG9saWN5IHRvIGRlYWwgd2l0aCBpdC4NPGJyLz4NPGJyLz4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw Ow08YnIvPg08YnIvPg08YnIvPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NPGJyLz51bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg08 YnIvPg08YnIvPlRoZSBJRVRGIFNlY3JldGFyaWF0DTxici8+DTxici8+PC9ibG9ja3F1b3RlPjwv ZGl2Pg== --__MESSAGE_BODY_PART__1-- From nobody Tue Jan 17 23:10:48 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC3129507 for <6lo@ietfa.amsl.com>; Tue, 17 Jan 2017 23:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NApAjA80zU-O for <6lo@ietfa.amsl.com>; Tue, 17 Jan 2017 23:10:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49833129500 for <6lo@ietf.org>; Tue, 17 Jan 2017 23:10:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZA93839; Wed, 18 Jan 2017 07:10:42 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 07:10:41 +0000 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by nkgeml414-hub.china.huawei.com (10.98.56.75) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 18 Jan 2017 15:10:35 +0800 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.95]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 15:10:31 +0800 From: houjianqiang To: "yonggeun.hong@gmail.com" Thread-Topic: [6lo] Adoption call for 6lo Applicability and Usecases Thread-Index: AdJxOJMyBtaDlY7hSHKa11jrPUt0UAAFOiwg Date: Wed, 18 Jan 2017 07:10:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.134.224] Content-Type: multipart/alternative; boundary="_000_DD0A994E4D6B3F4080662703C8C7C0869F20EDDGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.587F14F2.00A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.95, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a840aac3c4cd1603729291300cb7c3cd Archived-At: Cc: "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6lo] Adoption call for 6lo Applicability and Usecases X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:10:47 -0000 --_000_DD0A994E4D6B3F4080662703C8C7C0869F20EDDGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yong-Geun, Your draft ietf-6lo-use-cases gives an elaborated text on applicable user s= cenarios for 6lo which is very helpful in industrial deployment. Other than= the technologies listed in current draft, I would suggest to include PLC (= Power Line Communication) as well. PLC uses electric power lines as the med= ium for indoor and outdoor communications and is a good candidate for suppo= rting Smart Grid, Advanced Metering Infrastructure (AMI) and Smart Street L= ighting. 6lo is applicable to it. We have some PLC based deployment. I am a= bout to write some text regarding this case and may send you in a separate = email if there is interest. Other editorial comments as follows. Thanks. Change some subsection titles 3.1. title: better use "Short Range Narrow-band Digital Radiocommunication"= or abbreviation 3.7. title: better use "Timeslotted Channer Hopping" or "TSCH" This subsection titles in section 3 are a bit confusing in that some are co= mmunication technologies while the others are names of standard protocols (= ITU-T G.9959, IEEE 802.15.4e). Unify the subtitle abbreviation 3.2. title: "Bluetooth Low Energy" =3D> "Bluetooth LE" 3.4. title: "Master-Slave/Token-Passing" =3D> "MS/TP" Unify the titles of subsections either in full names or in abbreviations. Best regards, Jianqiang HOU --_000_DD0A994E4D6B3F4080662703C8C7C0869F20EDDGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Y= ong-Geun,

 

Your= draft ietf-6lo-use-cases gives an elaborated text on applicable user scena= rios for 6lo which is very helpful in industrial deployment. Other than the= technologies listed in current draft, I would suggest to include PLC (Power Line Communication) as well. PLC use= s electric power lines as the medium for indoor and outdoor communications = and is a good candidate for supporting Smart Grid, Advanced Metering Infras= tructure (AMI) and Smart Street Lighting. 6lo is applicable to it. We have some PLC based deployment. I am= about to write some text regarding this case and may send you in a separat= e email if there is interest.

 

Othe= r editorial comments as follows. Thanks.

 

C= hange some subsection titles

3.1.= title: better use “Short Range Narrow-band Digital Radiocommunicatio= n” or abbreviation

3.7.= title: better use “Timeslotted Channer Hopping” or “TSCH= ”

This= subsection titles in section 3 are a bit confusing in that some are commun= ication technologies while the others are names of standard protocols (ITU-= T G.9959, IEEE 802.15.4e).

 

U= nify the subtitle abbreviation

3.2.= title: “Bluetooth Low Energy” =3D> “Bluetooth LE̶= 1;

3.4.= title: “Master-Slave/Token-Passing” =3D> “MS/TP”= ;

Unif= y the titles of subsections either in full names or in abbreviations.<= /o:p>

 

Best= regards,

Jian= qiang HOU

--_000_DD0A994E4D6B3F4080662703C8C7C0869F20EDDGGEMM506MBSchina_-- From nobody Wed Jan 18 16:27:10 2017 Return-Path: X-Original-To: 6lo@ietfa.amsl.com Delivered-To: 6lo@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77112941D for <6lo@ietfa.amsl.com>; Wed, 18 Jan 2017 16:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZEP9qfce9rz for <6lo@ietfa.amsl.com>; Wed, 18 Jan 2017 16:27:07 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978AE129400 for <6lo@ietf.org>; Wed, 18 Jan 2017 16:27:06 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id d140so1617680wmd.0 for <6lo@ietf.org>; Wed, 18 Jan 2017 16:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgpunhs7nsuGseL47iW5vhIZ2A/0tnoesc2F9517/nU=; b=fzDUqn0uRzxlTAj7+1Wm8ACxQ2DOhNUy0CXOvv77E8/G054e1TJydfAtVTky4rbq4l 3Zncre5zmZ7YDi8Zt9qN91TXghciOFEZERpIE2X4sdu4u71b6mUuTIpURP1UsRuotiS7 BY9MNUqG+xCtVip4lc6/P/J8THKGzelJ8gmMSeTmqYisXXHhLmj+DxhemvkXsE4IhPrW mMg86xi9opzp0eercQ4Ug2EUmP7Sx86NsX2k3N7R597+AhS9+b4yzThdLdc0FUWAE70c VTj0kMtMq08MfWw6x2EqoCOWTxICl0X8SNnT3q32gXSFeVKq1C9qP4dOwp6Q7slawJ/8 0eSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgpunhs7nsuGseL47iW5vhIZ2A/0tnoesc2F9517/nU=; b=Ez9HY882TfEE80tbl4B2lQStZv3hPluq96yp7xk7Er4tb3mTlG7YAZAPKNRwXFY7A5 hKmHScuERXcADVlUtp1Q5r9w8CjS8boz3OVCR7+v2Ujf7FuANPNb00Ib2ATXqf4TAvVK PPLWqUYa5FnZPcb098T2KhiuQu1fv0oS1399VnuWO8syf30j3jjHuHjWw88yHtzVIcxn IBi96Zr06pR6MywrBKvTRaykz6gTKaVKcukJg6rAKxJxkYApd1mdV1pUGVs1dvCN5VU9 yqF1XF3GRJP0DuDd0OWGFiLUcru1AFoWgZ+t5tRmQV9KuUtxMl0TB9rEPunmCQNWOpJg wk3g== X-Gm-Message-State: AIkVDXJRNjq2231R0Jd+TS/7QQvLRaoowccfZ04C5z1HAEAouqPrlmRrAGHMkuMXlN1ZrbNp5gWpuD2kVJQQ4A== X-Received: by 10.223.130.232 with SMTP id 95mr5986462wrc.34.1484785625045; Wed, 18 Jan 2017 16:27:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.46.77 with HTTP; Wed, 18 Jan 2017 16:27:04 -0800 (PST) In-Reply-To: References: From: YongGeun Hong Date: Thu, 19 Jan 2017 09:27:04 +0900 Message-ID: To: houjianqiang Content-Type: multipart/alternative; boundary=001a114b4254bfb49805466797d0 Archived-At: Cc: "6lo@ietf.org" <6lo@ietf.org> Subject: Re: [6lo] Adoption call for 6lo Applicability and Usecases X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:27:08 -0000 --001a114b4254bfb49805466797d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Jianqiang HOU. Thanks for your comments. See my response in line. Best regards. Yong-Geun. On Wed, Jan 18, 2017 at 4:10 PM, houjianqiang wrote: > Hi Yong-Geun, > > > > Your draft ietf-6lo-use-cases gives an elaborated text on applicable user > scenarios for 6lo which is very helpful in industrial deployment. Other > than the technologies listed in current draft, I would suggest to include > PLC (Power Line Communication) as well. PLC uses electric power lines as > the medium for indoor and outdoor communications and is a good candidate > for supporting Smart Grid, Advanced Metering Infrastructure (AMI) and Sma= rt > Street Lighting. 6lo is applicable to it. We have some PLC based > deployment. I am about to write some text regarding this case and may sen= d > you in a separate email if there is interest. > [Yong-Geun] Yes, I believe that the PLC is a candidate of 6lo technologies and there was an related internet draft of IPv6 over PLC(draft-popa-6lo-6loplc-ipv6-over-ieee19012-networks). And there were similar comments of yours from Take Aanstoot. I agree 6lo is applicable to it. If you suggests some relevant texts, it could be integrated. And then let's discuss further. > > > Other editorial comments as follows. Thanks. > > > > *Change some subsection titles * > > 3.1. title: better use =E2=80=9CShort Range Narrow-band Digital > Radiocommunication=E2=80=9D or abbreviation > > 3.7. title: better use =E2=80=9CTimeslotted Channer Hopping=E2=80=9D or = =E2=80=9CTSCH=E2=80=9D > > This subsection titles in section 3 are a bit confusing in that some are > communication technologies while the others are names of standard protoco= ls > (ITU-T G.9959, IEEE 802.15.4e). > > > > *Unify the subtitle abbreviation* > > 3.2. title: =E2=80=9CBluetooth Low Energy=E2=80=9D =3D> =E2=80=9CBluetoot= h LE=E2=80=9D > > 3.4. title: =E2=80=9CMaster-Slave/Token-Passing=E2=80=9D =3D> =E2=80=9CMS= /TP=E2=80=9D > > Unify the titles of subsections either in full names or in abbreviations. > [Yong-Geun] Thanks. I will reflect your comments in a next revision. > > > Best regards, > > Jianqiang HOU > --001a114b4254bfb49805466797d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Jianqiang HOU.

Thanks for you= r comments.

See my response in line.
Best regards.

Yong-Geun.

On Wed, Jan 18, 2017 at 4= :10 PM, houjianqiang <houjianqiang@huawei.com> wrote:<= br>

Hi Yon= g-Geun,

=C2=A0

Your d= raft ietf-6lo-use-cases gives an elaborated text on applicable user scenari= os for 6lo which is very helpful in industrial deployment. Other than the t= echnologies listed in current draft, I would suggest to include PLC (Power Line Communication) as well. PLC use= s electric power lines as the medium for indoor and outdoor communications = and is a good candidate for supporting Smart Grid, Advanced Metering Infras= tructure (AMI) and Smart Street Lighting. 6lo is applicable to it. We have some PLC based deployment. I am= about to write some text regarding this case and may send you in a separat= e email if there is interest.


<= /div>
[Yong-Geun] Yes, I believe that the PLC is a candidate of 6lo tec= hnologies and there was an related internet draft of IPv6 over PLC(draft-po= pa-6lo-6loplc-ipv6-over-ieee19012-networks).=C2=A0And there were similar co= mments of yours from Take Aanstoot. I agree 6lo is applicable to it. If you= suggests some relevant texts, it could be integrated. And then let's d= iscuss further.=C2=A0

<= /u>

=C2=A0

Other = editorial comments as follows. Thanks.

=C2=A0

Cha= nge some subsection titles

3.1. t= itle: better use =E2=80=9CShort Range Narrow-band Digital Radiocommunicatio= n=E2=80=9D or abbreviation

3.7. t= itle: better use =E2=80=9CTimeslotted Channer Hopping=E2=80=9D or =E2=80=9C= TSCH=E2=80=9D

This s= ubsection titles in section 3 are a bit confusing in that some are communic= ation technologies while the others are names of standard protocols (ITU-T = G.9959, IEEE 802.15.4e).

=C2=A0

Uni= fy the subtitle abbreviation

3.2. t= itle: =E2=80=9CBluetooth Low Energy=E2=80=9D =3D> =E2=80=9CBluetooth LE= =E2=80=9D

3.4. t= itle: =E2=80=9CMaster-Slave/Token-Passing=E2=80=9D =3D> =E2=80=9CMS/TP= =E2=80=9D

Unify = the titles of subsections either in full names or in abbreviations.<= /p>


[Yong-Geun] Thanks. I will = reflect your comments in a next revision.
=C2=A0

=C2=A0

Best r= egards,

Jianqi= ang HOU


--001a114b4254bfb49805466797d0-- From nobody Fri Jan 27 11:16:12 2017 Return-Path: X-Original-To: 6lo@ietf.org Delivered-To: 6lo@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2D3129784; Fri, 27 Jan 2017 11:16:10 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148554457003.17931.7551230491594685776.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2017 11:16:10 -0800 Archived-At: Cc: 6lo-chairs@ietf.org, draft-ietf-6lo-dect-ule@ietf.org, Samita Chakrabarti , suresh.krishnan@ericsson.com, The IESG , 6lo@ietf.org, rfc-editor@rfc-editor.org Subject: [6lo] Protocol Action: 'Transmission of IPv6 Packets over DECT Ultra Low Energy' to Proposed Standard (draft-ietf-6lo-dect-ule-09.txt) X-BeenThere: 6lo@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 19:16:10 -0000 The IESG has approved the following document: - 'Transmission of IPv6 Packets over DECT Ultra Low Energy' (draft-ietf-6lo-dect-ule-09.txt) as Proposed Standard This document is the product of the IPv6 over Networks of Resource-constrained Nodes Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-dect-ule/ Technical Summary The DECT Ultra Low Energy is an addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE such as for Internet of Things applications. As an example, the technology could be integrated with residential gateway. DECT-ULE deployment typically use application profile based protocol support and 6lo-over-dect-ule is one of them. The differences between 6loWPAN(IPv6-over-IEEE802.15.4) and this specification are that DECT-ULE only supports Star topology, a 40-bit unique ID among DECT devices, optional MAC-48 bit assignment, larger MTU size than IEEE802.15.4 and thus different requirements for fragmentation and re-assembly. The document also shows a mechansim for deriving the 64-bit IID in order to form an IPv6 address and subsets of RFC6775, Header compression. The draft discusses privacy considerations and possible randomly generated IID support. Working Group Summary The document has been reviewed by several WG participants and the co-chairs. There were no contentious issues raised on the current version. Document Quality The document has been reviewed over the 6lo WG mailing list (Kerry Lynn, Ralph Droms, Samita Chakrabarti, Gabriel Montenegro) and the comments were addressed. A critical comment for the document was to remove reference of globally unique 64-bit IID when it is derived from 40bit DECT unique id, which was taken care in version 05. The chairs have been informed that RTX and Gigaset have implementations on the draft. An open source implementation might be available via ULE alliance. Personnel Samita Chakrabarti is the Document shepherd Suresh Krishnan is the Responsible Area Director