Subject: [netlmm] Comments on draft-ietf-netlmm-mn-ar-if-01.txt

From: "James Kempf" <[email-masked]>
Date: Fri, 30 Jun 2006 14:45:35 -0700

Overall, this document looks in to be in good shape. The addition of the 
text on DHCP has filled an important gap. There are a couple of points that 
may need attention, though. They are:

1) The assumed NETLMM protocol needs to be updated to be based on the actual 
NETLMM protocol, as soon as we get a WG draft.

2) There is brief mention occasionlly in the document about the addressing 
model in which each MN gets a separate address prefix. This model is used by 
GPRS. I think there should be more discussion of this, since it eliminates 
the need for inter-link transmission of NAs for DAD. In many cellular-style 
networks, the shared link model based on Ethernet is not likely to be very 
useful, so this addressing model might be a better match.

3) Section 2.3 needs to discuss what the MN should do about choosing a 
default router when it has moved. I think the latest version of the DNA 
draft should have some text in it indicating how the MN does default router 
reachability detection, but it leaves it up to the MN configuration whether 
it wants to eagerly or lazily switch to a new router. I think for NETLMM, 
the MN must be configured to switch eagerly, otherwise, it will experience 
packet loss or drop into NUD causing extensive delay. I think this applies 
to both the DHCP and autoconfig cases.

4) The draft only discusses multicast in the context of address 
configuration, in Section 4.1. draft-ietf-dna-protocol says that the MN need 
not send out an MLD REPORT if DNA reports that the MN has not moved to a new 
link. In a NETLMM domain, that will always be the case, but the new AR won't 
have the multicast listener state for the MN. I don't have any concrete 
proposal for solving this problem, though I can think of a few suggestions, 
some of which might require support from the NETLMM protocol itself.

5) There is currently a disconnect between this draft and draft-giaretta. 
This draft requires some way for an NA to get from one link to another 
through the LMA without having the TTL decremented so that a node on another 
link can report a DAD address collision with a SEND protected NA, where 
draft-giaretta says that the TTL will be decremented for all packets 
tunneled between links. The reason the TTL must be preserved is because ND 
uses a TTL of 255 to detect whether the packet was sent "on link" or not.

I'd appreciate if these could be entered into Traq, and also encourage 
people to discuss the draft further prior to the meeting (I'll be on 
vacation next week, unfortuantely).

            jak

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm