From nobody Mon Feb 1 23:50:17 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14FB1A037C for ; Mon, 1 Feb 2016 23:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.992 X-Spam-Level: X-Spam-Status: No, score=0.992 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 wJDqkr5iEfxn for ; Mon, 1 Feb 2016 23:49:37 -0800 (PST) Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.70]) by ietfa.amsl.com (Postfix) with SMTP id 465451A0015 for ; Mon, 1 Feb 2016 23:49:35 -0800 (PST) Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (Postfix) with ESMTP id 0DA7FAE0186; Tue, 2 Feb 2016 13:16:58 +0530 (IST) Received: from [10.32.14.64] ([10.32.14.64]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id u127pcop031134; Tue, 2 Feb 2016 13:21:39 +0530 To: "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> References: From: "S.V.R.Anand" Message-ID: <56B05F84.3080702@ece.iisc.ernet.in> Date: Tue, 2 Feb 2016 13:19:24 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080504030900070208070406" X-IISc-MailScanner-Information: Please contact nethelp@serc.iisc.in for more information X-IISc-MailScanner-ID: 0DA7FAE0186.AF0BB X-IISc-MailScanner: Found to be clean X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.818, required 6.5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, HTML_MESSAGE 0.00, NO_RDNS2 0.01, RP_MATCHES_RCVD -0.43, SMILEY -0.50) X-IISc-MailScanner-From: anand@ece.iisc.ernet.in MailScanner-NULL-Check: 1455004019.01456@NGradhorAZJJwOWwNYz4sw Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 07:49:41 -0000 This is a multi-part message in MIME format. --------------080504030900070208070406 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Pascal, Thanks a lot for your response and for all the references. Please see my=20 response in line. On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthubert) wrote: > > Hello Anand: > > > > Thanks for this, please see below: > > > Having= =20 a symmetric path, in principle, certainly offers advantages when we want=20 > the communicating nodes to use a well-defined path that has been set=20 up to meet > the QoS requirements of an application. Such a pinned path=20 can be appropriately > provisioned with required bandwidth resources=20 along the entire path. > > > > =D8 True but in radios, the links may be=20 very asymmetrical, and the optimal return path may be very different. >=20 > =D8 So the pinned-down return path may be different actually. > Surely the presence of uni-directional routes cannot be ignored. Some of = the dominating factors like, routing overheads, route and resource state maintenance on the nodes and the associated scalability issues,=20 implementation complexity, and so on, will prompt network designers to deploy networks w= ith reliable bi-directional links and routes. Because of the factors listed=20 here, one would like to ensure absence of bi-directional routes will be more of= an exception rather than a norm. No ? > > > I found the P2P RPL very appropriate for the current discussion.=20 What is > interesting is that the Bidirectional Route presented here=20 actually enables > creating a symmetric path between end nodes by=20 passing on the complete path > information in its signaling messages. In=20 this process, routing state is > installed along the path. > > > > =D8 I= =20 hope that we start new on-demand work for RPL, based on this and AODV.=20 It may be that the route is optimized for metrics that are mostly=20 directional, one way or the other, if the traffic is so. Ideally we=19d=20 build and associated 2 DODAGs, one for each direction. This is discussed=20 in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00 > Thanks for the draft! Would be happy to be part of the new work you are=20 proposing :) > > > As you noted, keeping signaling separate from data is certainly an= =20 elegant way. > > There can however be contexts when in-band signaling=20 that uses RH3 as per > RFC6554 data can be more efficient than using a=20 signaling protocol, assuming > the security concerns are addressed as=20 per RFC2460. This in-band approach is > attractive when we want to set=20 up a rapid on-the-fly symmetric path along with > 6TiSCH OTF making=20 bandwidth reservation along the way for transactional message >=20 exchanges. I am hinting at the possible PCE/NME based solution that (i)=20 works > with the RPL DODAG, (ii) considers the hop distance between the=20 communicating > node to assess energy costs, (iii) optimizes network=20 resource availability, and > finally provides right inputs for the=20 nodes. It may well be that dropping the > address is the right choice. >=20 > > > =D8 I can agree with that, and I used that sort of method in=20 https://tools.ietf.org/html/draft-thubert-tree-discovery > > Thanks again! Started reading it. Looks like we are revisiting concepts=20 already developed many years back. > > > I think I am doing too much of hand waving going on by leaving out= =20 all the > essential details. Hope I managed to vaguely convey the point.=20 > > I tend to feel that distributed, centralized and their combination=20 might > co-exist to optimize network resources, and therefore retaining=20 or dropping the > address in RH3-6LoRH can be made optional. > > > > > >=20 =D8 Could be, but should we do it now or when we have the actual need? >= =20 > =D8 Do you have a design in mind that limits the implementation=20 overhead of supporting both? > At the rick of sounding naive, can't the option of dropping or retaining=20 address be indicated by a bit ? > > > Am I making sense ? > > > > > > =D8 To me, certainly J > Anand > > > Anand > > > > > On Saturday 23 January 2016 02:34 PM, Pascal=20 Thubert (pthubert) wrote: > > > > > Hello Anand: > > > > > > > > > > > >=20 2 good points , that we need to continue in different threads if we do.=20 > > > > > > > > > The source routing optimization done by dropping the=20 addresses on the way > > > certainly has benefits. However, there could=20 be loss of a natural "symmetric" > > > property that one might want to=20 enforce between communicating end nodes in the > > > routing path. By=20 symmetry I mean using the same path in both the directions of > > >=20 communication. Policy based routing, centralized routing, for instance,=20 could > > > be potential users of this property. May be this does not=20 represent a common > > > use case. But nevertheless, we have to be aware=20 of this side effect which RFC6554 > > > swapping process does not have.=20 > > > > > > > > > > > > =D8 Pascal: Yes, Simon made that point=20 yesterday. > > > > > > =D8 It is generally not a good idea to reverse a=20 routing header. The RH may have been used to stay away from the shortest=20 path for some reason that is only valid on the way in (segment routing).=20 > > > > > > =D8 P2P RPL reverses a path that is learnt reactively, so w= e=20 have a real protocol for doing that sort of thing as opposed to an echo.=20 > > > > > > =D8 Reversing a header is discouraged by RFC 2460 (for RH0)= =20 unless it is authenticated (which means AH). We do not authenticate the=20 RH3, there are a number of reasons for that, general deprecation of AH,=20 no use of AH in LLNs etc& Note that AH does not protect the RH on the=20 way, it is just a validation at the receiver for the sole value of=20 reversing it. > > > > > > =D8 A RPL domain is usually protected by L2=20 security and that secures both RPL itself and the RH in packets, at=20 every hop > > > > > > =D8 The benefit of saving energy and lowering the=20 chances of loss are seen as overwhelming compared to the value of=20 possibly reversing the header > > > > > > =D8 Yet we might define a=20 variation where we do not pop out the first entry as we go. I do not see=20 a consensus on the value of doing it now. > > > > > > > > > > > > > > >=20 > > > Going further, the DAO projection proposal > > >=20 (draft-thubert-roll-dao-projection-02.txt) will have several virtual=20 roots > > > inside the RPL domain. The automatic assumption of a well=20 known root may not apply > > > when nodes within RPL domain communicate=20 with each other. I suppose it will > > > have a bearing on the RH3-6LoRH=20 performance. > > > > > > > > > > > > =D8 It is not really an assumption,= =20 but something we leverage as we go. The RPI is very much like a context=20 indicator. If an address shares a lon prefix with a root, adding the RPI=20 of that root is actually a compression technique. > > > > > > > > > > >=20 > The above observations are not serious, but feels good to ponder=20 over. Will be > > > happy to receive your comments. > > > > > > Thanks=20 Anand! > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > >=20 > On Monday 18 January 2016 11:24 PM, Pascal Thubert (pthubert) wrote:=20 > > > > > > > > > > > Dear all > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > The picture below illustrates how the RH3 6LoRH works=20 with draft 03 in a case like Root -> A -> B -> C -> leaf > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The=20 first 6LoRH is expected to be a full address (128 bits) to set up a=20 reference and the next 6LoRH are expected to be smaller and just=20 override the rightmost bits which form the delta from the reference. > >=20 > > > > > > > > > > > > > > > > > > > > > > > > > > Proposal: we could=20 consider that the 128bits source of the IP header before the RH3 is the=20 reference to start with. > > > > > > > > > > > > > > > > > > > > > > > >=20 > > > > With that even the first hop could be compressed the same way=20 as the other hops. With RPL, the root is the encapsulator if IP in IP in=20 used. Good thing, in that case the root is totally elided with the=20 IP-in-IP 6LoRH. > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 So this simple proposal saves up to 16 octets (thats in the case with a=20 single subnet and all addresses differ only by the last 2 bytes). Im=20 willing to add it in the next revision. > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > Any opposition? > > > > > > > > > > > > > > > >=20 > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > >=20 > > > > > > > > -- > > > > > > > This message has been scanned for=20 viruses and > > > > > > > dangerous content by MailScanner, and is > > >=20 > > > > believed to be clean. > > > > > > > > > > > > > >=20 _______________________________________________ > > > > > > > 6tisch=20 mailing list > > > > > > > 6tisch@ietf.org > > > > > > >=20 https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > --=20 > > > This message has been scanned for viruses and > > > dangerous=20 content by MailScanner, and is > > > believed to be clean. > > > > > > >=20 > > _______________________________________________ > > > 6tisch=20 mailing list > > > 6tisch@ietf.org > > >=20 https://www.ietf.org/mailman/listinfo/6tisch > > > -- > This message has=20 been scanned for viruses and > dangerous content by MailScanner, and is=20 > believed to be clean. --------------080504030900070208070406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Pascal,

Thanks a lot for your response and for all the references. Please see my response in line.

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthubert) wrote:<= br> > > Hello Anand: > >=A0=20 > > Thanks for this, please see below: > > > Having a symmetric path, in principle, certainly offers advantages w= hen we want > the communicating nodes to use a well-defined path that has been set= up to meet > the QoS requirements of an application. Such a pinned path can be ap= propriately > provisioned with required bandwidth resources along the entire path. > >=A0=20 > > =D8=A0 True but in radios, the links may be very asymmetrical, and t= he optimal return path may be very different. > > =D8=A0 So the pinned-down return path may be different actually. >

Surely the presence of uni-directional routes cannot be ignored. Some of the
dominating factors like, routing overheads, route and resource state<= br> maintenance on the nodes and the associated scalability issues, implementation
complexity, and so on, will prompt network designers to deploy networks with
reliable bi-directional links and routes. Because of the factors listed here,
one would like to ensure absence of bi-directional routes will be more of an
exception rather than a norm. No ?


>=A0=20 > > I found the P2P RPL very appropriate for the current discussion. Wha= t is > interesting is that the Bidirectional Route presented here actually = enables > creating a symmetric path between end nodes by passing on the comple= te path > information in its signaling messages. In this process, routing stat= e is > installed along the path. > >=A0=20 > > =D8=A0 I hope that we start new on-demand work for RPL, based on thi= s and AODV. It may be that the route is optimized for metrics that are mo= stly directional, one way or the other, if the traffic is so. Ideally we=19= d build and associated 2 DODAGs, one for each direction. This is discusse= d in https://tools.ietf.org/html/draft-thub= ert-roll-asymlink-00 >

Thanks for the draft! Would be happy to be part of the new work you are proposing :)

> > > As you noted, keeping signaling separate from data is certainly an e= legant way. > > There can however be contexts when in-band signaling that uses RH3 a= s per > RFC6554 data can be more efficient than using a signaling protocol, = assuming > the security concerns are addressed as per RFC2460. This in-band app= roach is > attractive when we want to set up a rapid on-the-fly symmetric path = along with > 6TiSCH OTF making bandwidth reservation along the way for transactio= nal message > exchanges. I am hinting at the possible PCE/NME based solution that = (i) works > with the RPL DODAG, (ii) considers the hop distance between the comm= unicating > node to assess energy costs, (iii) optimizes network resource availa= bility, and > finally provides right inputs for the nodes. It may well be that dro= pping the > address is the right choice. > >=A0=20 > > =D8=A0 I can agree with that, and I used that sort of method in https://tools.ietf.org/html/draft-thubert-tree-di= scovery > >=A0

Thanks again! Started reading it. Looks like we are=A0 revisiting concepts already developed many years back.

> > > I think I am doing too much of hand waving going on by leaving out a= ll the > essential details. Hope I managed to vaguely convey the point. > > I tend to feel that distributed, centralized and their combination m= ight > co-exist to optimize network resources, and therefore retaining or d= ropping the > address in RH3-6LoRH can be made optional. > >=A0=20 > >=A0=20 > > =D8=A0 Could be, but should we do it now or when we have the actual = need? > > =D8=A0 Do you have a design in mind that limits the implementation o= verhead of supporting both? >

At the rick of sounding naive, can't the option of dropping or retaining address be indicated by a bit ?

> > > Am I making sense ? > >=A0=20 > >=A0=20 > > =D8=A0 To me, certainly J >

Anand

> > > Anand > > > > > On Saturday 23 January 2016 02:34 PM, Pascal Thubert (pthubert) wrot= e: > > > > > Hello Anand: > > >=20 > > >=20 > > >=20 > > > 2 good points , that we need to continue in different threads i= f we do. > > >=20 > > >=20 > > > The source routing optimization done by dropping the addresses = on the way > > > certainly has benefits. However, there could be loss of a natur= al "symmetric" > > > property that one might want to enforce between communicating e= nd nodes in the > > > routing path. By symmetry I mean using the same path in both th= e directions of > > > communication. Policy based routing, centralized routing, for i= nstance, could > > > be potential users of this property. May be this does not repre= sent a common > > > use case. But nevertheless, we have to be aware of this side ef= fect which RFC6554 > > > swapping process does not have. > > >=20 > > >=20 > > >=20 > > > =D8=A0 Pascal: Yes, Simon made that point yesterday. > > >=20 > > > =D8=A0 It is generally not a good idea to reverse a routing hea= der. The RH may have been used to stay away from the shortest path for so= me reason that is only valid on the way in (segment routing). > > >=20 > > > =D8=A0 P2P RPL reverses a path that is learnt reactively, so we= have a real protocol for doing that sort of thing as opposed to an echo. > > >=20 > > > =D8=A0 Reversing a header is discouraged by RFC 2460 (for RH0) = unless it is authenticated (which means AH). We do not authenticate the R= H3, there are a number of reasons for that, general deprecation of AH, no= use of AH in LLNs etc& Note that AH does not protect the RH on the w= ay, it is just a validation at the receiver for the sole value of reversi= ng it. > > >=20 > > > =D8=A0 A RPL domain is usually protected by L2 security and tha= t secures both RPL itself and the RH in packets, at every hop > > >=20 > > > =D8=A0 The benefit of saving energy and lowering the chances of= loss are seen as overwhelming compared to the value of possibly reversin= g the header > > >=20 > > > =D8=A0 Yet we might define a variation where we do not pop out = the first entry as we go. I do not see a consensus on the value of doing = it now. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > Going further, the DAO projection proposal > > > (draft-thubert-roll-dao-projection-02.txt) will have several vi= rtual roots > > > inside the RPL domain. The automatic assumption of a well known= root may not apply > > > when nodes within RPL domain communicate with each other. I sup= pose it will > > > have a bearing on the RH3-6LoRH performance. > > >=20 > > >=20 > > >=20 > > > =D8=A0 It is not really an assumption, but something we leverag= e as we go. The RPI is very much like a context indicator. If an address = shares a lon prefix with a root, adding the RPI of that root is actually = a compression technique. > > >=20 > > >=20 > > >=20 > > > The above observations are not serious, but feels good to ponde= r over. Will be > > > happy to receive your comments. > > >=20 > > > Thanks Anand! > > >=20 > > >=20 > > >=20 > > > Pascal > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > On Monday 18 January 2016 11:24 PM, Pascal Thubert (pthubert) w= rote: > > > > > > >=20 > > > > Dear all > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > The picture below illustrates how the RH3 6LoRH works with= draft 03 in a case like Root -> A -> B -> C -> leaf > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > The first 6LoRH is expected to be a full address (128 bits= ) to set up a reference and the next 6LoRH are expected to be smaller and= just override the rightmost bits which form the delta from the reference= . > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > Proposal: we could consider that the 128bits source of the= IP header before the RH3 is the reference to start with. > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > With that even the first hop could be compressed the same = way as the other hops. With RPL, the root is the encapsulator if IP in IP= in used. Good thing, in that case the root is totally elided with the IP= -in-IP 6LoRH. > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > So this simple proposal saves up to 16 octets (thats in th= e case with a single subnet and all addresses differ only by the last 2 b= ytes). Im willing to add it in the next revision. > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > Any opposition? > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > Pascal > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > -- > > >=20 > > > > This message has been scanned for viruses and > > >=20 > > > > dangerous content by MailScanner, and is > > >=20 > > > > believed to be clean. > > >=20 > > > > > > >=20 > > > > _______________________________________________ > > >=20 > > > > 6tisch mailing list > > >=20 > > > > 6tisch@ietf.org > > >=20 > > > > https://www.ietf.org/mailman/listinfo/6tis= ch > > >=20 > > >=20 > > >=20 > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > >=20 > > >=20 > > > _______________________________________________ > > > 6tisch mailing list > > > 6tisch@ietf.org > > > https://www.ietf.org/mailman/listinfo/6tisch > > > --=20 > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.


