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

["Pascal Thubert (pthubert)" <[e-mail]>]

> 
> > 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?
> 
> If the host changes its mind, then it would make sense for it to first
listen to
> the ack/nak of its previous instructions before issuing a new
registration.
> 
> I don't see this as a difficult restriction, because I think that it
will be rare that
> a host can't decide whether it will register or unregister.

[Pascal] Decoupling from L2 capability should serve us well also,
shouldn't it?

 In mesh under:

- you do not have end to end ack
- you will have multipath
- you will have out of order packets

ND needs a TID. 

Pascal


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