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

[Erik Nordmark <[e-mail]>]

On 4/21/11 7:30 AM, [e-mail] wrote:
>
> Hi Erik,
>
> Comments in line...
>
>  > 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?
>
> As Pascal answered in his post, the TID is not particularly coupled with
> RPLv1. The TID is just an extra information provided by the node during
> ND registration which dramatically simplifies node localization but also
> enable DAD across a backbone of Edge Routers advertizing the same prefix.
> Which alternative solution would you suggest for DAD?

DAD works fine with what we have in ARO.
If the same EUI-64 (re)registers the same IPv6 address, then it is not a 
duplicate.
If a different EUI-64 tries to registers an IPv6 address (already 
registered with some other EUI-64), then it is a duplicate.
That is independent whether the check is done in a 6LR or 6LBR.

What do you see as the problem with DAD? Can you provide an example of 
what doesn't work with 6lowpan-nd?

> The TID can fit in "reserved" field of ARO/DAR/DAC and thus can come
> at no cost.

FWIW Complexity is the true cost, because unneeded complexity leads to 
non-interoperability for no benefit.

> Thanks to the lollipop mechanism defined in 6lowpan-nd-07 the TID can be
> implemented even in the most constrained devices which might not be able
> to consistently increment the TID.

The lollipop stuff is not proven technology. It existed in an early 
draft of OSPF, and was replaced. I assume it was replaced for a reason.

Any proven TID scheme would require stable storage on the device, so 
that the device doesn't accidentally reuse old TIDs too soon. I don't 
think we want to require that capability on all 6lowpan hosts, just 
because it is perceived too hard to have RPL keep track of things.

    Erik

> Regards,
> Nicolas
>
>
>  > 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.
>  > >
>  > __________________________________________________________
>  > ____________
>  > >
>
>
>
>
>
>