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

[Erik Nordmark <[e-mail]>]

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:[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.
> ______________________________________________________________________
>