--------------080504030900070208070406-- From nobody Tue Feb 2 22:22:23 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6991A6EDB; Tue, 2 Feb 2016 22:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 cMradbfnYF0k; Tue, 2 Feb 2016 22:22:15 -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 F2CA41A3BA3; Tue, 2 Feb 2016 22:22:13 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHW66990; Wed, 03 Feb 2016 06:22:10 +0000 (GMT) Received: from SZXEMI402-HUB.china.huawei.com (10.82.75.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 3 Feb 2016 06:22:09 +0000 Received: from SZXEMI507-MBS.china.huawei.com ([169.254.7.22]) by SZXEMI402-HUB.china.huawei.com ([10.83.65.54]) with mapi id 14.03.0235.001; Wed, 3 Feb 2016 14:22:04 +0800 From: "Satish Anamalamudi (Satish Anamalamudi)" To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) Thread-Index: AQHRXY5jBA/HX/YM9060aibxpZBvU58Z2Tbw Date: Wed, 3 Feb 2016 06:22:03 +0000 Message-ID: References: <56B05F84.3080702@ece.iisc.ernet.in> In-Reply-To: <56B05F84.3080702@ece.iisc.ernet.in> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.154.175] Content-Type: multipart/alternative; boundary="_000_BC1182E86737A7438C540E3B93DB7E518BD5B2SZXEMI507MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.56B19C93.0125, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.22, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5cea5fdf7b0c4a87907645dd8219c616 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:22:21 -0000 --_000_BC1182E86737A7438C540E3B93DB7E518BD5B2SZXEMI507MBSchina_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGksDQoNCj4gPiBJIGZvdW5kIHRoZSBQMlAgUlBMIHZlcnkgYXBwcm9wcmlhdGUgZm9yIHRoZSBj dXJyZW50IGRpc2N1c3Npb24uIFdoYXQgaXMNCj4gPiBpbnRlcmVzdGluZyBpcyB0aGF0IHRoZSBC aWRpcmVjdGlvbmFsIFJvdXRlIHByZXNlbnRlZCBoZXJlIGFjdHVhbGx5IGVuYWJsZXMNCj4gPiBj cmVhdGluZyBhIHN5bW1ldHJpYyBwYXRoIGJldHdlZW4gZW5kIG5vZGVzIGJ5IHBhc3Npbmcgb24g dGhlIGNvbXBsZXRlIHBhdGgNCj4gPiBpbmZvcm1hdGlvbiBpbiBpdHMgc2lnbmFsaW5nIG1lc3Nh Z2VzLiBJbiB0aGlzIHByb2Nlc3MsIHJvdXRpbmcgc3RhdGUgaXMNCj4gPiBpbnN0YWxsZWQgYWxv bmcgdGhlIHBhdGguDQo+ID4NCj4gPg0KPiA+DQo+ID4gqKogIEkgaG9wZSB0aGF0IHdlIHN0YXJ0 IG5ldyBvbi1kZW1hbmQgd29yayBmb3IgUlBMLCBiYXNlZCBvbiB0aGlzIGFuZCBBT0RWLiBJdCBt YXkgYmUgdGhhdCB0aGUgcm91dGUgaXMgb3B0aW1pemVkIGZvciBtZXRyaWNzIHRoYXQgYXJlIG1v c3RseSBkaXJlY3Rpb25hbCwgb25lIHdheSBvciB0aGUgb3RoZXIsIGlmIHRoZSB0cmFmZmljIGlz IHNvLiBJZGVhbGx5IHdlZCBidWlsZCBhbmQgYXNzb2NpYXRlZCAyIERPREFHcywgb25lIGZvciBl YWNoIGRpcmVjdGlvbi4gVGhpcyBpcyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMA0KPiA+DQo+DQo+IFRoYW5rcyBm b3IgdGhlIGRyYWZ0ISBXb3VsZCBiZSBoYXBweSB0byBiZSBwYXJ0IG9mIHRoZSBuZXcgd29yayB5 b3UgYXJlIHByb3Bvc2luZyA6KQ0KDQpXaGVuIHdlIGNyZWF0ZSAyIERPREFHcyBmb3IgYXN5bW1l dHJpY2FsIGxpbmtzLCB0d28gRElPIG1lc3NhZ2VzIGFyZSBnZW5lcmF0ZWQ6ICBvbmUgZnJvbSBz b3VyY2UgdG8gZGVzdGluYXRpb24gKGluc3RhbmNlLTEpIGFuZCB0aGUgb3RoZXIgZnJvbSBkZXN0 aW5hdGlvbiB0byBzb3VyY2UgKGluc3RhbmNlLTIpLiBTbywgdGhlcmUgd29uoa90IGJlIGFueSBE QU8gb3IgUkRPIG1lc3NhZ2VzIGluIFAyUC1SUEwgYmFzZWQgb24gYXN5bW1ldHJpYyBsaW5rcy4g QW0gSSBjb3JyZWN0Pw0KDQpJbiBQMlAtUlBMLCChrkFkZHJlc3OhryB2ZWN0b3IgaXMgY3JlYXRl ZCBieSB0aGUgc291cmNlIGR1cmluZyBESU8tUkRPIG11bHRpY2FzdCBmb3IgYm90aCBob3AtYnkt aG9wIHJvdXRpbmcgKG5vbi1zdG9yaW5nIG1vZGUpIGFuZCBzb3VyY2Ugcm91dGluZyAoc3Rvcmlu ZyBtb2RlKS4gRm9yIGFzeW1tZXRyaWMtbGluayBiYXNlZCBQMlAtUlBMLCBvbmUgoa5BZGRyZXNz oa8gdmVjdG9yIChESU8tUkRPKSBpcyBjcmVhdGVkIGJ5IHNvdXJjZSBmb3IgSW5zdGFuY2UtMSB0 byBkaXNjb3ZlciBwYXRoIGZyb20gZGVzdGluYXRpb24gdG8gc291cmNlIGFuZCB0aGUgb3RoZXIg b25lIG5lZWRzIHRvIGJlIGNyZWF0ZWQgYnkgZGVzdGluYXRpb24gdG8gZGlzY292ZXIgcGF0aCBm cm9tIHNvdXJjZSB0byBkZXN0aW5hdGlvbi4gSWYgdGhpcyBpcyB0byBiZSB0aGUgcHJvcG9zaW5n IG9wZXJhdGlvbnMgZm9yIGFzeW1tZXRyaWNhbCBQMlAtUlBMLCB0aGVuIHRoZXJlIHdvdWxkIGJl IHR3byByb3VuZHMgb2YgbXVsdGljYXN0IGNvbXBhcmVkIHRvIGp1c3Qgb25lIHJvdW5kIGluIHRo ZSB0cmFkaXRpb25hbCBQMlAtUlBMLiBJdCBpcyBkZXNpcmFibGUgaWYgd2UgY2FuIHJlbW92ZSB0 aGUgoa5BZGRyZXNzoa8gdmVjdG9yIGZyb20gdGhlIG11bHRpY2FzdCBESU8tUkRPIGZvciBhc3lt bWV0cmljLWxpbmsgYmFzZWQgUDJQLVJQTChlc3BlY2lhbGx5IGZvciBob3AtYnktaG9wIHJvdXRp bmcpLg0KDQpXaXRoIFJlZ2FyZHMsDQpTYXRpc2guDQoNCg0KRnJvbTogUm9sbCBbbWFpbHRvOnJv bGwtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFMuVi5SLkFuYW5kDQpTZW50OiAyMDE2 0rQy6sUy7O0gMTU6NDkNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyA2bG9AaWV0Zi5v cmcNCkNjOiA2dGlzY2hAaWV0Zi5vcmc7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5 IG5ldHdvcmtzDQpTdWJqZWN0OiBSZTogW1JvbGxdIE9uIDZMb1JIIGlzc3VlICMxMSAod2FzIFBy b3Bvc2VkIGltcHJvdmVtZW50IGluIFJIMy02TG9SSC4uLikNCg0KSGkgUGFzY2FsLA0KDQpUaGFu a3MgYSBsb3QgZm9yIHlvdXIgcmVzcG9uc2UgYW5kIGZvciBhbGwgdGhlIHJlZmVyZW5jZXMuIFBs ZWFzZSBzZWUgbXkgcmVzcG9uc2UgaW4gbGluZS4NCg0KT24gU3VuZGF5IDMxIEphbnVhcnkgMjAx NiAwMzowNSBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4NCj4gSGVsbG8g QW5hbmQ6DQo+DQo+DQo+DQo+IFRoYW5rcyBmb3IgdGhpcywgcGxlYXNlIHNlZSBiZWxvdzoNCj4N Cj4NCj4gSGF2aW5nIGEgc3ltbWV0cmljIHBhdGgsIGluIHByaW5jaXBsZSwgY2VydGFpbmx5IG9m ZmVycyBhZHZhbnRhZ2VzIHdoZW4gd2Ugd2FudA0KPiB0aGUgY29tbXVuaWNhdGluZyBub2RlcyB0 byB1c2UgYSB3ZWxsLWRlZmluZWQgcGF0aCB0aGF0IGhhcyBiZWVuIHNldCB1cCB0byBtZWV0DQo+ IHRoZSBRb1MgcmVxdWlyZW1lbnRzIG9mIGFuIGFwcGxpY2F0aW9uLiBTdWNoIGEgcGlubmVkIHBh dGggY2FuIGJlIGFwcHJvcHJpYXRlbHkNCj4gcHJvdmlzaW9uZWQgd2l0aCByZXF1aXJlZCBiYW5k d2lkdGggcmVzb3VyY2VzIGFsb25nIHRoZSBlbnRpcmUgcGF0aC4NCj4NCj4NCj4NCj4gqKogIFRy dWUgYnV0IGluIHJhZGlvcywgdGhlIGxpbmtzIG1heSBiZSB2ZXJ5IGFzeW1tZXRyaWNhbCwgYW5k IHRoZSBvcHRpbWFsIHJldHVybiBwYXRoIG1heSBiZSB2ZXJ5IGRpZmZlcmVudC4NCj4NCj4gqKog IFNvIHRoZSBwaW5uZWQtZG93biByZXR1cm4gcGF0aCBtYXkgYmUgZGlmZmVyZW50IGFjdHVhbGx5 Lg0KPg0KDQpTdXJlbHkgdGhlIHByZXNlbmNlIG9mIHVuaS1kaXJlY3Rpb25hbCByb3V0ZXMgY2Fu bm90IGJlIGlnbm9yZWQuIFNvbWUgb2YgdGhlDQpkb21pbmF0aW5nIGZhY3RvcnMgbGlrZSwgcm91 dGluZyBvdmVyaGVhZHMsIHJvdXRlIGFuZCByZXNvdXJjZSBzdGF0ZQ0KbWFpbnRlbmFuY2Ugb24g dGhlIG5vZGVzIGFuZCB0aGUgYXNzb2NpYXRlZCBzY2FsYWJpbGl0eSBpc3N1ZXMsIGltcGxlbWVu dGF0aW9uDQpjb21wbGV4aXR5LCBhbmQgc28gb24sIHdpbGwgcHJvbXB0IG5ldHdvcmsgZGVzaWdu ZXJzIHRvIGRlcGxveSBuZXR3b3JrcyB3aXRoDQpyZWxpYWJsZSBiaS1kaXJlY3Rpb25hbCBsaW5r cyBhbmQgcm91dGVzLiBCZWNhdXNlIG9mIHRoZSBmYWN0b3JzIGxpc3RlZCBoZXJlLA0Kb25lIHdv dWxkIGxpa2UgdG8gZW5zdXJlIGFic2VuY2Ugb2YgYmktZGlyZWN0aW9uYWwgcm91dGVzIHdpbGwg YmUgbW9yZSBvZiBhbg0KZXhjZXB0aW9uIHJhdGhlciB0aGFuIGEgbm9ybS4gTm8gPw0KDQoNCj4N Cj4NCj4gSSBmb3VuZCB0aGUgUDJQIFJQTCB2ZXJ5IGFwcHJvcHJpYXRlIGZvciB0aGUgY3VycmVu dCBkaXNjdXNzaW9uLiBXaGF0IGlzDQo+IGludGVyZXN0aW5nIGlzIHRoYXQgdGhlIEJpZGlyZWN0 aW9uYWwgUm91dGUgcHJlc2VudGVkIGhlcmUgYWN0dWFsbHkgZW5hYmxlcw0KPiBjcmVhdGluZyBh IHN5bW1ldHJpYyBwYXRoIGJldHdlZW4gZW5kIG5vZGVzIGJ5IHBhc3Npbmcgb24gdGhlIGNvbXBs ZXRlIHBhdGgNCj4gaW5mb3JtYXRpb24gaW4gaXRzIHNpZ25hbGluZyBtZXNzYWdlcy4gSW4gdGhp cyBwcm9jZXNzLCByb3V0aW5nIHN0YXRlIGlzDQo+IGluc3RhbGxlZCBhbG9uZyB0aGUgcGF0aC4N Cj4NCj4NCj4NCj4gqKogIEkgaG9wZSB0aGF0IHdlIHN0YXJ0IG5ldyBvbi1kZW1hbmQgd29yayBm b3IgUlBMLCBiYXNlZCBvbiB0aGlzIGFuZCBBT0RWLiBJdCBtYXkgYmUgdGhhdCB0aGUgcm91dGUg aXMgb3B0aW1pemVkIGZvciBtZXRyaWNzIHRoYXQgYXJlIG1vc3RseSBkaXJlY3Rpb25hbCwgb25l IHdheSBvciB0aGUgb3RoZXIsIGlmIHRoZSB0cmFmZmljIGlzIHNvLiBJZGVhbGx5IHdlZCBidWls ZCBhbmQgYXNzb2NpYXRlZCAyIERPREFHcywgb25lIGZvciBlYWNoIGRpcmVjdGlvbi4gVGhpcyBp cyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQt cm9sbC1hc3ltbGluay0wMA0KPg0KDQpUaGFua3MgZm9yIHRoZSBkcmFmdCEgV291bGQgYmUgaGFw cHkgdG8gYmUgcGFydCBvZiB0aGUgbmV3IHdvcmsgeW91IGFyZSBwcm9wb3NpbmcgOikNCg0KPg0K Pg0KPiBBcyB5b3Ugbm90ZWQsIGtlZXBpbmcgc2lnbmFsaW5nIHNlcGFyYXRlIGZyb20gZGF0YSBp cyBjZXJ0YWlubHkgYW4gZWxlZ2FudCB3YXkuDQo+DQo+IFRoZXJlIGNhbiBob3dldmVyIGJlIGNv bnRleHRzIHdoZW4gaW4tYmFuZCBzaWduYWxpbmcgdGhhdCB1c2VzIFJIMyBhcyBwZXINCj4gUkZD NjU1NCBkYXRhIGNhbiBiZSBtb3JlIGVmZmljaWVudCB0aGFuIHVzaW5nIGEgc2lnbmFsaW5nIHBy b3RvY29sLCBhc3N1bWluZw0KPiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYXJlIGFkZHJlc3NlZCBh cyBwZXIgUkZDMjQ2MC4gVGhpcyBpbi1iYW5kIGFwcHJvYWNoIGlzDQo+IGF0dHJhY3RpdmUgd2hl biB3ZSB3YW50IHRvIHNldCB1cCBhIHJhcGlkIG9uLXRoZS1mbHkgc3ltbWV0cmljIHBhdGggYWxv bmcgd2l0aA0KPiA2VGlTQ0ggT1RGIG1ha2luZyBiYW5kd2lkdGggcmVzZXJ2YXRpb24gYWxvbmcg dGhlIHdheSBmb3IgdHJhbnNhY3Rpb25hbCBtZXNzYWdlDQo+IGV4Y2hhbmdlcy4gSSBhbSBoaW50 aW5nIGF0IHRoZSBwb3NzaWJsZSBQQ0UvTk1FIGJhc2VkIHNvbHV0aW9uIHRoYXQgKGkpIHdvcmtz DQo+IHdpdGggdGhlIFJQTCBET0RBRywgKGlpKSBjb25zaWRlcnMgdGhlIGhvcCBkaXN0YW5jZSBi ZXR3ZWVuIHRoZSBjb21tdW5pY2F0aW5nDQo+IG5vZGUgdG8gYXNzZXNzIGVuZXJneSBjb3N0cywg KGlpaSkgb3B0aW1pemVzIG5ldHdvcmsgcmVzb3VyY2UgYXZhaWxhYmlsaXR5LCBhbmQNCj4gZmlu YWxseSBwcm92aWRlcyByaWdodCBpbnB1dHMgZm9yIHRoZSBub2Rlcy4gSXQgbWF5IHdlbGwgYmUg dGhhdCBkcm9wcGluZyB0aGUNCj4gYWRkcmVzcyBpcyB0aGUgcmlnaHQgY2hvaWNlLg0KPg0KPg0K Pg0KPiCoqiAgSSBjYW4gYWdyZWUgd2l0aCB0aGF0LCBhbmQgSSB1c2VkIHRoYXQgc29ydCBvZiBt ZXRob2QgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtdHJlZS1k aXNjb3ZlcnkNCj4NCj4NCg0KVGhhbmtzIGFnYWluISBTdGFydGVkIHJlYWRpbmcgaXQuIExvb2tz IGxpa2Ugd2UgYXJlICByZXZpc2l0aW5nIGNvbmNlcHRzIGFscmVhZHkgZGV2ZWxvcGVkIG1hbnkg eWVhcnMgYmFjay4NCg0KPg0KPg0KPiBJIHRoaW5rIEkgYW0gZG9pbmcgdG9vIG11Y2ggb2YgaGFu ZCB3YXZpbmcgZ29pbmcgb24gYnkgbGVhdmluZyBvdXQgYWxsIHRoZQ0KPiBlc3NlbnRpYWwgZGV0 YWlscy4gSG9wZSBJIG1hbmFnZWQgdG8gdmFndWVseSBjb252ZXkgdGhlIHBvaW50Lg0KPg0KPiBJ IHRlbmQgdG8gZmVlbCB0aGF0IGRpc3RyaWJ1dGVkLCBjZW50cmFsaXplZCBhbmQgdGhlaXIgY29t YmluYXRpb24gbWlnaHQNCj4gY28tZXhpc3QgdG8gb3B0aW1pemUgbmV0d29yayByZXNvdXJjZXMs IGFuZCB0aGVyZWZvcmUgcmV0YWluaW5nIG9yIGRyb3BwaW5nIHRoZQ0KPiBhZGRyZXNzIGluIFJI My02TG9SSCBjYW4gYmUgbWFkZSBvcHRpb25hbC4NCj4NCj4NCj4NCj4NCj4NCj4gqKogIENvdWxk IGJlLCBidXQgc2hvdWxkIHdlIGRvIGl0IG5vdyBvciB3aGVuIHdlIGhhdmUgdGhlIGFjdHVhbCBu ZWVkPw0KPg0KPiCoqiAgRG8geW91IGhhdmUgYSBkZXNpZ24gaW4gbWluZCB0aGF0IGxpbWl0cyB0 aGUgaW1wbGVtZW50YXRpb24gb3ZlcmhlYWQgb2Ygc3VwcG9ydGluZyBib3RoPw0KPg0KDQpBdCB0 aGUgcmljayBvZiBzb3VuZGluZyBuYWl2ZSwgY2FuJ3QgdGhlIG9wdGlvbiBvZiBkcm9wcGluZyBv ciByZXRhaW5pbmcgYWRkcmVzcyBiZSBpbmRpY2F0ZWQgYnkgYSBiaXQgPw0KDQo+DQo+DQo+IEFt IEkgbWFraW5nIHNlbnNlID8NCj4NCj4NCj4NCj4NCj4NCj4gqKogIFRvIG1lLCBjZXJ0YWlubHkg Sg0KPg0KDQpBbmFuZA0KDQo+DQo+DQo+IEFuYW5kDQo+DQo+DQo+DQo+DQo+IE9uIFNhdHVyZGF5 IDIzIEphbnVhcnkgMjAxNiAwMjozNCBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90 ZToNCj4gPg0KPg0KPiA+IEhlbGxvIEFuYW5kOg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0K PiA+IDIgZ29vZCBwb2ludHMgLCB0aGF0IHdlIG5lZWQgdG8gY29udGludWUgaW4gZGlmZmVyZW50 IHRocmVhZHMgaWYgd2UgZG8uDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IFRoZSBzb3VyY2Ugcm91 dGluZyBvcHRpbWl6YXRpb24gZG9uZSBieSBkcm9wcGluZyB0aGUgYWRkcmVzc2VzIG9uIHRoZSB3 YXkNCj4NCj4gPiBjZXJ0YWlubHkgaGFzIGJlbmVmaXRzLiBIb3dldmVyLCB0aGVyZSBjb3VsZCBi ZSBsb3NzIG9mIGEgbmF0dXJhbCAic3ltbWV0cmljIg0KPg0KPiA+IHByb3BlcnR5IHRoYXQgb25l IG1pZ2h0IHdhbnQgdG8gZW5mb3JjZSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kIG5vZGVzIGlu IHRoZQ0KPg0KPiA+IHJvdXRpbmcgcGF0aC4gQnkgc3ltbWV0cnkgSSBtZWFuIHVzaW5nIHRoZSBz YW1lIHBhdGggaW4gYm90aCB0aGUgZGlyZWN0aW9ucyBvZg0KPg0KPiA+IGNvbW11bmljYXRpb24u IFBvbGljeSBiYXNlZCByb3V0aW5nLCBjZW50cmFsaXplZCByb3V0aW5nLCBmb3IgaW5zdGFuY2Us IGNvdWxkDQo+DQo+ID4gYmUgcG90ZW50aWFsIHVzZXJzIG9mIHRoaXMgcHJvcGVydHkuIE1heSBi ZSB0aGlzIGRvZXMgbm90IHJlcHJlc2VudCBhIGNvbW1vbg0KPg0KPiA+IHVzZSBjYXNlLiBCdXQg bmV2ZXJ0aGVsZXNzLCB3ZSBoYXZlIHRvIGJlIGF3YXJlIG9mIHRoaXMgc2lkZSBlZmZlY3Qgd2hp Y2ggUkZDNjU1NA0KPg0KPiA+IHN3YXBwaW5nIHByb2Nlc3MgZG9lcyBub3QgaGF2ZS4NCj4NCj4g Pg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiCoqiAgUGFzY2FsOiBZZXMsIFNpbW9uIG1hZGUgdGhh dCBwb2ludCB5ZXN0ZXJkYXkuDQo+DQo+ID4NCj4NCj4gPiCoqiAgSXQgaXMgZ2VuZXJhbGx5IG5v dCBhIGdvb2QgaWRlYSB0byByZXZlcnNlIGEgcm91dGluZyBoZWFkZXIuIFRoZSBSSCBtYXkgaGF2 ZSBiZWVuIHVzZWQgdG8gc3RheSBhd2F5IGZyb20gdGhlIHNob3J0ZXN0IHBhdGggZm9yIHNvbWUg cmVhc29uIHRoYXQgaXMgb25seSB2YWxpZCBvbiB0aGUgd2F5IGluIChzZWdtZW50IHJvdXRpbmcp Lg0KPg0KPiA+DQo+DQo+ID4gqKogIFAyUCBSUEwgcmV2ZXJzZXMgYSBwYXRoIHRoYXQgaXMgbGVh cm50IHJlYWN0aXZlbHksIHNvIHdlIGhhdmUgYSByZWFsIHByb3RvY29sIGZvciBkb2luZyB0aGF0 IHNvcnQgb2YgdGhpbmcgYXMgb3Bwb3NlZCB0byBhbiBlY2hvLg0KPg0KPiA+DQo+DQo+ID4gqKog IFJldmVyc2luZyBhIGhlYWRlciBpcyBkaXNjb3VyYWdlZCBieSBSRkMgMjQ2MCAoZm9yIFJIMCkg dW5sZXNzIGl0IGlzIGF1dGhlbnRpY2F0ZWQgKHdoaWNoIG1lYW5zIEFIKS4gV2UgZG8gbm90IGF1 dGhlbnRpY2F0ZSB0aGUgUkgzLCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgcmVhc29ucyBmb3IgdGhh dCwgZ2VuZXJhbCBkZXByZWNhdGlvbiBvZiBBSCwgbm8gdXNlIG9mIEFIIGluIExMTnMgZXRjJiBO b3RlIHRoYXQgQUggZG9lcyBub3QgcHJvdGVjdCB0aGUgUkggb24gdGhlIHdheSwgaXQgaXMganVz dCBhIHZhbGlkYXRpb24gYXQgdGhlIHJlY2VpdmVyIGZvciB0aGUgc29sZSB2YWx1ZSBvZiByZXZl cnNpbmcgaXQuDQo+DQo+ID4NCj4NCj4gPiCoqiAgQSBSUEwgZG9tYWluIGlzIHVzdWFsbHkgcHJv dGVjdGVkIGJ5IEwyIHNlY3VyaXR5IGFuZCB0aGF0IHNlY3VyZXMgYm90aCBSUEwgaXRzZWxmIGFu ZCB0aGUgUkggaW4gcGFja2V0cywgYXQgZXZlcnkgaG9wDQo+DQo+ID4NCj4NCj4gPiCoqiAgVGhl IGJlbmVmaXQgb2Ygc2F2aW5nIGVuZXJneSBhbmQgbG93ZXJpbmcgdGhlIGNoYW5jZXMgb2YgbG9z cyBhcmUgc2VlbiBhcyBvdmVyd2hlbG1pbmcgY29tcGFyZWQgdG8gdGhlIHZhbHVlIG9mIHBvc3Np Ymx5IHJldmVyc2luZyB0aGUgaGVhZGVyDQo+DQo+ID4NCj4NCj4gPiCoqiAgWWV0IHdlIG1pZ2h0 IGRlZmluZSBhIHZhcmlhdGlvbiB3aGVyZSB3ZSBkbyBub3QgcG9wIG91dCB0aGUgZmlyc3QgZW50 cnkgYXMgd2UgZ28uIEkgZG8gbm90IHNlZSBhIGNvbnNlbnN1cyBvbiB0aGUgdmFsdWUgb2YgZG9p bmcgaXQgbm93Lg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4g PiBHb2luZyBmdXJ0aGVyLCB0aGUgREFPIHByb2plY3Rpb24gcHJvcG9zYWwNCj4NCj4gPiAoZHJh ZnQtdGh1YmVydC1yb2xsLWRhby1wcm9qZWN0aW9uLTAyLnR4dCkgd2lsbCBoYXZlIHNldmVyYWwg dmlydHVhbCByb290cw0KPg0KPiA+IGluc2lkZSB0aGUgUlBMIGRvbWFpbi4gVGhlIGF1dG9tYXRp YyBhc3N1bXB0aW9uIG9mIGEgd2VsbCBrbm93biByb290IG1heSBub3QgYXBwbHkNCj4NCj4gPiB3 aGVuIG5vZGVzIHdpdGhpbiBSUEwgZG9tYWluIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlci4g SSBzdXBwb3NlIGl0IHdpbGwNCj4NCj4gPiBoYXZlIGEgYmVhcmluZyBvbiB0aGUgUkgzLTZMb1JI IHBlcmZvcm1hbmNlLg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IKiqICBJdCBpcyBu b3QgcmVhbGx5IGFuIGFzc3VtcHRpb24sIGJ1dCBzb21ldGhpbmcgd2UgbGV2ZXJhZ2UgYXMgd2Ug Z28uIFRoZSBSUEkgaXMgdmVyeSBtdWNoIGxpa2UgYSBjb250ZXh0IGluZGljYXRvci4gSWYgYW4g YWRkcmVzcyBzaGFyZXMgYSBsb24gcHJlZml4IHdpdGggYSByb290LCBhZGRpbmcgdGhlIFJQSSBv ZiB0aGF0IHJvb3QgaXMgYWN0dWFsbHkgYSBjb21wcmVzc2lvbiB0ZWNobmlxdWUuDQo+DQo+ID4N Cj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gVGhlIGFib3ZlIG9ic2VydmF0aW9ucyBhcmUgbm90IHNl cmlvdXMsIGJ1dCBmZWVscyBnb29kIHRvIHBvbmRlciBvdmVyLiBXaWxsIGJlDQo+DQo+ID4gaGFw cHkgdG8gcmVjZWl2ZSB5b3VyIGNvbW1lbnRzLg0KPg0KPiA+DQo+DQo+ID4gVGhhbmtzIEFuYW5k IQ0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IFBhc2NhbA0KPg0KPiA+DQo+DQo+ID4N Cj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiBPbiBNb25kYXkgMTggSmFudWFyeSAyMDE2 IDExOjI0IFBNLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPg0KPiA+ID4NCj4N Cj4gPg0KPg0KPiA+ID4gRGVhciBhbGwNCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gVGhlIHBpY3R1cmUgYmVsb3cg aWxsdXN0cmF0ZXMgaG93IHRoZSBSSDMgNkxvUkggd29ya3Mgd2l0aCBkcmFmdCAwMyBpbiBhIGNh c2UgbGlrZSBSb290IC0+IEEgLT4gQiAtPiBDIC0+IGxlYWYNCj4NCj4gPg0KPg0KPiA+ID4NCj4N Cj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4g Pg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gVGhlIGZpcnN0IDZMb1JIIGlzIGV4cGVjdGVk IHRvIGJlIGEgZnVsbCBhZGRyZXNzICgxMjggYml0cykgdG8gc2V0IHVwIGEgcmVmZXJlbmNlIGFu ZCB0aGUgbmV4dCA2TG9SSCBhcmUgZXhwZWN0ZWQgdG8gYmUgc21hbGxlciBhbmQganVzdCBvdmVy cmlkZSB0aGUgcmlnaHRtb3N0IGJpdHMgd2hpY2ggZm9ybSB0aGUgZGVsdGEgZnJvbSB0aGUgcmVm ZXJlbmNlLg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBQcm9wb3NhbDogd2UgY291bGQgY29uc2lkZXIgdGhhdCB0 aGUgMTI4Yml0cyBzb3VyY2Ugb2YgdGhlIElQIGhlYWRlciBiZWZvcmUgdGhlIFJIMyBpcyB0aGUg cmVmZXJlbmNlIHRvIHN0YXJ0IHdpdGguDQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4g PiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IFdpdGggdGhhdCBldmVuIHRo ZSBmaXJzdCBob3AgY291bGQgYmUgY29tcHJlc3NlZCB0aGUgc2FtZSB3YXkgYXMgdGhlIG90aGVy IGhvcHMuIFdpdGggUlBMLCB0aGUgcm9vdCBpcyB0aGUgZW5jYXBzdWxhdG9yIGlmIElQIGluIElQ IGluIHVzZWQuIEdvb2QgdGhpbmcsIGluIHRoYXQgY2FzZSB0aGUgcm9vdCBpcyB0b3RhbGx5IGVs aWRlZCB3aXRoIHRoZSBJUC1pbi1JUCA2TG9SSC4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0K Pg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gU28gdGhpcyBzaW1w bGUgcHJvcG9zYWwgc2F2ZXMgdXAgdG8gMTYgb2N0ZXRzICh0aGF0cyBpbiB0aGUgY2FzZSB3aXRo IGEgc2luZ2xlIHN1Ym5ldCBhbmQgYWxsIGFkZHJlc3NlcyBkaWZmZXIgb25seSBieSB0aGUgbGFz dCAyIGJ5dGVzKS4gSW0gd2lsbGluZyB0byBhZGQgaXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQo+ DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ ID4NCj4NCj4gPiA+IEFueSBvcHBvc2l0aW9uPw0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+ DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBQYXNjYWwNCj4NCj4g Pg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0K Pg0KPiA+ID4gLS0NCj4NCj4gPg0KPg0KPiA+ID4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kDQo+DQo+ID4NCj4NCj4gPiA+IGRhbmdlcm91cyBjb250ZW50IGJ5 IE1haWxTY2FubmVyLCBhbmQgaXMNCj4NCj4gPg0KPg0KPiA+ID4gYmVsaWV2ZWQgdG8gYmUgY2xl YW4uDQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+ID4NCj4NCj4gPiA+IDZ0aXNjaCBt YWlsaW5nIGxpc3QNCj4NCj4gPg0KPg0KPiA+ID4gNnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlz Y2hAaWV0Zi5vcmc+DQo+DQo+ID4NCj4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vNnRpc2NoDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gLS0NCj4N Cj4gPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQNCj4NCj4g PiBkYW5nZXJvdXMgY29udGVudCBieSBNYWlsU2Nhbm5lciwgYW5kIGlzDQo+DQo+ID4gYmVsaWV2 ZWQgdG8gYmUgY2xlYW4uDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+ID4gNnRpc2NoIG1haWxpbmcgbGlz dA0KPg0KPiA+IDZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0KPg0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vNnRpc2NoDQo+DQo+DQo+IC0t DQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZA0KPiBkYW5n ZXJvdXMgY29udGVudCBieSBNYWlsU2Nhbm5lciwgYW5kIGlzDQo+IGJlbGlldmVkIHRvIGJlIGNs ZWFuLg0KDQo= --_000_BC1182E86737A7438C540E3B93DB7E518BD5B2SZXEMI507MBSchina_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi,

 

> > I found the P2P RPL very appropriate for t= he current discussion. What is

> > interesting is that the Bidirectional Rout= e presented here actually enables

> > creating a symmetric path between end node= s by passing on the complete path

> > information in its signaling messages. In = this process, routing state is

> > installed along the path.

> >

> > 

> >

> > =A8=AA  I hope that we start new on-d= emand work for RPL, based on this and AODV. It may be that the route is opt= imized for metrics that are mostly directional, one way or the other, if th= e traffic is so. Ideally wed build and associated 2 DODAGs, one for each direction. This is discussed in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00

