Subject: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

From: [email-masked]
Date: Thu, 12 Apr 2007 18:50: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-00.txt
	Pages		: 46
	Date		: 2007-4-12
	
   Host based IPv6 mobility is specified in Mobile IPv6 base
   specification [RFC3775].  In that model, the mobile node is
   responsible for doing the signaling to its home agent to enable
   session continuity as it moves between subnets.  The design principle
   in the case of host-based mobility relies on the mobile node being in
   control of the mobility management.  Network based mobility allows IP
   session continuity for a mobile node without its involvement in
   mobility management.  This specification describes a protocol
   solution for network based mobility management that relies on Mobile
   IPv6 signaling and reuse of home agent functionality.  A proxy
   mobility agent in the network which manages the mobility for a mobile
   node is the reason for referring to this protocol as Proxy Mobile
   IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-00.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-00.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-00.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: qinxia <[email-masked]>
Date: Mon, 16 Apr 2007 16:00:30 +0800

Hello Sri,

                  Good job!  Here are only some editorial comments:

Section 5.1.  Extensions to Binding Cache Conceptual Data Structure
......
o  A flag indicating if IPv6 HoA mobility is accepted.  If this flag
      is set, the relevant IPv6 HoA fields in this data structure have
      to be set to the configured values.  If this flag.

[comment] this sentence is not finished yet.
..........

Page 5 
   Mobile Node (MN)

      Through out this document, the term mobile node is used to refer
      to an IP node whose mobility is provided by the network.  The
      mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/
      IPv6 dual mode. ...........

Shall we define PMIPv4 protocol to present the operation in IPv4 mode which is
independent to PMIPv6? since a few of protocol decription in PMIP6 does not adapt to
ipv4 scenario , such as router advertisement is not exist at all in IPv4.
Besides PMIPv4, of course we may define extension to PMIP6 to support dural stack
mode.

If there is already a conclusion on this question, please skip over this comment.

Section 5.4
............
As a mobile moves from one
   mobile access gateway to the another, the serving mobile access
   gateway will not predictably be able to locate the serving local
   mobility anchor for that mobile that has its binding cache entry for
   the mobile node.  However, if there is only one local mobility anchor
   configured to serve a mobile node, the mobile access gateway can use
   Dynamic Home Agent Address Discovery scheme for discovering the
   address of the local mobility anchor.
..........
As LMA is a HA for a mobile node, So could you clarify the scenario where there are
several  LMAs for the distinct mobile node? Does that mean we need to support one
more active LMAs which assign same home prefix at same time. 

One more comment,  What is a PMIP domain? Often, we say in a PMIP domain, however, no
definetion is presented.
In Wimax, HA could act as a LMA in a CSN which has agreements with one more ASNs.
One network which is shaped into CSN and its pertinet ASNs could be called as local
mobility mangement domain. In this case, ASN may be far away from CSN. 

Best Wishes

Alice 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 6:50 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.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.
> 
> 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. 
> 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 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 16 Apr 2007 18:48:45 +0900

Dear Sri & all

glad to see PMIPv6 I-D's becoming a WG item. Thanks for your trouble.
I reviewed the draft and here are some comments.

1. Shared link support
I understand that PMIPv6 assumes only 'point-to-point link' and won't
take 'shared link' into consideration. However, in several places, the
draft mentions shared link support.

We'd better make it clear whether PMIPv6 supports shared link or not.
If PMIPv6 is applicable only to point-to-point link, shared link
related parts such as below need to be removed.

   This Proxy Mobile IPv6 scheme is independent of the underlying access
   technology or the link model.  The interface between the mobile node
   and the mobile access gateway can be either:

   o  Point-to-Point Link
   o  Shared Link

2. Initial attachment & Inter PMIPv6-domain handoff
I think Sec 3, Proxy Mobile IPv6 Protocol Overview
would better present the procedures in two separate steps
1) initial attachment &
2) Inter PMIPv6-domain handoff
just as described in
'Sec 7.1 Booting up in a Proxy Mobile IPv6 Domain' & '
'Sec 7.2. Roaming in Proxy Mobile IPv6 Network'.

For example, from Sec 3, I got the impression that an MN configures a
new address upon receiving an RA after network attachment. However,
for roaming case, the MN would just keep using the existing address.

3. Prefix based binding
I understand that Proxy BU binds prefix, not address. I'd like it to
be stated more explicitly.

4. MN profile
In Sec 6.11. it's written that MN's home network prefix is an optional
feature in MN's profile as below.

                                   The mobile node's profile at the
      minimum MUST have the mobile node's local mobility anchor address
      and the MN-Identity.  Optionally, it may have the mobile node's
      home network prefix and other configuration parameters.

If so, MAG may not get MN's home prefix from policy store. Without
home network prefix, how can the MAG emulate MN's home network or send
PBU? I guess either
1) MN's home prefix would be mandatory for MN's profile or
2) the draft should specify what would MAG do in case it can't get
MN's home prefix from policy store.

5. RA after PBU or PBU after RA
When an MN makes a new attachment, does MAG send an RA after Proxy
binding is established or before that? I'd like the draft make it
clear which is the case.

Also in case of the latter, the draft needs to explicitly specify what
would do if PBU is rejected (such as sending advertised prefix with
lifetime=0).

6. PMA role
It's not clear why a term 'PMA' is introduced again. Throughout the
draft, a term 'MAG' is used (in PMA's place) and 'PMA' is mentioned
just once.

7. MAG location
Does the following paragraph mean MAG is located in an access link,
i.e. the link where MNs attach themselves?

   The Proxy Mobile IPv6 scheme introduces a new function, the mobile
   access gateway.  It is a function that is on the access link where
   the mobile is anchored and does the mobility related signaling on
   behalf of the mobile node.

Thanks for your kind consideration.

Best Regards

JinHyeock

p.s.
A minor comment. For me, abbreviation is more readable. It's easier to
read 'MAG' than 'mobile access gateway'.

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 16 Apr 2007 18:57:26 +0900

Dear all,

> 4. MN profile
> In Sec 6.11. it's written that MN's home network prefix is an 
> optional feature in MN's profile as below.
> 
> If so, MAG may not get MN's home prefix from policy store. 
> Without home network prefix, how can the MAG emulate MN's 
> home network or send PBU? I guess either
> 2) the draft should specify what would MAG do in case it 
> can't get MN's home prefix from policy store.

