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

From: [email-masked]
Date: Thu, 21 Apr 2011 16:30:45 +0200

Hi Erik,

Comments in line...

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Thursday, April 21, 2011 1:25 AM
> To: [email-masked]
> Cc: Pascal Thubert (pthubert); [email-masked]; Dijk, Esko
> Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag 
in
> ARO]
> 
> On 4/20/11 1:21 AM, [email-masked] 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?

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

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.
 
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)" <[email-masked]>* Envoyé par :
> > [email-masked]
> >
> > 18/04/2011 10:37
> >
> >
> > A
> >              "Dijk, Esko" <[email-masked]>, "Erik Nordmark"
> > <[email-masked]> cc
> >              [email-masked]
> > 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-masked]]  > Sent: Monday,
> > April 18, 2011 10:19 AM  > To: Erik Nordmark; Pascal Thubert
> > (pthubert)  > Cc: [email-masked]  > 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-masked] [mailto:[email-masked]] On  >
> > Behalf Of Erik Nordmark  > Sent: Friday 15 April 2011 18:39  > To:
> > Pascal Thubert (pthubert)  > Cc: [email-masked]  > 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-masked] [mailto:6lowpan-
> [email-masked]]
> > 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-masked]
> >  > >> https://www.ietf.org/mailman/listinfo/6lowpan
> >  > > _______________________________________________
> >  > > 6lowpan mailing list
> >  > > [email-masked]
> >  > > https://www.ietf.org/mailman/listinfo/6lowpan
> >  > >
> >  >
> >  > _______________________________________________
> >  > 6lowpan mailing list
> >  > [email-masked]
> >  > 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-masked]
> > https://www.ietf.org/mailman/listinfo/6lowpan
> >
> >
> __________________________________________________________
> ____________
> > This email has been scanned by the MessageLabs Email Security System.
> >
> __________________________________________________________
> ____________
> >

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Apr 2011 14:40:18 -0700

On 4/21/11 7:30 AM, [email-masked] wrote:
>  > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
>  > ARO]
>  >

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

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

> 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

>  > > Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
>  > ARO]
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > Hi Esko, Erik
>  > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Apr 2011 09:30:37 +0200

Hello Nicolas, Erik,

> >
> > 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.
registered with
> some other EUI-64), then it is a duplicate.

[Pascal] TID is not related to uniqueness/DAD. It is related to
movement. A node that stays attached to the same router would not need
it. Tragically, LLNs are not like that.
TID enables to invalidate states that have a deprecated sequence.
Typically if you want to redistribute an ND registration into something
else then you need such thing.

I listed in another post 3 issues with ND that can be fixed with a TID
(scalability, out-of-order, and anti-replay). DAD is not in the list. 
DAD works as long as the EUI is unique, which is an assumption we
accepted for this work.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Apr 2011 09:37:37 +0200

> > 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.
> 
draft of
> OSPF, and was replaced. I assume it was replaced for a reason.
> 
[Pascal] that's FUD. 
OSPF does not use lollipop because it is not the appropriate tool, not
because it is a bad tool.
Lollipop has evolved. RPL has one that avoids the well-known pitfalls
like s1<s2<s3<s1.

> 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.

[Pascal] Nicolas 's point exactly. If the user of the TID has an
appropriate mechanism (like a modern lollipop) then the device is
allowed to reboot and loose states. So we are not requiring persistent
memory.
And you can't just avoid something simple in the host by pushing
something undeterminably  complex in the router, because a RPL router is
usually the exact same hardware with the same constraints as the host.

Pascal