Subject: RE: [netlmm] NETLMM design team update

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 27 Jun 2006 08:49:09 -0700

Hi Mohamed and Fred.  I'm sure you guys are not the only ones "curious"
about the MAG term. :)

We wanted to have a name for the functional NetLMM entity.  An Access
Router can have multiple functions such as RADIUS client, DHCP relay
agent, Foreign Agent, etc.  So MAG function would be one of the AR's
capability to provide NetLMM support.

A brief background on how the term was derived.  This was suggested in
the DT.

	Maybe for AR, Mobility Access Gateway = MAG? 

	Steals from the Packet Data Gateway = PDG term, as this entity's
function is to provide 	"mobility" for "accessing" the network,
funneling multiple MNs like a "gateway".

Kent 

> -----Original Message-----
> From: Mohamed Khalil [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 7:37 AM
> To: Templin, Fred L; Kent Leung (kleung); Roberts 
> Phil-APR042; [email-masked]
> Subject: RE: [netlmm] NETLMM design team update
> 
> 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.
> 
> 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
> [email-masked]
> 
> -----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.
>  
> 
> > -----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
> 

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 27 Jun 2006 09:42:11 -0700

I think it make some amount of sense to use a different name for the 
functional entity associated with NETLMM.

Suppose that the NETLMM functionality, instead of being located at a router, 
were in a wireless LAN switch. WLAN switches today provide IP mobility 
management using tunneling, independent of the last hop router, in a 
proprietary way. It's possible that, going forward, they may instead include 
NETLMM so that IP mobility is standarized.

That said, I kind of like Fred's suggestion of "Localized Mobility Gateway", 
since it co-ordinates with "Localized Mobility Anchor".

            jak

----- Original Message ----- 
From: "Kent Leung (kleung)" <[email-masked]>
To: "Mohamed Khalil" <[email-masked]>; "Templin, Fred L" 
<[email-masked]>; "Roberts Phil-APR042" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 27, 2006 8:49 AM
Subject: RE: [netlmm] NETLMM design team update

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 27 Jun 2006 22:16:25 +0200

Hi,

> since it co-ordinates with "Localized Mobility Anchor".

As long as we use a term which is more NetLMM specific than the generic 'AR',
I'm fine with LMG, MAG or whatever.

I plan to add this issue and the others that have been raised to the issue
tracker as soon as I can find time, and also start to add the resolutions
to an intermediary version of the draft as soon clear resolutions are
available.

Regards,

	Henrik

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 27 Jun 2006 13:29:26 -0700

Thanks Henrik,

I'm open to other suggestions, but I think my uneasiness with
"MAG" lies in the fact that at least in U.S. English it is a
slang/shortened form of "MAGnum" and often used in somewhat
seedy contexts, e.g., "a hot-rod car with MAG wheels", "a
357 MAG handgun", "a MAGnum bottle of wine", etc.

Fred

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 1:16 PM
To: James Kempf
Cc: Kent Leung (kleung); Mohamed Khalil; Templin, Fred L; Roberts
Phil-APR042; [email-masked]
Subject: Re: [netlmm] NETLMM design team update

Hi,

> since it co-ordinates with "Localized Mobility Anchor".

As long as we use a term which is more NetLMM specific than the generic
'AR',
I'm fine with LMG, MAG or whatever.

I plan to add this issue and the others that have been raised to the
issue
tracker as soon as I can find time, and also start to add the
resolutions
to an intermediary version of the draft as soon clear resolutions are
available.

Regards,

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 27 Jun 2006 23:00:40 +0200

Hi Fred,

> 357 MAG handgun", "a MAGnum bottle of wine", etc.

Sure.  If MAG bothers people, something else is fine, I think.

(Apart from that, I always thought MAG wheels were wheels with
 MAGnesium alloy spokes ,, :-} )

Best,

	Henrik

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 27 Jun 2006 20:19:46 -0700 (PDT)

Hi Fred,
  I think I was the first to raise this issue.
However, I'll let you enjoy it.

Regards,

--behcet

----- Original Message ----
From: "Templin, Fred L" <[email-masked]>
To: Henrik Levkowetz <[email-masked]>; James Kempf <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, June 27, 2006 3:29:26 PM
Subject: RE: [netlmm] NETLMM design team update

Thanks Henrik,

Fred

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Tuesday, June 27, 2006 1:16 PM
To: James Kempf
Cc: Kent Leung (kleung); Mohamed Khalil; Templin, Fred L; Roberts

Hi,

Regards,

    Henrik