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