Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
"Pete St. Pierre" <pete.st.pierre@oracle.com> Tue, 26 April 2011 05:15 UTC
Return-Path: <pete.st.pierre@oracle.com>
X-Original-To: 6lowpan@ietfa.amsl.com
Delivered-To: 6lowpan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB6E06CD for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWcRGyyxeLaA for <6lowpan@ietfa.amsl.com>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by ietfa.amsl.com (Postfix) with ESMTP id 9641AE067C for <6lowpan@ietf.org>; Mon, 25 Apr 2011 22:15:25 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p3Q5FMtj006845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Apr 2011 05:15:24 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p3Q5FMDR029932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2011 05:15:22 GMT
Received: from abhmt021.oracle.com (abhmt021.oracle.com [141.146.116.30]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p3Q5FGFV030670; Tue, 26 Apr 2011 00:15:16 -0500
Received: from [192.168.1.56] (/99.57.137.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Apr 2011 22:15:16 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="iso-8859-1"
From: "Pete St. Pierre" <pete.st.pierre@oracle.com>
In-Reply-To: <1303414920.1671.1849.camel@d430>
Date: Mon, 25 Apr 2011 22:15:14 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7289A47C-61EC-4E55-B201-1F4950517D3F@oracle.com>
References: <OF05FC8EC8.E2C545F7-ONC1257878.002DC800-C1257878.002DE486@Schneider-Electric.com> <4DAF6B38.7000604@acm.org> <6A2A459175DABE4BB11DE2026AA50A5D046502D9@XMB-AMS-107.cisco.com> <1303400445.1671.1576.camel@d430> <6A2A459175DABE4BB11DE2026AA50A5D0470FA00@XMB-AMS-107.cisco.com> <1303414920.1671.1849.camel@d430>
To: Geoff Mulligan <geoff@proto6.com>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4DB654ED.0001:SCFMA922111,ss=1,fgs=0
Cc: 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]
X-BeenThere: 6lowpan@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2011 05:15:27 -0000
Geoff - I think Erik has made some very good points on this topic. I don't see a need to make the ND draft any more complex than it already is. ...Pete On Apr 21, 2011, at 12:42 PM, Geoff Mulligan wrote: > Pascal, > I couple of people supporting the TID is not group consensus. We have > had many presentations and discussions about multiple LBRs, backbone > LBRs and more and none have met with the support of the working group. > > In your opinions we are crashing, but I fail to see that this is the > opinion of the working group. > > If there are other in the working group that strongly advocate this TID > idea or the work on multiple and backbone LBRs then they need to speak > up now en masse or we must move on. > > geoff > > > On Thu, 2011-04-21 at 21:32 +0200, Pascal Thubert (pthubert) wrote: >> Geoff: >> >> There is twice as much support for restoring the TID than there is for not doing it. >> Before we drop the TID, I'd like to see a proposal that allows a 6LoWPAN ND subnet to scale with multiple LBRs, allows nodes to move from a router to the next, and that does not need a TID. >> Otherwise, we are not speeding towards the wall, we're already crashing. >> >> Pascal >> http://www.xtranormal.com/watch/7011357/ >> >>> -----Original Message----- >>> From: Geoff Mulligan [mailto:geoff.ietf@mulligan.com] >>> Sent: Thursday, April 21, 2011 5:41 PM >>> To: Pascal Thubert (pthubert) >>> Cc: Erik Nordmark; nicolas.riou@schneider-electric.com; 6lowpan@ietf.org >>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in >>> ARO] >>> >>> Pascal, >>> We need to close on this discussion. >>> >>> Back in Hiroshima the Working Group decided that Backbone router stuff and >>> "address defense" across backbone routers was not going to be part of ND >>> draft. It appeared that the draft was getting way to complicated and the >>> Working Group decided to simplify things. >>> >>> I have not seen much support on the list for making these changes to include >>> the TID in ND. >>> >>> We need to get this draft completed. If there is a large "unheard from" >>> support group for these changes, please speak up or we shall move forward >>> with the draft as it is. >>> >>> geoff >>> >>> >>> >>> >>> On Thu, 2011-04-21 at 09:27 +0200, Pascal Thubert (pthubert) wrote: >>>> Hi Erik >>>> >>>> The TID is not a strong coupling between the H2R and the R2R operations, >>> and it is not a coupling with a RPL version explicitly. >>>> It is an abstract information that if defined properly can be used by many >>> forms or R2R interactions. >>>> As demonstrated by older versions of the ND spec (Backbone Router), RPL, >>> and MIP. >>>> >>>> 6LoWPAN ND cannot scale if the node needs to register to all LBRs. >>> 6LoWPAN ND does not define anymore any LBR interaction. >>>> IOW, 6LoPWAN ND lost the capability to scale when the backbone router >>> piece was removed from the draft. >>>> Which means that it lost its capability to apply in the domains I'm looking at >>> (industrial and metering). >>>> >>>> With the TID, we know that we can restore scalability in the future, and we >>> know how. I do not know of a plan B. >>>> >>>> Pascal >>>> http://www.xtranormal.com/watch/7011357/ >>>> >>>> >>>>> -----Original Message----- >>>>> From: Erik Nordmark [mailto:nordmark@acm.org] >>>>> Sent: Thursday, April 21, 2011 1:25 AM >>>>> To: nicolas.riou@schneider-electric.com >>>>> Cc: Pascal Thubert (pthubert); 6lowpan@ietf.org; Dijk, Esko >>>>> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" >>>>> flag in ARO] >>>>> >>>>> On 4/20/11 1:21 AM, nicolas.riou@schneider-electric.com wrote: >>>>>> >>>>>> Dear Pascal and al, >>>>>> >>>>>> I support the idea of reviving the TID in ARO and DAR/DAC. >>>>>> Supporting a TID directly in the node initiating the initial NS >>>>>> appears much simpler than time stamping in the parent router. >>>>> >>>>> How would you make this work if the protocol between the routers is >>>>> not RPLv1, but some future version of RPL or a completely different >>>>> routing protocol? >>>>> >>>>> The decoupling of the host-router interaction from router-router >>>>> interaction has served us well in the history of the Internet. >>>>> >>>>> Erik >>>>> >>>>>> A simple and efficient method to detect mobility of hosts along a >>>>>> backbone of Edge Routers is an important feature to deploy >>>>>> backbones of Edge Routers in Buildings and should be clarified >>>>>> before closing 6LoWPAN WG. >>>>>> >>>>>> Cheers, >>>>>> Nicolas >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *"Pascal Thubert (pthubert)" <pthubert@cisco.com>* Envoyé par : >>>>>> 6lowpan-bounces@ietf.org >>>>>> >>>>>> 18/04/2011 10:37 >>>>>> >>>>>> >>>>>> A >>>>>> "Dijk, Esko" <esko.dijk@philips.com>, "Erik Nordmark" >>>>>> <nordmark@acm.org> cc >>>>>> 6lowpan@ietf.org >>>>>> Objet >>>>>> Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in >>>>> ARO] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Hi Esko, Erik >>>>>> >>>>>> The discussion on RPL and hosts should happen on the RPL list >>>>>> under a different topic. The point being discussed here is this: >>>>>> >>>>>> The reality is also that those (LLN) networks will need to scale >>>>>> to large subnets in plants, building, etc... (see the requirement >>>>>> drafts in ROLL). Registering to all LBRS is totally impractical. >>>>>> 6LoWPAN ND requires a coordination between LBRs but does not say >>> how it happens. >>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>> ND-01to07; and it requires a TID, for the same reason as RPL. >>>>>> Removing the backbone operation and the TID from the draft is ostrich >>> policy. >>>>>> >>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as all >>>>>> other registrations do when strict ordering is not guaranteed (MIP >>>>>> being an example). Say that due to some config, a node registers a >>>>>> lifetime of X, then deregisters (lifetime 0), then reregisters >>>>>> (lifetime X) in a rapid sequence, but does not get an answer yet. >>>>>> Then it finally gets 2 AROs back, lifetime X and 0. What's the final state >>> in the router? >>>>>> >>>>>> I'd like to hear what others think. >>>>>> >>>>>> Pascal >>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Dijk, Esko [mailto:esko.dijk@philips.com] > Sent: >>>>>> Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal >>>>>> Thubert >>>>>> (pthubert) > Cc: 6lowpan@ietf.org > Subject: RE: [6lowpan] FW: >>>>>> TID in ARO [was: "Advertize on Behalf" flag in > ARO] > > Hello >>>>>> Erik, >>>>>>>> taking the definition you quoted: >>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>> forward > RPL traffic > > the question may arise what is "RPL >>>>>> traffic"? It is not defined in the RPL draft > it seems. Pascal >>>>>> clarified to me it is traffic associated to a RPL instance, not > >>>>>> necessarily RPL protocol messages. This means that a host could >>>>>> generate > RPL traffic without being aware of the existence of >>>>>> RPL at all. So, _not_ all > hosts have to speak RPL? >>>>>>> The RPL draft does not explicitly state if "hosts" in a RPL >>>>>> network always > speak RPL, never speak RPL, or can be mixed >>>>>> RPL/non-RPL speakers. >>>>>>> >>>>>>> Taking the definition of 'node' in the RPL draft: >>>>>>> 'node' refers to any RPL device, either a host or a router > >>>>>>> rules out (?) the option that all "hosts" are non-RPL speakers, >>>>>> since there > may be a "RPL device" (i.e. RPL-speaking device, I >>>>>> assume) that is also a host. >>>>>>> >>>>>>> I communicated these perceived unclarities to Pascal and the >>>>>> RFC editor 2 > weeks ago. Once this is clear I think the present >>>>>> discussion can continue. >>>>>>> And then there is the related discussion of ND support for >>>>>> sleepy devices, > the original topic of Anders ;) > > best >>>>>> regards, > > Esko > > > > -----Original Message----- > From: >>>>>> 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >>>>>> Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: >>>>>> Pascal Thubert (pthubert) > Cc: 6lowpan@ietf.org > Subject: Re: >>>>>> [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in > >>>>>> ARO] >>>>>>>> On 4/14/11 11:43 PM, Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> RPL can do what all classical IGPs can do WRT hosts. That is >>>>>> as long > > as the host address belongs to the router's prefix >>>>>> and stays attached > > to that router. >>>>>>> >>>>>>> I just realized that we might be talking about a different >>>>>> definition of "host". >>>>>>> What I mean by "host" is a node which does not participate in a >>>>>> routing > protocol, and does not forward packets (except packets >>>>>> explicitly addressed > to itself using e.g., a routing header). >>>>>>> >>>>>>> However, RPL has a different definition: >>>>>>> 'host' refers to an LLN device that can generate but does not >>>>>> forward > RPL traffic > > Basically per the RPL definition >>>>>> there is no such thing as a node which does > not participate in >>>>>> the RPL protocol. >>>>>>> IMHO what is in RPL should have been defined as a >>>>>> non-forwarding node, so > that we can have a sane discussion >>>>>> without getting entangled in terminology > issues. >>>>>>> >>>>>>> Which definition of "host" are you using above? >>>>>>> >>>>>>> Per the RPL definition there is no need for 6lowpan-nd, since >>>>>> all nodes will > speak RPL. This is rather confusing, don't you think? >>>>>>> >>>>>>> Erik >>>>>>> >>>>>>>> When the topology becomes multilink subnet and mobility is >>>>>> required > > then it is a new problem entirely, and NO, 4861 is >>>>>> not a suitable > > interaction with the router to allow the >>>>>> router to redistribute a host route. >>>>>>>> Because the neighbor cache that 4861 builds is not a of the >>>>>> same >>>>>>>> nature as the binding table that 6LoWPAN ND builds. Another >>>>>>>> thing >>>>>> that > > 6LoWPAN ND fails to express correctly. I proposed text >>>>>> to explain that > > (attached) but it was not considered, >>>>>> contributing to the illusion > > that a cache is a table. >>>>>>>> >>>>>>>> The reality is also that those networks will need to scale to >>>>>> large > > subnets in plants, building, etc... (see the >>>>>> requirement drafts in > > ROLL). Registering to all LBRS is totally >>> impractical. >>>>>> 6LoWPAN ND > > requires a coordination between LBRs but does not >>>>>> say how it happens. >>>>>>>> This problem was discussed in 6LoWPAN; the answer was in >>>>>> ND-01to07; > > and it requires a TID, for the same reason as RPL. >>>>>> Removing the > > backbone operation and the TID from the draft is >>>>>> ostrich >>>>> policy. >>>>>>>> >>>>>>>> RPL already adapted to the new reality of large multilink >>>>>> subnet with > > inner mobility. Placing the blame on RPL is >>>>>> another illusionist trick. >>>>>>>> And this is not RPL last call. >>>>>>>> >>>>>>>> BTW 6LoWPAN ND needs a TID to correlate the NS and the NA as >>>>>> all other > > registrations do when strict ordering is not >>>>>> guaranteed (MIP being an > > example). Say that due to some >>>>>> config, a node registers a lifetime of > > X, then deregisters >>>>>> (lifetime 0), then reregisters (lifetime X) in a > > rapid >>>>>> sequence, but does not get an answer yet. Then it finally gets >>>>>> 2 >>>>>>>> AROs back, lifetime X and 0. What's the final state in the router? >>>>>>>> >>>>>>>> It seems we can never agree on any of this. I'd like to hear >>>>>> what >>>>>>>> others think. >>>>>>>> >>>>>>>> Pascal >>>>>>>> http://www.xtranormal.com/watch/7011357/ >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>> bounces@ietf.org] >>>>>> On > >> Behalf Of Erik Nordmark > >> Sent: Friday, April 15, >>>>>> 2011 >>>>>> 1:30 AM > >> To: 6lo>> '6lowpan' >>>>>>>>> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag >>>>>> in ARO > >> > >> > >> On 4/13/11 12:53 AM, Pascal Thubert >>>>>> (pthubert) >>>>>> wrote: >>>>>>>>>> Hi Erik: >>>>>>>>>> >>>>>>>>>> The RPL (DAO) sequence number allows the node to increment >>>>>> rapidly > >>> in case of rapid changes and then lazily when the >>>>>> situation is > >>> stable and DAO are scarce. The increase is >>>>>> strictly monotonous which > > > >>> is critical to us. >>>>>>>>>> >>>>>>>>>> A time stamp imposes a synchronization between the routers. >>>>>> We do > >>> not have such mechanism in RPL. A time unit (a >>>>>> granularity) must be > >>> agreed upon. Within that unit, >>>>>> movements go undetected so the time > >>> unit must be thin grained >>> to cover rapid changes. >>>>>> Yet, depending on > >>> the medium, the time unit, and the size >>>>>> of the network, it is not > >>> necessarily easy/possible to >>>>>> guarantee a strictly monotonous value > >>> with a thin grained >>>>>> time unit. And we have limited space (2 >>>>>> octets) >>>>>>>>>> and have to deal with wrap around, which divides the space >>>>>> by at > > least 3. >>>>>>>>>> >>>>>>>>>> So RPL went for a sequence number. >>>>>>>>> >>>>>>>>> But the unstated assumption that RPL made is that all >>>>>> host-to-router > >> protocols have to now be RPL aware. That >>>>>> doesn't sound like good > > design. >>>>>>>>> A host isn't aware of whether the routers speak IS-IS or >>>>>> OSPF, so why > >> do the hosts need to be aware of RPL by passing >>>>>> some TID around? >>>>>>>>> >>>>>>>>>> I think ND has the same need as MIP for a TID == Sequence # . >>>>>> We > >>> know of MIP; We know of RPL. We know of the backbone >>>>>> router >>>>>>>>>> operation. We know we'll need the TID and we know exactly >>>>>>>>>> why. I think we should have it in the 6LowPAN ND spec right >>>>>>>>>> away to >>>>>> avoid > >>> interop issues when we add RPL and BR operations. >>>>>>>>> >>>>>>>>> I don't see a need in 6lowpan-nd for a TID; the protocol >>>>>> works fine > > without it. >>>>>>>>> I think RPL needs to be improved to deal with reality. Isn't >>>>>> there a > >> desire for RPL to handle 4861 hosts? Those would >>>>>> never know about a > > TID. >>>>>>>>> >>>>>>>>> Erik >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>>> The information contained in this message may be confidential >>>>>> and legally > protected under applicable law. The message is >>>>>> intended solely for the > addressee(s). If you are not the >>>>>> intended recipient, you are hereby notified > that any use, >>>>>> forwarding, dissemination, or reproduction of this message is > >>>>>> strictly prohibited and may be unlawful. If you are not the >>>>>> intended recipient, > please contact the sender by return e-mail >>>>>> and destroy all copies of the > original message. >>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>>> >>> __________________________________________________________ >>>>> ____________ >>>>>> This email has been scanned by the MessageLabs Email Security >>> System. >>>>>> >>>>> >>> __________________________________________________________ >>>>> ____________ >>>>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan
- [6lowpan] FW: TID in ARO [was: "Advertize on Beha… Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … nicolas.riou
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Geoff Mulligan
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Geoff Mulligan
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pascal Thubert (pthubert)
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Erik Nordmark
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Wassim Haddad
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Pete St. Pierre
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Basavaraj.Patil
- Re: [6lowpan] FW: TID in ARO [was: "Advertize on … Behcet Sarikaya