> >
>
> Thanks for the draft! Would be happy to be part of the new work you ar= e proposing :)

 

When we create 2 DODAGs= for asymmetrical links, two DIO messages are generated:  one from sou= rce to destination (instance-1) and the other from destination to source (i= nstance-2). So, there won=A1=AFt be any DAO or RDO messages in P2P-RPL based on asymmetric links. Am I correct?

 

In P2P-RPL, =A1=AEAddre= ss=A1=AF vector is created by the source during DIO-RDO multicast for both = hop-by-hop routing (non-storing mode) and source routing (storing mode). Fo= r asymmetric-link based P2P-RPL, one =A1=AEAddress=A1=AF vector (DIO-RDO) is created by source for Instance-1 to discover path from= destination to source and the other one needs to be created by destination= to discover path from source to destination. If this is to be the proposin= g operations for asymmetrical P2P-RPL, then there would be two rounds of multicast compared to just one round in = the traditional P2P-RPL. It is desirable if we can remove the =A1=AEAddress= =A1=AF vector from the multicast DIO-RDO for asymmetric-link based P2P-RPL(= especially for hop-by-hop routing).

 

With Regards,

Satish.

 <= /p>

 <= /p>

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of S.V.R.Anand
Sent: 2016=D2=B4= 2=EA=C52=EC=ED 15:49
To: Pascal Thubert (pthubert); 6lo@ietf.org
Cc: 6tisch@ietf.org; Routing Over Low power and Lossy networks
Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in = RH3-6LoRH...)

 

Hi Pascal,

Thanks a lot for your response and for all the references. Please see my re= sponse in line.

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthubert) wrote:
>

> Hello Anand:

> 

> 

> 

> Thanks for this, please see below:

> 

> 

> Having a symmetric path, in principle, certainl= y offers advantages when we want

> the communicating nodes to use a well-defined p= ath that has been set up to meet

> the QoS requirements of an application. Such a = pinned path can be appropriately

> provisioned with required bandwidth resources a= long the entire path.

> 

> 

> 

> =A8=AA  True but in radios, the links may = be very asymmetrical, and the optimal return path may be very different.

> 

> =A8=AA  So the pinned-down return path may= be different actually.

>

Surely the presence of uni-directional routes cannot be ignored. Some of th= e
dominating factors like, routing overheads, route and resource state
maintenance on the nodes and the associated scalability issues, implementat= ion
complexity, and so on, will prompt network designers to deploy networks wit= h
reliable bi-directional links and routes. Because of the factors listed her= e,
one would like to ensure absence of bi-directional routes will be more of a= n
exception rather than a norm. No ?


> 

> 

> I found the P2P RPL very appropriate for the cu= rrent discussion. What is

> interesting is that the Bidirectional Route pre= sented here actually enables

> creating a symmetric path between end nodes by = passing on the complete path

> information in its signaling messages. In this = process, routing state is

> installed along the path.

> 

> 

> 

> =A8=AA  I hope that we start new on-demand= work for RPL, based on this and AODV. It may be that the route is optimize= d for metrics that are mostly directional, one way or the other, if the tra= ffic is so. Ideally wed build and associated 2 DODAGs, one for each direction. This is discussed in https://tools.ietf.org/html/draft-thubert-roll-asymlink-00

>

Thanks for the draft! Would be happy to be part of the new work you are pro= posing :)

>

> 

> As you noted, keeping signaling separate from d= ata is certainly an elegant way.

> 

> There can however be contexts when in-band sign= aling that uses RH3 as per

> RFC6554 data can be more efficient than using a= signaling protocol, assuming

> the security concerns are addressed as per RFC2= 460. This in-band approach is

> attractive when we want to set up a rapid on-th= e-fly symmetric path along with

> 6TiSCH OTF making bandwidth reservation along t= he way for transactional message

> exchanges. I am hinting at the possible PCE/NME= based solution that (i) works

> with the RPL DODAG, (ii) considers the hop dist= ance between the communicating

> node to assess energy costs, (iii) optimizes ne= twork resource availability, and

> finally provides right inputs for the nodes. It= may well be that dropping the

> address is the right choice.

> 

> 

> 

> =A8=AA  I can agree with that, and I used = that sort of method in https:= //tools.ietf.org/html/draft-thubert-tree-discovery

> 

> 

Thanks again! Started reading it. Looks like we are  revisiting concep= ts already developed many years back.

>

> 

> I think I am doing too much of hand waving goin= g on by leaving out all the

> essential details. Hope I managed to vaguely co= nvey the point.

> 

> I tend to feel that distributed, centralized an= d their combination might

> co-exist to optimize network resources, and the= refore retaining or dropping the

> address in RH3-6LoRH can be made optional.=

> 

> 

> 

> 

> 

> =A8=AA  Could be, but should we do it now = or when we have the actual need?

> 

> =A8=AA  Do you have a design in mind that = limits the implementation overhead of supporting both?

>

At the rick of sounding naive, can't the option of dropping or retaining ad= dress be indicated by a bit ?

>

> 

> Am I making sense ?

> 

> 

> 

> 

> 

> =A8=AA  To me, certainly J

>

Anand

>

> 

> Anand

> 

> 

> 

> 

> On Saturday 23 January 2016 02:34 PM, Pascal Th= ubert (pthubert) wrote:

> >

> 

> > Hello Anand:

> 

> >

> 

> >

> 

> >

> 

> > 2 good points , that we need to continue i= n different threads if we do.

> 

> >

> 

> >

> 

> > The source routing optimization done by dr= opping the addresses on the way

> 

> > certainly has benefits. However, there cou= ld be loss of a natural "symmetric"

> 

> > property that one might want to enforce be= tween communicating end nodes in the

> 

> > routing path. By symmetry I mean using the= same path in both the directions of

> 

> > communication. Policy based routing, centr= alized routing, for instance, could

> 

> > be potential users of this property. May b= e this does not represent a common

> 

> > use case. But nevertheless, we have to be = aware of this side effect which RFC6554

> 

> > swapping process does not have.=

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  Pascal: Yes, Simon made that = point yesterday.

> 

> >

> 

> > =A8=AA  It is generally not a good id= ea to reverse a routing header. The RH may have been used to stay away from= the shortest path for some reason that is only valid on the way in (segmen= t routing).

> 

> >

> 

> > =A8=AA  P2P RPL reverses a path that = is learnt reactively, so we have a real protocol for doing that sort of thi= ng as opposed to an echo.

> 

> >

> 

> > =A8=AA  Reversing a header is discour= aged by RFC 2460 (for RH0) unless it is authenticated (which means AH). We = do not authenticate the RH3, there are a number of reasons for that, genera= l deprecation of AH, no use of AH in LLNs etc& Note that AH does not protect the RH on the way, it is just a validation at the= receiver for the sole value of reversing it.

> 

> >

> 

> > =A8=AA  A RPL domain is usually prote= cted by L2 security and that secures both RPL itself and the RH in packets,= at every hop

> 

> >

> 

> > =A8=AA  The benefit of saving energy = and lowering the chances of loss are seen as overwhelming compared to the v= alue of possibly reversing the header

> 

> >

> 

> > =A8=AA  Yet we might define a variati= on where we do not pop out the first entry as we go. I do not see a consens= us on the value of doing it now.

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > Going further, the DAO projection proposal=

> 

> > (draft-thubert-roll-dao-projection-02.txt)= will have several virtual roots

> 

> > inside the RPL domain. The automatic assum= ption of a well known root may not apply

> 

> > when nodes within RPL domain communicate w= ith each other. I suppose it will

> 

> > have a bearing on the RH3-6LoRH performanc= e.

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  It is not really an assumptio= n, but something we leverage as we go. The RPI is very much like a context = indicator. If an address shares a lon prefix with a root, adding the RPI of= that root is actually a compression technique.

> 

> >

> 

> >

> 

> >

> 

> > The above observations are not serious, bu= t feels good to ponder over. Will be

> 

> > happy to receive your comments.=

> 

> >

> 

> > Thanks Anand!

> 

> >

> 

> >

> 

> >

> 

> > Pascal

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > On Monday 18 January 2016 11:24 PM, Pascal= Thubert (pthubert) wrote:

> 

> > >

> 

> >

> 

> > > Dear all

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The picture below illustrates how the= RH3 6LoRH works with draft 03 in a case like Root -> A -> B -> C = -> leaf

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The first 6LoRH is expected to be a f= ull address (128 bits) to set up a reference and the next 6LoRH are expecte= d to be smaller and just override the rightmost bits which form the delta f= rom the reference.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Proposal: we could consider that the = 128bits source of the IP header before the RH3 is the reference to start wi= th.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > With that even the first hop could be= compressed the same way as the other hops. With RPL, the root is the encap= sulator if IP in IP in used. Good thing, in that case the root is totally e= lided with the IP-in-IP 6LoRH.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > So this simple proposal saves up to 1= 6 octets (thats in the case with a single subnet and all addresses differ o= nly by the last 2 bytes). Im willing to add it in the next revision.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Any opposition?

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Pascal

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > --

> 

> >

> 

> > > This message has been scanned for vir= uses and

> 

> >

> 

> > > dangerous content by MailScanner, and= is

> 

> >

> 

> > > believed to be clean.

> 

> >

> 

> > >

> 

> >

> 

> > > _____________________________________= __________

> 

> >

> 

> > > 6tisch mailing list

> 

> >

> 

> > > 6t= isch@ietf.org

> 

> >

> 

> > > https://www.ietf.org/mailman/listinfo/6tisch

> 

> >

> 

> >

> 

> >

> 

> > --

> 

> > This message has been scanned for viruses = and

> 

> > dangerous content by MailScanner, and is

> 

> > believed to be clean.

> 

> >

> 

> >

> 

> > __________________________________________= _____

> 

> > 6tisch mailing list

> 

> > 6tisch@= ietf.org

> 

> > https://www.ietf.org/mailman/listinfo/6tisch<= /p>

> 

> 

> --

> This message has been scanned for viruses and

> dangerous content by MailScanner, and is

> believed to be c= lean.

