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

[<[e-mail]>]

Agree. Erik has made some very good points. I don¹t see a need for
extending the ND I-D further.
The core protocol should be simple enough and that will suit most use
cases. However if Pascal has this special use case and applicability, he
could write another I-D explicitly for that purpose. I see no reason to
include Pascal's proposed enhancements in the 6lowpan ND I-D.

-Raj

On 4/26/11 12:15 AM, "ext Pete St. Pierre" <[e-mail]>
wrote:

>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:[e-mail]]
>>>> Sent: Thursday, April 21, 2011 5:41 PM
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: Erik Nordmark; [e-mail];
>>>>[e-mail]
>>>> 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:[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
>
>_______________________________________________
>6lowpan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/6lowpan