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

From: [email-masked]
Date: Sat, 15 Sep 2007 02:20:01 -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-05.txt
	Pages           : 60
	Date            : 2007-09-15

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-05.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-05.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-05.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: "John.zhao" <[email-masked]>
Date: Wed, 19 Sep 2007 11:57:14 +0800

Hi,Sri

	Some little comments:
	1)In section 6.13, if the scope of this section is restricted the
detachment detection within network based? Because some network based
approachs is listed here but didn't include any methods indicated by mobile
node. So I just want to make clarify about this.
	2)In section 7.3, the definition of ' Lower Default-Router List
Cache Time-out' seems will adjusted the RFC2461 to support a Netlmm
specified MN . Although we require the MN only should play as a normal IPv6
node. So if this statement is valid, I means that this should be specified
in RFC2461 and related document. When a machine deployed the IPv6 stack, it
didn't sure if the netlmm is used, so why and when it adjust this timeout
value in the mobile node? Maybe I missed some assumption. Something wrong
please indicated.
	3)And also in section 7.3, some context transfer is used to provide
the support for new MAG know about the previous MAG. Here I suggest the
policy store can be use to do this forward. Because the context transfer is
option after all. So we can use the policy store this value and let new MAG
retrieve these information during the same progress when MN enter into its
network. 
	4) Related with above suggestion , the 'link-address option' defined
in section 8.4 can be clarified to a option for use. If the SEND didn't be
used, and a same link-local address is shared between MAG , such as the
original link-local address or the link-local address of LMA etc, then the
link-local address of MN is no need to be known by any new MAGs. Meanwhile
the same link-local address can be transferred optionally via policy store
or by the context transfer way.
	My two cents. Maybe something is missed before by me, so there is
some little suggestion for your reference.

	Best Rgds,
Thanks.
John.zhao

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 18 Sep 2007 21:43:47 -0700

Hi John,

 Inline .. 

> -----Original Message-----
> From: John.zhao [mailto:[email-masked]] 
> Sent: Tuesday, September 18, 2007 8:57 PM
> To: 'Sri Gundavelli'
> Cc: [email-masked]
> Subject: [netlmm] Comments on I-D 
> Action:draft-ietf-netlmm-proxymip6-05.txt
> 
> Hi,Sri
> 
> 	Some little comments:

Its very specific to the access technology. It could be an L2
event or an L3 event. So, its not in scope for this document.
That's intentional.

> value in the mobile node? Maybe I missed some assumption. 

MN section is non-normative. We are not requiring any changes
to the MN stack. The discussion is only for faster handoffs
and general guidance.

> or by the context transfer way.

Ok. All of this can be defined in CT spec. We are not defining any
specific mechanism.

> some little suggestion for your reference.

Ok. Thanks for the review.

---

From: "John.zhao" <[email-masked]>
Date: Wed, 19 Sep 2007 15:14:57 +0800

Hi,Sri

> event or an L3 event. So, its not in scope for this document.
[John.zhao] Agree. But there are still some access related technologies is
listed here for example the ppp and so on. so I think at least we can
specify the MN detachment detection and resource cleanup can be initiated by
MN. Right? We didn't need to specify any detail technology here.
> to the MN stack. The discussion is only for faster handoffs
[John.zhao] The general guidance in RFC2461 is timing out prefixes and
default router. But in this version,it require MN must replace old default
router with the newly learnt default router. And you mean that is for faster
handoff.So, if do you mean that the MN will be care of the faster handoff?
If thus, the lifetime indicate in RA is invalid.
> Ok. All of this can be defined in CT spec. We are not defining any
[John.zhao] It fine define the related work in CT spec. But it seems not
belong to the scope of CT that transfer via policy store. Meanwhile, the
link-local option should be clarify as option,right?

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 19 Sep 2007 10:09:51 -0700

Hi John, 

> Sent: Wednesday, September 19, 2007 12:15 AM
> To: 'Sri Gundavelli'
> Cc: [email-masked]
> Subject: RE: [netlmm] Comments on I-D 

May be I dont follow this. How would the MN's detachment detection will
be triggered by the MN ? Again, MN section is non-normative. We
are not requiring changes to the MN behaviour. The MAG should have
the ability to detect the MN's detachment based on L2/L3 approaches
and outside the scope.

> If thus, the lifetime indicate in RA is invalid.

No. We are not mandating changes to host stack. We are only
suggesting to keep the flush timers values low. These are perfectly
tunable parameters as per 2461. This entire section explains the
PMIP operation as see from the MN perspective. When it sends a RS,
the MAG may send initial RA after completing the signaling. So,
this explains the MN operation in a PMIP6 domain, with out having
any implications on stack changes.

