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:[email protected]] > Sent: Thursday, April 21, 2011 5:41 PM > To: Pascal Thubert (pthubert) > Cc: Erik Nordmark; [email protected]; [email protected] > 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:[email protected]] > > > Sent: Thursday, April 21, 2011 1:25 AM > > > To: [email protected] > > > Cc: Pascal Thubert (pthubert); [email protected]; Dijk, Esko > > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" > > > flag in ARO] > > > > > > On 4/20/11 1:21 AM, [email protected] 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)" <[email protected]>* Envoyé par : > > > > [email protected] > > > > > > > > 18/04/2011 10:37 > > > > > > > > > > > > A > > > > "Dijk, Esko" <[email protected]>, "Erik Nordmark" > > > > <[email protected]> cc > > > > [email protected] > > > > 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:[email protected]] > Sent: > > > > Monday, April 18, 2011 10:19 AM > To: Erik Nordmark; Pascal > > > > Thubert > > > > (pthubert) > Cc: [email protected] > 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: > > > > [email protected] [mailto:[email protected]] On > > > > > Behalf Of Erik Nordmark > Sent: Friday 15 April 2011 18:39 > To: > > > > Pascal Thubert (pthubert) > Cc: [email protected] > 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: [email protected] [mailto:6lowpan- > > > [email protected]] > > > > 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 > > > > > >> [email protected] > > > > > >> https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > _______________________________________________ > > > > > > 6lowpan mailing list > > > > > > [email protected] > > > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 6lowpan mailing list > > > > > [email protected] > > > > > 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > > > > > > > > > __________________________________________________________ > > > ____________ > > > > This email has been scanned by the MessageLabs Email Security > System. > > > > > > > > __________________________________________________________ > > > ____________ > > > > > > > > _______________________________________________ > > 6lowpan mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
