Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in ARO]

[Wassim Haddad <[e-mail]>]

+1 


Regards,

Wassim H.





On Apr 21, 2011, at 8:40 AM, Geoff Mulligan wrote:

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