Agreed. I'd like to clearly see the followings in the draft. 

- Mandatory informain in policy store.
- Optional information in policy store.

Best Regards,

Youn-Hee Han

---

From: qinxia <[email-masked]>
Date: Mon, 16 Apr 2007 20:28:07 +0800

Hello all,
        my two cents, please see inline.

Best wishes
Alice 

> From: JinHyeock Choi [mailto:[email-masked]] 
> Sent: Monday, April 16, 2007 5:49 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt
> 
> Dear Sri & all
> 
> I understand that PMIPv6 assumes only 'point-to-point link' 
> and won't take 'shared link' into consideration. However, in 
> several places, the draft mentions shared link support.
> 
> If PMIPv6 is applicable only to point-to-point link, shared 
> link related parts such as below need to be removed.
> 
> 2. Initial attachment & Inter PMIPv6-domain handoff I think 
> Sec 3, Proxy Mobile IPv6 Protocol Overview would better 
> present the procedures in two separate steps
> 1) initial attachment &
> For example, from Sec 3, I got the impression that an MN 
> configures a new address upon receiving an RA after network 
> attachment. However, for roaming case, the MN would just keep 
> using the existing address.
> 
=> IMHO, need to clarify the defination of 'Proxy Mobile IPv6 Domain'.

> 3. Prefix based binding
> I understand that Proxy BU binds prefix, not address. I'd 
> like it to be stated more explicitly.
> 
> 4. MN profile
=> static configuration is not better than policy store in AAA.
> When an MN makes a new attachment, does MAG send an RA after 
> Proxy binding is established or before that? I'd like the 
> draft make it clear which is the case.
> 
> Also in case of the latter, the draft needs to explicitly 
> specify what would do if PBU is rejected (such as sending 
> advertised prefix with lifetime=0).
=>why do you care for the scheduling of them? RA is sent to MN, PBU is sent to LMA by
MAG, the two actions are in different directions, and they are independent with each
other. Sure we may have a choice whether RA or PBU go first, however it is not
critical.