--_000_BC1182E86737A7438C540E3B93DB7E518BD5B2SZXEMI507MBSchina_-- From nobody Sat Feb 6 01:58:41 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243F61B2A17; Sat, 6 Feb 2016 01:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 m-36SulEYBVb; Sat, 6 Feb 2016 01:58:33 -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 B0E081B2A12; Sat, 6 Feb 2016 01:58:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CID48145; Sat, 06 Feb 2016 09:58:28 +0000 (GMT) Received: from SZXEMI404-HUB.china.huawei.com (10.82.75.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 6 Feb 2016 09:58:27 +0000 Received: from SZXEMI507-MBS.china.huawei.com ([169.254.7.22]) by SZXEMI404-HUB.china.huawei.com ([10.82.75.40]) with mapi id 14.03.0235.001; Sat, 6 Feb 2016 17:58:21 +0800 From: "Satish Anamalamudi (Satish Anamalamudi)" To: Routing Over Low power and Lossy networks , "Pascal Thubert (pthubert)" , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) Thread-Index: AQHRXY5jBA/HX/YM9060aibxpZBvU58ezJIQ Date: Sat, 6 Feb 2016 09:58:20 +0000 Message-ID: References: <56B05F84.3080702@ece.iisc.ernet.in> In-Reply-To: <56B05F84.3080702@ece.iisc.ernet.in> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.154.175] Content-Type: multipart/alternative; boundary="_000_BC1182E86737A7438C540E3B93DB7E518BDBB4SZXEMI507MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.56B5C3C5.00B1, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.22, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5cea5fdf7b0c4a87907645dd8219c616 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 09:58:39 -0000 --_000_BC1182E86737A7438C540E3B93DB7E518BDBB4SZXEMI507MBSchina_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8gZXZlcnlvbmUsDQoNClBsZWFzZSBsZXQgbWUgcmVmcmVzaCBteSBwcmV2aW91cyBjb21t ZW50cyBhcyBmb2xsb3dzLg0KDQpkcmFmdC10aHViZXJ0LXJvbGwtYXN5bWxpbmstMDINCg0KMi1E T0RBR3MgZm9yIGFzeW1tZXRyaWNhbCBsaW5rczoNCg0KRm9yIHVwd2FyZCByb3V0ZXMgKEluc3Rh bmNlLTEpLCByb290IGdlbmVyYXRlcyBESU8gbWVzc2FnZSB3aXRoIE1PUD0wIChObyBkb3dud2Fy ZCByb3V0ZXMgYXJlIGFsbG93ZWQpLiBGb3IgdGhpcywgbm8gREFPIG1lc3NhZ2VzIGFyZSBnZW5l cmF0ZWQuDQoNCkZvciBkb3dud2FyZCByb3V0ZXMgKEluc3RhbmNlLTIpLCByb290IGdlbmVyYXRl cyBESU8gbWVzc2FnZXMgd2l0aCBNT1A9MiAoU3RvcmluZyBtb2RlKS4gU3Vic2VxdWVudGx5LCBE QU8gbWVzc2FnZXMgYXJlIGdlbmVyYXRlZCBiYWNrIHRvIHRoZWlyIGltbWVkaWF0ZSBwYXJlbnRz IGFuZCByb3V0aW5nIHN0YXRlIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBpbiBwYXJlbnQgbm9kZSBm b3IgZG93bndhcmQgdHJhZmZpYy4NCg0KU28sIHJvb3QgaXMgdGhlIHNhbWUgZm9yIGJvdGggSW5z dGFuY2UtMSBhbmQgSW5zdGFuY2UtMi4gSXMgdGhpcyBvYnNlcnZhdGlvbiBjb3JyZWN0Pw0KDQpJ ZiBteSBvYnNlcnZhdGlvbiBtYWtlcyBzZW5zZSB0aGVuIHRoZXJlIHdvbqGvdCBiZSBEQU8gbWVz c2FnZXMsIHdoaWNoIHdlcmUgdXNlZCBpbiB0cmFkaXRpb25hbCBSUEwgKFJGQzY1NTApLCBmb3Ig dXB3YXJkIHJvdXRlIHdpdGggMiBET0RBR3MgKGFzeW1tZXRyaWMgbGlua3MpLg0KDQoNCklmIHdl IGNvbnN0cnVjdCBwZWVyIHRvIHBlZXIgcm91dGVzIGJhc2VkIG9uIFJGQzY5OTcsIHRoZSBzdG9y eSB3b3VsZCBiZSBkaWZmZXJlbnQgZnJvbSBkcmFmdC10aHViZXJ0LXJvbGwtYXN5bWxpbmstMDIu IEluIFAyUC1SUEwgKFJGQzY5OTcpLCB0aGUgc291cmNlIHdpbGwgYWN0IGFzIGEgdGVtcG9yYXJ5 IHJvb3QgYW5kIG11bHRpY2FzdCB0aGUgRElPLVJETyBtZXNzYWdlcyB3aXRoIEluc3RhbmNlLTEu IE9uY2UsIHRoZSBkZXN0aW5hdGlvbiBpcyByZWFjaGVkIHRocm91Z2ggRElPLVJETyB0aGUgZGF0 YSBwYXRoIGZyb20gRGVzdGluYXRpb24gdG8gU291cmNlIGlzIGNyZWF0ZWQuIFRoZW4gd2UgYWdh aW4gbmVlZCB0byBpbml0aWF0ZSBESU8tUkRPIG1lc3NhZ2VzIHdpdGggSW5zdGFuY2UtMiBhdCBk ZXN0aW5hdGlvbiBmb3IgdGhlIGRhdGEgcGF0aCBmcm9tIFNvdXJjZSB0byBEZXN0aW5hdGlvbi4N Cg0KSWYgdGhpcyBvYnNlcnZhdGlvbiBpcyB0cnVlIHRoZW4gUDJQLVJQTCAoUkZDNjk5Nykgd2ls bCBuZWVkIHRvIGhhdmUgdHdvIHJvb3RzLiBBbSBJIGNvcnJlY3Q/DQoNCldpdGggUmVnYXJkcywN ClNhdGlzaA0KDQoNCkhpLA0KDQo+ID4gSSBmb3VuZCB0aGUgUDJQIFJQTCB2ZXJ5IGFwcHJvcHJp YXRlIGZvciB0aGUgY3VycmVudCBkaXNjdXNzaW9uLiBXaGF0IGlzDQo+ID4gaW50ZXJlc3Rpbmcg aXMgdGhhdCB0aGUgQmlkaXJlY3Rpb25hbCBSb3V0ZSBwcmVzZW50ZWQgaGVyZSBhY3R1YWxseSBl bmFibGVzDQo+ID4gY3JlYXRpbmcgYSBzeW1tZXRyaWMgcGF0aCBiZXR3ZWVuIGVuZCBub2RlcyBi eSBwYXNzaW5nIG9uIHRoZSBjb21wbGV0ZSBwYXRoDQo+ID4gaW5mb3JtYXRpb24gaW4gaXRzIHNp Z25hbGluZyBtZXNzYWdlcy4gSW4gdGhpcyBwcm9jZXNzLCByb3V0aW5nIHN0YXRlIGlzDQo+ID4g aW5zdGFsbGVkIGFsb25nIHRoZSBwYXRoLg0KPiA+DQo+ID4NCj4gPg0KPiA+IKiqICBJIGhvcGUg dGhhdCB3ZSBzdGFydCBuZXcgb24tZGVtYW5kIHdvcmsgZm9yIFJQTCwgYmFzZWQgb24gdGhpcyBh bmQgQU9EVi4gSXQgbWF5IGJlIHRoYXQgdGhlIHJvdXRlIGlzIG9wdGltaXplZCBmb3IgbWV0cmlj cyB0aGF0IGFyZSBtb3N0bHkgZGlyZWN0aW9uYWwsIG9uZSB3YXkgb3IgdGhlIG90aGVyLCBpZiB0 aGUgdHJhZmZpYyBpcyBzby4gSWRlYWxseSB3ZWQgYnVpbGQgYW5kIGFzc29jaWF0ZWQgMiBET0RB R3MsIG9uZSBmb3IgZWFjaCBkaXJlY3Rpb24uIFRoaXMgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aHViZXJ0LXJvbGwtYXN5bWxpbmstMDANCj4gPg0K Pg0KPiBUaGFua3MgZm9yIHRoZSBkcmFmdCEgV291bGQgYmUgaGFwcHkgdG8gYmUgcGFydCBvZiB0 aGUgbmV3IHdvcmsgeW91IGFyZSBwcm9wb3NpbmcgOikNCg0KV2hlbiB3ZSBjcmVhdGUgMiBET0RB R3MgZm9yIGFzeW1tZXRyaWNhbCBsaW5rcywgdHdvIERJTyBtZXNzYWdlcyBhcmUgZ2VuZXJhdGVk OiAgb25lIGZyb20gc291cmNlIHRvIGRlc3RpbmF0aW9uIChpbnN0YW5jZS0xKSBhbmQgdGhlIG90 aGVyIGZyb20gZGVzdGluYXRpb24gdG8gc291cmNlIChpbnN0YW5jZS0yKS4gU28sIHRoZXJlIHdv bqGvdCBiZSBhbnkgREFPIG9yIFJETyBtZXNzYWdlcyBpbiBQMlAtUlBMIGJhc2VkIG9uIGFzeW1t ZXRyaWMgbGlua3MuIEFtIEkgY29ycmVjdD8NCg0KSW4gUDJQLVJQTCwgoa5BZGRyZXNzoa8gdmVj dG9yIGlzIGNyZWF0ZWQgYnkgdGhlIHNvdXJjZSBkdXJpbmcgRElPLVJETyBtdWx0aWNhc3QgZm9y IGJvdGggaG9wLWJ5LWhvcCByb3V0aW5nIChub24tc3RvcmluZyBtb2RlKSBhbmQgc291cmNlIHJv dXRpbmcgKHN0b3JpbmcgbW9kZSkuIEZvciBhc3ltbWV0cmljLWxpbmsgYmFzZWQgUDJQLVJQTCwg b25lIKGuQWRkcmVzc6GvIHZlY3RvciAoRElPLVJETykgaXMgY3JlYXRlZCBieSBzb3VyY2UgZm9y IEluc3RhbmNlLTEgdG8gZGlzY292ZXIgcGF0aCBmcm9tIGRlc3RpbmF0aW9uIHRvIHNvdXJjZSBh bmQgdGhlIG90aGVyIG9uZSBuZWVkcyB0byBiZSBjcmVhdGVkIGJ5IGRlc3RpbmF0aW9uIHRvIGRp c2NvdmVyIHBhdGggZnJvbSBzb3VyY2UgdG8gZGVzdGluYXRpb24uIElmIHRoaXMgaXMgdG8gYmUg dGhlIHByb3Bvc2luZyBvcGVyYXRpb25zIGZvciBhc3ltbWV0cmljYWwgUDJQLVJQTCwgdGhlbiB0 aGVyZSB3b3VsZCBiZSB0d28gcm91bmRzIG9mIG11bHRpY2FzdCBjb21wYXJlZCB0byBqdXN0IG9u ZSByb3VuZCBpbiB0aGUgdHJhZGl0aW9uYWwgUDJQLVJQTC4gSXQgaXMgZGVzaXJhYmxlIGlmIHdl IGNhbiByZW1vdmUgdGhlIKGuQWRkcmVzc6GvIHZlY3RvciBmcm9tIHRoZSBtdWx0aWNhc3QgRElP LVJETyBmb3IgYXN5bW1ldHJpYy1saW5rIGJhc2VkIFAyUC1SUEwoZXNwZWNpYWxseSBmb3IgaG9w LWJ5LWhvcCByb3V0aW5nKS4NCg0KV2l0aCBSZWdhcmRzLA0KU2F0aXNoLg0KDQoNCkZyb206IFJv bGwgW21haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTLlYuUi5BbmFu ZA0KU2VudDogMjAxNtK0MurFMuztIDE1OjQ5DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KTsgNmxvQGlldGYub3JnDQpDYzogNnRpc2NoQGlldGYub3JnOyBSb3V0aW5nIE92ZXIgTG93IHBv d2VyIGFuZCBMb3NzeSBuZXR3b3Jrcw0KU3ViamVjdDogUmU6IFtSb2xsXSBPbiA2TG9SSCBpc3N1 ZSAjMTEgKHdhcyBQcm9wb3NlZCBpbXByb3ZlbWVudCBpbiBSSDMtNkxvUkguLi4pDQoNCkhpIFBh c2NhbCwNCg0KVGhhbmtzIGEgbG90IGZvciB5b3VyIHJlc3BvbnNlIGFuZCBmb3IgYWxsIHRoZSBy ZWZlcmVuY2VzLiBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlIGluIGxpbmUuDQoNCk9uIFN1bmRheSAz MSBKYW51YXJ5IDIwMTYgMDM6MDUgUE0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6 DQo+DQo+IEhlbGxvIEFuYW5kOg0KPg0KPg0KPg0KPiBUaGFua3MgZm9yIHRoaXMsIHBsZWFzZSBz ZWUgYmVsb3c6DQo+DQo+DQo+IEhhdmluZyBhIHN5bW1ldHJpYyBwYXRoLCBpbiBwcmluY2lwbGUs IGNlcnRhaW5seSBvZmZlcnMgYWR2YW50YWdlcyB3aGVuIHdlIHdhbnQNCj4gdGhlIGNvbW11bmlj YXRpbmcgbm9kZXMgdG8gdXNlIGEgd2VsbC1kZWZpbmVkIHBhdGggdGhhdCBoYXMgYmVlbiBzZXQg dXAgdG8gbWVldA0KPiB0aGUgUW9TIHJlcXVpcmVtZW50cyBvZiBhbiBhcHBsaWNhdGlvbi4gU3Vj aCBhIHBpbm5lZCBwYXRoIGNhbiBiZSBhcHByb3ByaWF0ZWx5DQo+IHByb3Zpc2lvbmVkIHdpdGgg cmVxdWlyZWQgYmFuZHdpZHRoIHJlc291cmNlcyBhbG9uZyB0aGUgZW50aXJlIHBhdGguDQo+DQo+ DQo+DQo+IKiqICBUcnVlIGJ1dCBpbiByYWRpb3MsIHRoZSBsaW5rcyBtYXkgYmUgdmVyeSBhc3lt bWV0cmljYWwsIGFuZCB0aGUgb3B0aW1hbCByZXR1cm4gcGF0aCBtYXkgYmUgdmVyeSBkaWZmZXJl bnQuDQo+DQo+IKiqICBTbyB0aGUgcGlubmVkLWRvd24gcmV0dXJuIHBhdGggbWF5IGJlIGRpZmZl cmVudCBhY3R1YWxseS4NCj4NCg0KU3VyZWx5IHRoZSBwcmVzZW5jZSBvZiB1bmktZGlyZWN0aW9u YWwgcm91dGVzIGNhbm5vdCBiZSBpZ25vcmVkLiBTb21lIG9mIHRoZQ0KZG9taW5hdGluZyBmYWN0 b3JzIGxpa2UsIHJvdXRpbmcgb3ZlcmhlYWRzLCByb3V0ZSBhbmQgcmVzb3VyY2Ugc3RhdGUNCm1h aW50ZW5hbmNlIG9uIHRoZSBub2RlcyBhbmQgdGhlIGFzc29jaWF0ZWQgc2NhbGFiaWxpdHkgaXNz dWVzLCBpbXBsZW1lbnRhdGlvbg0KY29tcGxleGl0eSwgYW5kIHNvIG9uLCB3aWxsIHByb21wdCBu ZXR3b3JrIGRlc2lnbmVycyB0byBkZXBsb3kgbmV0d29ya3Mgd2l0aA0KcmVsaWFibGUgYmktZGly ZWN0aW9uYWwgbGlua3MgYW5kIHJvdXRlcy4gQmVjYXVzZSBvZiB0aGUgZmFjdG9ycyBsaXN0ZWQg aGVyZSwNCm9uZSB3b3VsZCBsaWtlIHRvIGVuc3VyZSBhYnNlbmNlIG9mIGJpLWRpcmVjdGlvbmFs IHJvdXRlcyB3aWxsIGJlIG1vcmUgb2YgYW4NCmV4Y2VwdGlvbiByYXRoZXIgdGhhbiBhIG5vcm0u IE5vID8NCg0KDQo+DQo+DQo+IEkgZm91bmQgdGhlIFAyUCBSUEwgdmVyeSBhcHByb3ByaWF0ZSBm b3IgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbi4gV2hhdCBpcw0KPiBpbnRlcmVzdGluZyBpcyB0aGF0 IHRoZSBCaWRpcmVjdGlvbmFsIFJvdXRlIHByZXNlbnRlZCBoZXJlIGFjdHVhbGx5IGVuYWJsZXMN Cj4gY3JlYXRpbmcgYSBzeW1tZXRyaWMgcGF0aCBiZXR3ZWVuIGVuZCBub2RlcyBieSBwYXNzaW5n IG9uIHRoZSBjb21wbGV0ZSBwYXRoDQo+IGluZm9ybWF0aW9uIGluIGl0cyBzaWduYWxpbmcgbWVz c2FnZXMuIEluIHRoaXMgcHJvY2Vzcywgcm91dGluZyBzdGF0ZSBpcw0KPiBpbnN0YWxsZWQgYWxv bmcgdGhlIHBhdGguDQo+DQo+DQo+DQo+IKiqICBJIGhvcGUgdGhhdCB3ZSBzdGFydCBuZXcgb24t ZGVtYW5kIHdvcmsgZm9yIFJQTCwgYmFzZWQgb24gdGhpcyBhbmQgQU9EVi4gSXQgbWF5IGJlIHRo YXQgdGhlIHJvdXRlIGlzIG9wdGltaXplZCBmb3IgbWV0cmljcyB0aGF0IGFyZSBtb3N0bHkgZGly ZWN0aW9uYWwsIG9uZSB3YXkgb3IgdGhlIG90aGVyLCBpZiB0aGUgdHJhZmZpYyBpcyBzby4gSWRl YWxseSB3ZWQgYnVpbGQgYW5kIGFzc29jaWF0ZWQgMiBET0RBR3MsIG9uZSBmb3IgZWFjaCBkaXJl Y3Rpb24uIFRoaXMgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10aHViZXJ0LXJvbGwtYXN5bWxpbmstMDANCj4NCg0KVGhhbmtzIGZvciB0aGUgZHJhZnQh IFdvdWxkIGJlIGhhcHB5IHRvIGJlIHBhcnQgb2YgdGhlIG5ldyB3b3JrIHlvdSBhcmUgcHJvcG9z aW5nIDopDQoNCj4NCj4NCj4gQXMgeW91IG5vdGVkLCBrZWVwaW5nIHNpZ25hbGluZyBzZXBhcmF0 ZSBmcm9tIGRhdGEgaXMgY2VydGFpbmx5IGFuIGVsZWdhbnQgd2F5Lg0KPg0KPiBUaGVyZSBjYW4g aG93ZXZlciBiZSBjb250ZXh0cyB3aGVuIGluLWJhbmQgc2lnbmFsaW5nIHRoYXQgdXNlcyBSSDMg YXMgcGVyDQo+IFJGQzY1NTQgZGF0YSBjYW4gYmUgbW9yZSBlZmZpY2llbnQgdGhhbiB1c2luZyBh IHNpZ25hbGluZyBwcm90b2NvbCwgYXNzdW1pbmcNCj4gdGhlIHNlY3VyaXR5IGNvbmNlcm5zIGFy ZSBhZGRyZXNzZWQgYXMgcGVyIFJGQzI0NjAuIFRoaXMgaW4tYmFuZCBhcHByb2FjaCBpcw0KPiBh dHRyYWN0aXZlIHdoZW4gd2Ugd2FudCB0byBzZXQgdXAgYSByYXBpZCBvbi10aGUtZmx5IHN5bW1l dHJpYyBwYXRoIGFsb25nIHdpdGgNCj4gNlRpU0NIIE9URiBtYWtpbmcgYmFuZHdpZHRoIHJlc2Vy dmF0aW9uIGFsb25nIHRoZSB3YXkgZm9yIHRyYW5zYWN0aW9uYWwgbWVzc2FnZQ0KPiBleGNoYW5n ZXMuIEkgYW0gaGludGluZyBhdCB0aGUgcG9zc2libGUgUENFL05NRSBiYXNlZCBzb2x1dGlvbiB0 aGF0IChpKSB3b3Jrcw0KPiB3aXRoIHRoZSBSUEwgRE9EQUcsIChpaSkgY29uc2lkZXJzIHRoZSBo b3AgZGlzdGFuY2UgYmV0d2VlbiB0aGUgY29tbXVuaWNhdGluZw0KPiBub2RlIHRvIGFzc2VzcyBl bmVyZ3kgY29zdHMsIChpaWkpIG9wdGltaXplcyBuZXR3b3JrIHJlc291cmNlIGF2YWlsYWJpbGl0 eSwgYW5kDQo+IGZpbmFsbHkgcHJvdmlkZXMgcmlnaHQgaW5wdXRzIGZvciB0aGUgbm9kZXMuIEl0 IG1heSB3ZWxsIGJlIHRoYXQgZHJvcHBpbmcgdGhlDQo+IGFkZHJlc3MgaXMgdGhlIHJpZ2h0IGNo b2ljZS4NCj4NCj4NCj4NCj4gqKogIEkgY2FuIGFncmVlIHdpdGggdGhhdCwgYW5kIEkgdXNlZCB0 aGF0IHNvcnQgb2YgbWV0aG9kIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 aHViZXJ0LXRyZWUtZGlzY292ZXJ5DQo+DQo+DQoNClRoYW5rcyBhZ2FpbiEgU3RhcnRlZCByZWFk aW5nIGl0LiBMb29rcyBsaWtlIHdlIGFyZSAgcmV2aXNpdGluZyBjb25jZXB0cyBhbHJlYWR5IGRl dmVsb3BlZCBtYW55IHllYXJzIGJhY2suDQoNCj4NCj4NCj4gSSB0aGluayBJIGFtIGRvaW5nIHRv byBtdWNoIG9mIGhhbmQgd2F2aW5nIGdvaW5nIG9uIGJ5IGxlYXZpbmcgb3V0IGFsbCB0aGUNCj4g ZXNzZW50aWFsIGRldGFpbHMuIEhvcGUgSSBtYW5hZ2VkIHRvIHZhZ3VlbHkgY29udmV5IHRoZSBw b2ludC4NCj4NCj4gSSB0ZW5kIHRvIGZlZWwgdGhhdCBkaXN0cmlidXRlZCwgY2VudHJhbGl6ZWQg YW5kIHRoZWlyIGNvbWJpbmF0aW9uIG1pZ2h0DQo+IGNvLWV4aXN0IHRvIG9wdGltaXplIG5ldHdv cmsgcmVzb3VyY2VzLCBhbmQgdGhlcmVmb3JlIHJldGFpbmluZyBvciBkcm9wcGluZyB0aGUNCj4g YWRkcmVzcyBpbiBSSDMtNkxvUkggY2FuIGJlIG1hZGUgb3B0aW9uYWwuDQo+DQo+DQo+DQo+DQo+ DQo+IKiqICBDb3VsZCBiZSwgYnV0IHNob3VsZCB3ZSBkbyBpdCBub3cgb3Igd2hlbiB3ZSBoYXZl IHRoZSBhY3R1YWwgbmVlZD8NCj4NCj4gqKogIERvIHlvdSBoYXZlIGEgZGVzaWduIGluIG1pbmQg dGhhdCBsaW1pdHMgdGhlIGltcGxlbWVudGF0aW9uIG92ZXJoZWFkIG9mIHN1cHBvcnRpbmcgYm90 aD8NCj4NCg0KQXQgdGhlIHJpY2sgb2Ygc291bmRpbmcgbmFpdmUsIGNhbid0IHRoZSBvcHRpb24g b2YgZHJvcHBpbmcgb3IgcmV0YWluaW5nIGFkZHJlc3MgYmUgaW5kaWNhdGVkIGJ5IGEgYml0ID8N Cg0KPg0KPg0KPiBBbSBJIG1ha2luZyBzZW5zZSA/DQo+DQo+DQo+DQo+DQo+DQo+IKiqICBUbyBt ZSwgY2VydGFpbmx5IEoNCj4NCg0KQW5hbmQNCg0KPg0KPg0KPiBBbmFuZA0KPg0KPg0KPg0KPg0K PiBPbiBTYXR1cmRheSAyMyBKYW51YXJ5IDIwMTYgMDI6MzQgUE0sIFBhc2NhbCBUaHViZXJ0IChw dGh1YmVydCkgd3JvdGU6DQo+ID4NCj4NCj4gPiBIZWxsbyBBbmFuZDoNCj4NCj4gPg0KPg0KPiA+ DQo+DQo+ID4NCj4NCj4gPiAyIGdvb2QgcG9pbnRzICwgdGhhdCB3ZSBuZWVkIHRvIGNvbnRpbnVl IGluIGRpZmZlcmVudCB0aHJlYWRzIGlmIHdlIGRvLg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiBU aGUgc291cmNlIHJvdXRpbmcgb3B0aW1pemF0aW9uIGRvbmUgYnkgZHJvcHBpbmcgdGhlIGFkZHJl c3NlcyBvbiB0aGUgd2F5DQo+DQo+ID4gY2VydGFpbmx5IGhhcyBiZW5lZml0cy4gSG93ZXZlciwg dGhlcmUgY291bGQgYmUgbG9zcyBvZiBhIG5hdHVyYWwgInN5bW1ldHJpYyINCj4NCj4gPiBwcm9w ZXJ0eSB0aGF0IG9uZSBtaWdodCB3YW50IHRvIGVuZm9yY2UgYmV0d2VlbiBjb21tdW5pY2F0aW5n IGVuZCBub2RlcyBpbiB0aGUNCj4NCj4gPiByb3V0aW5nIHBhdGguIEJ5IHN5bW1ldHJ5IEkgbWVh biB1c2luZyB0aGUgc2FtZSBwYXRoIGluIGJvdGggdGhlIGRpcmVjdGlvbnMgb2YNCj4NCj4gPiBj b21tdW5pY2F0aW9uLiBQb2xpY3kgYmFzZWQgcm91dGluZywgY2VudHJhbGl6ZWQgcm91dGluZywg Zm9yIGluc3RhbmNlLCBjb3VsZA0KPg0KPiA+IGJlIHBvdGVudGlhbCB1c2VycyBvZiB0aGlzIHBy b3BlcnR5LiBNYXkgYmUgdGhpcyBkb2VzIG5vdCByZXByZXNlbnQgYSBjb21tb24NCj4NCj4gPiB1 c2UgY2FzZS4gQnV0IG5ldmVydGhlbGVzcywgd2UgaGF2ZSB0byBiZSBhd2FyZSBvZiB0aGlzIHNp ZGUgZWZmZWN0IHdoaWNoIFJGQzY1NTQNCj4NCj4gPiBzd2FwcGluZyBwcm9jZXNzIGRvZXMgbm90 IGhhdmUuDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gqKogIFBhc2NhbDogWWVzLCBT aW1vbiBtYWRlIHRoYXQgcG9pbnQgeWVzdGVyZGF5Lg0KPg0KPiA+DQo+DQo+ID4gqKogIEl0IGlz IGdlbmVyYWxseSBub3QgYSBnb29kIGlkZWEgdG8gcmV2ZXJzZSBhIHJvdXRpbmcgaGVhZGVyLiBU aGUgUkggbWF5IGhhdmUgYmVlbiB1c2VkIHRvIHN0YXkgYXdheSBmcm9tIHRoZSBzaG9ydGVzdCBw YXRoIGZvciBzb21lIHJlYXNvbiB0aGF0IGlzIG9ubHkgdmFsaWQgb24gdGhlIHdheSBpbiAoc2Vn bWVudCByb3V0aW5nKS4NCj4NCj4gPg0KPg0KPiA+IKiqICBQMlAgUlBMIHJldmVyc2VzIGEgcGF0 aCB0aGF0IGlzIGxlYXJudCByZWFjdGl2ZWx5LCBzbyB3ZSBoYXZlIGEgcmVhbCBwcm90b2NvbCBm b3IgZG9pbmcgdGhhdCBzb3J0IG9mIHRoaW5nIGFzIG9wcG9zZWQgdG8gYW4gZWNoby4NCj4NCj4g Pg0KPg0KPiA+IKiqICBSZXZlcnNpbmcgYSBoZWFkZXIgaXMgZGlzY291cmFnZWQgYnkgUkZDIDI0 NjAgKGZvciBSSDApIHVubGVzcyBpdCBpcyBhdXRoZW50aWNhdGVkICh3aGljaCBtZWFucyBBSCku IFdlIGRvIG5vdCBhdXRoZW50aWNhdGUgdGhlIFJIMywgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHJl YXNvbnMgZm9yIHRoYXQsIGdlbmVyYWwgZGVwcmVjYXRpb24gb2YgQUgsIG5vIHVzZSBvZiBBSCBp biBMTE5zIGV0YyYgTm90ZSB0aGF0IEFIIGRvZXMgbm90IHByb3RlY3QgdGhlIFJIIG9uIHRoZSB3 YXksIGl0IGlzIGp1c3QgYSB2YWxpZGF0aW9uIGF0IHRoZSByZWNlaXZlciBmb3IgdGhlIHNvbGUg dmFsdWUgb2YgcmV2ZXJzaW5nIGl0Lg0KPg0KPiA+DQo+DQo+ID4gqKogIEEgUlBMIGRvbWFpbiBp cyB1c3VhbGx5IHByb3RlY3RlZCBieSBMMiBzZWN1cml0eSBhbmQgdGhhdCBzZWN1cmVzIGJvdGgg UlBMIGl0c2VsZiBhbmQgdGhlIFJIIGluIHBhY2tldHMsIGF0IGV2ZXJ5IGhvcA0KPg0KPiA+DQo+ DQo+ID4gqKogIFRoZSBiZW5lZml0IG9mIHNhdmluZyBlbmVyZ3kgYW5kIGxvd2VyaW5nIHRoZSBj aGFuY2VzIG9mIGxvc3MgYXJlIHNlZW4gYXMgb3ZlcndoZWxtaW5nIGNvbXBhcmVkIHRvIHRoZSB2 YWx1ZSBvZiBwb3NzaWJseSByZXZlcnNpbmcgdGhlIGhlYWRlcg0KPg0KPiA+DQo+DQo+ID4gqKog IFlldCB3ZSBtaWdodCBkZWZpbmUgYSB2YXJpYXRpb24gd2hlcmUgd2UgZG8gbm90IHBvcCBvdXQg dGhlIGZpcnN0IGVudHJ5IGFzIHdlIGdvLiBJIGRvIG5vdCBzZWUgYSBjb25zZW5zdXMgb24gdGhl IHZhbHVlIG9mIGRvaW5nIGl0IG5vdy4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0K Pg0KPiA+DQo+DQo+ID4gR29pbmcgZnVydGhlciwgdGhlIERBTyBwcm9qZWN0aW9uIHByb3Bvc2Fs DQo+DQo+ID4gKGRyYWZ0LXRodWJlcnQtcm9sbC1kYW8tcHJvamVjdGlvbi0wMi50eHQpIHdpbGwg aGF2ZSBzZXZlcmFsIHZpcnR1YWwgcm9vdHMNCj4NCj4gPiBpbnNpZGUgdGhlIFJQTCBkb21haW4u IFRoZSBhdXRvbWF0aWMgYXNzdW1wdGlvbiBvZiBhIHdlbGwga25vd24gcm9vdCBtYXkgbm90IGFw cGx5DQo+DQo+ID4gd2hlbiBub2RlcyB3aXRoaW4gUlBMIGRvbWFpbiBjb21tdW5pY2F0ZSB3aXRo IGVhY2ggb3RoZXIuIEkgc3VwcG9zZSBpdCB3aWxsDQo+DQo+ID4gaGF2ZSBhIGJlYXJpbmcgb24g dGhlIFJIMy02TG9SSCBwZXJmb3JtYW5jZS4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4g PiCoqiAgSXQgaXMgbm90IHJlYWxseSBhbiBhc3N1bXB0aW9uLCBidXQgc29tZXRoaW5nIHdlIGxl dmVyYWdlIGFzIHdlIGdvLiBUaGUgUlBJIGlzIHZlcnkgbXVjaCBsaWtlIGEgY29udGV4dCBpbmRp Y2F0b3IuIElmIGFuIGFkZHJlc3Mgc2hhcmVzIGEgbG9uIHByZWZpeCB3aXRoIGEgcm9vdCwgYWRk aW5nIHRoZSBSUEkgb2YgdGhhdCByb290IGlzIGFjdHVhbGx5IGEgY29tcHJlc3Npb24gdGVjaG5p cXVlLg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IFRoZSBhYm92ZSBvYnNlcnZhdGlv bnMgYXJlIG5vdCBzZXJpb3VzLCBidXQgZmVlbHMgZ29vZCB0byBwb25kZXIgb3Zlci4gV2lsbCBi ZQ0KPg0KPiA+IGhhcHB5IHRvIHJlY2VpdmUgeW91ciBjb21tZW50cy4NCj4NCj4gPg0KPg0KPiA+ IFRoYW5rcyBBbmFuZCENCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiBQYXNjYWwNCj4N Cj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4gT24gTW9uZGF5IDE4 IEphbnVhcnkgMjAxNiAxMToyNCBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToN Cj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IERlYXIgYWxsDQo+DQo+ID4NCj4NCj4gPiA+DQo+ DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IFRoZSBw aWN0dXJlIGJlbG93IGlsbHVzdHJhdGVzIGhvdyB0aGUgUkgzIDZMb1JIIHdvcmtzIHdpdGggZHJh ZnQgMDMgaW4gYSBjYXNlIGxpa2UgUm9vdCAtPiBBIC0+IEIgLT4gQyAtPiBsZWFmDQo+DQo+ID4N Cj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4N Cj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IFRoZSBmaXJzdCA2TG9S SCBpcyBleHBlY3RlZCB0byBiZSBhIGZ1bGwgYWRkcmVzcyAoMTI4IGJpdHMpIHRvIHNldCB1cCBh IHJlZmVyZW5jZSBhbmQgdGhlIG5leHQgNkxvUkggYXJlIGV4cGVjdGVkIHRvIGJlIHNtYWxsZXIg YW5kIGp1c3Qgb3ZlcnJpZGUgdGhlIHJpZ2h0bW9zdCBiaXRzIHdoaWNoIGZvcm0gdGhlIGRlbHRh IGZyb20gdGhlIHJlZmVyZW5jZS4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4N Cj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gUHJvcG9zYWw6IHdlIGNvdWxkIGNv bnNpZGVyIHRoYXQgdGhlIDEyOGJpdHMgc291cmNlIG9mIHRoZSBJUCBoZWFkZXIgYmVmb3JlIHRo ZSBSSDMgaXMgdGhlIHJlZmVyZW5jZSB0byBzdGFydCB3aXRoLg0KPg0KPiA+DQo+DQo+ID4gPg0K Pg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBXaXRo IHRoYXQgZXZlbiB0aGUgZmlyc3QgaG9wIGNvdWxkIGJlIGNvbXByZXNzZWQgdGhlIHNhbWUgd2F5 IGFzIHRoZSBvdGhlciBob3BzLiBXaXRoIFJQTCwgdGhlIHJvb3QgaXMgdGhlIGVuY2Fwc3VsYXRv ciBpZiBJUCBpbiBJUCBpbiB1c2VkLiBHb29kIHRoaW5nLCBpbiB0aGF0IGNhc2UgdGhlIHJvb3Qg aXMgdG90YWxseSBlbGlkZWQgd2l0aCB0aGUgSVAtaW4tSVAgNkxvUkguDQo+DQo+ID4NCj4NCj4g PiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+ IFNvIHRoaXMgc2ltcGxlIHByb3Bvc2FsIHNhdmVzIHVwIHRvIDE2IG9jdGV0cyAodGhhdHMgaW4g dGhlIGNhc2Ugd2l0aCBhIHNpbmdsZSBzdWJuZXQgYW5kIGFsbCBhZGRyZXNzZXMgZGlmZmVyIG9u bHkgYnkgdGhlIGxhc3QgMiBieXRlcykuIEltIHdpbGxpbmcgdG8gYWRkIGl0IGluIHRoZSBuZXh0 IHJldmlzaW9uLg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+ DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBBbnkgb3Bwb3NpdGlvbj8NCj4NCj4gPg0KPg0KPiA+ ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4g UGFzY2FsDQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4g PiA+DQo+DQo+ID4NCj4NCj4gPiA+IC0tDQo+DQo+ID4NCj4NCj4gPiA+IFRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZA0KPg0KPiA+DQo+DQo+ID4gPiBkYW5nZXJv dXMgY29udGVudCBieSBNYWlsU2Nhbm5lciwgYW5kIGlzDQo+DQo+ID4NCj4NCj4gPiA+IGJlbGll dmVkIHRvIGJlIGNsZWFuLg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiA+DQo+DQo+ ID4gPiA2dGlzY2ggbWFpbGluZyBsaXN0DQo+DQo+ID4NCj4NCj4gPiA+IDZ0aXNjaEBpZXRmLm9y ZzxtYWlsdG86NnRpc2NoQGlldGYub3JnPg0KPg0KPiA+DQo+DQo+ID4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaA0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0K Pg0KPiA+IC0tDQo+DQo+ID4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVz ZXMgYW5kDQo+DQo+ID4gZGFuZ2Vyb3VzIGNvbnRlbnQgYnkgTWFpbFNjYW5uZXIsIGFuZCBpcw0K Pg0KPiA+IGJlbGlldmVkIHRvIGJlIGNsZWFuLg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPg0KPiA+IDZ0aXNj aCBtYWlsaW5nIGxpc3QNCj4NCj4gPiA2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBpZXRm Lm9yZz4NCj4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNj aA0KPg0KPg0KPiAtLQ0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQNCj4gZGFuZ2Vyb3VzIGNvbnRlbnQgYnkgTWFpbFNjYW5uZXIsIGFuZCBpcw0KPiBiZWxp ZXZlZCB0byBiZSBjbGVhbi4NCg0K --_000_BC1182E86737A7438C540E3B93DB7E518BDBB4SZXEMI507MBSchina_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hello everyone,

 

Please let me refresh m= y previous comments as follows.

 

draft-thubert-roll-asym= link-02

 

2-DODAGs for asymmetric= al links:

 

For upward routes (Inst= ance-1), root generates DIO message with MOP=3D0 (No downward routes are al= lowed). For this, no DAO messages are generated.

 

For downward routes (In= stance-2), root generates DIO messages with MOP=3D2 (Storing mode). Subsequ= ently, DAO messages are generated back to their immediate parents and routi= ng state information is stored in parent node for downward traffic.

 

So, root is the same fo= r both Instance-1 and Instance-2. Is this observation correct?

 

If my observation makes= sense then there won=A1=AFt be DAO messages, which were used in traditiona= l RPL (RFC6550), for upward route with 2 DODAGs (asymmetric links).

 

 

If we construct peer to= peer routes based on RFC6997, the story would be different from draft-thub= ert-roll-asymlink-02. In P2P-RPL (RFC6997), the source will act as a tempor= ary root and multicast the DIO-RDO messages with Instance-1. Once, the destination is reached through DIO-RDO the data= path from Destination to Source is created. Then we again need to initiate= DIO-RDO messages with Instance-2 at destination for the data path from Sou= rce to Destination.

 

If this observation is = true then P2P-RPL (RFC6997) will need to have two roots. Am I correct?=

 

With Regards,

Satish

 <= /p>

 <= /p>

Hi,

 

> > I found the P2P RPL very appropriate for the cu= rrent discussion. What is

> > interesting is that the Bidirectional Route pre= sented here actually enables

> > creating a symmetric path between end nodes by = passing on the complete path

> > information in its signaling messages. In this = process, routing state is

> > installed along the path.

> >

> >

> >

> > =A8=AA  I hope that we start new on-demand= work for RPL, based on this and AODV. It may be that the route is optimize= d for metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs= , one for each direction. This is discussed in https://tools.ietf.org/html/= draft-thubert-roll-asymlink-00

> >

> 

> Thanks for the draft! Would be happy to be part of t= he new work you are proposing :)

 

When we create 2 DODAGs for asymmetrical links, two DIO m= essages are generated:  one from source to destination (instance-1) an= d the other from destination to source (instance-2). So, there won=A1=AFt be any DAO or RDO messages in P2P-RPL based on asymme= tric links. Am I correct?

 

In P2P-RPL, =A1=AEAddress=A1=AF vector is created by the = source during DIO-RDO multicast for both hop-by-hop routing (non-storing mo= de) and source routing (storing mode). For asymmetric-link based P2P-RPL, one =A1=AEAddress=A1=AF vector (DIO-RDO) is created by sour= ce for Instance-1 to discover path from destination to source and the other= one needs to be created by destination to discover path from source to des= tination. If this is to be the proposing operations for asymmetrical P2P-RPL, then there would be two rounds of multicast comp= ared to just one round in the traditional P2P-RPL. It is desirable if we ca= n remove the =A1=AEAddress=A1=AF vector from the multicast DIO-RDO for asym= metric-link based P2P-RPL(especially for hop-by-hop routing).

 

