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

[Erik Nordmark <[e-mail]>]

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
>