> 
> 6. PMA role
> It's not clear why a term 'PMA' is introduced again. 
> Throughout the draft, a term 'MAG' is used (in PMA's place) 
> and 'PMA' is mentioned just once.
> 

=>PMA is a function, MAG is an entity. 
To Sri, here, maybe, some explanation could be inserted to describe the relocation
between PMA and MAG.

> 7. MAG location
> Does the following paragraph mean MAG is located in an access 
> link, i.e. the link where MNs attach themselves?
> 

=> IMO, MAG is in Access network, relatively, LMA is in core service network. in
wimax, MAG is provided by ASP, LMA is provided by NSP.

> A minor comment. For me, abbreviation is more readable. It's 
> easier to read 'MAG' than 'mobile access gateway'.
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:35:43 -0700

Hi JinHyeock,

Thanks for the comments. Please see inline.

Sri

-----Original Message-----
From: JinHyeock Choi [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 2:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Dear Sri & all

1. Shared link support

   o  Point-to-Point Link
   o  Shared Link

[Sri] From Jari's and chair's input, if there are any issues with shared
links, just take it out. So, mostly will review this one more time and
take the appropriate action of taking out or clarifying it. We will
take care of this in the next rev.

[Sri] Good point. Will do that.

[Sri] Ok. Will go over the text to make sure, there is no ambiguity.

3. Prefix based binding

[Sri] The routing section and in many places, its stated that the
route is for the whole prefix. Will make it more explicit, anyways.

4. MN profile

[Sri] 
We wanted to provide the room for dynamic home network prefix
allocation by the local mobility anchor. If the home network prefix
is not statically configured, the local mobility anchor may do the
allocation. It can depend on DHCP PD [RFC-3633] for leazing the prefix,
local store or using other backend mechanisms, it can allocate the
prefix and can return the same in the Proxy Binding Ack. The mobile
access gateway can emulate the home link by sending the RA with 
the mobile node's home network prefix, after receiving the proxy
binding acknowledgement. So, supporting more than one way of 
prefix allocation/configuration is for deployment flexibility. Any
case, we will properly clarify this.

[Sri] Good point. Will clarify this more clearly for all cases.

[Sri] Its specified in general terms, see below. But, will add the
specific PBU rejection case. 

"If the network determines that the mobile node will not be offered
the network-based mobility service, the mobile access gateway MUST
ensure that the Router Advertisements it sends will not contain
the mobile node's home prefix, but will be the hosted on-link
prefix.  Also, if the mobile node attempts to obtain an IPv6
address, the mobile access gateway or the DHCP relay agent on the
link MUST ensure that the prefix hint that gets added to the DHCP
message will be of the local hosted prefix."

6. PMA role

[Sri] PMA is the proxy mobility function. MAG is entity hosting the
PMA function. MAG is the adopted term and that's what we use. 
Will clarify it.

7. MAG location

[Sri] Yes. The MAG and the mobile are attached to a link. 

Best Regards

JinHyeock

p.s.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:35:43 -0700

Hi JinHyeock,

Sri

-----Original Message-----
From: JinHyeock Choi [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 2:49 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Dear Sri & all

1. Shared link support

   o  Point-to-Point Link
   o  Shared Link

3. Prefix based binding

4. MN profile

[Sri] 

6. PMA role

7. MAG location

Best Regards

JinHyeock

p.s.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:37:09 -0700

Hi Alice,

Please see inline.

-----Original Message-----
From: qinxia [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 1:01 AM
To: 'Sri Gundavelli'
Cc: [email-masked]
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

 Hello Sri,

Page 5 
   Mobile Node (MN)

Shall we define PMIPv4 protocol to present the operation in IPv4 mode which
is
independent to PMIPv6? since a few of protocol decription in PMIP6 does not
adapt to
ipv4 scenario , such as router advertisement is not exist at all in IPv4.
Besides PMIPv4, of course we may define extension to PMIP6 to support dural
stack
mode.

[Sri] Its about the mobile node's capability. Any case, lets review both the
docs and see how they are structured. Lets defer these IPv4 related comments
till the next rev of this doc and the -00 version of the IPv4 doc is
published.
The split was done very quickly and we did realize that there will be work
to
properly fix it. 

If there is already a conclusion on this question, please skip over this
comment.

Section 5.4
............
As LMA is a HA for a mobile node, So could you clarify the scenario where
there are
several  LMAs for the distinct mobile node? Does that mean we need to
support one

[Sri] The mobile node's home network prefix is not anchored on any physical
link of the local mobility anchor and so unlike in 3775 case, there is only
one local mobility anchor serving the mobile node. 

One more comment,  What is a PMIP domain? Often, we say in a PMIP domain,
however, no
definetion is presented.
In Wimax, HA could act as a LMA in a CSN which has agreements with one more
ASNs.
One network which is shaped into CSN and its pertinet ASNs could be called
as local
mobility mangement domain. In this case, ASN may be far away from CSN. 

[Sri] PMIP domain is a local mobility management domain.

Best Wishes

Alice

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 16 Apr 2007 10:38:54 -0700

Hi Youn-Hee,

-----Original Message-----
From: Youn-Hee Han [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 2:57 AM
To: 'JinHyeock Choi'; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Dear all,

[Sri] Sure. That might be a better way. This is in the scope of
the other comments received, on the MAG's operational logic when
the MN-HNP is present in the profile and when it is not present
..etc. We will take care of this.

Thanks
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Apr 2007 11:19:06 -0700

> case, we will properly clarify this.

The default would be to *not* store the MN's home prefix
in any "policy store". The default would be for the LMA
to assign this prefix when it receives a proxy BU from a
MAG for the first time for a particular mobile node.

Once the MAG obtains the prefix, it will start emulating
the MN's home network. This also means the router advert
is sent after receiving the proxy Binding Ack.

Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 17 Apr 2007 09:43:52 +0900

Dear Sri

Thanks for kind and prompt reply. Kindly see in-line comments.

> take care of this in the next rev.

I see. IMO, it's better to limit PMIPv6 applicability to p2p link
rather than adapt it to shared link.

> case, we will properly clarify this.

We'd better deal this in two cases 1) initial attachment and 2)
roaming inside PMIPv6 domain. I'm mostly concerned about the case 2).

For the case 1) initial attachment, MAG itself can allocate the home
network prefix and use the prefix to emulate home network & send PBU
as written above.

However, for the case 2) roaming inside PMIPv6 domain, MAG needs to
get MN's CURRENT home network prefix for home emulation & PBU.

Let me clarify this with an example.

Assume an MN moves into a PMIPv6 domain for the first time and
attaches itself to MAG 1. The MN is allocated Prefix 1 as its home
network prefix and configures an address with Prefix 1.

Now assume the MN roams inside the same PMIPv6 domain and attaches
itself to an another MAG, MAG 2. MAG 2 should know the MN's existing
home network prefix 'Prefix 1' for home emulation & PBU. Unless MAG2
can retrieve Prefix 1 from policy store, it is in trouble.

> message will be of the local hosted prefix."

ok. I am concerned about the following case.

First, MAG advertises prefix 1 & MN configures an address with Prefix 1.
Then, MAG sends a PBU with prefix 1 but LMA rejects the PBU.

In that case MAG needs
not only passively NOT-advertising MN's home prefix
but also actively invalidate MN's home prefix by advertising the
prefix with its lifetime=0.

> [Sri] Yes. The MAG and the mobile are attached to a link.

ok. Because MAG is entity hosting the PMA function, the above implies
that PMA resides in access link too.

Best Regards.

JinHyeock

---

From: "JinHyeock Choi" <[email-masked]>
Date: Tue, 17 Apr 2007 09:44:42 +0900

Dear Vijay

Thanks for your clarification. kindly see in-line comments.

> is sent after receiving the proxy Binding Ack.

As I wrote to Sri, we'd better deal with this in two separate cases 1)
initial attachment & 2) roaming inside PMIPv6 domain.

I can see how your description will work for the initial attachment
case but can't be sure of the roaming case.

Assume an MN is allocated prefix 1 as its home network prefix. When it
moves to a new MAG inside the same PMIPv6 domain, how can the new MAG
know the MN's current home network prefix, prefix 1?

Or, if the MAG doesn't know the MN's current home network prefix, how
can it emulate its home network and send PBU?

I think that we'd better clarify
1) how to assign a home network prefix to an MN when it attaches to
PMIPv6 domain for the first time &
2) how can a new MAG acquire an MN's existing home network prefix when
the MN roams inside PMIv6 domain.

Best Regards

JinHyeock

---

From: qinxia <[email-masked]>
Date: Tue, 17 Apr 2007 10:37:17 +0800

Hello Sri,
                     Thanks for your reply. Please see inlines.
Best wishes
Alice 

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, April 17, 2007 1:37 AM
> To: 'qinxia'
> Cc: [email-masked]
> Section 5.1.  Extensions to Binding Cache Conceptual Data 
> Structure ......
> Shall we define PMIPv4 protocol to present the operation in 
> IPv4 mode which is independent to PMIPv6? since a few of 
> protocol decription in PMIP6 does not adapt to
> Besides PMIPv4, of course we may define extension to PMIP6 to 
> support dural stack mode.
> 
> 
> [Sri] Its about the mobile node's capability. Any case, lets 
> review both the docs and see how they are structured. Lets 
> defer these IPv4 related comments till the next rev of this 
> doc and the -00 version of the IPv4 doc is published.
> The split was done very quickly and we did realize that there 
> will be work to properly fix it. 
> 
> 
> As LMA is a HA for a mobile node, So could you clarify the 
> scenario where there are several  LMAs for the distinct 
> mobile node? Does that mean we need to support one more 
> active LMAs which assign same home prefix at same time. 
> 
> 
> [Sri] The mobile node's home network prefix is not anchored 
> on any physical link of the local mobility anchor and so 
> unlike in 3775 case, there is only one local mobility anchor 
> serving the mobile node. 
> 
[qx] if only one single LMA could serve mobile node, IMHO, there is a single-point
failure problem. If this unique LMA goes kaput, how could we deal with these tunnels?

