Subject: [netlmm] NETLMM design team update

From: "Roberts Phil-APR042" <[email-masked]>
Date: Tue, 20 Jun 2006 10:53:17 -0400

The design team is still continuing its work on the protocol design.  We
submitted a draft-00 of the document yesterday
(draft-giaretta-netlmm-dt-protocol-00.txt) and we would like to express
to the working group our assessment of the status of our work, what one
should expect from the draft at this stage, and what we would like as
working group input at this stage of the process.

The design team believes it has a good understanding of the new
functional elements being proposed for the NETLMM protocol and their
operation, of the message sequences between those functional elements,
and the contents of those messages.  The design team still has work to
do in describing these elements and in working out to its own
satisfaction some lingering issues that haven't been sufficiently
assessed in the protocol design.

The protocol draft (insert link) at this stage has descriptions of all
the functional elements and all of the protocol messages and fields.
The design team is considering another message in the protocol sequences
but hasn't had enough time to digest the implications of it and
integrate it well into the document.  This version of the document is a
snapshot of the work and the design team realizes that more smoothing
and cleaning up is needed.  There is a section documenting open issues
that the design team is still working on.

It would be good for the working group when considering this document
not to focus too much on specific details, but to focus on the big
picture concepts in the document - the functional entities, the protocol
exchanges, and the required fields.  The design team welcomes input at
this stage, but please be sensitive to the fact that comments at this
stage need to be kept at a high level.  There will be a time for
detailed review, but at this point big picture comments are what the
design team would like input on.

At IETF66 the design team will present the status of the work at that
time, which will probably include resolution of some outstanding items,
and another draft iteration either shortly before or shortly after IETF.

Phil Roberts on behalf of the design team

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Jun 2006 08:14:10 -0700

A copy of the protocol design document is posted here:

http://www.geocities.com/kempf42/draft-giaretta-netlmm-dt-protocol-00.txt

            jak

----- Original Message ----- 
From: "Roberts Phil-APR042" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 20, 2006 7:53 AM
Subject: [netlmm] NETLMM design team update

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

---

From: "Genadi Velev" <[email-masked]>
Date: Fri, 23 Jun 2006 16:49:38 +0200

Folks,

after reading this initial version of the NetLMM protocol I-D, I have
some high-level comments. Hopefully they will help for improving the
next version of the I-D.

A) The process of assignment of serving LMA to a MN is a bit unclear to
me. It's explained that this is outside the scope of the NetLMM protocol
and done during NetLMM bootstrapping procedure. IMO this procedure is
specific to NetLMM protocol because it discovers an LMA, which on the
other hand is a NetLMM-specific entity. Is there a plan in the DT to
elaborate on the NetLMM bootstrapping in the next version of the I-D? 

B) The LMA Allocation Request and LMA Allocation Reply messages are
exchanges between LMA and (maybe ?) policy decision point (PDP). Since,
e.g., the PDP needs to implement at least these 2 NetlMM messages, it
needs to be described in more detail, as an entity part of the protocol.

C) It's not mentioned how the MN's link-local IP address is treated in
the NetLMM infrastructure. Doesn't it need to be checked for uniqueness
at the LMA? What happens in the MAG when it receives NS for link-local
IP address DAD? 
 
Thanks,
Genadi

P.S. Some minor comments for text improvement:
- on page 10: "PDP" is mentioned without introducing this abbreviation.
I guess it's a Policy Decision Point entity, isn't it?  Some pointer
would be helpful (maybe RFC 2753?).
- the meaning of "tunnel ID" is unclear. 
- figure(s) with signaling flow chart would be very helpful for easier
understanding the succession of the message exchange.

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Tuesday, June 20, 2006 5:14 PM
> To: Roberts Phil-APR042; [email-masked]
> Subject: Re: [netlmm] NETLMM design team update
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jun 2006 11:59:47 -0700

Phil and others,
 
Overall observation is that the work appears to be on-target
and looks like a useful starting point for moving forward.
Specific high-level comments appear below.
 
Fred
[email-masked]

Comments on: 'draft-giaretta-netlmm-dt-protocol-00.txt':
********************************************************

1) Section 2 (and throughout the document) the term "IP Link"
is used here but was removed from the "ps" and "req" documents.
Suggest just using "link" as was done for the other documents.

2) Section 2 (and extensively throughout the document) "NetLMM
address" only speaks to *address* assignments for MNs, but
*prefix* assignments should also be in-scope. This is necessary
to avoid multilink subnet issues over multiple-access links
as well as to provide mobile router functionality for MNs.

3) Throughout the document, the specification should allow
for the possibility that the MAG and LMA are co-located.
Maybe there are already no inconsistencies wrt to this?

4) Section 4, paragraph beginning: "When a mobile node then
leaves the NetLMM infrastructure", how can the MAG know that
the MN has left the NetLMM infrastructureas opposed to moving
to some other MAG within the infrastructure?

5) Section 5.2 (and elsewhere throughout the document) seems
to imply that the tunnel between the LMA and MAG needs to be
bidirectional, but why must that be so? At least in terms of
the data plane, the tunnel should only need to be
unidirectional from LMA->MAG.

6) Section 5.4 (and elsewhere throughout the document) the spec
should allow for the possibility that Router Advertisements
could carry *no* prefix information options, e.g., so that
MN's will have to procure prefixes via a mechanism such as
DHCPv6 prefix delegation. (See also Sections 8.2.3.3 and
8.2.3.4.)

7) Section 5.11, have implications of data corruption been
analysed in order to warrant a SHOULD for accepting messages
with zero UDP checksum?

8) Section 7.1, unused values for Status/Type/Sub-type should
be listed as "Reserved for future use". Same comment for all
of the options specified under Section 7.2.

9) Section 8.1.1 seems to imply that LMA discovery (from the
MAG's perspective) is out-of-scope. This seems like a fundamental
aspect of NETLMM operation, so either an "LMA Discovery" spec
is needed or the procedure needs to be dealt with here. (Same
comment for Section 8.1.3.3.)

10) Section 9.1, suggest leaving open the possibility that
LMAs/MAGs could act as neighbor discovery proxies and/or
routing-bridges so that packets forwarded btw two MNs that
configure addresses from the same IP prefix are not subject
to Hop Limit decrementation (thus avoiding multilink subnet
issues).

11) Immediately after Section 10, suggest adding a new section
on "Multilink Subnet Considerations". Should explain scenarios
in which multilink subnet is naturally avoided and warn against
scenarios in which mutlilink subnet issues exist. Also, add
reference for 'draft-thaler-intarea-multilink-subnet-issues-00'.

12) Section 15, would like to see a reference for RFC3315
and corresponding citation(s) in the document.

________________________________

From: Roberts Phil-APR042 [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 7:53 AM
To: [email-masked]
Subject: [netlmm] NETLMM design team update