Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt

From: [email-masked]
Date: Thu, 06 Sep 2007 02:20:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.

	Title           : Proxy Mobile IPv6
	Author(s)       : S. Gundavelli, et al.
	Filename        : draft-ietf-netlmm-proxymip6-03.txt
	Pages           : 55
	Date            : 2007-09-06

This specification describes a network-based mobility management
protocol.  It is called Proxy Mobile IPv6 and is based on Mobile IPv6
[RFC-3775].  This protocol enables mobility support to a host without
requiring its participation in any mobility related signaling.  The
design principle in the case of network-based mobility management
protocol relies on the network being in control of the mobility
management.  The mobility entities in the network are responsible for
tracking the movements of the host and initiating the required
mobility signaling on its behalf.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-03.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-netlmm-proxymip6-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-netlmm-proxymip6-03.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 5 Sep 2007 23:34:04 -0700

This is the latest version of the PMIP6 draft. Please
review and let us know any comments you have. Any nits,
technical issues, editorial ..please let us know and
we will fix them right away.

We want to go last call, asap. Please review and comment.

Regards
Sri

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, September 05, 2007 11:20 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt 
> 
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
>

---

From: "Shyam H" <[email-masked]>
Date: Fri, 7 Sep 2007 16:21:20 -0700

Dear Sri

Thank you for updating the Proxy-MIP6 draft. We reviewed and discussed
the draft in detail and these are our comments.

First, the draft is written nicely, organized very well; enjoyed
reading it; we thank the authors for the good work.

We did not like the timestamp format change; it was not needed, we
have to make changes to our code.; but fine.

In MAG signaling, you should add the RS and RA flow related points;
You should add a small section  with couple of lines on what the MAG
does when RA arrives; this is missing; it is there in the seq diagram.

Lot of new error checking rules; but good; very detailed

You should specify when the HA should consider the timestamp from MAG
as as outof sync. Suggest some time window  like 1 second; define a
protocol variable. Or, make NTP use a must. Not an issue for us; we
have RO.

On PBU and PBA retransmissions or timeouts, please say it is as per
rfc3775; or define new protocol constants

PBA cannot have the type-II routing header, can it ? there is no home
address ; you should mention this; to avoid interop problems.

Hope this review helps. Thank you again for completing this document; good job.

- Shyam

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 9 Sep 2007 20:12:48 -0700

Hi Shyam,

Please see inline ...

> From: Shyam H [mailto:[email-masked]] 
> Sent: Friday, September 07, 2007 4:21 PM
> To: [email-masked]
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-03.txt
> 
> Dear Sri
> 
> 

Ok.

> protocol variable. Or, make NTP use a must. Not an issue for us; we

Ok.

> rfc3775; or define new protocol constants

This is a good point. I've worked on the text for this and other
points you raised, you will see it in the next rev.

> address ; you should mention this; to avoid interop problems.

Format of the PBA is given. Its not there in it. But, if it needs to
be explicitly mentioned, will do that.

> Hope this review helps. Thank you again for completing this 

Thanks for the comments.

Sri

> > > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Sep 2007 14:26:38 +0300

What's the significance of MN-Identifier as carried in PBU?

Is it for the sake of identifying the MN during dynamic HNP assignment
in-band with PMIP?

If so, given that the HNP may also be assigned during network access
authentication (out-of band with PMIP, as commonly done in integrated
bootstrapping scenarios), we shall not mandate that the MN-identifier
identifies the real MN.

Another way of using of MN-identifier is to identify the "proxy MN" (MAG)
with RFC 4285. 

Alper

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 10 Sep 2007 07:36:07 -0700

Hi Alper,

There were some comments on this from Jari. See the section
on "Acquiring the MN identifier" (Sec 6.6).

The MN-Identifier may not be the real identifier of the MN.
But, the LMA and MAG must be able to identify a MN using
this identifier and exchange it in the signaling messages.

Also, but, it is not the identifier of the MAG. We are
creating a BCE state and that is for a MN. The identifier
of the MAG is used for authenticating and authorizing purposes.
And this identifier changes at each handoff and so what is
stored in the BCE is the MN identifier.

Sri

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 4:27 AM
> To: [email-masked]
> Subject: [netlmm] Significance of MN-Identifier
>

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 10 Sep 2007 22:35:48 +0300

Hi Sri,

> this identifier and exchange it in the signaling messages.

Why do they have to identify the MN? This is what I'm trying to understand.
What exactly do they achieve with the identity of the MN, when the signaling
is between the MAG and LMA and the state info they are dealing with is a
binding between a CoA and a HNP.

> stored in the BCE is the MN identifier.

BCE shall have a CoA and a HNP. Again I'm trying to understand why the BCE
shall have the MN identifier.

Alper

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 10 Sep 2007 12:45:40 -0700 (PDT)

Alper,

> shall have the MN identifier.

At handoff, nMAG may not know the HNP of the mobile node. How does it
communicate with the LMA about the MN, if MN-Id is not used ? That's
is essential, its required in BCE and also in signaling messages.

Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 11 Sep 2007 11:45:46 +0300

Sri,

So it is just for HNP assignment as I was saying:

>>> Is it for the sake of identifying the MN during dynamic HNP 
>>> assignment in-band with PMIP?

HNP can be assigned during network access authentication. I can't imagine
when this is not possible or desirable. 

That's why mandating presence of MN-id that identifies the MN is not
necessary, imo.

If people can show a reason why we must also support HNP assignment in-band
with PMIP, we can say:

	When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that
carries 	the MN-id MUST be included in the PBU. 

Alper

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 11 Sep 2007 14:01:25 -0400

Alper,

I don't know what the issue is for MN-ID in the PMIP6 signaling
messages. Could you explain why we are having this debate?

MN-ID is the unique identifier to identify the session state in the LMA.
There are several good reasons to mandate the presence of MN-ID in the
PBU/PBA. For example, it helps to identify the session state in the LMA
for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a
MIP6 HA. Note that during IKEv2 exchange for MIP6, the IDi field (that
carries the same MN-ID) in the IKE packets help identify the ongoing
(PMIP6) session related to the MN. 

Hope this helps.

-Kuntal

> Sent: Tuesday, September 11, 2007 3:46 AM
> To: 'Sri Gundavelli'
> Cc: [email-masked]
> Subject: RE: [netlmm] Significance of MN-Identifier
> 
> Sri,
> 
> If people can show a reason why we must also support HNP assignment
in-
> band