> 
> One more comment,  What is a PMIP domain? Often, we say in a 
> PMIP domain, however, no definetion is presented.
> One network which is shaped into CSN and its pertinet ASNs 
> could be called as local mobility mangement domain. In this 
> case, ASN may be far away from CSN. 
>  
> 

[qx]: I still think this description is simple and obscure. Maybe one or two scenario
in wimax or other radio network will do some help.

> >    in the case of host-based mobility relies on the mobile 
> node being 
> > in
> >    control of the mobility management.  Network based 
> mobility allows 
> > IP
> message to 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-ietf-netlmm-proxymip6-00.txt".
> >

---

From: qinxia <[email-masked]>
Date: Tue, 17 Apr 2007 10:45:40 +0800

Hello folks,
Please see inlines.

Regards
Alice  

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, April 17, 2007 2:19 AM
> To: Sri Gundavelli; 'JinHyeock Choi'
> Cc: [email-masked]
> > allocation by the local mobility anchor. If the home 
> network prefix is 
> > not statically configured, the local mobility anchor may do the 
> > allocation. It can depend on DHCP PD [RFC-3633] for leazing the 
> > prefix, local store or using other backend mechanisms, it 
> can allocate 
> > the prefix and can return the same in the Proxy Binding Ack. The 
> > mobile access gateway can emulate the home link by sending 
> the RA with 
> > binding acknowledgement. So, supporting more than one way of prefix 
> > allocation/configuration is for deployment flexibility. Any 
> case, we 
> The default would be to *not* store the MN's home prefix in 
> any "policy store". The default would be for the LMA to 
> assign this prefix when it receives a proxy BU from a MAG for 
> the first time for a particular mobile node.
> 
[qx] I don't think, we should constrict in this case. The MAG may obtain MN home
prefix from AAA infrastructure, and then advertise RA to mobile nodes, at the same
time, the MAG could register with LMA by sending PBU. Both cases are ok.

> Once the MAG obtains the prefix, it will start emulating the 
> MN's home network. This also means the router advert is sent 
> after receiving the proxy Binding Ack.
> 
> Vijay
>

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 17 Apr 2007 14:59:07 +0900

Dear qinxia and sri,

please see inlines

> time, the MAG could register with LMA by sending PBU. Both 

I agree. Both methods should be allowed to let MN knows the home prefix. 
But, my favorite is to utilize policy store as much as posible and get the 
home prefix from policy store. In this case, as JinHyeock said, we should 
take note the situation that LMA denies the PUB after MAG emulated the 
home network for MN. To solve it, invalidating the home prefix by using 
lifetime=0 seems to be the good way.

Youn-Hee Han

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 17 Apr 2007 15:26:57 +0900

Dear JinHyeock,  

Please see inlines.

> can retrieve Prefix 1 from policy store, it is in trouble.

In this case, IMO, MAG 2 can send PBU with MN-Identifier present 
in the NAI option. The PBU contains the Home Network Prefix Option 
set to value 0. This can enable LMA to extract the right home prefix 
from the binding cache entry for the MN. The prefix can be delivered 
by PBAck to MAG 2. 
 
> specify what

It is good point. IMO, the new version of draft should include it.

Youn-Hee Han

---

From: "Kalin Getov" <[email-masked]>
Date: Tue, 17 Apr 2007 14:10:41 +0200

Hi all,

sorry for jumping into this discussion...but just want to understand this right. Is it possible or allowed that the MN gets its home link emulated from MAG before the PBAck is received? I thought if PMIP is chosen as mobility management protocol the MN won't get RA with the home network prefix (or any other prefix) before the MAG gets the acknowledgment from the LMA. Could you explain please...?Thanks!

Best Regards 

Kalin Getov

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

---

From: Christian Vogt <[email-masked]>
Date: Tue, 17 Apr 2007 15:27:14 +0300

> is sent after receiving the proxy Binding Ack.

Note that the order of RA transmission and the PBU/PBA exchange is
important to consider for two reasons:

(1)  MN access authentication.  If access authentication takes place
based on SEND, the MAG may be required to wait for an authenticated RS
from the MN before it sends the PBU.  Of course, this is just one
example of how access authentication may work, and other means are well
possible.  But since draft-ietf-netlmm-proxymip6 does not specify access
authentication, the protocol should allow a MAG to defer the PBU message
until it has received the MN's RA.

(2)  MN home link prefix discovery.  As was mentioned in conjunction
with JinHyeock's comments on draft-ietf-netlmm-proxymip6, the MAG may
not be able to retrieve a MN's home link prefix from the policy store,
but may discover it instead during the PBU/PBA exchange with the LMA.
The base protocol should also facilitate this order of RA and PBU/PBA.

In the latter case, MN access authentication obviously cannot be
performed based on a SEND-authenticated RA from the MN.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 17 Apr 2007 15:27:33 +0300

Hi Alice, Sri:

>> [Sri] The mobile node's home network prefix is not anchored on any
>> physical link of the local mobility anchor and so unlike in 3775
>> case, there is only one local mobility anchor serving the mobile
>> node.
>> 
> [qx] if only one single LMA could serve mobile node, IMHO, there is a
> single-point failure problem. If this unique LMA goes kaput, how
> could we deal with these tunnels?

LMA fail-over is probably a separate issue and should not be part of the
base protocol specification.  It seems like an issue the WG could
concentrate on /after/ the work on the base protocol is done.

FWIW, the fact that the LMA is not physically tied to a link with the
MN's home link seems to render LMA fail-over easier to realize that it
is, e.g., for standard Mobile IPv6.

>> One more comment,  What is a PMIP domain? Often, we say in a PMIP
>> domain, however, no definetion is presented. In Wimax, HA could act
>> as a LMA in a CSN which has agreements with one more ASNs. One
>> network which is shaped into CSN and its pertinet ASNs could be
>> called as local mobility mangement domain. In this case, ASN may be
>> far away from CSN.
>> 
> [qx]: I still think this description is simple and obscure. Maybe one
> or two scenario in wimax or other radio network will do some help.

