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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 15 Apr 2011 08:43:04 +0200

Forwarding without the mail attached (was bounced by the mailer)

Pascal
http://www.xtranormal.com/watch/7011357/

-----Original Message-----
From: Pascal Thubert (pthubert) 
Sent: Friday, April 15, 2011 8:41 AM
To: 'Erik Nordmark'
Cc: [email-masked]
Subject: TID in ARO [was: "Advertize on Behalf" flag in ARO]

Hi Erik:

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.

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 15 Apr 2011 09:38:32 -0700

> the host address belongs to the router's prefix and stays attached to

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

>> To: 6lo>>  '6lowpan'

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 18 Apr 2011 10:37:45 +0200

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.

I'd like to hear what others think.

Pascal

> 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:
> 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
> 
> 
> 
> 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".
> 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).
> 
> Basically per the RPL definition there is no such thing as a node
which does
> not participate in the RPL protocol.
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
> 
> > 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.
> >
> > 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.
> >
> > 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
> 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: Erik Nordmark <[email-masked]>
Date: Wed, 20 Apr 2011 16:23:34 -0700

> different topic. The point being discussed here is this:

But it is hard to have that discussion if we don't know whether the 
'hosts' are participating in RPL or not.
For this email I assume they are not.

 > operation and the TID from the draft is ostrich policy.

Clearly the backend of the network needs to be able to handle changes in 
terms of the host's location, whether the backend is a set of LBRs or a 
set of RPL speakers. But that doesn't mean that the hosts need to be 
burdened with carrying a TID around. Different backends might use 
different mechanisms to serialize the changes to the host's location.

For example, when I go to an ATM machine to take out some money from my 
bank, there might be transaction IDs, timestamps, and many other 
wonderful things happening in the backend ATM network and the bank's 
database.

But that doesn't mean that I as a user of the ATM has to retain a 
transaction ID that I key into the ATM.

I think we can have the same degree of decoupling between 6lowpan and 
the routing protocols, and we do between the ATM user and the bank's 
database.

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

    Erik

---

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

of
2
> 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

> >>>> I think RPL needs to be improved to deal with reality. Isn't
there
> > a
> >> protected under applicable law. The message is intended solely for
> >> the addressee(s). If you are not the intended recipient, you are
> >> hereby
> > notified

---

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

Erik