With Regards,

Satish.

 

 

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of S.= V.R.Anand

Sent: 2016=D2=B42=EA=C5= 2=EC=ED 15:49

To: Pascal Thubert (pthubert); 6lo@ietf.org

Cc: 6tisch@ietf.org; Routing Over Low power and Lossy net= works

Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed impr= ovement in RH3-6LoRH...)

 

Hi Pascal,

 

Thanks a lot for your response and for all the references= . Please see my response in line.

 

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthub= ert) wrote:

> 

> Hello Anand:

> 

> 

> 

> Thanks for this, please see below:=

> 

> 

> Having a symmetric path, in principle, certainly off= ers advantages when we want

> the communicating nodes to use a well-defined path t= hat has been set up to meet

> the QoS requirements of an application. Such a pinne= d path can be appropriately

> provisioned with required bandwidth resources along = the entire path.

> 

> 

> 

> =A8=AA  True but in radios, the links may be ve= ry asymmetrical, and the optimal return path may be very different.

> 

> =A8=AA  So the pinned-down return path may be d= ifferent actually.

> 

 

Surely the presence of uni-directional routes cannot be i= gnored. Some of the

dominating factors like, routing overheads, route and res= ource state

maintenance on the nodes and the associated scalability i= ssues, implementation

complexity, and so on, will prompt network designers to d= eploy networks with

reliable bi-directional links and routes. Because of the = factors listed here,

one would like to ensure absence of bi-directional routes= will be more of an

exception rather than a norm. No ?

 

 

> 

> 

> I found the P2P RPL very appropriate for the current= discussion. What is

> interesting is that the Bidirectional Route presente= d here actually enables

> creating a symmetric path between end nodes by passi= ng on the complete path

> information in its signaling messages. In this proce= ss, routing state is

> installed along the path.

> 

> 

> 

> =A8=AA  I hope that we start new on-demand work= for RPL, based on this and AODV. It may be that the route is optimized for= metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs= , one for each direction. This is discussed in https://tools.ietf.org/html/= draft-thubert-roll-asymlink-00

> 

 

Thanks for the draft! Would be happy to be part of the ne= w work you are proposing :)

 

> 

> 

> As you noted, keeping signaling separate from data i= s certainly an elegant way.

> 

> There can however be contexts when in-band signaling= that uses RH3 as per

> RFC6554 data can be more efficient than using a sign= aling protocol, assuming

> the security concerns are addressed as per RFC2460. = This in-band approach is

> attractive when we want to set up a rapid on-the-fly= symmetric path along with

> 6TiSCH OTF making bandwidth reservation along the wa= y for transactional message

> exchanges. I am hinting at the possible PCE/NME base= d solution that (i) works

> with the RPL DODAG, (ii) considers the hop distance = between the communicating

> node to assess energy costs, (iii) optimizes network= resource availability, and

> finally provides right inputs for the nodes. It may = well be that dropping the

> address is the right choice.

> 

> 

> 

> =A8=AA  I can agree with that, and I used that = sort of method in https://tools.ietf.org/html/draft-thubert-tree-discovery<= o:p>

> 

> 

 

Thanks again! Started reading it. Looks like we are = revisiting concepts already developed many years back.

 

> 

> 

> I think I am doing too much of hand waving going on = by leaving out all the

> essential details. Hope I managed to vaguely convey = the point.

> 

> I tend to feel that distributed, centralized and the= ir combination might

> co-exist to optimize network resources, and therefor= e retaining or dropping the

> address in RH3-6LoRH can be made optional.

> 

> 

> 

> 

> 

> =A8=AA  Could be, but should we do it now or wh= en we have the actual need?

> 

> =A8=AA  Do you have a design in mind that limit= s the implementation overhead of supporting both?

> 

 

At the rick of sounding naive, can't the option of droppi= ng or retaining address be indicated by a bit ?

 

> 

> 

> Am I making sense ?

> 

> 

> 

> 

> 

> =A8=AA  To me, certainly J

> 

 

Anand

 

> 

> 

> Anand

> 

> 

> 

> 

> On Saturday 23 January 2016 02:34 PM, Pascal Thubert= (pthubert) wrote:

> >

> 

> > Hello Anand:

> 

> >

> 

> >

> 

> >

> 

> > 2 good points , that we need to continue in dif= ferent threads if we do.

> 

> >

> 

> >

> 

> > The source routing optimization done by droppin= g the addresses on the way

> 

> > certainly has benefits. However, there could be= loss of a natural "symmetric"

> 

> > property that one might want to enforce between= communicating end nodes in the

> 

> > routing path. By symmetry I mean using the same= path in both the directions of

> 

> > communication. Policy based routing, centralize= d routing, for instance, could

> 

> > be potential users of this property. May be thi= s does not represent a common

> 

> > use case. But nevertheless, we have to be aware= of this side effect which RFC6554

> 

> > swapping process does not have.

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  Pascal: Yes, Simon made that point= yesterday.

> 

> >

> 

> > =A8=AA  It is generally not a good idea to= reverse a routing header. The RH may have been used to stay away from the = shortest path for some reason that is only valid on the way in (segment routing).

> 

> >

> 

> > =A8=AA  P2P RPL reverses a path that is le= arnt reactively, so we have a real protocol for doing that sort of thing as= opposed to an echo.

> 

> >

> 

> > =A8=AA  Reversing a header is discouraged = by RFC 2460 (for RH0) unless it is authenticated (which means AH). We do no= t authenticate the RH3, there are a number of reasons for that, general deprecation of AH, no use of AH in LLNs etc& Note th= at AH does not protect the RH on the way, it is just a validation at the re= ceiver for the sole value of reversing it.

> 

> >

> 

> > =A8=AA  A RPL domain is usually protected = by L2 security and that secures both RPL itself and the RH in packets, at e= very hop

> 

> >

> 

> > =A8=AA  The benefit of saving energy and l= owering the chances of loss are seen as overwhelming compared to the value = of possibly reversing the header

> 

> >

> 

> > =A8=AA  Yet we might define a variation wh= ere we do not pop out the first entry as we go. I do not see a consensus on= the value of doing it now.

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > Going further, the DAO projection proposal=

> 

> > (draft-thubert-roll-dao-projection-02.txt) will= have several virtual roots

> 

> > inside the RPL domain. The automatic assumption= of a well known root may not apply

> 

> > when nodes within RPL domain communicate with e= ach other. I suppose it will

> 

> > have a bearing on the RH3-6LoRH performance.

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  It is not really an assumption, bu= t something we leverage as we go. The RPI is very much like a context indic= ator. If an address shares a lon prefix with a root, adding the RPI of that root is actually a compression technique.

> 

> >

> 

> >

> 

> >

> 

> > The above observations are not serious, but fee= ls good to ponder over. Will be

> 

> > happy to receive your comments.

> 

> >

> 

> > Thanks Anand!

> 

> >

> 

> >

> 

> >

> 

> > Pascal

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > On Monday 18 January 2016 11:24 PM, Pascal Thub= ert (pthubert) wrote:

> 

> > >

> 

> >

> 

> > > Dear all

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The picture below illustrates how the RH3 = 6LoRH works with draft 03 in a case like Root -> A -> B -> C ->= leaf

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The first 6LoRH is expected to be a full a= ddress (128 bits) to set up a reference and the next 6LoRH are expected to = be smaller and just override the rightmost bits which form the delta from the reference.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Proposal: we could consider that the 128bi= ts source of the IP header before the RH3 is the reference to start with.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > With that even the first hop could be comp= ressed the same way as the other hops. With RPL, the root is the encapsulat= or if IP in IP in used. Good thing, in that case the root is totally elided with the IP-in-IP 6LoRH.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > So this simple proposal saves up to 16 oct= ets (thats in the case with a single subnet and all addresses differ only b= y the last 2 bytes). Im willing to add it in the next revision.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Any opposition?

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Pascal

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > --

> 

> >

> 

> > > This message has been scanned for viruses = and

> 

> >

> 

> > > dangerous content by MailScanner, and is

> 

> >

> 

> > > believed to be clean.

> 

> >

> 

> > >

> 

> >

> 

> > > __________________________________________= _____

> 

> >

> 

> > > 6tisch mailing list

> 

> >

> 

> > > 6tisch@ietf.org<mailto:6tisch@ietf.org&= gt;

> 

> >

> 

> > > https://www.ietf.org/mailman/listinfo/6tis= ch

> 

> >

> 

> >

> 

> >

> 

> > --

> 

> > This message has been scanned for viruses and

> 

> > dangerous content by MailScanner, and is

> 

> > believed to be clean.

> 

> >

> 

> >

> 

> > _______________________________________________=

> 

> > 6tisch mailing list

> 

> > 6tisch@ietf.org<mailto:6tisch@ietf.org>

> 

> > https://www.ietf.org/mailman/listinfo/6tisch

> 

> 

> --

> This message has been scanned for viruses and

> dangerous content by MailScanner, and is<= /span>

> believed to be clean.

 