The PMIP domain could defined as "the set of administratively contiguous
physical access links on which the mobile node can communicate via an IP
address from its PMIP home link prefix."

Kind regards,
- Christian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 08:10:11 -0700

Hi Kalin,

-----Original Message-----
> From: Kalin Getov [mailto:[email-masked]] 
> Sent: Tuesday, April 17, 2007 5:11 AM
> To: Youn-Hee Han
> Cc: [email-masked]; [email-masked]
> Subject: Re: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt
> 
>   Hi all,
>
> sorry for jumping into this discussion...but just want to understand this
> right. Is it possible or allowed that the MN gets its home link emulated
> from MAG before the PBAck is received? I thought if PMIP is chosen as
> mobility management protocol the MN won't get RA with the home network
> prefix (or any other prefix) before the MAG gets the acknowledgment from
> the LMA. Could you explain please...?Thanks!

Yes. If the mobile node's home prefix is available for the MAG, it can
certainly send an RA advertising the home prefix as the on-link prefix
on the access link. However, the data path or the tunnel will be setup
only after the PBA is recvd. Now, if the LMA rejects the PBA, the MAG
can always send the RA with the 0 prefix lifetime and that will preempt
the mobile node from using that prefix. 

Thanks
Sri

Best Regards 

Kalin Getov

