Subject: RE: [netlmm] NETLMM design team update

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 26 Jun 2006 04:05:09 -0700

Hi Fred.  Comments below.

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Friday, June 23, 2006 12:00 PM
> To: Roberts Phil-APR042; [email-masked]
> Subject: RE: [netlmm] NETLMM design team update
> 
> 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.
> 

Input taken.  There were discussions on the term and it was agreed at
that time not to use IP link for some reason.  We'll need to revisit
this.

> 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.
> 

The protocol mechanism supports NETLMM network prefix. We need to figure
how to document this more clearly. 

> 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?
> 

I think we should cover this topic.

> 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?
> 

The MAG just detects that MN is no longer attached to the network.  If
MAG did not receive Location Dereg from the LMA (i.e. which would have
cleared its state for the MN), the MAG should send a Location Dereg to
the LMA.  So in the handover case, it's likely MAG had already been
informed.  So the answer is that MAG does not know the difference.

> 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.
> 

We had some discussions on this topic of bidirectional vs.
unidirectional tunnel.  This issue was brought up by Vidya's draft as
well.  For now, it's only bidirectional support. 

> 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.)
> 

If the M bit is set in RA, then host uses DHCP.  I'm not sure if it
matters that the prefix option is in the RA or not for this case?

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

Good pt.  We need to clarify if zero UDP checksum should be accepted in
the case only if the message is authenticated by other means, thus
eliminating this data sanity check.

> 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.)
> 

I think this type of info can be in the applicability drafts.  See my
other email on this topic.

> 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).
> 

This needs some more thought.

> 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'.
> 

Seems reasonable to me.

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

OK.

Kent

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jun 2006 15:37:55 -0700

Thanks Kent,

Just out of curiosity, why was it decided to change the term
AR -> MAG? I'm having a hard time stomaching "MAG" for some
reason; "AR" just seemed cleaner and simpler to me.

I'm OK with the change of MAP -> LMA, but if it were put to
a vote I would ask to have "AR" brought back...

Fred

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 4:05 AM
To: Templin, Fred L; Roberts Phil-APR042; [email-masked]
Subject: RE: [netlmm] NETLMM design team update

Hi Fred.  Comments below.

Seems reasonable to me.

OK.

Kent

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 27 Jun 2006 09:37:13 -0500

I am with the same opinion to have AR intead of MAG

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 5:38 PM
To: Kent Leung (kleung); Roberts Phil-APR042; [email-masked]
Subject: RE: [netlmm] NETLMM design team update

Thanks Kent,

Just out of curiosity, why was it decided to change the term
AR -> MAG? I'm having a hard time stomaching "MAG" for some reason; "AR"
just seemed cleaner and simpler to me.

Fred

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Monday, June 26, 2006 4:05 AM
To: Templin, Fred L; Roberts Phil-APR042; [email-masked]
Subject: RE: [netlmm] NETLMM design team update

Hi Fred.  Comments below.

> 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.
> 

Seems reasonable to me.

OK.

Kent

---

From: Julien Laganier <[email-masked]>
Date: Tue, 27 Jun 2006 16:46:04 +0200

Hi,

My 2 cents on the subject (I don't have a strong opinion on the 
matter.) 

I think that the supplementary functionality one can find in a "NetLMM 
AR" compared to a plain plain AR justify the need for a different 
name (i.e. MAG.)

--julien

On Tuesday 27 June 2006 16:37, Mohamed Khalil wrote:
> AR -> MAG? I'm having a hard time stomaching "MAG" for some reason;
> "AR" just seemed cleaner and simpler to me.
>
> > 1) Section 2 (and throughout the document) the term "IP Link" is
> > used here but was removed from the "ps" and "req" documents.
> Input taken.  There were discussions on the term and it was agreed
> at that time not to use IP link for some reason.  We'll need to
> revisit this.
>
> > "NetLMM address" only speaks to *address* assignments for MNs,
> > but *prefix* assignments should also be in-scope. This is
> The protocol mechanism supports NETLMM network prefix. We need to
> figure how to document this more clearly.
>
> The MAG just detects that MN is no longer attached to the network. 
> If MAG did not receive Location Dereg from the LMA (i.e. which
> would have cleared its state for the MN), the MAG should send a
> Location Dereg to the LMA.  So in the handover case, it's likely
> MAG had already been informed.  So the answer is that MAG does not
> know the difference.
>
> unidirectional tunnel.  This issue was brought up by Vidya's draft
> as well.  For now, it's only bidirectional support.
>
> Good pt.  We need to clarify if zero UDP checksum should be
> accepted in the case only if the message is authenticated by other
> means, thus eliminating this data sanity check.
>
> I think this type of info can be in the applicability drafts.  See
> my other email on this topic.
>

---

From: "Mohamed Khalil" <[email-masked]>
Date: Tue, 27 Jun 2006 10:07:43 -0500

may be Mobility Access Router (MAR) will make a better name.

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 9:46 AM
To: [email-masked]
Cc: Khalil, Mohamed [RICH2:2S20:EXCH]; Templin, Fred L; Kent Leung
(kleung); Roberts Phil-APR042
Subject: MAG vs AR (Was: [netlmm] NETLMM design team update)

Hi,

--julien

On Tuesday 27 June 2006 16:37, Mohamed Khalil wrote:
> Just out of curiosity, why was it decided to change the term AR -> 
> MAG? I'm having a hard time stomaching "MAG" for some reason; "AR" 
> > 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
> > 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
> > 7) Section 5.11, have implications of data corruption been analysed 
> > in order to warrant a SHOULD for accepting messages with zero UDP 
> > checksum?
>
> Good pt.  We need to clarify if zero UDP checksum should be accepted 
> in the case only if the message is authenticated by other means, thus 
> > 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Jun 2006 08:17:24 -0700

There is a point to be made the "Access Router (AR)" is defined
in RFC3753 in a way that doesn't cover what the design team is
trying to capture, but I still think there must be some better
term than "MAG".

Not sure if the design team is open to entertaining suggestions,
but one possibility would be "Localized Mobility Gateway (LMG)"
to go with "Localized Mobility Anchor (LMA)". I'll sit back now
and wait for the design team's response.

Fred

-----Original Message-----
From: Julien Laganier [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 7:46 AM
To: [email-masked]
Cc: Mohamed Khalil; Templin, Fred L; Kent Leung (kleung); Roberts
Phil-APR042

Hi,

--julien