--_000_BC1182E86737A7438C540E3B93DB7E518BDBB4SZXEMI507MBSchina_-- From nobody Wed Feb 10 08:00:30 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91B41B2C3E; Wed, 10 Feb 2016 08:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kmgpxw8JzpyP; Wed, 10 Feb 2016 08:00:19 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C871B2C4B; Wed, 10 Feb 2016 08:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=100850; q=dns/txt; s=iport; t=1455120019; x=1456329619; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i4jQIS0fqlR709nSp4ZFx/XAFynw619TQ4D+C393xiw=; b=XxdJMA/E4YgphRYzt4dYQ5DgrPabdA/chqcPFfyW3fiRk1FtZ93qrGgc W+jxdSC/ul+cmSuCAJtUT6Qcpr+V8hs0TkAbJ0D+mqNMpV7DZ15Dp1moq qyOwCUHHfmGoMXm10S64xHfT7Y6aafelsvx/s4Ze5ikp2mQ6wK6AZbTMh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAsXbtW/5pdJa1egm5MUm0GiFaxI?= =?us-ascii?q?AENgWMDFwEJhSJKAhyBIDgUAQEBAQEBAYEKhEEBAQEDAQEBARcNBkELBQsCAQY?= =?us-ascii?q?CEQQBAQEgAQYHAiULFAkIAgQBDQUIEwSHdAgOlBSsDwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAREEgh+Dc4Q3hBYyF4QNBZJuhAoBhUuHfoFjhEOIVYptg1EBHgEBQoI?= =?us-ascii?q?AHIFIaocaAh4EAxZ8AQEB?= X-IronPort-AV: E=Sophos; i="5.22,426,1449532800"; d="scan'208,217"; a="70047602" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Feb 2016 16:00:17 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u1AG0HUI019583 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 10 Feb 2016 16:00:17 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 10 Feb 2016 10:00:16 -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.1104.009; Wed, 10 Feb 2016 10:00:16 -0600 From: "Pascal Thubert (pthubert)" To: "Satish Anamalamudi (Satish Anamalamudi)" , Routing Over Low power and Lossy networks , "6lo@ietf.org" <6lo@ietf.org> Thread-Topic: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) Thread-Index: AQHRZBwdzVc4Nr5l4EaF2w8GeZpy1Q== Date: Wed, 10 Feb 2016 16:00:08 +0000 Deferred-Delivery: Wed, 10 Feb 2016 15:59:49 +0000 Message-ID: <5afe3f6ee28847e6859488ba760e1069@XCH-RCD-001.cisco.com> References: <56B05F84.3080702@ece.iisc.ernet.in> In-Reply-To: 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.208.43] Content-Type: multipart/alternative; boundary="_000_5afe3f6ee28847e6859488ba760e1069XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed improvement in RH3-6LoRH...) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 16:00:25 -0000 --_000_5afe3f6ee28847e6859488ba760e1069XCHRCD001ciscocom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8gU2F0aXNoDQoNCkhlbGxvIGV2ZXJ5b25lLA0KDQpQbGVhc2UgbGV0IG1lIHJlZnJlc2gg bXkgcHJldmlvdXMgY29tbWVudHMgYXMgZm9sbG93cy4NCg0KZHJhZnQtdGh1YmVydC1yb2xsLWFz eW1saW5rLTAyDQoNCjItRE9EQUdzIGZvciBhc3ltbWV0cmljYWwgbGlua3M6DQoNCkZvciB1cHdh cmQgcm91dGVzIChJbnN0YW5jZS0xKSwgcm9vdCBnZW5lcmF0ZXMgRElPIG1lc3NhZ2Ugd2l0aCBN T1A9MCAoTm8gZG93bndhcmQgcm91dGVzIGFyZSBhbGxvd2VkKS4gRm9yIHRoaXMsIG5vIERBTyBt ZXNzYWdlcyBhcmUgZ2VuZXJhdGVkLg0KDQpGb3IgZG93bndhcmQgcm91dGVzIChJbnN0YW5jZS0y KSwgcm9vdCBnZW5lcmF0ZXMgRElPIG1lc3NhZ2VzIHdpdGggTU9QPTIgKFN0b3JpbmcgbW9kZSku IFN1YnNlcXVlbnRseSwgREFPIG1lc3NhZ2VzIGFyZSBnZW5lcmF0ZWQgYmFjayB0byB0aGVpciBp bW1lZGlhdGUgcGFyZW50cyBhbmQgcm91dGluZyBzdGF0ZSBpbmZvcm1hdGlvbiBpcyBzdG9yZWQg aW4gcGFyZW50IG5vZGUgZm9yIGRvd253YXJkIHRyYWZmaWMuDQoNClNvLCByb290IGlzIHRoZSBz YW1lIGZvciBib3RoIEluc3RhbmNlLTEgYW5kIEluc3RhbmNlLTIuIElzIHRoaXMgb2JzZXJ2YXRp b24gY29ycmVjdD8NCg0KDQpQVCA+IGNvcnJlY3QNCg0KSWYgbXkgb2JzZXJ2YXRpb24gbWFrZXMg c2Vuc2UgdGhlbiB0aGVyZSB3b26hr3QgYmUgREFPIG1lc3NhZ2VzLCB3aGljaCB3ZXJlIHVzZWQg aW4gdHJhZGl0aW9uYWwgUlBMIChSRkM2NTUwKSwgZm9yIHVwd2FyZCByb3V0ZSB3aXRoIDIgRE9E QUdzIChhc3ltbWV0cmljIGxpbmtzKS4NCg0KDQpJZiB3ZSBjb25zdHJ1Y3QgcGVlciB0byBwZWVy IHJvdXRlcyBiYXNlZCBvbiBSRkM2OTk3LCB0aGUgc3Rvcnkgd291bGQgYmUgZGlmZmVyZW50IGZy b20gZHJhZnQtdGh1YmVydC1yb2xsLWFzeW1saW5rLTAyLiBJbiBQMlAtUlBMIChSRkM2OTk3KSwg dGhlIHNvdXJjZSB3aWxsIGFjdCBhcyBhIHRlbXBvcmFyeSByb290IGFuZCBtdWx0aWNhc3QgdGhl IERJTy1SRE8gbWVzc2FnZXMgd2l0aCBJbnN0YW5jZS0xLiBPbmNlLCB0aGUgZGVzdGluYXRpb24g aXMgcmVhY2hlZCB0aHJvdWdoIERJTy1SRE8gdGhlIGRhdGEgcGF0aCBmcm9tIERlc3RpbmF0aW9u IHRvIFNvdXJjZSBpcyBjcmVhdGVkLiBUaGVuIHdlIGFnYWluIG5lZWQgdG8gaW5pdGlhdGUgRElP LVJETyBtZXNzYWdlcyB3aXRoIEluc3RhbmNlLTIgYXQgZGVzdGluYXRpb24gZm9yIHRoZSBkYXRh IHBhdGggZnJvbSBTb3VyY2UgdG8gRGVzdGluYXRpb24uDQoNCklmIHRoaXMgb2JzZXJ2YXRpb24g aXMgdHJ1ZSB0aGVuIFAyUC1SUEwgKFJGQzY5OTcpIHdpbGwgbmVlZCB0byBoYXZlIHR3byByb290 cy4gQW0gSSBjb3JyZWN0Pw0KDQoNClBUID4gVGhpcyBpcyBwcm9iYWJseSBhIGdvb2QgYXBwcm9h Y2gsIHllcy4gRWFjaCBEQUcgd291bGQgYmUgZGlyZWN0aW9uYWwsIHRoYXQgaXMgYmFzZWQgb24g bWV0cmljcyBpbiBvbmUgZGlyZWN0aW9uLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCg0KSGks DQoNCj4gPiBJIGZvdW5kIHRoZSBQMlAgUlBMIHZlcnkgYXBwcm9wcmlhdGUgZm9yIHRoZSBjdXJy ZW50IGRpc2N1c3Npb24uIFdoYXQgaXMNCj4gPiBpbnRlcmVzdGluZyBpcyB0aGF0IHRoZSBCaWRp cmVjdGlvbmFsIFJvdXRlIHByZXNlbnRlZCBoZXJlIGFjdHVhbGx5IGVuYWJsZXMNCj4gPiBjcmVh dGluZyBhIHN5bW1ldHJpYyBwYXRoIGJldHdlZW4gZW5kIG5vZGVzIGJ5IHBhc3Npbmcgb24gdGhl IGNvbXBsZXRlIHBhdGgNCj4gPiBpbmZvcm1hdGlvbiBpbiBpdHMgc2lnbmFsaW5nIG1lc3NhZ2Vz LiBJbiB0aGlzIHByb2Nlc3MsIHJvdXRpbmcgc3RhdGUgaXMNCj4gPiBpbnN0YWxsZWQgYWxvbmcg dGhlIHBhdGguDQo+ID4NCj4gPg0KPiA+DQo+ID4gqKogIEkgaG9wZSB0aGF0IHdlIHN0YXJ0IG5l dyBvbi1kZW1hbmQgd29yayBmb3IgUlBMLCBiYXNlZCBvbiB0aGlzIGFuZCBBT0RWLiBJdCBtYXkg YmUgdGhhdCB0aGUgcm91dGUgaXMgb3B0aW1pemVkIGZvciBtZXRyaWNzIHRoYXQgYXJlIG1vc3Rs eSBkaXJlY3Rpb25hbCwgb25lIHdheSBvciB0aGUgb3RoZXIsIGlmIHRoZSB0cmFmZmljIGlzIHNv LiBJZGVhbGx5IHdlZCBidWlsZCBhbmQgYXNzb2NpYXRlZCAyIERPREFHcywgb25lIGZvciBlYWNo IGRpcmVjdGlvbi4gVGhpcyBpcyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0wMA0KPiA+DQo+DQo+IFRoYW5rcyBmb3Ig dGhlIGRyYWZ0ISBXb3VsZCBiZSBoYXBweSB0byBiZSBwYXJ0IG9mIHRoZSBuZXcgd29yayB5b3Ug YXJlIHByb3Bvc2luZyA6KQ0KDQpXaGVuIHdlIGNyZWF0ZSAyIERPREFHcyBmb3IgYXN5bW1ldHJp Y2FsIGxpbmtzLCB0d28gRElPIG1lc3NhZ2VzIGFyZSBnZW5lcmF0ZWQ6ICBvbmUgZnJvbSBzb3Vy Y2UgdG8gZGVzdGluYXRpb24gKGluc3RhbmNlLTEpIGFuZCB0aGUgb3RoZXIgZnJvbSBkZXN0aW5h dGlvbiB0byBzb3VyY2UgKGluc3RhbmNlLTIpLiBTbywgdGhlcmUgd29uoa90IGJlIGFueSBEQU8g b3IgUkRPIG1lc3NhZ2VzIGluIFAyUC1SUEwgYmFzZWQgb24gYXN5bW1ldHJpYyBsaW5rcy4gQW0g SSBjb3JyZWN0Pw0KDQpJbiBQMlAtUlBMLCChrkFkZHJlc3OhryB2ZWN0b3IgaXMgY3JlYXRlZCBi eSB0aGUgc291cmNlIGR1cmluZyBESU8tUkRPIG11bHRpY2FzdCBmb3IgYm90aCBob3AtYnktaG9w IHJvdXRpbmcgKG5vbi1zdG9yaW5nIG1vZGUpIGFuZCBzb3VyY2Ugcm91dGluZyAoc3RvcmluZyBt b2RlKS4gRm9yIGFzeW1tZXRyaWMtbGluayBiYXNlZCBQMlAtUlBMLCBvbmUgoa5BZGRyZXNzoa8g dmVjdG9yIChESU8tUkRPKSBpcyBjcmVhdGVkIGJ5IHNvdXJjZSBmb3IgSW5zdGFuY2UtMSB0byBk aXNjb3ZlciBwYXRoIGZyb20gZGVzdGluYXRpb24gdG8gc291cmNlIGFuZCB0aGUgb3RoZXIgb25l IG5lZWRzIHRvIGJlIGNyZWF0ZWQgYnkgZGVzdGluYXRpb24gdG8gZGlzY292ZXIgcGF0aCBmcm9t IHNvdXJjZSB0byBkZXN0aW5hdGlvbi4gSWYgdGhpcyBpcyB0byBiZSB0aGUgcHJvcG9zaW5nIG9w ZXJhdGlvbnMgZm9yIGFzeW1tZXRyaWNhbCBQMlAtUlBMLCB0aGVuIHRoZXJlIHdvdWxkIGJlIHR3 byByb3VuZHMgb2YgbXVsdGljYXN0IGNvbXBhcmVkIHRvIGp1c3Qgb25lIHJvdW5kIGluIHRoZSB0 cmFkaXRpb25hbCBQMlAtUlBMLiBJdCBpcyBkZXNpcmFibGUgaWYgd2UgY2FuIHJlbW92ZSB0aGUg oa5BZGRyZXNzoa8gdmVjdG9yIGZyb20gdGhlIG11bHRpY2FzdCBESU8tUkRPIGZvciBhc3ltbWV0 cmljLWxpbmsgYmFzZWQgUDJQLVJQTChlc3BlY2lhbGx5IGZvciBob3AtYnktaG9wIHJvdXRpbmcp Lg0KDQpXaXRoIFJlZ2FyZHMsDQpTYXRpc2guDQoNCg0KRnJvbTogUm9sbCBbbWFpbHRvOnJvbGwt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFMuVi5SLkFuYW5kDQpTZW50OiAyMDE20rQy 6sUy7O0gMTU6NDkNClRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyA2bG9AaWV0Zi5vcmc8 bWFpbHRvOjZsb0BpZXRmLm9yZz4NCkNjOiA2dGlzY2hAaWV0Zi5vcmc8bWFpbHRvOjZ0aXNjaEBp ZXRmLm9yZz47IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzDQpTdWJq ZWN0OiBSZTogW1JvbGxdIE9uIDZMb1JIIGlzc3VlICMxMSAod2FzIFByb3Bvc2VkIGltcHJvdmVt ZW50IGluIFJIMy02TG9SSC4uLikNCg0KSGkgUGFzY2FsLA0KDQpUaGFua3MgYSBsb3QgZm9yIHlv dXIgcmVzcG9uc2UgYW5kIGZvciBhbGwgdGhlIHJlZmVyZW5jZXMuIFBsZWFzZSBzZWUgbXkgcmVz cG9uc2UgaW4gbGluZS4NCg0KT24gU3VuZGF5IDMxIEphbnVhcnkgMjAxNiAwMzowNSBQTSwgUGFz Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4NCj4gSGVsbG8gQW5hbmQ6DQo+DQo+DQo+ DQo+IFRoYW5rcyBmb3IgdGhpcywgcGxlYXNlIHNlZSBiZWxvdzoNCj4NCj4NCj4gSGF2aW5nIGEg c3ltbWV0cmljIHBhdGgsIGluIHByaW5jaXBsZSwgY2VydGFpbmx5IG9mZmVycyBhZHZhbnRhZ2Vz IHdoZW4gd2Ugd2FudA0KPiB0aGUgY29tbXVuaWNhdGluZyBub2RlcyB0byB1c2UgYSB3ZWxsLWRl ZmluZWQgcGF0aCB0aGF0IGhhcyBiZWVuIHNldCB1cCB0byBtZWV0DQo+IHRoZSBRb1MgcmVxdWly ZW1lbnRzIG9mIGFuIGFwcGxpY2F0aW9uLiBTdWNoIGEgcGlubmVkIHBhdGggY2FuIGJlIGFwcHJv cHJpYXRlbHkNCj4gcHJvdmlzaW9uZWQgd2l0aCByZXF1aXJlZCBiYW5kd2lkdGggcmVzb3VyY2Vz IGFsb25nIHRoZSBlbnRpcmUgcGF0aC4NCj4NCj4NCj4NCj4gqKogIFRydWUgYnV0IGluIHJhZGlv cywgdGhlIGxpbmtzIG1heSBiZSB2ZXJ5IGFzeW1tZXRyaWNhbCwgYW5kIHRoZSBvcHRpbWFsIHJl dHVybiBwYXRoIG1heSBiZSB2ZXJ5IGRpZmZlcmVudC4NCj4NCj4gqKogIFNvIHRoZSBwaW5uZWQt ZG93biByZXR1cm4gcGF0aCBtYXkgYmUgZGlmZmVyZW50IGFjdHVhbGx5Lg0KPg0KDQpTdXJlbHkg dGhlIHByZXNlbmNlIG9mIHVuaS1kaXJlY3Rpb25hbCByb3V0ZXMgY2Fubm90IGJlIGlnbm9yZWQu IFNvbWUgb2YgdGhlDQpkb21pbmF0aW5nIGZhY3RvcnMgbGlrZSwgcm91dGluZyBvdmVyaGVhZHMs IHJvdXRlIGFuZCByZXNvdXJjZSBzdGF0ZQ0KbWFpbnRlbmFuY2Ugb24gdGhlIG5vZGVzIGFuZCB0 aGUgYXNzb2NpYXRlZCBzY2FsYWJpbGl0eSBpc3N1ZXMsIGltcGxlbWVudGF0aW9uDQpjb21wbGV4 aXR5LCBhbmQgc28gb24sIHdpbGwgcHJvbXB0IG5ldHdvcmsgZGVzaWduZXJzIHRvIGRlcGxveSBu ZXR3b3JrcyB3aXRoDQpyZWxpYWJsZSBiaS1kaXJlY3Rpb25hbCBsaW5rcyBhbmQgcm91dGVzLiBC ZWNhdXNlIG9mIHRoZSBmYWN0b3JzIGxpc3RlZCBoZXJlLA0Kb25lIHdvdWxkIGxpa2UgdG8gZW5z dXJlIGFic2VuY2Ugb2YgYmktZGlyZWN0aW9uYWwgcm91dGVzIHdpbGwgYmUgbW9yZSBvZiBhbg0K ZXhjZXB0aW9uIHJhdGhlciB0aGFuIGEgbm9ybS4gTm8gPw0KDQoNCj4NCj4NCj4gSSBmb3VuZCB0 aGUgUDJQIFJQTCB2ZXJ5IGFwcHJvcHJpYXRlIGZvciB0aGUgY3VycmVudCBkaXNjdXNzaW9uLiBX aGF0IGlzDQo+IGludGVyZXN0aW5nIGlzIHRoYXQgdGhlIEJpZGlyZWN0aW9uYWwgUm91dGUgcHJl c2VudGVkIGhlcmUgYWN0dWFsbHkgZW5hYmxlcw0KPiBjcmVhdGluZyBhIHN5bW1ldHJpYyBwYXRo IGJldHdlZW4gZW5kIG5vZGVzIGJ5IHBhc3Npbmcgb24gdGhlIGNvbXBsZXRlIHBhdGgNCj4gaW5m b3JtYXRpb24gaW4gaXRzIHNpZ25hbGluZyBtZXNzYWdlcy4gSW4gdGhpcyBwcm9jZXNzLCByb3V0 aW5nIHN0YXRlIGlzDQo+IGluc3RhbGxlZCBhbG9uZyB0aGUgcGF0aC4NCj4NCj4NCj4NCj4gqKog IEkgaG9wZSB0aGF0IHdlIHN0YXJ0IG5ldyBvbi1kZW1hbmQgd29yayBmb3IgUlBMLCBiYXNlZCBv biB0aGlzIGFuZCBBT0RWLiBJdCBtYXkgYmUgdGhhdCB0aGUgcm91dGUgaXMgb3B0aW1pemVkIGZv ciBtZXRyaWNzIHRoYXQgYXJlIG1vc3RseSBkaXJlY3Rpb25hbCwgb25lIHdheSBvciB0aGUgb3Ro ZXIsIGlmIHRoZSB0cmFmZmljIGlzIHNvLiBJZGVhbGx5IHdlZCBidWlsZCBhbmQgYXNzb2NpYXRl ZCAyIERPREFHcywgb25lIGZvciBlYWNoIGRpcmVjdGlvbi4gVGhpcyBpcyBkaXNjdXNzZWQgaW4g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtcm9sbC1hc3ltbGluay0w MA0KPg0KDQpUaGFua3MgZm9yIHRoZSBkcmFmdCEgV291bGQgYmUgaGFwcHkgdG8gYmUgcGFydCBv ZiB0aGUgbmV3IHdvcmsgeW91IGFyZSBwcm9wb3NpbmcgOikNCg0KPg0KPg0KPiBBcyB5b3Ugbm90 ZWQsIGtlZXBpbmcgc2lnbmFsaW5nIHNlcGFyYXRlIGZyb20gZGF0YSBpcyBjZXJ0YWlubHkgYW4g ZWxlZ2FudCB3YXkuDQo+DQo+IFRoZXJlIGNhbiBob3dldmVyIGJlIGNvbnRleHRzIHdoZW4gaW4t YmFuZCBzaWduYWxpbmcgdGhhdCB1c2VzIFJIMyBhcyBwZXINCj4gUkZDNjU1NCBkYXRhIGNhbiBi ZSBtb3JlIGVmZmljaWVudCB0aGFuIHVzaW5nIGEgc2lnbmFsaW5nIHByb3RvY29sLCBhc3N1bWlu Zw0KPiB0aGUgc2VjdXJpdHkgY29uY2VybnMgYXJlIGFkZHJlc3NlZCBhcyBwZXIgUkZDMjQ2MC4g VGhpcyBpbi1iYW5kIGFwcHJvYWNoIGlzDQo+IGF0dHJhY3RpdmUgd2hlbiB3ZSB3YW50IHRvIHNl dCB1cCBhIHJhcGlkIG9uLXRoZS1mbHkgc3ltbWV0cmljIHBhdGggYWxvbmcgd2l0aA0KPiA2VGlT Q0ggT1RGIG1ha2luZyBiYW5kd2lkdGggcmVzZXJ2YXRpb24gYWxvbmcgdGhlIHdheSBmb3IgdHJh bnNhY3Rpb25hbCBtZXNzYWdlDQo+IGV4Y2hhbmdlcy4gSSBhbSBoaW50aW5nIGF0IHRoZSBwb3Nz aWJsZSBQQ0UvTk1FIGJhc2VkIHNvbHV0aW9uIHRoYXQgKGkpIHdvcmtzDQo+IHdpdGggdGhlIFJQ TCBET0RBRywgKGlpKSBjb25zaWRlcnMgdGhlIGhvcCBkaXN0YW5jZSBiZXR3ZWVuIHRoZSBjb21t dW5pY2F0aW5nDQo+IG5vZGUgdG8gYXNzZXNzIGVuZXJneSBjb3N0cywgKGlpaSkgb3B0aW1pemVz IG5ldHdvcmsgcmVzb3VyY2UgYXZhaWxhYmlsaXR5LCBhbmQNCj4gZmluYWxseSBwcm92aWRlcyBy aWdodCBpbnB1dHMgZm9yIHRoZSBub2Rlcy4gSXQgbWF5IHdlbGwgYmUgdGhhdCBkcm9wcGluZyB0 aGUNCj4gYWRkcmVzcyBpcyB0aGUgcmlnaHQgY2hvaWNlLg0KPg0KPg0KPg0KPiCoqiAgSSBjYW4g YWdyZWUgd2l0aCB0aGF0LCBhbmQgSSB1c2VkIHRoYXQgc29ydCBvZiBtZXRob2QgaW4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRodWJlcnQtdHJlZS1kaXNjb3ZlcnkNCj4NCj4N Cg0KVGhhbmtzIGFnYWluISBTdGFydGVkIHJlYWRpbmcgaXQuIExvb2tzIGxpa2Ugd2UgYXJlICBy ZXZpc2l0aW5nIGNvbmNlcHRzIGFscmVhZHkgZGV2ZWxvcGVkIG1hbnkgeWVhcnMgYmFjay4NCg0K Pg0KPg0KPiBJIHRoaW5rIEkgYW0gZG9pbmcgdG9vIG11Y2ggb2YgaGFuZCB3YXZpbmcgZ29pbmcg b24gYnkgbGVhdmluZyBvdXQgYWxsIHRoZQ0KPiBlc3NlbnRpYWwgZGV0YWlscy4gSG9wZSBJIG1h bmFnZWQgdG8gdmFndWVseSBjb252ZXkgdGhlIHBvaW50Lg0KPg0KPiBJIHRlbmQgdG8gZmVlbCB0 aGF0IGRpc3RyaWJ1dGVkLCBjZW50cmFsaXplZCBhbmQgdGhlaXIgY29tYmluYXRpb24gbWlnaHQN Cj4gY28tZXhpc3QgdG8gb3B0aW1pemUgbmV0d29yayByZXNvdXJjZXMsIGFuZCB0aGVyZWZvcmUg cmV0YWluaW5nIG9yIGRyb3BwaW5nIHRoZQ0KPiBhZGRyZXNzIGluIFJIMy02TG9SSCBjYW4gYmUg bWFkZSBvcHRpb25hbC4NCj4NCj4NCj4NCj4NCj4NCj4gqKogIENvdWxkIGJlLCBidXQgc2hvdWxk IHdlIGRvIGl0IG5vdyBvciB3aGVuIHdlIGhhdmUgdGhlIGFjdHVhbCBuZWVkPw0KPg0KPiCoqiAg RG8geW91IGhhdmUgYSBkZXNpZ24gaW4gbWluZCB0aGF0IGxpbWl0cyB0aGUgaW1wbGVtZW50YXRp b24gb3ZlcmhlYWQgb2Ygc3VwcG9ydGluZyBib3RoPw0KPg0KDQpBdCB0aGUgcmljayBvZiBzb3Vu ZGluZyBuYWl2ZSwgY2FuJ3QgdGhlIG9wdGlvbiBvZiBkcm9wcGluZyBvciByZXRhaW5pbmcgYWRk cmVzcyBiZSBpbmRpY2F0ZWQgYnkgYSBiaXQgPw0KDQo+DQo+DQo+IEFtIEkgbWFraW5nIHNlbnNl ID8NCj4NCj4NCj4NCj4NCj4NCj4gqKogIFRvIG1lLCBjZXJ0YWlubHkgSg0KPg0KDQpBbmFuZA0K DQo+DQo+DQo+IEFuYW5kDQo+DQo+DQo+DQo+DQo+IE9uIFNhdHVyZGF5IDIzIEphbnVhcnkgMjAx NiAwMjozNCBQTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4gPg0KPg0KPiA+ IEhlbGxvIEFuYW5kOg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IDIgZ29vZCBwb2lu dHMgLCB0aGF0IHdlIG5lZWQgdG8gY29udGludWUgaW4gZGlmZmVyZW50IHRocmVhZHMgaWYgd2Ug ZG8uDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IFRoZSBzb3VyY2Ugcm91dGluZyBvcHRpbWl6YXRp b24gZG9uZSBieSBkcm9wcGluZyB0aGUgYWRkcmVzc2VzIG9uIHRoZSB3YXkNCj4NCj4gPiBjZXJ0 YWlubHkgaGFzIGJlbmVmaXRzLiBIb3dldmVyLCB0aGVyZSBjb3VsZCBiZSBsb3NzIG9mIGEgbmF0 dXJhbCAic3ltbWV0cmljIg0KPg0KPiA+IHByb3BlcnR5IHRoYXQgb25lIG1pZ2h0IHdhbnQgdG8g ZW5mb3JjZSBiZXR3ZWVuIGNvbW11bmljYXRpbmcgZW5kIG5vZGVzIGluIHRoZQ0KPg0KPiA+IHJv dXRpbmcgcGF0aC4gQnkgc3ltbWV0cnkgSSBtZWFuIHVzaW5nIHRoZSBzYW1lIHBhdGggaW4gYm90 aCB0aGUgZGlyZWN0aW9ucyBvZg0KPg0KPiA+IGNvbW11bmljYXRpb24uIFBvbGljeSBiYXNlZCBy b3V0aW5nLCBjZW50cmFsaXplZCByb3V0aW5nLCBmb3IgaW5zdGFuY2UsIGNvdWxkDQo+DQo+ID4g YmUgcG90ZW50aWFsIHVzZXJzIG9mIHRoaXMgcHJvcGVydHkuIE1heSBiZSB0aGlzIGRvZXMgbm90 IHJlcHJlc2VudCBhIGNvbW1vbg0KPg0KPiA+IHVzZSBjYXNlLiBCdXQgbmV2ZXJ0aGVsZXNzLCB3 ZSBoYXZlIHRvIGJlIGF3YXJlIG9mIHRoaXMgc2lkZSBlZmZlY3Qgd2hpY2ggUkZDNjU1NA0KPg0K PiA+IHN3YXBwaW5nIHByb2Nlc3MgZG9lcyBub3QgaGF2ZS4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ ID4NCj4NCj4gPiCoqiAgUGFzY2FsOiBZZXMsIFNpbW9uIG1hZGUgdGhhdCBwb2ludCB5ZXN0ZXJk YXkuDQo+DQo+ID4NCj4NCj4gPiCoqiAgSXQgaXMgZ2VuZXJhbGx5IG5vdCBhIGdvb2QgaWRlYSB0 byByZXZlcnNlIGEgcm91dGluZyBoZWFkZXIuIFRoZSBSSCBtYXkgaGF2ZSBiZWVuIHVzZWQgdG8g c3RheSBhd2F5IGZyb20gdGhlIHNob3J0ZXN0IHBhdGggZm9yIHNvbWUgcmVhc29uIHRoYXQgaXMg b25seSB2YWxpZCBvbiB0aGUgd2F5IGluIChzZWdtZW50IHJvdXRpbmcpLg0KPg0KPiA+DQo+DQo+ ID4gqKogIFAyUCBSUEwgcmV2ZXJzZXMgYSBwYXRoIHRoYXQgaXMgbGVhcm50IHJlYWN0aXZlbHks IHNvIHdlIGhhdmUgYSByZWFsIHByb3RvY29sIGZvciBkb2luZyB0aGF0IHNvcnQgb2YgdGhpbmcg YXMgb3Bwb3NlZCB0byBhbiBlY2hvLg0KPg0KPiA+DQo+DQo+ID4gqKogIFJldmVyc2luZyBhIGhl YWRlciBpcyBkaXNjb3VyYWdlZCBieSBSRkMgMjQ2MCAoZm9yIFJIMCkgdW5sZXNzIGl0IGlzIGF1 dGhlbnRpY2F0ZWQgKHdoaWNoIG1lYW5zIEFIKS4gV2UgZG8gbm90IGF1dGhlbnRpY2F0ZSB0aGUg UkgzLCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgcmVhc29ucyBmb3IgdGhhdCwgZ2VuZXJhbCBkZXBy ZWNhdGlvbiBvZiBBSCwgbm8gdXNlIG9mIEFIIGluIExMTnMgZXRjJiBOb3RlIHRoYXQgQUggZG9l cyBub3QgcHJvdGVjdCB0aGUgUkggb24gdGhlIHdheSwgaXQgaXMganVzdCBhIHZhbGlkYXRpb24g YXQgdGhlIHJlY2VpdmVyIGZvciB0aGUgc29sZSB2YWx1ZSBvZiByZXZlcnNpbmcgaXQuDQo+DQo+ ID4NCj4NCj4gPiCoqiAgQSBSUEwgZG9tYWluIGlzIHVzdWFsbHkgcHJvdGVjdGVkIGJ5IEwyIHNl Y3VyaXR5IGFuZCB0aGF0IHNlY3VyZXMgYm90aCBSUEwgaXRzZWxmIGFuZCB0aGUgUkggaW4gcGFj a2V0cywgYXQgZXZlcnkgaG9wDQo+DQo+ID4NCj4NCj4gPiCoqiAgVGhlIGJlbmVmaXQgb2Ygc2F2 aW5nIGVuZXJneSBhbmQgbG93ZXJpbmcgdGhlIGNoYW5jZXMgb2YgbG9zcyBhcmUgc2VlbiBhcyBv dmVyd2hlbG1pbmcgY29tcGFyZWQgdG8gdGhlIHZhbHVlIG9mIHBvc3NpYmx5IHJldmVyc2luZyB0 aGUgaGVhZGVyDQo+DQo+ID4NCj4NCj4gPiCoqiAgWWV0IHdlIG1pZ2h0IGRlZmluZSBhIHZhcmlh dGlvbiB3aGVyZSB3ZSBkbyBub3QgcG9wIG91dCB0aGUgZmlyc3QgZW50cnkgYXMgd2UgZ28uIEkg ZG8gbm90IHNlZSBhIGNvbnNlbnN1cyBvbiB0aGUgdmFsdWUgb2YgZG9pbmcgaXQgbm93Lg0KPg0K PiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPiBHb2luZyBmdXJ0aGVy LCB0aGUgREFPIHByb2plY3Rpb24gcHJvcG9zYWwNCj4NCj4gPiAoZHJhZnQtdGh1YmVydC1yb2xs LWRhby1wcm9qZWN0aW9uLTAyLnR4dCkgd2lsbCBoYXZlIHNldmVyYWwgdmlydHVhbCByb290cw0K Pg0KPiA+IGluc2lkZSB0aGUgUlBMIGRvbWFpbi4gVGhlIGF1dG9tYXRpYyBhc3N1bXB0aW9uIG9m IGEgd2VsbCBrbm93biByb290IG1heSBub3QgYXBwbHkNCj4NCj4gPiB3aGVuIG5vZGVzIHdpdGhp biBSUEwgZG9tYWluIGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlci4gSSBzdXBwb3NlIGl0IHdp bGwNCj4NCj4gPiBoYXZlIGEgYmVhcmluZyBvbiB0aGUgUkgzLTZMb1JIIHBlcmZvcm1hbmNlLg0K Pg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IKiqICBJdCBpcyBub3QgcmVhbGx5IGFuIGFz c3VtcHRpb24sIGJ1dCBzb21ldGhpbmcgd2UgbGV2ZXJhZ2UgYXMgd2UgZ28uIFRoZSBSUEkgaXMg dmVyeSBtdWNoIGxpa2UgYSBjb250ZXh0IGluZGljYXRvci4gSWYgYW4gYWRkcmVzcyBzaGFyZXMg YSBsb24gcHJlZml4IHdpdGggYSByb290LCBhZGRpbmcgdGhlIFJQSSBvZiB0aGF0IHJvb3QgaXMg YWN0dWFsbHkgYSBjb21wcmVzc2lvbiB0ZWNobmlxdWUuDQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+ DQo+DQo+ID4gVGhlIGFib3ZlIG9ic2VydmF0aW9ucyBhcmUgbm90IHNlcmlvdXMsIGJ1dCBmZWVs cyBnb29kIHRvIHBvbmRlciBvdmVyLiBXaWxsIGJlDQo+DQo+ID4gaGFwcHkgdG8gcmVjZWl2ZSB5 b3VyIGNvbW1lbnRzLg0KPg0KPiA+DQo+DQo+ID4gVGhhbmtzIEFuYW5kIQ0KPg0KPiA+DQo+DQo+ ID4NCj4NCj4gPg0KPg0KPiA+IFBhc2NhbA0KPg0KPiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+ DQo+DQo+ID4NCj4NCj4gPiBPbiBNb25kYXkgMTggSmFudWFyeSAyMDE2IDExOjI0IFBNLCBQYXNj YWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4g RGVhciBhbGwNCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0K PiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gVGhlIHBpY3R1cmUgYmVsb3cgaWxsdXN0cmF0ZXMgaG93 IHRoZSBSSDMgNkxvUkggd29ya3Mgd2l0aCBkcmFmdCAwMyBpbiBhIGNhc2UgbGlrZSBSb290IC0+ IEEgLT4gQiAtPiBDIC0+IGxlYWYNCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4N Cj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4N Cj4gPg0KPg0KPiA+ID4gVGhlIGZpcnN0IDZMb1JIIGlzIGV4cGVjdGVkIHRvIGJlIGEgZnVsbCBh ZGRyZXNzICgxMjggYml0cykgdG8gc2V0IHVwIGEgcmVmZXJlbmNlIGFuZCB0aGUgbmV4dCA2TG9S SCBhcmUgZXhwZWN0ZWQgdG8gYmUgc21hbGxlciBhbmQganVzdCBvdmVycmlkZSB0aGUgcmlnaHRt b3N0IGJpdHMgd2hpY2ggZm9ybSB0aGUgZGVsdGEgZnJvbSB0aGUgcmVmZXJlbmNlLg0KPg0KPiA+ DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+ DQo+ID4gPiBQcm9wb3NhbDogd2UgY291bGQgY29uc2lkZXIgdGhhdCB0aGUgMTI4Yml0cyBzb3Vy Y2Ugb2YgdGhlIElQIGhlYWRlciBiZWZvcmUgdGhlIFJIMyBpcyB0aGUgcmVmZXJlbmNlIHRvIHN0 YXJ0IHdpdGguDQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4N Cj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IFdpdGggdGhhdCBldmVuIHRoZSBmaXJzdCBob3AgY291 bGQgYmUgY29tcHJlc3NlZCB0aGUgc2FtZSB3YXkgYXMgdGhlIG90aGVyIGhvcHMuIFdpdGggUlBM LCB0aGUgcm9vdCBpcyB0aGUgZW5jYXBzdWxhdG9yIGlmIElQIGluIElQIGluIHVzZWQuIEdvb2Qg dGhpbmcsIGluIHRoYXQgY2FzZSB0aGUgcm9vdCBpcyB0b3RhbGx5IGVsaWRlZCB3aXRoIHRoZSBJ UC1pbi1JUCA2TG9SSC4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4g Pg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gU28gdGhpcyBzaW1wbGUgcHJvcG9zYWwgc2F2 ZXMgdXAgdG8gMTYgb2N0ZXRzICh0aGF0cyBpbiB0aGUgY2FzZSB3aXRoIGEgc2luZ2xlIHN1Ym5l dCBhbmQgYWxsIGFkZHJlc3NlcyBkaWZmZXIgb25seSBieSB0aGUgbGFzdCAyIGJ5dGVzKS4gSW0g d2lsbGluZyB0byBhZGQgaXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQo+DQo+ID4NCj4NCj4gPiA+ DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IEFu eSBvcHBvc2l0aW9uPw0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPg0KPg0KPiA+ DQo+DQo+ID4gPg0KPg0KPiA+DQo+DQo+ID4gPiBQYXNjYWwNCj4NCj4gPg0KPg0KPiA+ID4NCj4N Cj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4NCj4NCj4gPg0KPg0KPiA+ID4gLS0NCj4N Cj4gPg0KPg0KPiA+ID4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kDQo+DQo+ID4NCj4NCj4gPiA+IGRhbmdlcm91cyBjb250ZW50IGJ5IE1haWxTY2FubmVyLCBh bmQgaXMNCj4NCj4gPg0KPg0KPiA+ID4gYmVsaWV2ZWQgdG8gYmUgY2xlYW4uDQo+DQo+ID4NCj4N Cj4gPiA+DQo+DQo+ID4NCj4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+DQo+ID4NCj4NCj4gPiA+IDZ0aXNjaCBtYWlsaW5nIGxpc3QNCj4N Cj4gPg0KPg0KPiA+ID4gNnRpc2NoQGlldGYub3JnPG1haWx0bzo2dGlzY2hAaWV0Zi5vcmc8bWFp bHRvOjZ0aXNjaEBpZXRmLm9yZyUzY21haWx0bzo2dGlzY2hAaWV0Zi5vcmc+Pg0KPg0KPiA+DQo+ DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZ0aXNjaA0KPg0K PiA+DQo+DQo+ID4NCj4NCj4gPg0KPg0KPiA+IC0tDQo+DQo+ID4gVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kDQo+DQo+ID4gZGFuZ2Vyb3VzIGNvbnRlbnQgYnkg TWFpbFNjYW5uZXIsIGFuZCBpcw0KPg0KPiA+IGJlbGlldmVkIHRvIGJlIGNsZWFuLg0KPg0KPiA+ DQo+DQo+ID4NCj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPg0KPiA+IDZ0aXNjaCBtYWlsaW5nIGxpc3QNCj4NCj4gPiA2dGlzY2hAaWV0Zi5v cmc8bWFpbHRvOjZ0aXNjaEBpZXRmLm9yZzxtYWlsdG86NnRpc2NoQGlldGYub3JnJTNjbWFpbHRv OjZ0aXNjaEBpZXRmLm9yZz4+DQo+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82dGlzY2gNCj4NCj4NCj4gLS0NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kDQo+IGRhbmdlcm91cyBjb250ZW50IGJ5IE1haWxTY2FubmVyLCBh bmQgaXMNCj4gYmVsaWV2ZWQgdG8gYmUgY2xlYW4uDQoNCg== --_000_5afe3f6ee28847e6859488ba760e1069XCHRCD001ciscocom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hello Sati= sh

 

Hello everyone,

 

Please let me refresh my previous comments as follows.

 

draft-thubert-roll-asymlink-02

 

2-DODAGs for asymmetrical links:

 

For upward routes (Instance-1), root generates DIO message with MOP= =3D0 (No downward routes are allowed). For this, no DAO messages are genera= ted.

 

For downward routes (Instance-2), root generates DIO messages with MO= P=3D2 (Storing mode). Subsequently, DAO messages are generated back to thei= r immediate parents and routing state information is stored in parent node for downward traffic.

 

So, root is the same for both Instance-1 and Instance-2. Is this obse= rvation correct?

 

 

PT > correct

 

If my observation makes sense then there won=A1=AFt be DAO messages, = which were used in traditional RPL (RFC6550), for upward route with 2 DODAG= s (asymmetric links).

 

 

If we construct peer to peer routes based on RFC6997, the story would= be different from draft-thubert-roll-asymlink-02. In P2P-RPL (RFC6997), th= e source will act as a temporary root and multicast the DIO-RDO messages with Instance-1. Once, the destination = is reached through DIO-RDO the data path from Destination to Source is crea= ted. Then we again need to initiate DIO-RDO messages with Instance-2 at des= tination for the data path from Source to Destination.

 