[email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 08:10:11 -0700

Hi Christian/Alice:

-----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Tuesday, April 17, 2007 5:02 AM
> To: qinxia
> Cc: 'Sri Gundavelli'; [email-masked]

Yes. I agree.

The mobile node's home prefix is anchored on a single node, unlike in
3775, where the prefix is on a link and being served by multiple
home agents on that link. This link virtualization makes it difficult
to make the prefix anchored on two nodes, with out other some protocol
between the LMA's.

Moreover, in the absence of context transfer procedures, the serving
the MAG will not be able to identify the local mobility anchor that
has the BCE for the mobile node. 

So, currently, the supported configuration in the base protocol is
a single LMA serving a mobile node. Offcourse, any serious deployment
would certainly have multiple LMA's using vendor specific reliability
schemes or based on the reliability work that's hapenning in MIP6 WG.

> address from its PMIP home link prefix."

Ok. We will clarify the definition.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 08:26:35 -0700

Hi JinHyeock,

-----Original Message-----
From: JinHyeock Choi [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 5:44 PM
To: Sri Gundavelli
Cc: [email-masked]
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Dear Sri

[Sri] Ok.

[Sri] Sure. This is in the mentioned in the document. If the mobile's
home prefix is not in a policy store, the serving MAG always needs
to obtain from that information from the LMA, irrespective of the
case if the mobile is attaching for the first time in that PMIP domain
or if it just moved from some other MAG. This is documented and will
be looked at again to make sure, the text is clear.

In that case MAG needs

[Sri] Yes. We need to specify this. We generally said, the MAG should
not advertise the prefix any more, but, we need to explicitly send
an RA with 0 lifetime.

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 18 Apr 2007 08:56:38 +0900

Dear Youn-Hee

Thanks for your kind elaboration.

> from the binding cache entry for the MN. The prefix can be delivered

That would work. However, I think that would better be a fall-back
mechanism rather than a standard procedure.

Best Regards

JinHyeock

---

From: "JinHyeock Choi" <[email-masked]>
Date: Wed, 18 Apr 2007 08:58:20 +0900

Dear Sri

> be looked at again to make sure, the text is clear.

ok. Let me summarize the roaming procedure as below.

1. An MN with a home network prefix roams and attaches to an another MAG.
2. The MAG contacts the policy store.
3. The policy store
   SHOULD (MAY) provide the MN's LMA address (existing home network prefix).
4. If the MAG gets the MN's home network prefix,
   it performs home network emulation & PBU.
5. If the MAG doesn't get the MN's home network prefix,
   it asks for the prefix from the LMA with PBU.

Do I understand right?

I have a question.Vijay wrote that

  "The default would be to *not* store the MN's home prefix
   in any "policy store".

Does the above apply to only initial attachment case or also roaming
case? If that is for both cases, a MAG would mostly get home network
prefix from LMA.

Best Regards

JinHyeock

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 18:35:25 -0700

Hi JinHyeock,

Please see inline ...

[Sri] It SHOULD. Certain access technologies may be using some context
transfer procedures and the serving MAG MAY have this information from
other sources and in that case, the LMA address need not be present in
the policy store.

Do I understand right?

[Sri] Yes. 

[Sri] If its not in the policy store, it always comes from the LMA.
But, again if there are context transfer procedures in place, the MAG
may learn the mobile node's home network prefix info, as part of the
hand-off procedures, and so it can emulate the link and need not have 
to learn this from the LMA.

Regards
Sri

---

From: qinxia <[email-masked]>
Date: Wed, 18 Apr 2007 10:10:33 +0800

Hello Vogt and Sri,

Kindly see inlines.

Alice  

> Sent: Tuesday, April 17, 2007 8:02 PM
> To: qinxia
> > single-point failure problem. If this unique LMA goes 
> kaput, how could 
> > we deal with these tunnels?
> 
> LMA fail-over is probably a separate issue and should not be 
> part of the base protocol specification.  It seems like an 
> issue the WG could concentrate on /after/ the work on the 
> base protocol is done.
> 
> FWIW, the fact that the LMA is not physically tied to a link 
> with the MN's home link seems to render LMA fail-over easier 
> to realize that it is, e.g., for standard Mobile IPv6.
> 

[qx] no matter it is easy or hard, do you think we may clarify this problem in a
separate draft?

> The PMIP domain could defined as "the set of administratively 
> contiguous physical access links on which the mobile node can 
> communicate via an IP address from its PMIP home link prefix."
> 

[qx] if a PMIP domain is a set of  administratively  contiguous physical access
links, in future convergence network,
A PMIP domain could be include multi-radio access networks. multi-radio access
networks may be administrated by one specific service probider. The service provider
has its own core service network(CSN). LMA is an entity located in CSN.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 19:27:37 -0700

Hi Alice, 

-----Original Message-----
From: qinxia [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 7:11 PM
To: 'Christian Vogt'
Cc: 'Sri Gundavelli'; [email-masked]; 'Andy Huang'
Subject: RE: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

Hello Vogt and Sri,

Kindly see inlines.

Alice  

> to realize that it is, e.g., for standard Mobile IPv6.

[qx] no matter it is easy or hard, do you think we may clarify this problem
in a
separate draft?

[Sri] Sure.

> communicate via an IP address from its PMIP home link prefix."

[qx] if a PMIP domain is a set of  administratively  contiguous physical
access
links, in future convergence network,
A PMIP domain could be include multi-radio access networks. multi-radio
access
networks may be administrated by one specific service probider. The service
provider
has its own core service network(CSN). LMA is an entity located in CSN. 

[Sri] PMIP Domain maps to the NETLMM domain definition. Its defined in the
PS
specification. So, dont see a reason to say more that what the base PS
document says, draft-ietf-netlmm-nohost-req-05.txt, its an RFC now.

"
Localized Mobility Management Domain 
      
            An Access Network in the sense defined in [1] in which 
            mobility is handled by the NETLMM protocol.                   
"

---

From: Christian Vogt <[email-masked]>
Date: Wed, 18 Apr 2007 09:03:58 +0300

> schemes or based on the reliability work that's hapenning in MIP6 WG.

A simple approach to allow for multiple LMAs even in the current
protocol specification might be to allow for LMA pre-configuration in a
given MN's policy store entry.  Such an "LMA IP Address" entry could be
optional, reserved to cases where multiple LMA exist in the same PMIP6
domain.

- Christian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 17 Apr 2007 23:28:17 -0700

-----Original Message-----
From: Christian Vogt [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 11:04 PM
To: Sri Gundavelli
Cc: 'qinxia'; [email-masked]
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

- Christian

[Sri]
If multiple LMA's are configured to serve a mobile node, and when the
mobile node moves between the MAG's, the new MAG would not be able
to predictably identify the LMA that has the BCE for the mobile node.
This is not an issue in 3775, as the state moves with the mobile. So,
we either have context transfer procedures or the MAG would not know
where to send the PBU. Also, from routing perspective, with the 
per-mn-prefix model and not having a physical link that can be shared
by two LMA's, both the LMA's have to advertise the aggregated prefix
into IGP and it can get tricky as where the packets get directed.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Wed, 18 Apr 2007 10:09:45 +0300

Sri,

if you have multiple LMAs out of which /one/ should serve the MN, then I
would assume that LMA could be identified in the MN's policy store.
Note that my comment wasn't related to LMA fail-over, where different
LMAs might end up serving the same MN.

- Christian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 18 Apr 2007 00:28:07 -0700

Hi Christian,

-----Original Message-----
> Sent: Wednesday, April 18, 2007 12:10 AM
> To: Sri Gundavelli

Ok. Thanks for the clarification. I was talking about the fail-over
case.

Regards
Sri

---

From: "JinHyeock Choi" <[email-masked]>
Date: Thu, 19 Apr 2007 10:17:08 +0900

Sri

> other sources and in that case, the LMA address need not be present in

I see. 'The procedure to acquire MN's profile', is this out of scope?
Will the draft just mention that MAG gets MN's profile with either
Context Transfer or Policy Store?

> to learn this from the LMA.

I see. Thanks for your elaboration.

Best Regards

JinHyeock

---

From: qinxia <[email-masked]>
Date: Thu, 19 Apr 2007 09:51:38 +0800

Hello Sri,
        kindly see inlines.
Alice  

> Sent: Wednesday, April 18, 2007 2:28 PM
> To: 'Christian Vogt'
> > So, currently, the supported configuration in the base 
> protocol is a 
> > single LMA serving a mobile node. Offcourse, any serious deployment 
> A simple approach to allow for multiple LMAs even in the 
> current protocol specification might be to allow for LMA 
> pre-configuration in a given MN's policy store entry.  Such 
> an "LMA IP Address" entry could be optional, reserved to 
> cases where multiple LMA exist in the same PMIP6 domain.
> 
> - Christian
> 
> 
> [Sri]
> If multiple LMA's are configured to serve a mobile node, and 
> when the mobile node moves between the MAG's, the new MAG 
> would not be able to predictably identify the LMA that has 
> the BCE for the mobile node.
> This is not an issue in 3775, as the state moves with the 
> mobile. So, we either have context transfer procedures or the 
> MAG would not know where to send the PBU. Also, from routing 
> perspective, with the per-mn-prefix model and not having a 
> physical link that can be shared by two LMA's, both the LMA's 
> have to advertise the aggregated prefix into IGP and it can 
> get tricky as where the packets get directed.
> 

[qx]: How to detect whether the share tunnel is still alive? How to get to know the
LMA does not go kaput? Does it depend on PBU/PBA or other? How long it takes by
PBU/PBA?

---

From: Christian Vogt <[email-masked]>
Date: Thu, 19 Apr 2007 15:28:50 +0300

> LMA does not go kaput? Does it depend on PBU/PBA or other? How long it takes by

Alice,

fail-over is really too complex to be included into the base protocol
specification.  One cannot just rely on the PBU/PBA exchange during
registration, as LMA failure between successive registrations would
remain undetected or get detected only late.  Especially with localized
mobility management, users would rightly expect fail-over to happen very
efficiently.

Beyond failure detection, LMA fail-over would need to include routing
updates so as to direct packets destined to the MN via the new LMA.
This might require updates to IGP, as Sri has mentioned, or
other mechanisms that are transparent to routers outside the localized
mobility management domain.

Finally, fail-over includes updating the MN's serving MAG.  If the
policy store holds the MN's assigned LMA, then the store must be updated
as well.

These are just some topics to be considered, and the devil is, of
course, in the details.  So I would really recommend not to discuss LMA
fail-over at this point, but attend to it at a stage when the base
protocol is out.  As I mentioned in an earlier mail, lack of a fail-over
mechanism doesn't necessarily prevent the base protocol from allowing
multiple LMA per domain.  Just the number of LMAs assigned to a given MN
should be limited to a single one, which in turn could be identified in
the MN's policy store entry.

Does this sound reasonable to you?

- Christian

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 19 Apr 2007 17:40:18 -0700

Hello JinHyeock,

Sorry for disappearing from this thread for a while.

> case but can't be sure of the roaming case.

The same mechanism can be used in the handover case too.
(lets not call it roaming).

> know the MN's current home network prefix, prefix 1?

MAG2 would also get the home prefix for the mobile node
from the LMA. MAG2 will not start emulating the home link
until it gets the prefix from the LMA.

Having the MN's prefix in the policy store is a bit
cumbersome. I would rather see the LMA dynamically
managing the prefixes for the mobile node. After all
the routing in a network, where the LMA sits, is setup
so that packets meant for the MN's prefix reach a
particular LMA.

There should also be an ability to dynamically assign
an LMA to a mobile node. Having prefixes stored in a
policy store and dynamically assigning LMAs don't go
together.

Vijay

---

From: qinxia <[email-masked]>
Date: Fri, 20 Apr 2007 09:45:58 +0800

Hello Vogt,

          ok, I just want to make sure that there are problems at this point. As the
basic protocol is over, we may concern us with solving this problem.
         
Best regards

          Alice

> Sent: Thursday, April 19, 2007 8:29 PM
> To: qinxia
> >> mobile node moves between the MAG's, the new MAG would not 
> be able to 
> >> predictably identify the LMA that has the BCE for the mobile node.
> mobile. So, 
> > [qx]: How to detect whether the share tunnel is still alive? How to 
> > get to know the LMA does not go kaput? Does it depend on PBU/PBA or 
> > other? How long it takes by PBU/PBA?
> 
> Alice,
> 
> fail-over is really too complex to be included into the base 
> protocol specification.  One cannot just rely on the PBU/PBA 
> exchange during registration, as LMA failure between 
> successive registrations would remain undetected or get 
> detected only late.  Especially with localized mobility 
> management, users would rightly expect fail-over to happen 
> very efficiently.
> 
> Beyond failure detection, LMA fail-over would need to include 
> routing updates so as to direct packets destined to the MN 
> via the new LMA.
> other mechanisms that are transparent to routers outside the 
> localized mobility management domain.
> 
> Finally, fail-over includes updating the MN's serving MAG.  
> If the policy store holds the MN's assigned LMA, then the 
> store must be updated as well.
> 
> These are just some topics to be considered, and the devil 
> is, of course, in the details.  So I would really recommend 
> not to discuss LMA fail-over at this point, but attend to it 
> at a stage when the base protocol is out.  As I mentioned in 
> an earlier mail, lack of a fail-over mechanism doesn't 
> necessarily prevent the base protocol from allowing multiple 
> LMA per domain.  Just the number of LMAs assigned to a given 
> MN should be limited to a single one, which in turn could be 
> identified in the MN's policy store entry.
>

---

From: "JinHyeock Choi" <[email-masked]>
Date: Sat, 21 Apr 2007 16:01:26 +0900

Dear Vijay

> until it gets the prefix from the LMA.

ok. Allow me to write down the procedure in detail as below.

1. The MN attaches to MAG2 and presents its MN-identifier.

2. MAG2 gets the MN's policy profile to find out the MN's LMA address.

3. MAG2 sends to the MN's LMA the PBU with
   1) MN-Identifier & 2) Home Network Prefix Option set to value 0 .

4. Upon receiving the PBU, the MN's LMA finds the MN's home network prefix
   in its binding cache with the MN-Identifier.

5. The MN's LMA sends back PBack with the MN's home network prefix, prefix 1.

6. MAG2 finds out the MN's home network prefix and starts emulating
home network
   by sending an RA with prefix 1.

Do I understand right? Is this the default procedure the draft proposes?

Best Regards

JinHyeock

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 22 Apr 2007 02:38:10 +0900

Hi Christian

> is, e.g., for standard Mobile IPv6.

agree.

We have HA reliability spec in MIP6 WG. This document may be  
applicable to PMIP, too.
PMIP is much easier for reliability since # of managed tunnel is  
smaller than MIP6.
This applicability can be discussed later once the PMIP base spec is  
done.

ryuji

> contiguous

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 22 Apr 2007 02:56:07 +0900

Hi Vijay and Sri,

> cumbersome. I would rather see the LMA dynamically

I rather say policy store itself is cumbersome:-p
I understand that some information must be pre-configured on MN.

But the PMIP base spec. does not specify how to access the policy  
store for MAG.
It mean no interoperability can be expected.
Will this WG define this after the PMIP6 base spec.?

As Youn-Hee Han pointed out, it will be nice to specify available  
information
clearly in policy store, too.

regards,
ryuji

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 22 Apr 2007 10:09:41 -0700

> 2. MAG2 gets the MN's policy profile to find out the MN's LMA address.

This is of course optional. Other mechanisms like DNS can be
used.

> Do I understand right? Is this the default procedure the draft proposes?

Yes.

Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 23 Apr 2007 13:49:52 +0900

Vijay

> This is of course optional. Other mechanisms like DNS can be

Do you mean 'getting the MN's policy profile' is optional? Please take
notice that I wrote down just 'MAG2 acquires MN's policy profile'
without mentioning anything about specific acquisition methods.

> > Do I understand right? Is this the default procedure the draft proposes?

Thanks for your clarification.

Best Regards

JinHyeock

---

From: "Youn-Hee Han" <[email-masked]>
Date: Mon, 23 Apr 2007 14:11:28 +0900

Hello Vijay and Sri,

I have similar questions as JinHyeock posted.
Please give us clear explanation.

Q1) In a policy store, is the MN's home prefix manadory or optional?

Q2) If a policy store provides MAG with the MN's home prefix, 
      can MAG starts to emulate the MN's home network and send 
      RA with the prefix *before* it receives PBAck from LMA?