> link-local option should be clarify as option,right?

We already have the messages between LMA and MAG for exchanging this.
Dont see a need to provide multiple solutions for this link-local
address collision.

> > > some little suggestion for your reference.

Thanks
Sri

---

From: "John.zhao" <[email-masked]>
Date: Thu, 20 Sep 2007 11:29:56 +0800

Hi,Sri
	Thanks.See inline.

> > > > 	1)In section 6.13, if the scope of this section is
restricted the detachment detection within network based? Because some
> > > > network based approachs is listed here but didn't include any
methods indicated by mobile node. So I just want to make clarify > > > >
about this.
> > >
> > > Its very specific to the access technology. It could be an L2 event or
an L3 event. So, its not in scope for this document.
> > > That's intentional.
> > >
> > [John.zhao] Agree. But there are still some access related technologies
is listed here for example the ppp and so on. so I think > > at least we can
specify the MN detachment detection and resource cleanup can be initiated by
MN. Right? We didn't need to specify > > any detail technology here.
> 
> May be I dont follow this. How would the MN's detachment detection will be
triggered by the MN ? Again, MN section is non-normative. > We are not
requiring changes to the MN behaviour. The MAG should have the ability to
detect the MN's detachment based on L2/L3 approaches
> and outside the scope. 
[John.zhao] Yes it is true. But the MN initiated termination can provide a
rapid trigger and event to MAG in time. Without the involved of MN, any
others is passive. So I sugget modify the following text :
	'In general, the mobile access gateway can depend on one or more of
the following methods for the detection presence of the mobile node on the
connected link:
   o  Link-layer event specific to the access technology
   o  PPP Session termination event on point-to-point link types
   o  IPv6 Neighbor Unreachability Detection event from IPv6 stack
   o  Notification event from the local mobility anchor
   o  Absence of data traffic from the mobile node on the link for a certain
duration of time'
	
	We can append a sentence as following at the end of the above list:
   o  Notification event from the mobile node
	Here we didn't need to involve any new method, but some existed
method can be utilized,such as DHCP release and so on.
> 
> > > > 	2)In section 7.3, the definition of ' Lower Default-Router
List Cache Time-out' seems will adjusted the RFC2461 to support > > > > a
Netlmm specified MN . Although we require the MN only should play as a
normal IPv6 node. So if this statement is valid, I > > > > means that this
should be specified in RFC2461 and related document. When a machine deployed
the IPv6 stack, it didn't sure > > > > if the netlmm is used, so why and
when it adjust this timeout value in the mobile node? Maybe I missed some
assumption.
> > > > Something wrong please indicated.
> > >
> > > MN section is non-normative. We are not requiring any changes to the
MN stack. The discussion is only for faster handoffs
> > [John.zhao] The general guidance in RFC2461 is timing out prefixes and
default router. But in this version,it require MN must
> > replace old default router with the newly learnt default router. And you
mean that is for faster handoff.So, if do you mean that > > the MN will be
care of the faster handoff? If thus, the lifetime indicate in RA is invalid.
> 
> No. We are not mandating changes to host stack. We are only suggesting to
keep the flush timers values low. These are perfectly
> tunable parameters as per 2461. This entire section explains the PMIP
operation as see from the MN perspective. When it sends a RS,
> the MAG may send initial RA after completing the signaling. So, this
explains the MN operation in a PMIP6 domain, with out having
> any implications on stack changes.
[John.zhao] I see. When I search in RFC2461.The definition of prefix list
and default list as the following:
' Prefix List  - A list of the prefixes that define a set of addresses that
are on-link.  Prefix List entries are created from information received in
Router Advertisements.  Each entry has an associated invalidation timer
value (extracted from the advertisement) used to expire prefixes when they
become invalid.  A special "infinity" timer value specifies that a prefix
remains valid forever, unless a new (finite) value is received in a
subsequent advertisement.
 Default Router List - A list of routers to which packets may be sent.Router
list entries point to entries in the Neighbor Cache; the algorithm for
selecting a default router favors routers known to be reachable over those
whose reachability is suspect.  Each entry also has an associated
invalidation timer value (extracted from Router Advertisements) used to
delete entries that are no longer advertised.'
	Meanwhile there is the following sentences description the
modification of lifetime as the following:
' However, when received information for a specific parameter (e.g., Link
MTU) or option (e.g., Lifetime on a specific Prefix) differs from
information received earlier, and the parameter/option can only have one
value, the most recently-received information is considered authoritative.'
	But this will depend on the receive of a new RA message. That seems
