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 protected] [mailto:[email protected]] 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 protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