Q3) If a policy store does not provide it, should MAG defer sending RA
      solicited by MN's RS until it receives PBAck from LMA? 

Best Regards,

Youn-Hee Han

> Sent: Monday, April 23, 2007 1:50 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> > This is of course optional. Other mechanisms like DNS can be used.
> 
> Do you mean 'getting the MN's policy profile' is optional? 
> Please take notice that I wrote down just 'MAG2 acquires MN's 
> policy profile'
> > > 5. The MN's LMA sends back PBack with the MN's home 
> network prefix, 
> > > prefix 1.
> > >

---

From: Sri Gundavelli <[email-masked]>
Date: Sun, 22 Apr 2007 22:25:31 -0700 (PDT)

Hi Youn-Hee,

I thought we both answered this. Is the confusion related
to Vijay's comment on the suggested default behaviour of
allowing the LMA to dynamically allocate the prefix as
supposed to configuring the home prefix in a profile ?
That's does not imply, we disallow the static configuration.
Its always better for the LMA to do the prefix allocation
and management, that was the point.

Please see inline.

Sri

> Q1) In a policy store, is the MN's home prefix manadory or optional?

Optional.

>      RA with the prefix *before* it receives PBAck from LMA?

Yes. Also, if the LMA rejects the PBU, the MAG should stop
advertising the MN's home prefix on the access link.

