Subject: [netlmm] Yet another review of draft-giaretta-netlmm-dt-protocol-01

From: Julien Laganier <[email-masked]>
Date: Fri, 29 Sep 2006 16:51:03 +0200

Folks,

Herewith included is my review of the DT's NETLMM protocol draft. I 
think the revised document has progressed a lot since -00: It was 
nice to read. I have however a couple of observations/questions, and 
some editorial nits.

Best,

--julien

---------------------------------------------------------------------

- Page 6, 2. Terminology

The definition for the NetLMM Address says "The invariant IP address 
on the MN inside the NetLMM domain." This seems to suggest that the 
MN has only one such address ("The") whereas it is possible that a MN 
whish to have more invariant addresses (e.g. a temporary RFC3041 
address and a long term public address stored in the DNS.) I'd 
suggest rewording into "An invariant IP address..."

- Page 9, 4.1. Mobility Management

It is written "In the case of stateless address autoconfiguration 
being used, the MAG also sends a router advertisement to the attached 
mobile." I don't think sending an RA is specific to SLAAC. If DHCP is 
used a RA will be sent as well, but with the 'M' bit (Managed) set. 
Of course there might be cases when no RAs would be sent (e.g. PPP)

- Page 10, 4.1. Mobility Management

Figure 2 represents message 7 (Router Advertisement) and 8 (DAD) as 
Link-Layer signalling (====), while RA and NS-DAD are network layer 
messages. They should probably be represented as Non-NetLMM 
signalling (....)

Also, I don't understand why the LMA need to be told by the PDP the MN 
ID which has been allocated to it, since MN ID will be provided to 
the LMA by the MAG in the location registration message. This seems 
redundant.

- Page 12, 4.1. Mobility Management

Figure 3 doesn't shows RS/RA exchange between MN and MAG as per DNAv6. 
Howevere figure 2 shows a RA sent by the MAG to MN. Suggest to show 
RS/RA in both places or nowhere, or perhaps explain why there's the 
possibility that RA isn't sent upon handover. 

- Page 14, 4.3.1. Message retransmission:

It is stated that "RTO SHOULD not exceed the limit of RTO_MAX 
seconds"; does it mean that when 2 * previous RTO exceed RTO_MAX 
retransmission are stopped, or the RTO is limited to RTO_MAX for 
further retransmissions?

I found this wording "with a resolution better than 1 second (such as 
1ms, for instance)" vague. Does it mean resolution should be strictly 
lesser than 1 second? or lesser or equal? or something else?

- Page 15

This sentence: "Optionally, NetLMM entities MAY use more enhanced 
schemes to dynamically re-calculate and adjust the RTO." is too 
vague. I'd propose "Other specifications may describe enhanced RTO 
calculation schemes to be used by NetLMM entities. They are out of 
scope of this specification."

- Page 26, 6.3. ID Option

Regarding Type 0 "128-bits opaque cryptographically generated 
identifier": I think that the length should not be fixed, it is 
better to allow for many length, and the length of the ID can be 
inferred from the TLV length anyway. Then I think that 
"cryptographically generated" conflicts with opaque. It should be 
one, or the other, but not both. Suggest separating into two 
different types, one "variable length opaque identifier" and one 
"variable length cryptographically generated identifier (such as 
proposed ORCHID)"

- Page 26/27, 6.4. Prefix Option

I am confused by the Subnet Prefix / Address Prefix fields... Why do 
you need both? 

At least the prefix length encoded in the Address Prefix seems 
redundant since it can be inferred from the TLV length?

Then I don't understand how they would be used in practice. For 
example which of those fields would be filled in the Prefix Length 
field of an RA?

- Page 43, 8.2.1. Link-local multicast

It is written "To support some functions, such as for Duplicate 
Address Detection (DA), MAGs might proxy associated Neighbor 
Discovery messages to perform DAD procedure with LMA nodes."

As we've discussed so far on the ML, the proxying of ND messages part 
of DAD will be needed only when shared links are present in the 
NetLMM domain (but still under the per-MN subnet prefix .) This is 
needed to insure unicity of link-layer adddresses across all links of 
the domain, so that when two MN first attach to different links but 
later on move on the same link there is no risk of collision. This is 
not required for DAD of global addresses as collision cannot occurs: 
each MN has its "own" subnet prefix.

The proxying needs to be done from a MAG where DAD occurs to the LMA. 
Then if the LMA detects that the DADed link-local is used at another 
MAG, it should proxy the NS up to that MAG. This is contradiction 
with the current text which seems to imply that only the MAG proxies 
DAD.

Further, in order for that proxying to happen, the NetLMM protocol 
should specify how it is done, and an option allowing to carry the NS 
and NA part of DAD, otherwise they will be dropped because of their 
TTL. None of those is currently specified.

Hence I suggest that an option/message to carry NS/NA part of DAD is 
specified in this document (DAD_probe for NS, DAD_defend for NA?), 
and that the sentence be replaced with something alone those lines:

"On shared links, it is required that the MAGs and LMA be able to 
proxy Neighbor Discovery messages part of the Duplicate Addres 
Detection procedure [RFC2462]. When such proxying is required as 
described in per [I-D.ietf-netlmm-mn-ar-if]:
	-  MAGs SHOULD follow procedures defined in
	   [I-D.ietf-netlmm-mn-ar-if]
	-  MAGs and LMAs MUST proxy NS and NA messages part of DAD
           encapsulated in a NetLMM message/option as specified in
           Section XXX of this document. "

Page 44, 8.2.2. IP Multicast,

Figure 5. shows a MN sending IGMP report to join a multicast session. 
However, after a handover occurs, the new MAG isn't aware of the 
multicast listener state of that MN. Hence we should probably specify 
that "the MAG MUST re-establish the multicast listener state for 
newly attached MNs. It SHOULD reconstruct this state using IGMPv3 or 
MLDv2 General Membership Query."

We can also add that "Alternatively, the MAG MAY use multicast 
listener state transfer techniques which are beyond the scope of this 
specification."

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