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

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Apr 2011 16:24:40 -0700

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?

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:[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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Apr 2011 09:27:15 +0200

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

> 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]
> 
> > 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.
> 
> The decoupling of the host-router interaction from router-router interaction
> has served us well in the history of the Internet.
> 
>       Erik
> 
> > 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
> > large subnets in plants, building, etc... (see the requirement drafts
> > in ROLL). Registering to all LBRS is totally impractical. 6LoWPAN ND
> > example). Say that due to some config, a node registers a lifetime of
> > rapid sequence, but does not get an answer yet. Then it finally gets 2
> >  > 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,
> > 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  >
> > generate  > RPL traffic without being aware of the existence of RPL at
> > all. So, _not_ all  > hosts have to speak RPL?
> > always  > speak RPL, never speak RPL, or can be mixed RPL/non-RPL
> > speakers.
> >  >
> >  > 'node' refers to any RPL device, either a host or a router  >  >
> > there  > may be a "RPL device" (i.e. RPL-speaking device, I assume)
> > that is also a host.
> >  >
> > editor 2  > weeks ago. Once this is clear I think the present
> > discussion can continue.
> > 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]
> >  > > 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".
> > routing  > protocol, and does not forward packets (except packets
> > explicitly addressed  > to itself using e.g., a routing header).
> >  >
> > 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.
> >  >
> > 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.
> > 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.
> >  > >
> > with  > > inner mobility. Placing the blame on RPL is another
> > illusionist trick.
> > 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
> >  > >> 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.
> >  > >>>
> > 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
> > > >>> 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
> >  > >>
> > 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.
> >

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 21 Apr 2011 09:40:45 -0600

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Apr 2011 21:32:08 +0200

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

> From: Geoff Mulligan [mailto:[email-masked]]
> Sent: Thursday, April 21, 2011 5:41 PM
> Cc: Erik Nordmark; [email-masked]; [email-masked]
> 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.
> 
> support group for these changes, please speak up or we shall move forward
> with the draft as it is.
> 
> 	geoff
> 
> 
> 
> 
> > 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.
> > 6LoWPAN ND cannot scale if the node needs to register to all LBRs.
> 6LoWPAN ND does not define anymore any LBR interaction.
> > > Subject: Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf"
> > > flag in ARO]
> > >
> > > > 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?
> > >
> > > > 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > > > 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.
> > > >
> > > > 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?
> > > >
> > > >  > 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,
> > > > 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.
> > > >  >
> > > >  > '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:
> > > >  > > 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.
> > > >  >
> > > > 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.
> > > >  >
> > > >  > 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
> > > >  >
> > > > 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.
> > > > 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.
> > > >  > >
> > > > 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.
> > > >  > > RPL already adapted to the new reality of large multilink
> > > > subnet with  > > inner mobility. Placing the blame on RPL is
> > > > another illusionist trick.
> > > >  > > 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
> > > >  > >> Subject: Re: [6lowpan] Fwd: Re: "Advertize on Behalf" flag
> > > > in ARO  > >>  > >>  > >> On 4/13/11 12:53 AM, Pascal Thubert
> > > > (pthubert)
> > > > wrote:
> > > >  > >>> Hi Erik:
> > > >  > >>>
> > > >  > >>> 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.
> > > >  > >>>
> > > > 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?
> > > >  > >>
> > > > > >>> 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
> > > >  > >> I don't see a need in 6lowpan-nd for a TID; the protocol
> > > > works fine  > > without it.
> > > > there a  > >> desire for RPL to handle 4861 hosts? Those would
> > > > never know about a  > > TID.
> > > >  > >>
> > > >  > >> Erik
> > > >  > >>
> > > >  > 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.
> > > >

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 21 Apr 2011 13:42:00 -0600

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

---

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

Geoff:

My sense is that we failed to meet a quorum to work efficiently on the backbone router. After the split, it was always a few hands both ways.
Nevertheless, this group worked on the problem for over a year after Dublin, and the design was pretty clear. 
The TID was required to distribute the LBRs.

This thread is not about the backbone router draft. Here, we are talking about the TID in the ND options. 

Scaling to thousands is a requirement in a number of environments I'm dealing with, in particular industrial.
So I'm asking you and the group which plan B we have to scale if there is no TID. I've not seen any so far.
If there's none then yes, we're hitting a wall. That's problem 1.

In any fashion, I've not seen how the current ND  draft operates if control packets are lost or out of order (eg mesh under).
For all I've seen, the host cannot be sure of the final state in the router because the ack is not correlated with the req.
That's problem 2.

Finally, a TID in the control also helps protect the protocol against replay attacks. Any MIC is enough.

I'd like to see a real sense of the group whether we want the TID in or not. Guys, please?

Pascal

> From: Geoff Mulligan [mailto:[email-masked]]
> Sent: Thursday, April 21, 2011 9:42 PM
> Subject: RE: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
> ARO]
> 
> 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
> 
> 
> > 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.
> > > 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.
> > >
> > > > 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.
> > > >
> > > > 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
> > > > > > 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?
> > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 	Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf"
> flag
> > > > > > in
> > > > > ARO]
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hi Esko, Erik
> > > > > >
> > > > > > 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.
> > > > > > 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.
> > > > > > TID in ARO [was: "Advertize on Behalf" flag in  > ARO]  >  >
> > > > > > Hello Erik,
> > > > > >  > '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?
> > > > > >  > 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.
> > > > > > [email-masked] [mailto:[email-masked]] On
> > > > > > [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag in
> > > > > > > ARO]
> > > > > >  > > 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.
> > > > > >  >
> > > > > >  > 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).
> > > > > >  >
> > > > > >  > '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.
> > > > > >  > 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.
> > > > > > 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.
> > > > > >  > > BTW 6LoWPAN ND needs a TID to correlate the NS and the NA
> > > > > > as all other  > > registrations do when strict ordering is not
> > > > > > config, a node registers a lifetime of  > > X, then
> > > > > > deregisters (lifetime 0), then reregisters (lifetime X) in a
> > > > > >  > >> -----Original Message-----  > >> From:
> > > > > > [email-masked] [mailto:6lowpan-
> > > > > [email-masked]]
> > > > > >  > >> 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.
> > > > > >  > >>>
> > > > > > 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  > >>>
> > > > > >  > >>> and have to deal with wrap around, which divides the
> > > > > > space by at  > > least 3.
> > > > > >  > >>>
> > > > > > OSPF, so why  > >> do the hosts need to be aware of RPL by
> > > > > > passing some TID around?
> > > > > >  > >>
> > > > > > 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
> > > > > >  > >> 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
> > > > > >  > >>
> > > > > >  > 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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Apr 2011 16:21:44 -0700

Erik

---

From: Wassim Haddad <[email-masked]>
Date: Mon, 25 Apr 2011 22:07:53 -0700

+1 

Regards,

Wassim H.

---

From: "Pete St. Pierre" <[email-masked]>
Date: Mon, 25 Apr 2011 22:15:14 -0700

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

---

From: <[email-masked]>
Date: Tue, 26 Apr 2011 13:59:28 +0000

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" <[email-masked]>
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
>
>>> 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.
>>>>flag in
>>>>stuff and
>>>>include
>>>>> As demonstrated by older versions of the ND spec (Backbone Router),
>>>>>RPL,
>>>> and MIP.
>>>>> 
>>>>> Which means that it lost its capability to apply in the domains I'm
>>>>>looking at
>>>>> With the TID, we know that we can restore scalability in the future,
>>>>>and we
>>>>>>>     Re: [6lowpan] FW: TID in ARO [was: "Advertize on Behalf" flag
>>>>>>>in
>>>>>> ARO]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Hi Esko, Erik
>>>>>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 26 Apr 2011 10:01:03 -0700 (PDT)

I also think that we must move on.

We must move on and start looking into securing 6lowpan ND?

Regards,

Behcet

> > 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.
and
> > > > It is an abstract  information that if defined properly can be used by 
>many
RPL,
> > > >  With the TID, we know that we can restore scalability in the future, and  
>we
in