Re: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

[Erik Nordmark <[e-mail]>]

On 03/22/10 10:45 AM, Mathilde Durvy (mdurvy) wrote:
> Hi Erik, Samita,
>
> Thanks for your draft. This proposal is much closer to what I had in mind
> myself and I feel this is a great step forward!
>
> I have a few questions / comments:
> - Assumptions: why do you assume that 6LR use RA to configure their global
> addresses while host are allowed to use DHCPv6? In IPv6, routers are
> typically ignoring received RAs... It is not very clear whether your
> proposal allows the case where all addresses (host and 6LR) are assigned
> using DHCPv6. It might also be that in a route-over situation the routing
> protocol itself would take care of distributing well chosen
> prefixes/addresses to allow prefix aggregation in routing tables or routing
> messages.

We just borrowed this from draft-ietf-6lowpan-nd-08.

As I said during the presentation yesterday, I think the key thing to 
standardize around ND is the host-router interaction. This router-border 
interaction is, as you point out, something that can be done in 
different ways.

I think it makes sense to provide an optional way to perform the 
router-border interaction as part of the ND work, while making it clear 
that there are other ways to do those pieces such as the routing protocol.

But I don't think DHCPv6 can be used to assign the same prefix to all 
the routers in the 6lowpan (DHCP prefix delegation would give them all 
different prefixes which is not what we want.)

> - Is there any relation between the concept of 'node lifetime' and
> 'reachable time'? Couldn't you achieve the same effect by setting high
> values for the reachable time?

The reachable time in RFC 4861 is a per-link property advertised by the 
routers, that affects how quickly NUD can detect unreachable nodes.

The node lifetime (aka registration lifetime) needs to be tied to how 
each host sleeps, and that is likely to be different for different hosts.

Hence the flow of the two lifetimes are in opposite directions.

> - Section 7.3: I feel like you are underestimating the role that the routing
> protocol might play. If you take the example of what RPL is defining, an
> IPv6 host could very well be a RPL leaf node, in which case it might
> discover its default router by listening to DIO messages, and send DAO to
> 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 or
> another scheme for address allocation, RS/RA might be completely disabled.
> What do you think?

The assumption for the ND work is that there is something called a 
"host" which does not participate in the routing protocol.
If all the nodes in the network participate in the routing protocol, 
whether it is an enterprise network running OSPF or a lowpan running 
RPL, there is little or no need for Neighbor Discovery.

> - Section 7.3: Reading your description, is it correct to say that hosts
> perform NUD and address resolution for their default router? (of course the
> number of messages is reduced by the heavy use of the SLLA option).

The address resolution for the router comes from the host sending a RS 
and receiving one (or more) RAs in response, where the RA contains the 
SLLA option.

> Do you
> also use NS/NA to perform NUD and address resolution between 6LR?

While it isn't forbidden to use NUD and other parts of RFC 4861 
router-to-router, I don't think this is common in the case of RIP, OSPF, 
or IS-IS, and I don't expect it to be common for the routing protocols 
that would be used for lowpan networks.

> - Section 7.3: ND uses already upper-layer protocol feedback. Would you
> consider to extend it to include lower layer feedback?

One can use lower-layer negative feedback (packet didn't make it; link 
lost) as an indication and hint, but in general lower-layer positive 
feedback isn't an indication that the packet made it to the IP 
destination. (That observation was made by Steve Deering a long time 
ago, as was the basis for the NUD design.)

> To summarize my comments, I would like to understand a bit better how you
> envision the operation of nd-simple when a routing protocol such as RPL is
> used on top of it.

The key for nd-simple is the host-to-router interaction, with protocols 
like RPL handling the router-to-router (including edge/border routers).

    Erik