If this observation is true then P2P-RPL (RFC6997) will need to have = two roots. Am I correct?

 

 

PT > This is probably a good approach, yes. Each DA= G would be directional, that is based on metrics in one direction.

 

Cheers,

 

Pascal

 

 

 

Hi,

 

> > I found the P2P RPL very appropriate for the cu= rrent discussion. What is

> > interesting is that the Bidirectional Route pre= sented here actually enables

> > creating a symmetric path between end nodes by = passing on the complete path

> > information in its signaling messages. In this = process, routing state is

> > installed along the path.

> >

> >

> >

> > =A8=AA  I hope that we start new on-demand= work for RPL, based on this and AODV. It may be that the route is optimize= d for metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs= , one for each direction. This is discussed in http= s://tools.ietf.org/html/draft-thubert-roll-asymlink-00

> >

> 

> Thanks for the draft! Would be happy to be part of t= he new work you are proposing :)

 

When we create 2 DODAGs for asymmetrical links, two DIO m= essages are generated:  one from source to destination (instance-1) an= d the other from destination to source (instance-2). So, there won=A1=AFt be any DAO or RDO messages in P2P-RPL based on asymme= tric links. Am I correct?

 

In P2P-RPL, =A1=AEAddress=A1=AF vector is created by the = source during DIO-RDO multicast for both hop-by-hop routing (non-storing mo= de) and source routing (storing mode). For asymmetric-link based P2P-RPL, one =A1=AEAddress=A1=AF vector (DIO-RDO) is created by sour= ce for Instance-1 to discover path from destination to source and the other= one needs to be created by destination to discover path from source to des= tination. If this is to be the proposing operations for asymmetrical P2P-RPL, then there would be two rounds of multicast comp= ared to just one round in the traditional P2P-RPL. It is desirable if we ca= n remove the =A1=AEAddress=A1=AF vector from the multicast DIO-RDO for asym= metric-link based P2P-RPL(especially for hop-by-hop routing).

 

With Regards,

Satish.

 

 

From: Roll [mail= to:roll-bounces@ietf.org] On Behalf Of S.V.R.Anand

Sent: 2016=D2= =B42=EA=C52=EC=ED 15:49

To: Pascal Thubert (pthubert); 6lo@ietf.org

Cc: 6tisch@ietf.org; Routing Over Low po= wer and Lossy networks

Subject: Re: [Roll] On 6LoRH issue #11 (was Proposed impr= ovement in RH3-6LoRH...)

 

Hi Pascal,

 

Thanks a lot for your response and for all the references= . Please see my response in line.

 

On Sunday 31 January 2016 03:05 PM, Pascal Thubert (pthub= ert) wrote:

> 

> Hello Anand:

> 

> 

> 

> Thanks for this, please see below:=

> 

> 

> Having a symmetric path, in principle, certainly off= ers advantages when we want

> the communicating nodes to use a well-defined path t= hat has been set up to meet

> the QoS requirements of an application. Such a pinne= d path can be appropriately

> provisioned with required bandwidth resources along = the entire path.

> 

> 

> 

> =A8=AA  True but in radios, the links may be ve= ry asymmetrical, and the optimal return path may be very different.

> 

> =A8=AA  So the pinned-down return path may be d= ifferent actually.

> 

 

Surely the presence of uni-directional routes cannot be i= gnored. Some of the

dominating factors like, routing overheads, route and res= ource state

maintenance on the nodes and the associated scalability i= ssues, implementation

complexity, and so on, will prompt network designers to d= eploy networks with

reliable bi-directional links and routes. Because of the = factors listed here,

one would like to ensure absence of bi-directional routes= will be more of an

exception rather than a norm. No ?

 

 

> 

> 

> I found the P2P RPL very appropriate for the current= discussion. What is

> interesting is that the Bidirectional Route presente= d here actually enables

> creating a symmetric path between end nodes by passi= ng on the complete path

> information in its signaling messages. In this proce= ss, routing state is

> installed along the path.

> 

> 

> 

> =A8=AA  I hope that we start new on-demand work= for RPL, based on this and AODV. It may be that the route is optimized for= metrics that are mostly directional, one way or the other, if the traffic is so. Ideally wed build and associated 2 DODAGs= , one for each direction. This is discussed in http= s://tools.ietf.org/html/draft-thubert-roll-asymlink-00

> 

 

Thanks for the draft! Would be happy to be part of the ne= w work you are proposing :)

 

> 

> 

> As you noted, keeping signaling separate from data i= s certainly an elegant way.

> 

> There can however be contexts when in-band signaling= that uses RH3 as per

> RFC6554 data can be more efficient than using a sign= aling protocol, assuming

> the security concerns are addressed as per RFC2460. = This in-band approach is

> attractive when we want to set up a rapid on-the-fly= symmetric path along with

> 6TiSCH OTF making bandwidth reservation along the wa= y for transactional message

> exchanges. I am hinting at the possible PCE/NME base= d solution that (i) works

> with the RPL DODAG, (ii) considers the hop distance = between the communicating

> node to assess energy costs, (iii) optimizes network= resource availability, and

> finally provides right inputs for the nodes. It may = well be that dropping the

> address is the right choice.

> 

> 

> 

> =A8=AA  I can agree with that, and I used that = sort of method in https:= //tools.ietf.org/html/draft-thubert-tree-discovery

> 

> 

 

Thanks again! Started reading it. Looks like we are = revisiting concepts already developed many years back.

 

> 

> 

> I think I am doing too much of hand waving going on = by leaving out all the

> essential details. Hope I managed to vaguely convey = the point.

> 

> I tend to feel that distributed, centralized and the= ir combination might

> co-exist to optimize network resources, and therefor= e retaining or dropping the

> address in RH3-6LoRH can be made optional.

> 

> 

> 

> 

> 

> =A8=AA  Could be, but should we do it now or wh= en we have the actual need?

> 

> =A8=AA  Do you have a design in mind that limit= s the implementation overhead of supporting both?

> 

 

At the rick of sounding naive, can't the option of droppi= ng or retaining address be indicated by a bit ?

 

> 

> 

> Am I making sense ?

> 

> 

> 

> 

> 

> =A8=AA  To me, certainly J

> 

 

Anand

 

> 

> 

> Anand

> 

> 

> 

> 

> On Saturday 23 January 2016 02:34 PM, Pascal Thubert= (pthubert) wrote:

> >

> 

> > Hello Anand:

> 

> >

> 

> >

> 

> >

> 

> > 2 good points , that we need to continue in dif= ferent threads if we do.

> 

> >

> 

> >

> 

> > The source routing optimization done by droppin= g the addresses on the way

> 

> > certainly has benefits. However, there could be= loss of a natural "symmetric"

> 

> > property that one might want to enforce between= communicating end nodes in the

> 

> > routing path. By symmetry I mean using the same= path in both the directions of

> 

> > communication. Policy based routing, centralize= d routing, for instance, could

> 

> > be potential users of this property. May be thi= s does not represent a common

> 

> > use case. But nevertheless, we have to be aware= of this side effect which RFC6554

> 

> > swapping process does not have.

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  Pascal: Yes, Simon made that point= yesterday.

> 

> >

> 

> > =A8=AA  It is generally not a good idea to= reverse a routing header. The RH may have been used to stay away from the = shortest path for some reason that is only valid on the way in (segment routing).

> 

> >

> 

> > =A8=AA  P2P RPL reverses a path that is le= arnt reactively, so we have a real protocol for doing that sort of thing as= opposed to an echo.

> 

> >

> 

> > =A8=AA  Reversing a header is discouraged = by RFC 2460 (for RH0) unless it is authenticated (which means AH). We do no= t authenticate the RH3, there are a number of reasons for that, general deprecation of AH, no use of AH in LLNs etc& Note th= at AH does not protect the RH on the way, it is just a validation at the re= ceiver for the sole value of reversing it.

> 

> >

> 

> > =A8=AA  A RPL domain is usually protected = by L2 security and that secures both RPL itself and the RH in packets, at e= very hop

> 

> >

> 

> > =A8=AA  The benefit of saving energy and l= owering the chances of loss are seen as overwhelming compared to the value = of possibly reversing the header

> 

> >

> 

> > =A8=AA  Yet we might define a variation wh= ere we do not pop out the first entry as we go. I do not see a consensus on= the value of doing it now.

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > Going further, the DAO projection proposal=

> 

> > (draft-thubert-roll-dao-projection-02.txt) will= have several virtual roots

> 

> > inside the RPL domain. The automatic assumption= of a well known root may not apply

> 

> > when nodes within RPL domain communicate with e= ach other. I suppose it will

> 

> > have a bearing on the RH3-6LoRH performance.

> 

> >

> 

> >

> 

> >

> 

> > =A8=AA  It is not really an assumption, bu= t something we leverage as we go. The RPI is very much like a context indic= ator. If an address shares a lon prefix with a root, adding the RPI of that root is actually a compression technique.

> 

> >

> 

> >

> 

> >

> 

> > The above observations are not serious, but fee= ls good to ponder over. Will be

> 

> > happy to receive your comments.

> 

> >

> 

> > Thanks Anand!

> 

> >

> 

> >

> 

> >

> 

> > Pascal

> 

> >

> 

> >

> 

> >

> 

> >

> 

> >

> 

> > On Monday 18 January 2016 11:24 PM, Pascal Thub= ert (pthubert) wrote:

> 

> > >

> 

> >

> 

> > > Dear all

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The picture below illustrates how the RH3 = 6LoRH works with draft 03 in a case like Root -> A -> B -> C ->= leaf

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > The first 6LoRH is expected to be a full a= ddress (128 bits) to set up a reference and the next 6LoRH are expected to = be smaller and just override the rightmost bits which form the delta from the reference.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Proposal: we could consider that the 128bi= ts source of the IP header before the RH3 is the reference to start with.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > With that even the first hop could be comp= ressed the same way as the other hops. With RPL, the root is the encapsulat= or if IP in IP in used. Good thing, in that case the root is totally elided with the IP-in-IP 6LoRH.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > So this simple proposal saves up to 16 oct= ets (thats in the case with a single subnet and all addresses differ only b= y the last 2 bytes). Im willing to add it in the next revision.

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Any opposition?

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > Pascal

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > >

> 

> >

> 

> > > --

> 

> >

> 

> > > This message has been scanned for viruses = and

> 

> >

> 

> > > dangerous content by MailScanner, and is

> 

> >

> 

> > > believed to be clean.

> 

> >

> 

> > >

> 

> >

> 

> > > __________________________________________= _____

> 

> >

> 

> > > 6tisch mailing list

> 

> >

> 

> > > 6tisch@ietf.org= <mailto:6tisch@ietf.org>

> 

> >

> 

> > > https://www.ietf.o= rg/mailman/listinfo/6tisch

> 

> >

> 

> >

> 

> >

> 

> > --

> 

> > This message has been scanned for viruses and

> 

> > dangerous content by MailScanner, and is

> 

> > believed to be clean.

> 

> >

> 

> >

> 

> > _______________________________________________=

> 

> > 6tisch mailing list

> 

> > 6tisch@ietf.org= <mailto:6tisch@ietf.org>

> 

> > https://www.ietf.o= rg/mailman/listinfo/6tisch

> 

> 

> --

> This message has been scanned for viruses and

> dangerous content by MailScanner, and is<= /span>

> believed to be clean.

 

--_000_5afe3f6ee28847e6859488ba760e1069XCHRCD001ciscocom_-- From nobody Mon Feb 15 04:19:54 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B189C1A86F1 for ; Sat, 13 Feb 2016 12:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.208 X-Spam-Level: X-Spam-Status: No, score=-99.208 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 jt-qgqrLQZwR for ; Sat, 13 Feb 2016 12:57:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CA91A86EF for ; Sat, 13 Feb 2016 12:57:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CB679180006; Sat, 13 Feb 2016 12:57:18 -0800 (PST) To: wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, maria.ines.robles@ericsson.com, mcr+ietf@sandelman.ca X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160213205718.CB679180006@rfc-editor.org> Date: Sat, 13 Feb 2016 12:57:18 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 04:19:54 -0800 Cc: roll@ietf.org, yasuyuki.tanaka@inf.ethz.ch, rfc-editor@rfc-editor.org Subject: [Roll] [Editorial Errata Reported] RFC6550 (4618) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 20:57:21 -0000 The following errata report has been submitted for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4618 -------------------------------------- Type: Editorial Reported by: Yasuyuki Tanaka Section: 6.7.6 Original Text ------------- Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Corrected Text -------------- Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Feb 15 04:19:56 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE851B326B; Mon, 15 Feb 2016 04:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 bnqlkODO2guR; Mon, 15 Feb 2016 04:18:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9261B324A; Mon, 15 Feb 2016 04:18:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E745D18046E; Mon, 15 Feb 2016 04:18:25 -0800 (PST) To: yasuyuki.tanaka@inf.ethz.ch, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160215121825.E745D18046E@rfc-editor.org> Date: Mon, 15 Feb 2016 04:18:25 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 15 Feb 2016 04:19:54 -0800 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6550 (4618) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:18:34 -0000 The following errata report has been held for document update for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4618 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Yasuyuki Tanaka Date Reported: 2016-02-13 Held by: Alvaro Retana (IESG) Section: 6.7.6 Original Text ------------- Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Corrected Text -------------- Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Notes ----- The error is clear, but it should not affect implementations. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Feb 16 06:13:00 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61F1B32C9; Mon, 15 Feb 2016 04:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 d4ILXJZzKF9L; Mon, 15 Feb 2016 04:24:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE851B32C6; Mon, 15 Feb 2016 04:24:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D8610180206; Mon, 15 Feb 2016 04:24:07 -0800 (PST) To: dominique.barthel@orange.com, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160215122407.D8610180206@rfc-editor.org> Date: Mon, 15 Feb 2016 04:24:07 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 06:12:54 -0800 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6550 (4457) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:24:16 -0000 The following errata report has been held for document update for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4457 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Dominique Barthel Date Reported: 2015-08-27 Held by: Alvaro Retana (IESG) Section: 20.9 Original Text ------------- in title of section (one instance) and text (two instances) "DODAG Informational Solicitation" Corrected Text -------------- "DODAG Information Solicitation" Notes ----- DIS is defined in Section 2 (Terminology) as "DODAG Information Solicitation". This acronym is expanded consistently throughout the RFC but in this section. === Alvaro Retana === Note that this error affects the name of the IANA registry as well. A future revision of this document should request an update to that name as well. -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Tue Feb 16 06:13:02 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6831D1B32C6; Mon, 15 Feb 2016 04:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 j3-3OZBlb6XN; Mon, 15 Feb 2016 04:25:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AAF1B32C3; Mon, 15 Feb 2016 04:25:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id DE3DA18046D; Mon, 15 Feb 2016 04:25:10 -0800 (PST) To: dominique.barthel@orange.com, wintert@acm.org, pthubert@cisco.com, abr@sdesigns.dk, jhui@archrock.com, kelsey@ember.com, pal@cs.stanford.edu, kpister@dustnetworks.com, rstruik.ext@gmail.com, jpv@cisco.com, roger.alexander@cooperindustries.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160215122510.DE3DA18046D@rfc-editor.org> Date: Mon, 15 Feb 2016 04:25:10 -0800 (PST) Archived-At: X-Mailman-Approved-At: Tue, 16 Feb 2016 06:12:57 -0800 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6550 (4458) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 12:25:18 -0000 The following errata report has been held for document update for RFC6550, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6550&eid=4458 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Dominique Barthel Date Reported: 2015-08-27 Held by: Alvaro Retana (IESG) Section: 20.10 Original Text ------------- No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags. Corrected Text -------------- No bit is currently defined for the DIO (DODAG Information Object) Flags. Notes ----- This is obviously an erroneous copy-paste from section 20.9 -------------------------------------- RFC6550 (draft-ietf-roll-rpl-19) -------------------------------------- Title : RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Wed Feb 17 12:30:23 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181C31A1B95; Wed, 17 Feb 2016 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 dsiiw2rKlfCy; Wed, 17 Feb 2016 08:52:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BA681A1B91; Wed, 17 Feb 2016 08:52:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 44DA8180006; Wed, 17 Feb 2016 08:52:14 -0800 (PST) To: jeremy.dubrulle@student.umons.ac.be, jpv@cisco.com, mjkim@kt.com, kpister@dustnetworks.com, nicolas.dejean@coronis.com, dominique.barthel@orange-ftgroup.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160217165214.44DA8180006@rfc-editor.org> Date: Wed, 17 Feb 2016 08:52:14 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 17 Feb 2016 12:30:22 -0800 Cc: roll@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] [Errata Held for Document Update] RFC6551 (4531) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:52:29 -0000 The following errata report has been held for document update for RFC6551, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6551&eid=4531 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jeremy Dubrulle Date Reported: 2015-11-13 Held by: Alvaro Retana (IESG) Section: 3.2 Original Text ------------- Figure 3: NE Sub-Object Format Corrected Text -------------- Figure 3: NE Object Body Format Notes ----- Figure 3 describes the format of the NE object body while Figure 4 describes the format of the NE Sub-Object. -------------------------------------- RFC6551 (draft-ietf-roll-routing-metrics-18) -------------------------------------- Title : Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks Publication Date : March 2012 Author(s) : JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel Category : PROPOSED STANDARD Source : Routing Over Low power and Lossy networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Feb 18 15:34:01 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998201B359C; Thu, 18 Feb 2016 15:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 ExULyt91JEp9; Thu, 18 Feb 2016 15:33:58 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED5D1B34D2; Thu, 18 Feb 2016 15:33:58 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EC4C5180209; Thu, 18 Feb 2016 15:33:40 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160218233340.EC4C5180209@rfc-editor.org> Date: Thu, 18 Feb 2016 15:33:40 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 7731 on Multicast Protocol for Low-Power and Lossy Networks (MPL) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 23:33:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7731 Title: Multicast Protocol for Low-Power and Lossy Networks (MPL) Author: J. Hui, R. Kelsey Status: Standards Track Stream: IETF Date: February 2016 Mailbox: jonhui@nestlabs.com, richard.kelsey@silabs.com Pages: 29 Characters: 63216 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-trickle-mcast-12.txt URL: https://www.rfc-editor.org/info/rfc7731 DOI: http://dx.doi.org/10.17487/RFC7731 This document specifies the Multicast Protocol for Low-Power and Lossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL Forwarders in an MPL Domain. MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Feb 18 15:34:29 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500641B36D7; Thu, 18 Feb 2016 15:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 lQw8sirjWO15; Thu, 18 Feb 2016 15:34:26 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62441B362F; Thu, 18 Feb 2016 15:34:16 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C0032187A98; Thu, 18 Feb 2016 15:33:59 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160218233359.C0032187A98@rfc-editor.org> Date: Thu, 18 Feb 2016 15:33:59 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 7732 on Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 23:34:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7732 Title: Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) Author: P. van der Stok, R. Cragie Status: Informational Stream: IETF Date: February 2016 Mailbox: consultancy@vanderstok.org, robert.cragie@arm.com Pages: 15 Characters: 34403 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-admin-local-policy-03.txt URL: https://www.rfc-editor.org/info/rfc7732 DOI: http://dx.doi.org/10.17487/RFC7732 The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks (MPL) multicast messages with Admin-Local scope in a border router. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Feb 18 15:34:51 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906871B3559; Thu, 18 Feb 2016 15:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 uF1QX0EHBSty; Thu, 18 Feb 2016 15:34:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5911B362F; Thu, 18 Feb 2016 15:34:29 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 59AEF1832BB; Thu, 18 Feb 2016 15:34:12 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160218233412.59AEF1832BB@rfc-editor.org> Date: Thu, 18 Feb 2016 15:34:12 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 7733 on Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 23:34:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7733 Title: Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control Author: A. Brandt, E. Baccelli, R. Cragie, P. van der Stok Status: Standards Track Stream: IETF Date: February 2016 Mailbox: anders_brandt@sigmadesigns.com, Emmanuel.Baccelli@inria.fr, robert.cragie@arm.com, consultancy@vanderstok.org Pages: 38 Characters: 85372 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-applicability-home-building-12.txt URL: https://www.rfc-editor.org/info/rfc7733 DOI: http://dx.doi.org/10.17487/RFC7733 The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments. This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Feb 19 04:53:54 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1BF1B29D5 for ; Fri, 19 Feb 2016 04:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 RkcF6U-fjH2W for ; Fri, 19 Feb 2016 04:53:51 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 40FE71AD09F for ; Fri, 19 Feb 2016 04:53:51 -0800 (PST) Received: from localhost ([::1]:45492 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1aWkZC-0007Z4-RT; Fri, 19 Feb 2016 04:53:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: mariainesrobles@gmail.com X-Trac-Project: roll Date: Fri, 19 Feb 2016 12:53:50 -0000 X-URL: https://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/roll/trac/ticket/173#comment:1 Message-ID: <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> X-Trac-Ticket-ID: 173 In-Reply-To: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mariainesrobles@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: Cc: roll@ietf.org Subject: Re: [Roll] [roll] #173 (useofrplinfo): Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 12:53:52 -0000 #173: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf Comment (by mariainesrobles@gmail.com): Pascal said: “Yes We have to define the support for the non RPL leaf. This needs a different draft. My expectation is that the draft would indicate that the non RPL leaf is known by the 6LR through 6LowPAN ND with 6BBr extension (for the sequence number). IMHO, whether in storing or not storing, it would be good that the 6LR injects a DAO with self as transit with the external (E) bit set and the leaf address as target. So the other nodes know. So that in non-storing the root terminated the RH3 at the last router. Routing will take the packet back to that 6LR. The 6LR should strip the 6LoRH, which is easy in the compressed format. But stripping is illegal unless there’s an IP in IP. So the problem is really the IP conformance. One way to solve that is to say that there is an implicit IP in IP from link local to link local in front of any 6LoRH.” -- -------------------------------------+------------------------------------- Reporter: | Owner: mariainesrobles@gmail.com | mariainesrobles@gmail.com Type: defect | Status: new Priority: major | Milestone: Component: useofrplinfo | Version: Severity: Active WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: roll From nobody Fri Feb 19 08:38:04 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC121B3215 for ; Fri, 19 Feb 2016 08:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 Om8KEh-ZcRn2 for ; Fri, 19 Feb 2016 08:38:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E585B1B2E00 for ; Fri, 19 Feb 2016 08:38:00 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 509AE2002A for ; Fri, 19 Feb 2016 11:38:48 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 850A663750 for ; Fri, 19 Feb 2016 11:37:59 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <20160218233340.EC4C5180209@rfc-editor.org> References: <20160218233340.EC4C5180209@rfc-editor.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Roll] RFC 7731, 7732, 7733 set pubished yesterday! X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 16:38:03 -0000 --=-=-= Content-Type: text/plain It's been a long haul for the authors here. My sincere thanks to: Jonathan Hui Richard Kelsey Peter van der Stok Robert Cragie Anders Brandt E. Baccelli You guys persevered through a really long IESG and RFC-editor queue process. Remember that RFC7732 (admin-local scope) was decided back in November 2013 at the Vancouver IETF, ad the dinner BOF. *** It was *SUPPOSED* to be the shortest RFC ever *** Whew. Now on to more controversial topics: Leaf node support in RPL. Ines & Michael. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVsdE5ICLcPvd0N1lAQI9vAf/XoHWMxTEVsfscrJtC+RLd+w6lj7ofmbq MdRxm79D3UNpREaHFvOKFpZ+43Uj4lhjsjmUYBoKUjTJqbk6goZ9G/s4cSX57ibP tHITQlGvoc/tjhXm5FZwT4eM2clTueQzD6u94ARMfBp7f9ErZm7ZM1+MX8KF+kkO xnM+fSIPXdF59gJyiAuAfFfsO1MGJhQoir/qUJlO37Pghz07enaOjHgl7pXuVc7m YzVH+vnwxRvpHqiKtYIyo/FIAvyYyKA2+4ODsAMRp+7Mi+GtZK7OQJV8rXC6SS2E tl1z1hEhxIJyq+C2EvKwg6NMHP/dE6NrNhJSVnNMu2qisH1GyWmCtA== =dbml -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 19 09:37:44 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886231A90A1 for ; Fri, 19 Feb 2016 09:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 8Ko416DlDIcv for ; Fri, 19 Feb 2016 09:37:40 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7E51A702B for ; Fri, 19 Feb 2016 09:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2997; q=dns/txt; s=iport; t=1455903458; x=1457113058; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to; bh=kzPM0R5qV4MjufLiCZ2cng+3y2U9BLnm2e0+7tltp80=; b=Veeh2Z1DHWDASXpievIXWZnFN8TCvnA134DsYZrTUaWAXK9OgeGgqXh6 jeZbA7H8oUMtHqxpQUVena3ZwzcGTFEQgY/OZOhKLyEYwOC5e3ypMWilM lbRTWFyVxj7+1mb5YMunijIYjiWUJkkeiLpQpnhcjt+5aoYIHVZwtiEMy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBABaUsdW/xbLJq1ehAxtvDsXAQmCP?= =?us-ascii?q?IMwAoIiAQEBAQEBZSeEQgEBBAEBAWsFBRELBBQJFg8JAwIBAgEVMBMGAgEBiBY?= =?us-ascii?q?Osn6IawEBAQEBBQEBAQEBARqGEoQ7gTaDS4NuBY4eiGmFV4gHgiaGe4VSjkhig?= =?us-ascii?q?hCBch4uiDwBAQE?= X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208,217";a="635609607" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 17:37:36 +0000 Received: from [10.86.254.170] ([10.86.254.170]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1JHbZYp032430 for ; Fri, 19 Feb 2016 17:37:36 GMT References: <20160218233340.EC4C5180209@rfc-editor.org> <29721.1455899879@obiwan.sandelman.ca> To: roll@ietf.org From: Paul Duffy Organization: Cisco Systems Message-ID: <56C752E0.4070605@cisco.com> Date: Fri, 19 Feb 2016 12:37:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <29721.1455899879@obiwan.sandelman.ca> Content-Type: multipart/alternative; boundary="------------010003050809070104000900" Archived-At: Subject: Re: [Roll] RFC 7731, 7732, 7733 set pubished yesterday! X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.com, Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:37:42 -0000 This is a multi-part message in MIME format. --------------010003050809070104000900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1! ;) On 2/19/2016 11:37 AM, Michael Richardson wrote: > It's been a long haul for the authors here. > My sincere thanks to: > Jonathan Hui > Richard Kelsey > Peter van der Stok > Robert Cragie > Anders Brandt > E. Baccelli > > You guys persevered through a really long IESG and RFC-editor queue process. > Remember that RFC7732 (admin-local scope) was decided back in November 2013 > at the Vancouver IETF, ad the dinner BOF. > > *** It was *SUPPOSED* to be the shortest RFC ever *** > > Whew. Now on to more controversial topics: Leaf node support in RPL. > > Ines & Michael. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------010003050809070104000900 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit
+1!

