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

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 01:25:17 -0700

I've updated the PMIP6 document based on the review comments
I've received recently. I really want to speed up the LC process
and so I've updated the document. I do not plan to spin any more
versions before LC is initiated and complete. Any comments I
missed or I may receive as part of the LC will be addressed only
in the final version.

This update is based on the discussions threads with JinHyeock,
Julien, Alex, Pete, Kilian and many others ...

Thanks
Sri

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 1:20 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-06.txt 
> 
> 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-06.txt
> 	Pages           : 62
> 	Date            : 2007-09-24
> 
> 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 a 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-06.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-06.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-06.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: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Sep 2007 13:42:28 +0200

Sri Gundavelli wrote:
> 
> I've updated the PMIP6 document based on the review comments I've 
> received recently. I really want to speed up the LC process and so 
> I've updated the document. I do not plan to spin any more versions 
> before LC is initiated and complete. Any comments I missed or I may 
> receive as part of the LC will be addressed only in the final 
> version.
> 

Thanks for the update, I've checked it fits my understanding of
timestamp-vs-seqno.

I don't know when you spin more versions, but here are more comments.

> 6.11.  Supporting DHCPv6 based Address Configuration on the Access
> Link
> 
> This non-normative section explains how Stateful Address 
> Configuration using DHCPv6 can be enabled on the access link attached
>  to a mobile access gateway and how a mobile node attached to that 
> link can obtain an address from its home network prefix using DHCPv6.

Basically I agree that the DHCP behaviour described in this section is
non-normative (==informative?).  Would it be better placed as an Appendix?

> If the received Router Advertisement has the Managed Address 
> Configuration flag set, the mobile node, as it would normally do, 
> will send a DHCPv6 Request [RFC-3315].

I think it will first send a Solicit, to discover DHCP Server's address. 
  'Request' would come after the 'Advertise' the Server sends.

Moreover, if/when we're to discuss DHCP behaviour we risk important 
disagreements on how it should work.  (1) how prefix delegation is 
integrated, (2) how PMIP6 handover influences DHCP exchanges, (3) how 
and what the MAG DHCP Relay inserts in the client messages, (4) how the 
server identifies the client.

I have some doubts about MAG DHCP Relay inserting the HNP into the 
link-address field of RELAY-FORW.  I don't think that field was designed 
with ephemeral ptp interfaces in mind, but with fixed shared non-dynamic 
interfaces in mind.  And I don't think the HNP is the right identifier 
for that ephemeral link.

I think a better tool for this need could be to insert the Subscriber-ID 
option (rfc4580) by the MAG DHCP Relay in the RELAY-FORW message, to 
contain the MAC address of the mobile; or the Remote-ID (rfc4649).  I 
think at least these two are better adapted for ephemeral ptp links, 
better than the link-address field.  Or a variant thereof.

Nits:
> In this format, the integer number of seconds is contained in the 
> first 48 bits of the field, and the remaining 16 bits indicate the 
> number of 1/64K fractions of a second.

1/64000 fractions of a second?  Or 1/65536 fractions of a second.  I
propose to specifically say 1/65536 fractions because 64k means 65536
only if we talk bits (not seconds), in my understanding.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 20:50:18 -0700

Hi Alex,

> non-normative (==informative?).  Would it be better placed as 

This text provides the basic guidance on how to enable DHCP based 
addressing. This guidance is important for deployments. I should
rephrase this slightly to explicitly state the spec does not mandate
on having DHCP relay on the MAG. Its an optional configuration. That
was the intent, I should remove this line on non-normative part.

> server identifies the client.

Prefix assignment is done by the LMA and it can use DHCP PD for
that. The draft does not cover the details on how the LMA does
the prefix allocation. 

> only if we talk bits (not seconds), in my understanding.

Ok. Will fix it.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 24 Sep 2007 20:50:18 -0700

Hi Alex,

Ok. Will fix it.

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Sep 2007 14:34:15 +0200

Hi Sri,

Sri Gundavelli wrote:
>>> 6.11.  Supporting DHCPv6 based Address Configuration on the 
>>> Access Link
>>> 
>>> Configuration using DHCPv6 can be enabled on the access link 
>>> attached to a mobile access gateway and how a mobile node 
>>> attached to that link can obtain an address from its home network
>>>  prefix using DHCPv6.
>> 
>> Basically I agree that the DHCP behaviour described in this section
>>  is non-normative (==informative?).  Would it be better placed as 
>> an Appendix?
>> 
> 
> addressing. This guidance is important for deployments.

Sri, I'm sorry to say so and please don't take it personal, as usual.

This guidance is simply wrong.  It wrongly interprets rfc 3315 which is
itself not according to implementations, in this respect.

> I should rephrase this slightly to explicitly state the spec does not
>  mandate on having DHCP relay on the MAG. Its an optional 
> configuration. That was the intent, I should remove this line on 
> non-normative part.

I think this is another matter.  If you want to make it a normative
suggestion and keep it in the main body of the spec I think you should
remove the use of link address for a prefix and use something else.  I
could suggest something to use, but I feel like you have overlooked my
previous suggestions, I'll wait when we can discuss this openly. (maybe 
I"m writing too many messages too, sorry about that).

>>  integrated, (2) how PMIP6 handover influences DHCP exchanges, (3)
>>  how and what the MAG DHCP Relay inserts in the client messages,
>> (4) how the server identifies the client.
> 
> 
> Prefix assignment is done by the LMA and it can use DHCP PD for that.
>  The draft does not cover the details on how the LMA does the prefix
>  allocation.

It doesn't even say that the LMA could use DHCP PD for that.

>>  propose to specifically say 1/65536 fractions because 64k means 
>> 65536 only if we talk bits (not seconds), in my understanding.
>> 
> 
> Ok. Will fix it.

Thank you.

Alex