is no relate to what we just said that the ' Lower Default-Router List Cache
Time-out'.
	So I mean that what is the description of tunable?How to tune this
timer? Maybe this is a stupid question. Hope didn't make you trouble.Could
you help me explain that?

> > > > 	3)And also in section 7.3, some context transfer is used to
provide the support for new MAG know about the previous MAG. Here > > > > I
suggest the policy store can be use to do this forward. Because the context
transfer is option after all. So we can use the > > > > policy store this
value and let new MAG retrieve these information during the same progress
when MN enter into its network.
> > > > 	4) Related with above suggestion , the 'link-address option'
defined in section 8.4 can be clarified to a option for use. If > > > > the
SEND didn't be used, and a same link-local address is shared between MAG
,such as the original link-local address or the > > > > link-local address
of LMA etc, then the link-local address of MN is no need to be known by any
new MAGs. Meanwhile
> > > > the same link-local address can be transferred optionally via policy
store or by the context transfer way.
specific mechanism.
> > [John.zhao] It fine define the related work in CT spec. But it seems not
belong to the scope of CT that transfer via policy store.
> > Meanwhile, the link-local option should be clarify as option,right?
> 
> We already have the messages between LMA and MAG for exchanging this. Dont
see a need to provide multiple solutions for this link-local
> address collision.
[John.zhao] If the MAG can use the same link-local address in non-SEND
environment. Why do we need exchange the link-local of MN between LMA and
MAG again? 
	If we can use the same link-local address to be used by difference
MAG faced to a MN, then how we can inform MAGs to know about this link-local
address if without the use of context transfer?
	 
> 
> 
> > > > 	My two cents. Maybe something is missed before by me,so
there is some little suggestion for your reference.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 19 Sep 2007 22:15:38 -0700

John, 

> method can be utilized,such as DHCP release and so on.

If the mobile does a DHCP release, it does not require the MAG
to release the prefix. MAG ensures the mobile node believes its
on its home link, as long as the node is attached to the link.
The MN may have released the DHCP address, but may have chosen
to use an autoconfigured address. So, we cant depend on this
event. I've already listed some possibilities in a generic way
and I think, the above points are sufficient. I cant think of any
other event that a normal 2461 compatible IPv6 host can send and
that the MAG can use for detachment detection. So, I dont see the
point.

> suggesting to

I see your point. I will look into this and will fix the text,
if required.

> environment. Why do we need exchange the link-local of MN 

Ok. If the MAG's are configured with the same link-local address,
its not required to send the address to the LMA. Its optional.

> address if without the use of context transfer?

All the MAG's are provisioned with that address.

---

From: "John.zhao" <[email-masked]>
Date: Thu, 20 Sep 2007 14:23:58 +0800

Hi,Sri
> 发件人: Sri Gundavelli [mailto:[email-masked]]
> John,
> > > > 1) About the resource cleanup problem .
[John.zhao] Exactly, we can't depend on this event if a MS use an
autoconfigured address. That is the current situation. But if we need is the
first problem If thus, then we can design some patch for this problem
Otherwise, it can't be use even we have some new method. So I only suggest
we can open this door at here for the consideration in the future. After all
, that is useful for network resource cleanup. And I won't involve the
discussion of new method. The requirement is enough. How do you think?
> > List Cache Time-out'  ......
> 
[John.zhao] OK.
> > > > provide the support for new MAG know about the previous MAG.
> > > > defined in section 8.4 can be clarified to a option for use.
> 
[John.zhao] OK.I'm fine.
> All the MAG's are provisioned with that address.
[John.zhao] OK.I'm fine. So that maybe need to be reported by the original
MAG to policy store during the initial network entry progress.
> > there is some little suggestion for your reference.
		Best Rgds,
Thanks,
John.zhao

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 19 Sep 2007 23:53:27 -0700

Hi John, 

> discussion of new method. The requirement is enough. How do you think?

No. It may be extended in the future, currently there is no such event. I
dont
think, its that simple to rely on such event. The host may die and the stack
may not even generatet that event. Also, I dont think we need to open doors
in this draft to allow some future work. Having that text does not mean any
thing to the future work. If the use case is valid, you can justify it any
day. 
The draft may generally point to some very obvious approaches, such as CT,
..etc that are out of scope for this document, but when such support is
there
in a given system architecture, Ex: R4 interface, it may be worth pointing
it
out, but its not for enabling some future work. 

In this case, we dont even know a solution that works and so we dont need to
refer to that approach. But, I agree with you, such an event will be very
useful,
if that exists. Thanks for reviewing the draft. I will look into your other
comments.

Regards
Sri