;)

On 2/19/2016 11:37 AM, Michael Richardson wrote:
It's been a long haul for the authors here.
My sincere thanks to:
   Jonathan Hui
   Richard Kelsey
   Peter van der Stok
   Robert Cragie
   Anders Brandt
   E. Baccelli

You guys persevered through a really long IESG and RFC-editor queue process.
Remember that RFC7732 (admin-local scope) was decided back in November 2013
at the Vancouver IETF, ad the dinner BOF.

*** It was *SUPPOSED* to be the shortest RFC ever ***

Whew.  Now on to more controversial topics: Leaf node support in RPL.

Ines & Michael.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--------------010003050809070104000900-- From nobody Sun Feb 21 19:52:00 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2080C1B2AD6 for ; Sun, 21 Feb 2016 19:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.292 X-Spam-Level: ** X-Spam-Status: No, score=2.292 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 LBwGVoVePmEW for ; Sun, 21 Feb 2016 19:51:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5493B1B2A3D for ; Sun, 21 Feb 2016 19:51:57 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 36DA92002A for ; Sun, 21 Feb 2016 22:52:53 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C842263750 for ; Sun, 21 Feb 2016 22:51:55 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 03:51:59 -0000 --=-=-= Content-Type: text/plain At the interim meeting last fall, we came across two problems for which we have no clear recommendation, and which we think needs some protocol work. The situation is described in ticket 173, and in section 5.10 of useofrplinfo. Consider the packet flow: 6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 --> not-RPL-aware 6LN In storing mode the packet goes up to the common parent (which may be below the root) via typically a default route, and then follows the hop-by-hop down the tree. An RPI header needs to be inserted by the 6LN. In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is not necessary, since the receiving node is RPL aware, it can remove the RPI. In this case, however, the end-node is not RPI aware, so the 6LR3 needs to remove the RPI. In order for that to happen, the IPIP header needs to be addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's address. here are two possible ways to deal with this issue: 1) Pascal has pointed out that we can use an IPIP header on a hop-by-hop basis, using either link-local addresses, or even GUA addresses, but each IPIP header needs to be added/removed at each hop. 2) If the definition of the RPI was changed so that it isn't a "discard if not recognized" type. This change is an incompatible on-the-wire change, and would represent a flag day. However, this change could perhaps be done with the updated 6LoRH compression work, as that is also an incompatible on-the-wire change for which we presently have no way to signal. 3) These proposals are not mutually exclusive: we could do both. I'm not looking for "yes, I like proposal X", but rather I'm looking for replies of the form of "I can not live with proposal X because Y" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVsqF2ICLcPvd0N1lAQLKbAf/bdbpnemm8HVs/KX7Jt2KaYL9JlXKLIkn AKKe6C+PBVa8g7KOSuOT8TZzw4qS29Q4icIlcSKSW+sxFx/AthUxgayXNOTV664y nSihG37ITpbJeP8VU9vCJmofAY7U0j7L0pcmRZCDiXcZBmw7q4ImEzB8Pdf3ng+1 eaMPCTdzDQ2W9WJF2REuyOtYdeURroqws5V178Y1rTIM6bHqOCmZ8RBcV9H/PdQl ODusl166ntake7YmPITvXuu+2F3vkQGhEialovWv3esWPb/3UFgFZkHigC24POfw c7WgO2FkCJkrse9PjZDeEshDe+DC6CDP22wChEqETgAyPqQM6f6cJw== =tGZl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 22 07:19:57 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F021B3566 for ; Mon, 22 Feb 2016 07:19:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 le263fZYUXiI for ; Mon, 22 Feb 2016 07:19:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9F91B3565 for ; Mon, 22 Feb 2016 07:19:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A90032002A for ; Mon, 22 Feb 2016 10:20:52 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94C1B63750 for ; Mon, 22 Feb 2016 10:19:53 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: <9111.1456113115@obiwan.sandelman.ca> References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 15:19:56 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is > not necessary, since the receiving node is RPL aware, it can remove the > RPI. > In this case, however, the end-node is not RPI aware, so the 6LR3 needs > to remove the RPI. In order for that to happen, the IPIP header needs > to be addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's > address. I wanted to add that the sending node has no way of knowing if it is in situation 5.9 or situation 5.10, so absent some signaling that there are no non-RPL aware nodes in the DAG, then sending nodes must assume that the receiver is not-RPI aware. An additional possible protocol action might be to signal in the DIOs that that the RPL network is entirely RPL-aware. This would/could get negated by DAOs having a bit so indicate if each target address is RPI aware (i.e. if it was learned from ND or via DAO). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVssnFoCLcPvd0N1lAQKJowf+N4ueMVU+e7B+tzBvIijlN/4RfW7IY2sb n1OQt1hnltD4uODhBUOeB+qPaMjiXWyg9QChF73XDqQkAQSScM1eSBFuE6UZ6GtR f59uHQO+uY7lJxiDVKavfvlZufkTzG8ODipL8psxY5ZVvg8YZGdjwe82/YL8pLHb mDDNhxYFB6fERy+0tIAlPNQ2MkKto+W9W/1g5xYy4ThmNfjkZUhfgForb8JRUY/N FZ0uJ/bQg4GctUfIa12dwatRndEZyfJhdOa/SwU1v7heN+j8jGxWtQOKqoBxCMA+ 8IupWwNJIa6zXI1xDnYU4xz85NtfWAeM03YEBITCUrNN7NMRNonlvw== =xv98 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Feb 22 22:46:07 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0781A6FB4 for ; Mon, 22 Feb 2016 22:46:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.207 X-Spam-Level: X-Spam-Status: No, score=-12.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_GIRL=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 hh5Rf0ibgqet for ; Mon, 22 Feb 2016 22:46:04 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34071A1B45 for ; Mon, 22 Feb 2016 22:46:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2537; q=dns/txt; s=iport; t=1456209963; x=1457419563; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=91cWsSOtMZrh2PxAcyTJlw4v9b+wOB3cyNOmyDWj0fY=; b=byNhwRW+NsDPfkdw3oz77Fish5j5+Y39fv1nyccX/SGRLXg6sfJdTbOf izLMfiDds7Gm3Oo0e3oe21xpxj32pLDPMbMQ4cIgzH8iJGQbP7UyYxHXG mnB0SzPBeHYU6862LqizDq22ulYKIZIljlTKttJRcIqI2bIs1Qd0Oo81d 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APBQDi/8tW/5JdJa1egzqBPwZLq16OP?= =?us-ascii?q?4FmMYIsgzACgUs5EwEBAQEBAQFkJ4RBAQEBBCdeBAIBCBEEAQEoBzIUCQgCBBM?= =?us-ascii?q?IiBO7DgEBAQEBAQEBAQEBAQEBAQEBARiGEoQ6hCOETAWHWIYKiSUBiESFEo54j?= =?us-ascii?q?kgBIQFAg2Rqhn8GN30BAQE?= X-IronPort-AV: E=Sophos;i="5.22,488,1449532800"; d="scan'208";a="240582019" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2016 06:46:02 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u1N6k2PX006984 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Feb 2016 06:46:02 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 00:46:01 -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.1104.009; Tue, 23 Feb 2016 00:46:01 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf Thread-Index: AQHRbSRsyXI4sJtst06/NzdgD2VkoZ85L+gg Date: Tue, 23 Feb 2016 06:45:55 +0000 Deferred-Delivery: Tue, 23 Feb 2016 06:45:02 +0000 Message-ID: References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> In-Reply-To: <9111.1456113115@obiwan.sandelman.ca> 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.98.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 06:46:05 -0000 For completeness, Michael,=20 The change Nb2 reverses a decision that makes sure that if a packet with an= HbH header / RPI escapes the RPL domain, it is immediately discarded. This= impact has to be weighted. Cheers, Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: lundi 22 f=E9vrier 2016 04:52 > To: roll@ietf.org > Subject: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-le= af >=20 >=20 > At the interim meeting last fall, we came across two problems for which w= e > have no clear recommendation, and which we think needs some protocol > work. >=20 > The situation is described in ticket 173, and in section 5.10 of useofrpl= info. >=20 > Consider the packet flow: > 6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 --> not-RPL-aware 6LN >=20 > In storing mode the packet goes up to the common parent (which may be > below the root) via typically a default route, and then follows the hop-b= y- > hop down the tree. An RPI header needs to be inserted by the 6LN. >=20 > In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is n= ot > necessary, since the receiving node is RPL aware, it can remove the RPI. >=20 > In this case, however, the end-node is not RPI aware, so the 6LR3 needs t= o > remove the RPI. In order for that to happen, the IPIP header needs to be > addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's address. >=20 > here are two possible ways to deal with this issue: >=20 > 1) Pascal has pointed out that we can use an IPIP header on a hop-by-hop > basis, using either link-local addresses, or even GUA addresses, but > each IPIP header needs to be added/removed at each hop. >=20 > 2) If the definition of the RPI was changed so that it isn't a > "discard if not recognized" type. This change is an incompatible > on-the-wire change, and would represent a flag day. > However, this change could perhaps be done with the updated 6LoRH > compression work, as that is also an incompatible on-the-wire > change for which we presently have no way to signal. >=20 > 3) These proposals are not mutually exclusive: we could do both. >=20 > I'm not looking for "yes, I like proposal X", but rather I'm looking for = replies > of the form of "I can not live with proposal X because Y" >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Tue Feb 23 09:39:59 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5EE1B3B88 for ; Tue, 23 Feb 2016 09:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.023 X-Spam-Level: * X-Spam-Status: No, score=1.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_GIRL=2.3, SPF_PASS=-0.001] autolearn=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 d8Hn7jTEfqSG for ; Tue, 23 Feb 2016 09:39:55 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 F0BF01B3B82 for ; Tue, 23 Feb 2016 09:39:54 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id g62so4940170wme.0 for ; Tue, 23 Feb 2016 09:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=MUWOBJLVfe4zHERNbiskB9xbEa5MC2TLJ24EH7vZ6mT8TpIKJ1EvsryJcwxLGTzGJH K5b9sRFCYATYElN+m5E371lfigIlR5r77uZyc2r7RuaPRrXoawOkyn94nUQK3p5ga4fY RjWY3RU6hYgdxKF2yt+dQQTNynVu+93+BkQwhCcFSmzUPafPddbbYPD2B3c+d8ydmoGz 5ULsSR0W6myG4KwjS3mSMc5siOgv4v8MRN04F4rSlFCTJlY4vOEcv5GlCNaheq+ArpGY rkI5q5gwrpWa4xaEUm6fYfXKAah6e038mFlXO0Ln6JnWDzEVlJKRSdQdPkCFQYW/uiGz UG1A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=k1LGIdH3tumyPN5RbujKLT5hLLXQz3ElfpIKf/AUppN0l6y+qt3eJhEJ1auNa6T+Vt ra7cqm7cMNu/ZPMbPPyDqf3RBd30Z4NVYSX3RoT9M5Ua2MfFkW6SmWkyyigNC3N+OsOX aNuFD2VMRWnc+H2WtTjt/XC/SDsfBFxwNLLinjxb5iH+WIs8Sok+bGf6kD9xeP213/wP SNLy52zznglWimZZs2e2NSZl/EsVq0JXYuyWQ9cCI8LECHsXPlALVauyFXYpv+EpZsv5 qoX6Ejb6K2EB7hU/+wIniquXmj3zXVvjWDL/acPwhjopQeMLCaFrKedsugRRF1IaMdVw SBqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=payfXBSsSbIAgap0d18aMNj2moO5ImOBs6p96Gx/BmA=; b=eLIMNicRkIzAqoFtyNbfCL1acJgwWVE0ilpqXBdr1mHQZYjvaNvKSE25qmCXid6U6S GesHpXXrfIe0XKd/kSXdgsYiYT3bQUCYQ36SaRcKoGrUK8isqDInLUVNwIoRMPEISkVu BoUVCvB3pUziijqkgHS4Mz3PD0zDGrA6Pj/Hdn8FInUHAqEF10CXAAipk7AZW5O4jYlN aAUJOKraauYfNzmj4iid4c1ri9nXdDfQOfQdUgZlJQIGHJYKHKorlM8Nbr/dMyD+9Scx v5PvvO1vQo9KPz1EK6Dhy3oUN1sKUZRo96Ag7tEm+ZfOdijIAucJ37AOOXXLRZ/eoN0m LWGA== X-Gm-Message-State: AG10YORDxHhFoddwwIzx3EjUIpkXD4o3ac12Rhsa3By/YxNoSXouUKbFRy6R+ZJ5hzy3a13UX0pnmO3fU8KGVA== MIME-Version: 1.0 X-Received: by 10.194.189.71 with SMTP id gg7mr35117161wjc.127.1456249193431; Tue, 23 Feb 2016 09:39:53 -0800 (PST) Sender: simon.duquennoy@gmail.com Received: by 10.194.164.130 with HTTP; Tue, 23 Feb 2016 09:39:53 -0800 (PST) In-Reply-To: References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> Date: Tue, 23 Feb 2016 18:39:53 +0100 X-Google-Sender-Auth: Qs-wFpIKYND4m9Dy12XhtjHtZrQ Message-ID: From: Simon Duquennoy To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary=047d7bb03ac2e10b4a052c736fe0 Archived-At: Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:39:57 -0000 --047d7bb03ac2e10b4a052c736fe0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael, Pascal, I think we need at least #1 in order for the problem to be solved not only in a 6LoRH context. Having both #1 and #2 is even more appealing, for more simplicity in the 6LoRH case. Thanks, Simon On Tue, Feb 23, 2016 at 7:45 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > For completeness, Michael, > > The change Nb2 reverses a decision that makes sure that if a packet with > an HbH header / RPI escapes the RPL domain, it is immediately discarded. > This impact has to be weighted. > > Cheers, > > Pascal > > > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael > Richardson > > Sent: lundi 22 f=C3=A9vrier 2016 04:52 > > To: roll@ietf.org > > Subject: [Roll] how to solve flow from RPL-aware-leaf to > non-RPL-aware-leaf > > > > > > At the interim meeting last fall, we came across two problems for which > we > > have no clear recommendation, and which we think needs some protocol > > work. > > > > The situation is described in ticket 173, and in section 5.10 of > useofrplinfo. > > > > Consider the packet flow: > > 6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 --> not-RPL-aware 6LN > > > > In storing mode the packet goes up to the common parent (which may be > > below the root) via typically a default route, and then follows the > hop-by- > > hop down the tree. An RPI header needs to be inserted by the 6LN. > > > > In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP is > not > > necessary, since the receiving node is RPL aware, it can remove the RPI= . > > > > In this case, however, the end-node is not RPI aware, so the 6LR3 needs > to > > remove the RPI. In order for that to happen, the IPIP header needs to = be > > addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's address. > > > > here are two possible ways to deal with this issue: > > > > 1) Pascal has pointed out that we can use an IPIP header on a hop-by-ho= p > > basis, using either link-local addresses, or even GUA addresses, but > > each IPIP header needs to be added/removed at each hop. > > > > 2) If the definition of the RPI was changed so that it isn't a > > "discard if not recognized" type. This change is an incompatible > > on-the-wire change, and would represent a flag day. > > However, this change could perhaps be done with the updated 6LoRH > > compression work, as that is also an incompatible on-the-wire > > change for which we presently have no way to signal. > > > > 3) These proposals are not mutually exclusive: we could do both. > > > > I'm not looking for "yes, I like proposal X", but rather I'm looking fo= r > replies > > of the form of "I can not live with proposal X because Y" > > > > -- > > Michael Richardson , Sandelman Software Works > > -=3D IPv6 IoT consulting =3D- > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --047d7bb03ac2e10b4a052c736fe0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael, Pascal,

I think we need at lea= st #1 in order for the problem to be solved not only in a 6LoRH context.
Having both #1 and #2 is even more appealing, for more simplicity i= n the 6LoRH case.

Thanks,
Simon


On Tue, Feb 23, 2016 at 7:45 AM, Pascal Thubert (pthubert) <pthubert@cis= co.com> wrote:
For complete= ness, Michael,

The change Nb2 reverses a decision that makes sure that if a packet with an= HbH header / RPI escapes the RPL domain, it is immediately discarded. This= impact has to be weighted.

Cheers,

Pascal


> -----Original Message-----
> From: Roll [mailto:roll-bounc= es@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 22 f=C3=A9vrier 2016 04:52
> To: roll@ietf.org
> Subject: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware= -leaf
>
>
> At the interim meeting last fall, we came across two problems for whic= h we
> have no clear recommendation, and which we think needs some protocol > work.
>
> The situation is described in ticket 173, and in section 5.10 of useof= rplinfo.
>
> Consider the packet flow:
>=C2=A0 =C2=A0 6LN --> 6LR1 --> common parent (6LR2) --> 6LR3 -= -> not-RPL-aware 6LN
>
> In storing mode the packet goes up to the common parent (which may be<= br> > below the root) via typically a default route, and then follows the ho= p-by-
> hop down the tree.=C2=A0 An RPI header needs to be inserted by the 6LN= .
>
> In section 5.9 (Flow from RPL-aware-leaf to RPL-aware-leaf), an IPIP i= s not
> necessary, since the receiving node is RPL aware, it can remove the RP= I.
>
> In this case, however, the end-node is not RPI aware, so the 6LR3 need= s to
> remove the RPI.=C2=A0 In order for that to happen, the IPIP header nee= ds to be
> addressed to 6LR3, but 6LN doesn't have any idea what 6LR3's a= ddress.
>
> here are two possible ways to deal with this issue:
>
> 1) Pascal has pointed out that we can use an IPIP header on a hop-by-h= op
>=C2=A0 =C2=A0 basis, using either link-local addresses, or even GUA add= resses, but
>=C2=A0 =C2=A0 each IPIP header needs to be added/removed at each hop. >
> 2) If the definition of the RPI was changed so that it isn't a
>=C2=A0 =C2=A0 "discard if not recognized" type.=C2=A0 This ch= ange is an incompatible
>=C2=A0 =C2=A0 on-the-wire change, and would represent a flag day.
>=C2=A0 =C2=A0 However, this change could perhaps be done with the updat= ed 6LoRH
>=C2=A0 =C2=A0 compression work, as that is also an incompatible on-the-= wire
>=C2=A0 =C2=A0 change for which we presently have no way to signal.
>
> 3) These proposals are not mutually exclusive: we could do both.
>
> I'm not looking for "yes, I like proposal X", but rather= I'm looking for replies
> of the form of "I can not live with proposal X because Y" >
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>
>

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

--047d7bb03ac2e10b4a052c736fe0-- From nobody Thu Feb 25 06:41:24 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6135C1AD069 for ; Thu, 25 Feb 2016 06:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham 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 UmZxCpYGzpkt for ; Thu, 25 Feb 2016 06:41:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21DB1AD062 for ; Thu, 25 Feb 2016 06:41:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B23D92009E for ; Thu, 25 Feb 2016 09:42:28 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D11C6374E for ; Thu, 25 Feb 2016 09:41:19 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 14:41:23 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > The change Nb2 reverses a decision that makes sure that if a packet > with an HbH header / RPI escapes the RPL domain, it is immediately > discarded. This impact has to be weighted. It would only be discarded if the receiving machine does not speak RPL/RPI. If by chance, it does understand that header, then would not discard it by 2460 rule. It could be configured to drop packets with RPI in them. So the protection isn't that great in my opinion, while the cost is pretty significant. But, I agree that it's a concern. We have the opportunity in 6LoRH to effectively make other incompatible changes since deploying 6LoRH will be an incompatible change. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVs8SjICLcPvd0N1lAQJq0wf+NUnztnNlJAYrODDrhAekubaGAUwqHaEe jJRacnRqxRcz+nlPj0nlfuF78A3gIf6A3nzeqSnFYDe+euVhkTRsSZr3sgWi12LU r7CX8IfKu9kkD1FhJ0odTs4qHMXNfB3KIGG5+alwAVx4IMmlAXLIGGv7IrAKsz3R jxnEPr4zpSeLOaOkh4F+BJmL3/DZtiCegQeY8ptkjzHSpYZ7Oa15nte+3QqF/7q2 LyS8gHHsDM0S5QQS2bHPePPS2W5dn/Hy6Ap9e1hy8BMDhXqR49PAwRWRtBg9rFY9 ++dxYs6lumGzHNPB4s5xod0Oe1be39O6m69FmTLToXfsxQ1YCFxM8A== =184G -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Feb 27 15:22:25 2016 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 155081B2D70; Sat, 27 Feb 2016 15:22:21 -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.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160227232221.12361.31203.idtracker@ietfa.amsl.com> Date: Sat, 27 Feb 2016 15:22:21 -0800 Archived-At: Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 23:22:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks of the IETF. Title : When to use RFC 6553, 6554 and IPv6-in-IPv6 Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-01.txt Pages : 30 Date : 2016-02-26 Abstract: This document states different cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is required to set the bases to help defining the compression of RPL routing information in LLN environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-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 Mon Feb 29 05:35:47 2016 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3619D1A903E for ; Mon, 29 Feb 2016 05:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 XmV6LIhxrtBo for ; Mon, 29 Feb 2016 05:35:44 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B0A1A8BB3 for ; Mon, 29 Feb 2016 05:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1268; q=dns/txt; s=iport; t=1456752944; x=1457962544; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SIJPuX5LdyXYjKQxl+3la6a3/k+Z9gD2fssVMkNlf6c=; b=JXQKijSvz7+u73f3gdv62VZeKvSWrO45VqkM4lvU/+uTAg1eCExYJXhE WsSAP7BbEAkVgN3jx1/voCBE8tHEH5taRxlKLypcaLmodZ0fZBHY5gEeS qrG+7hAkX7KBdKI/smK71JN82qmje4xGvws0zKHo6WUUWF8VLZLGJBK6x A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgCWSNRW/4oNJK1egzqBPwa6ZQENg?= =?us-ascii?q?WeCXYM2AoExOBQBAQEBAQEBZCeEQQEBAQSBBQQCAQgRBAEBAScHMhQJCAIEEwi?= =?us-ascii?q?IF75cAQEBAQEBAQEBAQEBAQEBAQEBGIYShDqEGYRWBY1jiSkBjVqOe45JAR4BA?= =?us-ascii?q?UKDZGqHRX4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208";a="81451140" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 13:35:43 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1TDZhYG027131 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Feb 2016 13:35:43 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 07:35:43 -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.1104.009; Mon, 29 Feb 2016 07:35:42 -0600 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf Thread-Index: AQHRb9qeL4f1KCPGMkGwLsdNoV8BL59DDACA Date: Mon, 29 Feb 2016 13:35:38 +0000 Deferred-Delivery: Mon, 29 Feb 2016 13:35:15 +0000 Message-ID: <98b394ec95df4457b3dd8472fa4a46fe@XCH-RCD-001.cisco.com> References: <068.083c7610ff2ac4904b0f3d42985de0e5@trac.tools.ietf.org> <083.ab1b0b92eb7919631cac4e82fc5f8d77@trac.tools.ietf.org> <9111.1456113115@obiwan.sandelman.ca> <19270.1456411279@obiwan.sandelman.ca> In-Reply-To: <19270.1456411279@obiwan.sandelman.ca> 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.228.42.190] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-aware-leaf X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Routing Over Low power and Lossy networks List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 13:35:46 -0000 Agreed, Michael. Pascal > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: jeudi 25 f=E9vrier 2016 15:41 > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] how to solve flow from RPL-aware-leaf to non-RPL-awar= e- > leaf >=20 >=20 > Pascal Thubert (pthubert) wrote: > > The change Nb2 reverses a decision that makes sure that if a packet > > with an HbH header / RPI escapes the RPL domain, it is immediately > > discarded. This impact has to be weighted. >=20 > It would only be discarded if the receiving machine does not speak RPL/RP= I. > If by chance, it does understand that header, then would not discard it b= y > 2460 rule. It could be configured to drop packets with RPI in them. >=20 > So the protection isn't that great in my opinion, while the cost is prett= y > significant. But, I agree that it's a concern. >=20 > We have the opportunity in 6LoRH to effectively make other incompatible > changes since deploying 6LoRH will be an incompatible change. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20