>      solicited by MN's RS until it receives PBAck from LMA?

Yes. It would not know the home prefix info for it to emulate the
home link.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 22 Apr 2007 23:15:32 -0700

> without mentioning anything about specific acquisition methods.

I used the word "optional" to refer to the MAG2 getting the
MN's LMA address. MAG2 could still go to the "policy store"
to get the MN's profile. It does not have to go to the
"policy store" to get the LMA's address.
(I hate the word "policy store". :)).

Vijay

---

From: "JinHyeock Choi" <[email-masked]>
Date: Mon, 23 Apr 2007 15:57:46 +0900

Vijay

> MN's LMA address.

I assume you meant 'getting MN's LMA address from policy profile' is
optional. I find the following two statements conflicting.

    The Proxy Mobile IPv6 model assumes that the mobile access gateway
    will be able to obtain the address of the local mobility anchor in
    one or more ways.  This MAY be a configured entry in the mobile
    node's policy profile, or it MAY be obtained through mechanisms
    outside the scope of this document.

    and the MN-Identity.

The first says policy profile MAY have MN's LMA address, whereas
the second says policy profile MUST have MN's LMA address.

> MAG2 could still go to the "policy store"

I see. However, I assume anyway MAG2 should get the MN's profile with
whichever method.

> (I hate the word "policy store". :)).

ok. If you provide another term, I'll use that. :-)

Best Regards

JinHyeock

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Apr 2007 00:05:31 -0700

> the second says policy profile MUST have MN's LMA address.

Yes, this needs to be fixed. Other mechanisms for the MAG to
obtains the LMA's address should be allowed.

Vijay

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Wed, 25 Apr 2007 11:34:03 +0200

I would appreciate clarifications regarding the concept of PMIPv6 domain.

This is my current understanding from the draft:

A PMIPv6 domain encompasses one or several MAG's and one or several LMA's.
A MN can boot and roam inside a PMIPv6 domain using its MN-HNP.
The MN-HNP is assigned at MAG's policy store level or by LMA's on a 
per-MN basis.
The MN-HNP does not correspond to a physical address at LMA's level.

These are my questions:

(a) If several LMA's are defined in a PMIPv6 domain, should all LMA's be 
accessible from any MAG in the domain to allow complete roaming inside 
this domain?

(b) Does the concept of "roaming between PMIPv6 domains" make any sense?

(c) Applicability example:
Consider 2 disjoint PMIPv6 domains:
D1 has MAG1 and LMA1, D2 has MAG2 and LMA2.
D1 and D2 provide mobility access and service to separate Mobile users. 
The later can roam inside their domain but not across.
It happens now that D1 and D2 gets interconnected (MAG1 is connected to 
LMA2 and MAG2 to LMA1).

If we do this, do we merge 2 PMIPv6 domains into a single domain or do 
we interconnect 2 PMIPv6 domains?
Does the draft make special restrictions in this case?

Thanks, Bruno.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 25 Apr 2007 09:41:00 -0700

Hi Bruno,

Please see inline ...

-----Original Message-----
From: Bruno Mongazon-Cazavet
[mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 2:34 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [netlmm] I-D ACTION:draft-ietf-netlmm-proxymip6-00.txt

These are my questions:

[Sri] Sure

[Sri] Yes and that is global mobility. It is expected that the mobile node
      will use 3775  host-based mobility for roaming between PMIP domains.

[Sri] This is really upto the deployment. If its under one administrative
control and if they want to leverage network-based mobility, it can
be collapsed into one domain. Or, the domain separation can still be
preserved and by requiring host-based mobility for allowing mobiles
from one domain to roam into the other domain. This up to the deployment
and the specification has no control on this aspect.

Thanks
Sri

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Thu, 26 Apr 2007 09:14:24 +0200

> Please see inline ...
Hi Sri,

Thanks for the reply.
Please find additional questions inline.
> accessible from any MAG in the domain to allow complete roaming inside 
[Bruno] Don't you think this should be mentioned in the draft?
>       will use 3775  host-based mobility for roaming between PMIP domains.
[Bruno] So if my mobile node is not RFC3775-capable, it cannot roam 
between PMIPv6 domains?
Don't you think this can be written in the draft to make things clear?

I would suggest that such a feature can be studied in netlmm. What's 
your opinion?
I can contribute!
> and the specification has no control on this aspect.
[bruno] Do you mean the draft allows the 2 interconnected PMIPv6 domains 
to be left under different administrative control?

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 26 Apr 2007 19:49:49 -0700

Hi Bruno,

This is implicit. But, we will ensure there is no ambiguity there.
Even the basic network illustration in the document show multiple
LMA's and MAG's.

> I would suggest that such a feature can be studied in netlmm. What's 

I assume the scope of PMIP domain is in the PS statement and I think
the direction is for choosing host-based mobility for inter-domain
mobility. If this not clear, I'm sure you can publish a doc.

The draft has no control on this aspect. This is more about a choice
of a deployment model. The scope or the size of a domain is not for 
the specification to dictate. It has bearing on the access technology,
handoff latency, size of the network ..many other parameters.

Sri