Subject: [netlmm] Re: Comments on draft-krishnan-netlmm-pmip-sel-00

From: "Damic, Damjan" <[email-masked]>
Date: Tue, 10 Jul 2007 16:03:41 +0200

Hi Jong-Hyouk, Suresh,

Few weeks ago we published a draft dealing with the same PMIP6 aspect,
i.e., active participation of MNs in the mobility mode selection.

Our draft goes a bit beyond draft-krishnan-netlmm-pmip-sel-00, and
already comprises several "negotiation" mechanisms:
- extended RS sent by MN (Very similar, but we proposed using an option,
not a flag)
- RA extension - option enabling simultaneous delivery of both Home, and
on-link prefix
- new DHCPv6 options that can be used to request appropriate home
network information in the stateful addressing scenario

Please take a look, and see if this already answers some of your
questions:
http://www.ietf.org/internet-drafts/draft-damic-netlmm-pmip6-ind-discove
r-01.txt

Kind regards,
Damjan

>From: Suresh Krishnan <[email-masked]>
>Subject: [netlmm] Re: Comments on draft-krishnan-netlmm-pmip-sel-00
>To: Jong-Hyouk Lee <[email-masked]>
>Cc: [email-masked]
>
>Hi Jong-Hyouk,
>   Thanks for the comments. Please see responses inline.
>
>Jong-Hyouk Lee wrote:
><snip>
>> However, there is no guarantee that the MN must send a RS message 
>> which prior to a RA message sent from the MAG. The author should 
>> define how to overcome. For instance, the MN using this 
>mechanism has 
>> to receive only the RA message responding RS message with C bit.
>
>You are right. I had not thought about this case when I wrote 
>the draft. 
>  I need to think a bit more about this.
>
>> 
>> Also, I'm confusing with the sentance "a topologically 
>correct prefix 
>> for the link (i.e., Not the home prefix)". As I understand, it would 
>> use for C bit (set 1). Is it right? If so, who is 
>responsible for this 
>> prefix? MAG? or LMA? (Actually, MAG sends RA messages in its subnet)
>
>The topologically correct prefix is the one the MN would have 
>got if there was no PMIP service on the network (i.e. the 
>prefix of CoA). So in case of stateless autoconf, this would 
>be one of the prefixes probably in a multicast RA sent out by 
>the AR/MAG with the A bit set.
>
>> 
>> In the document, the author use a keyward, PMA. Does it 
>stand for "Proxy 
>> Mobility Agent"?
>
>Yes. This was a term used in the earlier versions of the PMIP draft. 
>Guess it has been removed.
>
>> 
>> For myself, I like this mechanism. There need a mobility selection 
>> mechanism initiated client (MN) in the current PMIPv6 specification.
>
>Sounds good.
>
>
>Cheers
>Suresh

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

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 10 Jul 2007 10:47:04 -0400

Hi Damjan,
   Thanks for the pointer. From the abstract, I thought the draft 
covered only pmip advertisement & discovery. I went through it but I 
could not find the part where the mobile CHOOSES what mobility mode it 
wants.

 From what I saw you propose using a RS option to indicate that the MN 
is PMIP capable. It is not clear from the draft how the MAG uses this to 
figure out what service the MN prefers. Also the MAG action on receiving 
this option is unspecified. Can you please clarify this aspect?

Cheers
Suresh

---

From: "Damic, Damjan" <[email-masked]>
Date: Tue, 10 Jul 2007 17:42:09 +0200

Hi Suresh,

I agree with your comments, PMIP6 indication is exactly what we wanted
to describe in the draft.
The MN does not explictly request PMIP6 / MIP6 service, and neither MAG
has to make that decision.

As we see it, the goal is to minimize the impact on the legacy terminal
e.g. nodes that are not MIP-capable.
For the ideal case where MAG can somehow deduce what kind of mobility MN
needs / is allowed, the direct enforcement of the designated prefix in
RA probably would work. The problem is that AAA policy or some other
profile information is not sufficient to pinpoint the correct mobility
mode. Especially when targeting the PMIP6-MIP6 interworking scenario
things look to be more complicated (in this case expecting that MIP6
client implemenations will be PMIP6 aware - MN could either continue
with MIP6 mode, or switch the session over to PMIP6 mobility).

We expect the hosts will need a topologically correct on-link prefix in
most of the cases. This applies for all non-mobile scenario plus CoA
configuration of the MIP6 hosts, hence PMIP6 prefix will need to be
advertised only in seldom individual cases:
The PMIP6 indication in the RS reveals that MN is capable of processing
the network-based mobility indication flag and the related PMIP6 prefix
option. In this case MAG should include both prefix types in the
responding RA, leaving the actual selection of mobility mode to the MN.
Same mechanism should work for the legacy nodes as well... the
unknown/unsupported option will be discarded and MN will configure its
address using the valid on-link prefix.

Hope this clarifies the intention and answers your question.

Regards,
Damjan

>-----Original Message-----
>From: Suresh Krishnan [mailto:[email-masked]] 
>Sent: Tuesday, July 10, 2007 4:47 PM
>To: Damic, Damjan
>Cc: [email-masked]; [email-masked]
>Subject: Re: Comments on draft-krishnan-netlmm-pmip-sel-00
>
>Hi Damjan,
>   Thanks for the pointer. From the abstract, I thought the 
>draft covered only pmip advertisement & discovery. I went 
>through it but I could not find the part where the mobile 
>CHOOSES what mobility mode it wants.
>
> From what I saw you propose using a RS option to indicate 
>that the MN is PMIP capable. It is not clear from the draft 
>how the MAG uses this to figure out what service the MN 
>prefers. Also the MAG action on receiving this option is 
>unspecified. Can you please clarify this aspect?
>
>Cheers
>Suresh
>
>Damic, Damjan wrote:
>> Hi Jong-Hyouk, Suresh,
>> 
>> - extended RS sent by MN (Very similar, but we proposed using an 
>> option, not a flag)
>> - RA extension - option enabling simultaneous delivery of both Home, 
>> and on-link prefix
>>> You are right. I had not thought about this case when I wrote the 
>>> draft.
>>> The topologically correct prefix is the one the MN would 
>have got if 
>>> there was no PMIP service on the network (i.e. the prefix 
>of CoA). So 
>>> in case of stateless autoconf, this would be one of the prefixes 
>>> probably in a multicast RA sent out by the AR/MAG with the 
>A bit set.
>>>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 10 Jul 2007 18:19:55 -0400

Hi Damjan,
   I see where you are coming from. You would like to reduce the impact 
to legacy nodes. But then the question becomes, what service would the 
MAG provide for a legacy node which is not PMIP aware? Following your 
reasoning, you expect the node to configure an on-link prefix right? 
This is probably where our goals diverge. I would have expected the MN 
to get PMIP service instead.

Cheers
Suresh

---

From: "Damic, Damjan" <[email-masked]>
Date: Wed, 11 Jul 2007 13:41:49 +0200

Hi Suresh,

We are obviously considering the same set of issues, although with a
slightly different interpretation.
I spent quite some time thinking over this, so it would be useful to
hear your comments on the following aspects:

- PMIP6 as a "default" mobility type within the network
Clarification from my side as this is a point where we seem to diverge:
Advertising PMIP6 prefix to all mobility-unaware nodes is not harmful,
but probably undesired. The operator may treat PMIP6 as an add-on
service, and grant the priviledge  per individual subscriber. According
to your draft, all IPv6 terminals would have to implement "PMIP6
awareness" (including the proposed RS extension) in order to request the
correct on-link prefix. In my opinion this is an unlikely expectation.

- Mobility type determined by the network
I don't think it is not the most plausible solution. The
AAA/subscription profile can authorize or prohibit the use of PMIP6
service, but does not provide sufficient information about the terminal
capabilities, correct? This is valid only in case of mobility-unaware
nodes - according to the AAA information the MAG alone can determine
which prefix it will provide in the RA. As the profile is usually linked
to the subscriber and not the terminal, hence the problem. Besides, the
terminal capabilities can change with time - de/installation of a MIP6
client is not a big deal, and most likely will not reflect in the
individual profile.

- PMIP6-MIP6 interaction
MAG cannot accurately deduce the target prefix for the potential
MIP-enabled terminals (explained in the paragraph above). Provision of
PMIP6 Home Prefix in the RA's Prefix Information Option implicitly
causes MN to configure PMIP6 HoA as the MIP6-CoA, but it's not apparent
and perceivable to the MN.
Our draft introduces 2 explicit mechanisms for PMIP6 indication:
1) general indication pointing to the MN it is residing in the PMIP6
domain - explict flag in RA's designated field
(http://tools.ietf.org/id/draft-haberman-ipv6-ra-flags-option-00.txt) to
specify the network-based mobility support is present.
2) Two distinctive prefixes in the RA, so the MN can explicitly tell
them apart
I have to re-check the interaction scenarios analyzed in the latest
http://tools.ietf.org/wg/netlmm/draft-giaretta-netlmm-mip-interactions-0
1.txt, to see if there are conflicting issues with both proposed host
configuration approaches, so might come with a follow-up here.

- MN actively participating in mobility type selection
In my opinion both proposals are OK with the general NETLMM
requirements. Sending indication or preference for the mobility type
does not equal PMIP6 mobility-related signaling taking place between MAG
and LMA, so the MN is not actually participating in the mobility
management.
One of the posts on this thread mentioned other scenarios such as
PMIP6-IPv4 setup... This somehow leads towards the generic mobility
negotiation framework which might significantly affect the MN, and
thereby compromises the fundamental premise of the NETLMM concept. We
should keep it as simple as it can be...

Thanks,
Damjan

>Sent: Wednesday, July 11, 2007 12:20 AM
>To: Damic, Damjan
>   I see where you are coming from. You would like to reduce 
>the impact to legacy nodes. But then the question becomes, 
>what service would the MAG provide for a legacy node which is 
>not PMIP aware? Following your reasoning, you expect the node 
>to configure an on-link prefix right? 
>This is probably where our goals diverge. I would have 
>expected the MN to get PMIP service instead.
>
>Cheers
>Suresh
>
>Damic, Damjan wrote:
>> Hi Suresh,
>> 
>> The MN does not explictly request PMIP6 / MIP6 service, and neither 
>> MAG has to make that decision.
>> 
>> As we see it, the goal is to minimize the impact on the legacy 
>> terminal e.g. nodes that are not MIP-capable.
>> For the ideal case where MAG can somehow deduce what kind of 
>mobility 
>> MN needs / is allowed, the direct enforcement of the 
>designated prefix 
>> in RA probably would work. The problem is that AAA policy or some 
>> other profile information is not sufficient to pinpoint the correct 
>> mobility mode. Especially when targeting the PMIP6-MIP6 interworking 
>> scenario things look to be more complicated (in this case expecting 
>> that MIP6 client implemenations will be PMIP6 aware - MN 
>could either 
>> continue with MIP6 mode, or switch the session over to PMIP6 
>mobility).
>> 
>> We expect the hosts will need a topologically correct on-link prefix 
>> in most of the cases. This applies for all non-mobile scenario plus 
>> CoA configuration of the MIP6 hosts, hence PMIP6 prefix will need to 
>> be advertised only in seldom individual cases:
>> The PMIP6 indication in the RS reveals that MN is capable of 
>> processing the network-based mobility indication flag and 
>the related 
>> PMIP6 prefix option. In this case MAG should include both 
>prefix types 
>> in the responding RA, leaving the actual selection of 
>mobility mode to the MN.
>>> could not find the part where the mobile CHOOSES what mobility mode 
>>> it wants.
>>>
>that the MN 
>>> is PMIP capable. It is not clear from the draft how the MAG 
>uses this 
>>> to figure out what service the MN prefers. Also the MAG action on 
>>> receiving this option is unspecified. Can you please clarify this 
>>> aspect?
>>>
>>> Cheers
>>> Suresh
>>>
>>> Damic, Damjan wrote:
>>>> Hi Jong-Hyouk, Suresh,
>>>>
>http://www.ietf.org/internet-drafts/draft-damic-netlmm-pmip6-ind-disc
>>> o
>>>> ve
>>>> r-01.txt
>>>>
>>>> Kind regards,
>>>> Damjan
>>>>
>>>>
>>>>

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 12 Jul 2007 11:32:43 -0400

Hi Damjan,

Damic, Damjan wrote:
> service, and grant the priviledge  per individual subscriber. 

The main justification of PMIP is that it enables legacy nodes to have 
the benefits of mobility while being blissfully unaware of the signaling 
related to it.

> According

OK. But how is draft-damic any different in this aspect? The comparison 
boils down to this.

Node is PMIP aware
==================
draft-damic : Node explicitly requests PMIP service
draft-krishnan : Node explicitly requests CMIP service

Node is PMIP unaware
====================
draft-damic : Node gets CMIP service
draft-krishnan : Node gets PMIP service

> client is not a big deal, and most likely will not reflect in the

After the MN expresses its PREFERENCE, the MAG can still override it 
with the information from the profile, if it so requires.

> specify the network-based mobility support is present.

I agree this is necessary.

> configuration approaches, so might come with a follow-up here.

I am not sure why the MN needs to tell these prefixes apart. An MN 
either needs PMIP (home prefix) or CMIP (on-link prefix). It should not 
need to care which is which. Or are you envisioning a case where the MN 
may need both?

> should keep it as simple as it can be...

Agree.

Cheers
Suresh

---

From: "Damic, Damjan" <[email-masked]>
Date: Fri, 13 Jul 2007 20:43:37 +0200

Hi Suresh, 

Comments in-line...

>Sent: Thursday, July 12, 2007 5:33 PM
>To: Damic, Damjan

[DD] Ideally true, but I find it hard to believe any operator will
actually allow this. Calculating with PMIP6 as a supplementary service
might make more sense. There is actually a good example that I could
elaborate further on, however will skip the details (some people resent
when other SDOs are discussed here).

>OK. But how is draft-damic any different in this aspect? The 

[DD] I will not advocate one approach over the other, but it has to do
with the general intention clarified above. I was contemplating about
this in the follow manner:
CMIP MN just needs a local address/prefix for CoA, where the real
indication of its mobility type would be the subsequent BU. Signaling a
preference for CMIP beforehand  seems somehow unnatural. On the other
hand, the PMIP nodes would ideally be unaware of network capabilities,
so expliciting this preference is also tricky. But, if we are talking
about mobility-aware CMIP6 nodes, then I don't see an issue adding PMIP6
extensions to the MIP6 stack. It preserves the convential MIP6 mobility
model, unless MN explicitly decides for PMIP. 

>with the information from the profile, if it so requires.

[DD] Absolutely agree. That was just clarifying that network alone
cannot decide on mobility type with absolute certainty.

>need to care which is which. Or are you envisioning a case 

[DD] Delivering a single prefix to the MN would be much simpler, of
course. The problem is that we kept coming back to the cases where MN
(which doesn't want or should not receive PMIP6 prefix) could somehow
get it. The second prefix option was introduced to prevent those
situations.

Thanks for the comments. Wish you a nice weekend,
Damjan

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 17:29:32 +0200

Hi Damic, Suresh, all,

> Hi Suresh,
> 
> I agree with your comments, PMIP6 indication is exactly what 
> we wanted to describe in the draft.
> The MN does not explictly request PMIP6 / MIP6 service, and 
> neither MAG has to make that decision.
> 
> As we see it, the goal is to minimize the impact on the 
> legacy terminal e.g. nodes that are not MIP-capable.

I have this issue with enhancing PMIP6 awareness in mobile nodes
at layer-3. The nice idea of PMIP was that it is transparent,
working without mobile node involvement in mobility signaling and
requires minimal if any changes (i.e. no new client or stack
modifications) in the mobile node. Why we now try to change these
assumptions and try to add 'mobility client' like functionality to
mobile nodes? Instead of calling the new functionality as a 'host
mobility client' we extend address configuration phase, ultimately
moving some of the unwanted 'client' functionality there. Also
instead of doing separate mobility signaling we bloat NDP and DHCP.
I find this slightly controversial in PMIP6 context. Though, I am
well aware of the uses cases that would benefit from the proposed
functionality, but still..

[snip]

Sorry for the rant ;-)

Cheers,
	Jouni

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 24 Jul 2007 11:49:48 -0400

Hi Jouni,
   I see your point and I can empathize with you. I just want to clarify 
a few things. The mechanism I proposed DOES NOT require any changes on 
mobility unaware nodes (classic PMIP) and everything works as expected. 
As far as using mobility signaling instead of using NDP/DHCP hacks, this 
becomes impossible because PMIP makes the MN believe that it has NOT 
MOVED and hence results in no mobility signaling from the MN. So I do 
not see any other way out of this. If there is such a way, I would be 
very happy to follow it.

Thanks
Suresh

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 18:26:40 +0200

Hi Suresh, 

> Hi Jouni,
>    I see your point and I can empathize with you. I just want 
> to clarify a few things. The mechanism I proposed DOES NOT 
> require any changes on mobility unaware nodes (classic PMIP) 
> and everything works as expected. 

Yes, but then a MAG needs to be prepared to handle two different
kinds of mobile nodes. Those that are vanilla IPv6 hosts and 
those that are PMIP6 aware. How does MAG know the difference?
Based on the -proxymip6-01 when a MAG sends a RA the binding is
already in process or completed. The MAG does not need to wait
for a mobile to send a RS.

> As far as using mobility signaling instead of using NDP/DHCP 
> hacks, this becomes impossible because PMIP makes the MN 
> believe that it has NOT MOVED and hence results in no 
> mobility signaling from the MN. So I do not see any other way 

Didn't get this. These prefix & mobility mode selections are
mostly an issue durign the initial entry to the network.. afaik.

> out of this. If there is such a way, I would be very happy to 
> follow it.

Cheers,
	Jouni

> >> I agree with your comments, PMIP6 indication is exactly what we 
> >> wanted to describe in the draft.
> > I have this issue with enhancing PMIP6 awareness in mobile nodes at 
> > layer-3. The nice idea of PMIP was that it is transparent, working 
> > without mobile node involvement in mobility signaling and requires 
> > minimal if any changes (i.e. no new client or stack
> > moving some of the unwanted 'client' functionality there. 
> Also instead 
> > of doing separate mobility signaling we bloat NDP and DHCP.
> > I find this slightly controversial in PMIP6 context. 
> Though, I am well 
> > aware of the uses cases that would benefit from the proposed

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Thu, 26 Jul 2007 03:47:28 +0900

Dear colleague.

> for a mobile to send a RS.

Actually, the MAG would send its RA message. However, there is an interval
time for sending RA message and an MN (wants to use its own mobility
signaling such as MIPv6) could send a RS message to get a RA message. Well,
as you mentioned, sure, there is no guarantee that the MN must send the RS
message with prior to the RA message sent from the MAG. This issue was
already mentioned before (
http://www1.ietf.org/mail-archive/web/netlmm/current/msg02594.html ), so
that S. Krishnan will consider this in the next version. Note that I cannot
be present in the Chicago meeting, S. Krishnan may perhaps solve this issue.

Cheers.

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 26 Jul 2007 12:15:06 +0200

Hi Jouni,

[Damjan is out of the office] The intention of draft-damic is to give the mobile nodes some means to tell the network that they would like / would not like the network to run the PMIP service. Static provisioning of the mobility mode for a MN in the policy store has its issues, the subscriber can switch to a terminal with different capabiliteis and the policy store wouldn't know it. There might be mobile nodes implementing MIP that would prefere to do their own mobility management. Yes, they would need to be enhanced to become PMIP aware :-( But the draft-damic and draft-krishnan give such MNs at least an oportunity to express their  preference.

Some additional comments inline...

thanks
domagoj

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 24. srpanj 2007 18:27
> To: [email-masked]
> Cc: Damic, Damjan; [email-masked]
> Subject: RE: [netlmm] RE: Comments on 
> draft-krishnan-netlmm-pmip-sel-00
> 
> Hi Suresh, 
> 
> > Hi Jouni,
> >    I see your point and I can empathize with you. I just want to 
> > clarify a few things. The mechanism I proposed DOES NOT require any 
> > changes on mobility unaware nodes (classic PMIP) and 
> everything works 
> > as expected.
> 
> Yes, but then a MAG needs to be prepared to handle two 
> different kinds of mobile nodes. Those that are vanilla IPv6 
> hosts and those that are PMIP6 aware. How does MAG know the 
> difference?
> Based on the -proxymip6-01 when a MAG sends a RA the binding 
> is already in process or completed. The MAG does not need to 
> wait for a mobile to send a RS.

MAG can wait for an RS, although it doesn't need to.

> 
> > As far as using mobility signaling instead of using NDP/DHCP hacks, 
> > this becomes impossible because PMIP makes the MN believe 
> that it has 
> > NOT MOVED and hence results in no mobility signaling from 
> the MN. So I 
> > do not see any other way
> 

Before mobility signalling can be used the MN needs to configure its CoA, and for that it needs RA containing on-link prefix. Besides, MIP6 signalling is transparent to MAG, the MAG will never know if the MN sent BU or not.

> 
> > out of this. If there is such a way, I would be very happy 
> to follow 
> > it.
> 
> Cheers,
> 	Jouni
> 
> 
> 
> > 
> > Thanks
> > Suresh
> >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 26 Jul 2007 16:43:05 -0400

Hi Domagoj,

Say, the MN has a MIP6 session i.e. there is a MSA/MSP for the MN and it
has a mip6 binding at a given HA in the MSP. Now the MN hands over to a
different access network where it performs access authentication with
the ASA. 

In the split scenario, the ASA has no idea about MSA/MSP...so the
question of the ASA authorizing PMIP6 to be run from an AR/MAG in the
access network to the MN's HA in the MSP does not arise at this point
(when the MN seeks an address from the AR).

In the integrated case (i.e. ASA is the MSA), the ASA/MSA will know
about the mobility state of the MN. It will know that the MN has an
ongoing MIP6 session. Hence the ASA/MSA will select MIP6 as the mobility
mode and let the MN run MIP6 with the HA in the MSP. 

So, I don't see the reason for the MN to express it's preference for
continuing IP mobility service with MIP6. The network has full knowledge
of the MN's mobility state; hence it can take appropriate decision about
the mobility mode.

BR,
Kuntal

> From: Premec, Domagoj [mailto:[email-masked]]
> Sent: Thursday, July 26, 2007 5:15 AM
> To: [email-masked]; [email-masked]
> 
> Hi Jouni,
> 
> [Damjan is out of the office] The intention of draft-damic is to give
the
> mobile nodes some means to tell the network that they would like /
would
> not like the network to run the PMIP service. Static provisioning of
the
> mobility mode for a MN in the policy store has its issues, the
subscriber
> can switch to a terminal with different capabiliteis and the policy
store
> wouldn't know it. There might be mobile nodes implementing MIP that
would
> prefere to do their own mobility management. Yes, they would need to
be
> enhanced to become PMIP aware :-( But the draft-damic and
draft-krishnan
> give such MNs at least an oportunity to express their  preference.
> 
hacks,
> Before mobility signalling can be used the MN needs to configure its
CoA,
> and for that it needs RA containing on-link prefix. Besides, MIP6
> signalling is transparent to MAG, the MAG will never know if the MN
sent
> BU or not.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 27 Jul 2007 13:39:14 +0200

Hi Kuntal, 

Please see inline... 

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: 26. srpanj 2007 22:43
> To: Premec, Domagoj; [email-masked]; 
> [email-masked]
> Say, the MN has a MIP6 session i.e. there is a MSA/MSP for 
> the MN and it has a mip6 binding at a given HA in the MSP. 
> Now the MN hands over to a different access network where it 
> performs access authentication with the ASA. 

The draft covers the case before the MIP6 session is even established. During the initial attachment to the network, how will the network detect whether the MN wants PMIP service or preferes to run its own mobility management? Draft makes it possible for the MN to express its preference.

> 
> In the split scenario, the ASA has no idea about MSA/MSP...so 
> the question of the ASA authorizing PMIP6 to be run from an 
> AR/MAG in the access network to the MN's HA in the MSP does 
> not arise at this point (when the MN seeks an address from the AR).
> 

ASA could authorize PMIP service within the access network (LMA in ASP), right? However, if the MS is MIP6 capable, it does not need the PMIP service and needs to be able to tell that to the access network.

In my mind, if ASP can provide PMIP service, then the ASA is the policy store from the PMIP draft and it may be able to talk to the MSA. MAG is always in the ASP, but the LMA could be either in the ASP or in the MSP. Maybe the PMIP draft should have a couple of words about policy store, ASA, ASP, MSA, LMA and their relationship?

> In the integrated case (i.e. ASA is the MSA), the ASA/MSA 
> will know about the mobility state of the MN. It will know 
> that the MN has an ongoing MIP6 session.

Yes, but only after the MIP6 session is already established. We need a mechanism to negotiate the type of the session (PMIP/CMIP) before it is established.

 Hence the ASA/MSA 
> will select MIP6 as the mobility mode and let the MN run MIP6 
> with the HA in the MSP. 
> 
> So, I don't see the reason for the MN to express it's 
> preference for continuing IP mobility service with MIP6.

Yes, it is not needed for continuing of the mobility service, but for the initial establishment.

 The 
> network has full knowledge of the MN's mobility state; hence 
> it can take appropriate decision about the mobility mode.
> 
> BR,
> Kuntal

domagoj

> > > kinds of mobile nodes. Those that are vanilla IPv6 hosts 
> and those 
> > > that are PMIP6 aware. How does MAG know the difference?
> > > already in process or completed. The MAG does not need to 
> wait for a 
> > > mobile to send a RS.
> > 
> > > Didn't get this. These prefix & mobility mode selections 
> are mostly 
> > > an issue durign the initial entry to the network.. afaik.
> > 
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Fri, 27 Jul 2007 11:53:06 -0400

Hi Domagoj,

Please see my comments inline....

> Sent: Friday, July 27, 2007 6:39 AM
> To: Chowdhury, Kuntal; [email-masked];
> The draft covers the case before the MIP6 session is even established.
> During the initial attachment to the network, how will the network
detect
> whether the MN wants PMIP service or preferes to run its own mobility
> management? Draft makes it possible for the MN to express its
preference.
[KC>] It is not _necessary_ for the network to know whether the MN
_wants_ PMIP6 or MIP6 during initial attachment. The issue of assigning
the same HoA to two different interfaces does not arise at this time
since this is the initial attachment.

> ASA could authorize PMIP service within the access network (LMA in
ASP),
> right? However, if the MS is MIP6 capable, it does not need the PMIP
> service and needs to be able to tell that to the access network.
> 
[KC>] The MN has MIP6 service with its MSP. If the ASA authorizes PMIP6
to be used for mobility within the ASP, there is no scope of
interference between the PMIP6 session in the ASP and the MIP6 session
that the MN has with the MSP. So, there is no issue at all.

> In my mind, if ASP can provide PMIP service, then the ASA is the
policy
> store from the PMIP draft and it may be able to talk to the MSA. MAG
is
> always in the ASP, but the LMA could be either in the ASP or in the
MSP.
> Maybe the PMIP draft should have a couple of words about policy store,
> ASA, ASP, MSA, LMA and their relationship?
> 
[KC>] Hmmm....in the split mode, the ASA has no knowledge of the MSA.
Since the LMA can be in the ASP (IMHO) for mobility management within
the ASP, we perhaps need a sentence or two to explain that in the pmip6
base I-D.

> Yes, but only after the MIP6 session is already established. We need a
> mechanism to negotiate the type of the session (PMIP/CMIP) before it
is
> established.
[KC>] At the initial attach, there is no need to negotiate which mode
will be used for rendering mobility service to the MN. This negotiation
(rather expression of *preference* by the MN) is merely a FYI for the
network. 

> Yes, it is not needed for continuing of the mobility service, but for
the
> initial establishment.
[KC>] As I explained, it is not needed for initial attach at all.

> > > > > clarify a few things. The mechanism I proposed DOES NOT
require
> > any

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 30 Jul 2007 15:05:22 +0200

Hi Kuntal,

It seems we're discussing different use cases here. The draft was written with an idea to enable negotiation of the mobility mode (PMIP/CMIP) during inital network attachment. You seem to bring up the case of changing the access network and moving in/out of a PMIP domain. 

> [KC>] It is not _necessary_ for the network to know whether 
> the MN _wants_ PMIP6 or MIP6 during initial attachment.

I agree, it is not necessary. If the network doesn't know the MN's MIP capabilities, it will default to the PMIP mode, and everything will work fine. IMO, if the MN is MIP6 capable, it should be allowed to run its own mobility management and not be forced into PMIP. At least MN should have a means to tell the network that it would like to run MIP by itself. 

> The 
> issue of assigning the same HoA to two different interfaces 
> does not arise at this time since this is the initial attachment.

The draft was not written with this particular problem in mind.

> [KC>] The MN has MIP6 service with its MSP. If the ASA 
> authorizes PMIP6 to be used for mobility within the ASP, 
> there is no scope of interference between the PMIP6 session 
> in the ASP and the MIP6 session that the MN has with the MSP. 
> So, there is no issue at all.

Yes, except that the PMIP service with the ASP is not needed at all. Technicaly it will work flawlessly, but what is the benefit of using PMIP in such configuration?

> [KC>] At the initial attach, there is no need to negotiate 
> which mode will be used for rendering mobility service to the 
> MN.

PMIP was meant to provide mobility for simple IP hosts, not for MIP capable hosts. Only problem is, at the time when the PMIP service must be started the network is not able to tell the simple IP from the MIP capable host. So it will blindly provide PMIP to all hosts. PMIP doesn't come for free: it installs additional state in the network and is not exactly supporting the end-to-end principle.

> This negotiation (rather expression of *preference* by 
> the MN) is merely a FYI for the network. 

I agree that this is just expression of preference. If the network decides to run PMIP service for this host, there is nothing the host can do about it.

regards
domagoj

> Sent: 27. srpanj 2007 17:53
> > > Say, the MN has a MIP6 session i.e. there is a MSA/MSP for the MN 
> > > and it has a mip6 binding at a given HA in the MSP.
> [KC>] It is not _necessary_ for the network to know whether 
> the MN _wants_ PMIP6 or MIP6 during initial attachment. The 
> issue of assigning the same HoA to two different interfaces 
> does not arise at this time since this is the initial attachment.
> 
> 
> > >
> > > question of the ASA authorizing PMIP6 to be run from an AR/MAG in 
> > > the access network to the MN's HA in the MSP does not 
> arise at this 
> > > point (when the MN seeks an address from the AR).
> > >
> > 
> [KC>] The MN has MIP6 service with its MSP. If the ASA 
> authorizes PMIP6 to be used for mobility within the ASP, 
> there is no scope of interference between the PMIP6 session 
> in the ASP and the MIP6 session that the MN has with the MSP. 
> So, there is no issue at all.
> 
> 
> Since the LMA can be in the ASP (IMHO) for mobility 
> management within the ASP, we perhaps need a sentence or two 
> to explain that in the pmip6 base I-D.
> 
> 
> will know 
> > > ongoing MIP6 session.
> [KC>] At the initial attach, there is no need to negotiate 
> which mode will be used for rendering mobility service to the 
> MN. This negotiation (rather expression of *preference* by 
> the MN) is merely a FYI for the network. 
> 
> 
> >  Hence the ASA/MSA
> > > will select MIP6 as the mobility mode and let the MN run 
> MIP6 with 
> > > the HA in the MSP.
> > >
> preference for 
> > > continuing IP mobility service with MIP6.
> > 
> > > network has full knowledge of the MN's mobility state; 
> hence it can 
> > > take appropriate decision about the mobility mode.
> > >
> > > BR,
> > > Kuntal
> > 
> > domagoj
> > 
> > 
> > >
> > >
> > > > not like the network to run the PMIP service. Static 
> provisioning
> of
> > > the
> > > > prefere to do their own mobility management. Yes, they 
> would need
> to
> > > be
> > > > > > > modifications) in the mobile node. Why we now try 
> to change
> > > these
> > > > > > > mobile nodes? Instead of calling the new 
> functionality as a
> > > 'host
> information 
> > > of Starent Networks, Corp. The information transmitted may not be 
> > > used to create or change any contractual obligations of Starent 
> > > Networks, Corp.  Any review, retransmission, 
> dissemination or other 
> > > use of, or taking of any action in reliance upon this 
> e-mail and its 
> > > attachments by persons or entities other than the 
> intended recipient 
> > > is prohibited. If you are not the intended recipient, 
> please notify 
> > > the sender immediately -- by replying to this message or 
> by sending 
> > > an email to [email-masked] -- and destroy 
> all copies 
> > > of this message and any attachments without reading or disclosing 
> > > their contents. Thank you."
> > >
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 30 Jul 2007 10:01:05 -0400

Hi Domagoj,

Please see inline....

Thanks,
Kuntal

> Sent: Monday, July 30, 2007 8:05 AM
> 
> Hi Kuntal,
> 
> It seems we're discussing different use cases here. The draft was
written
> with an idea to enable negotiation of the mobility mode (PMIP/CMIP)
during
> inital network attachment. You seem to bring up the case of changing
the
> access network and moving in/out of a PMIP domain.
> 
[KC>] This is because the discussion was about _necessity_ to define
this expression-of-preference by the host. After this email exchange, it
appears that this expression-of-preference by the host about CMIP or
PMIP is merely an FYI for the network and NOT necessary for proper
operation. Basically I have not encountered anything that breaks if this
is not used.

> I agree, it is not necessary. If the network doesn't know the MN's MIP
> capabilities, it will default to the PMIP mode, and everything will
work
> fine. IMO, if the MN is MIP6 capable, it should be allowed to run its
own
> mobility management and not be forced into PMIP. At least MN should
have a
> means to tell the network that it would like to run MIP by itself.
> 
[KC>] the network operator has a heavy say on what mobility protocol
will be used by the hosts. Having said that, I am OK with your last
statement...the MIP6 capable host may like to send a hint to the
network. Please make this clear in your I-D.

> Yes, except that the PMIP service with the ASP is not needed at all.
> Technicaly it will work flawlessly, but what is the benefit of using
PMIP
> in such configuration?
[KC>] Hmmm...I was merely responding to your "PMIP in ASP" problem
scenario. Please read your statement about that (above). BTW, PMIP in
ASP is indeed a valid scenario in some deployments.

> PMIP was meant to provide mobility for simple IP hosts, not for MIP
> capable hosts. Only problem is, at the time when the PMIP service must
be
> started the network is not able to tell the simple IP from the MIP
capable
> host. So it will blindly provide PMIP to all hosts. PMIP doesn't come
for
> free: it installs additional state in the network and is not exactly
> supporting the end-to-end principle.
> 
[KC>] An operator may choose to use PMIP for mobility management of ALL
hosts. BTW, I would prefer to stay away from CMIP vs. PMIP comparison
debate here. There are other I-Ds on that topic. Please note that CMIP
requires OTA signaling overhead and per MN IPsec/IKE state maintenance
in the network (no free lunch anywhere :-)

> I agree that this is just expression of preference. If the network
decides
> to run PMIP service for this host, there is nothing the host can do
about
> it.
[KC>] Yep, I think this should be made pretty clear in your I-D. 

the
> > > > > Before mobility signalling can be used the MN needs to
configure
> > its
> > > > > signalling is transparent to MAG, the MAG will never know if
the
> > MN
> > > > > > > > without mobile node involvement in mobility signaling
and
> > > > > > requires

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 31 Jul 2007 15:18:35 +0200

Kuntal,

OK, in the next revision of the draft we'll make it clear that the proposed mobility mode negotiation is just a hint for the network and that the final decision about the mobility mode is always done by the network. My understanding is that such clarification would address your concerns, if there is something else that I missed, please let me know.

thanks
domagoj

> Sent: 30. srpanj 2007 16:01
> [KC>] This is because the discussion was about _necessity_ to 
> define this expression-of-preference by the host. After this 
> email exchange, it appears that this expression-of-preference 
> by the host about CMIP or PMIP is merely an FYI for the 
> network and NOT necessary for proper operation. Basically I 
> have not encountered anything that breaks if this is not used.
> 
> 
> > > _wants_ PMIP6 or MIP6 during initial attachment.
> > 
> [KC>] the network operator has a heavy say on what mobility 
> protocol will be used by the hosts. Having said that, I am OK 
> with your last statement...the MIP6 capable host may like to 
> send a hint to the network. Please make this clear in your I-D.
> 
> > > The
> > > issue of assigning the same HoA to two different 
> interfaces does not 
> > > arise at this time since this is the initial attachment.
> > 
> > > [KC>] The MN has MIP6 service with its MSP. If the ASA authorizes 
> > > PMIP6 to be used for mobility within the ASP, there is no 
> scope of 
> > > interference between the PMIP6 session in the ASP and the MIP6 
> > > session that the MN has with the MSP.
> [KC>] Hmmm...I was merely responding to your "PMIP in ASP" 
> problem scenario. Please read your statement about that 
> (above). BTW, PMIP in ASP is indeed a valid scenario in some 
> deployments.
> 
> 
> > > [KC>] At the initial attach, there is no need to negotiate which 
> > > mode will be used for rendering mobility service to the MN.
> > 
> [KC>] An operator may choose to use PMIP for mobility 
> management of ALL hosts. BTW, I would prefer to stay away 
> from CMIP vs. PMIP comparison debate here. There are other 
> I-Ds on that topic. Please note that CMIP requires OTA 
> signaling overhead and per MN IPsec/IKE state maintenance in 
> the network (no free lunch anywhere :-)
> 
> 
> 
> > > This negotiation (rather expression of *preference* by the MN) is 
> > > merely a FYI for the network.
> > 
> > > _wants_ PMIP6 or MIP6 during initial attachment. The issue of 
> > > assigning the same HoA to two different interfaces does 
> not arise at 
> > > this time since this is the initial attachment.
> > >
> > >
> > > > >
> > > [KC>] The MN has MIP6 service with its MSP. If the ASA authorizes 
> > > PMIP6 to be used for mobility within the ASP, there is no 
> scope of 
> > > interference between the PMIP6 session in the ASP and the MIP6 
> > > session that the MN has with the MSP.
> > > Since the LMA can be in the ASP (IMHO) for mobility management 
> > > within the ASP, we perhaps need a sentence or two to 
> explain that in 
> > > the pmip6 base I-D.
> > >
> > >
> > > > mechanism to negotiate the type of the session 
> (PMIP/CMIP) before
> it
> > > is
> > > > established.
> > > >
> > > [KC>] At the initial attach, there is no need to negotiate which 
> > > mode will be used for rendering mobility service to the MN. This 
> > > negotiation (rather expression of *preference* by the MN) 
> is merely 
> > > a FYI for the network.
> > >
> > >
> > > >  Hence the ASA/MSA
> > > > > > wouldn't know it. There might be mobile nodes 
> implementing MIP
> > > that
> > > > > would
> > > > > > > > >> The MN does not explictly request PMIP6 / 
> MIP6 service,
> > > > > > > > and neither
> > > > > > > > > mobility client' we extend address 
> configuration phase,
> > > > > > > ultimately

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 31 Jul 2007 12:08:29 -0400

Hi Folks,
   Sorry for jumping in late in this discussion. I am in agreement with 
both Kuntal and Domagoj that the selection is just a hint. But I do not 
agree with the contention that it is NOT NECESSARY to have this 
mechanism. From a purely network point of view this may seem useless, 
but from a MN point of view, I can see why it will be necessary. e.g. MN 
wants to use RO.

Cheers
Suresh

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 31 Jul 2007 11:19:21 -0500

I agree with Suresh.
The MN can utilize the information about the network capability or feature
enabled in terms of making a decision about network selection, mode of
operation etc. 
So I do believe it is necessary to provide the MN enough information or
indication about PMIP6 service or capability in the network.

-Raj

On 7/31/07 11:08 AM, "ext Suresh Krishnan" <[email-masked]>
wrote:

>> OK, in the next revision of the draft we'll make it clear that the proposed
>> mobility mode negotiation is just a hint for the network and that the final
>> decision about the mobility mode is always done by the network. My
>> understanding is that such clarification would address your concerns, if
>> there is something else that I missed, please let me know.
>> 
>> thanks
>> domagoj
>> 
>>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 31 Jul 2007 19:13:12 -0400

Thanks Domagoj. Perhaps a more appropriate title would be "mobility mode
hint". There isn't any negotiation per se.

BR,
Kuntal

> Sent: Tuesday, July 31, 2007 8:19 AM
> 
> Kuntal,
> 
> OK, in the next revision of the draft we'll make it clear that the
> proposed mobility mode negotiation is just a hint for the network and
that
> the final decision about the mobility mode is always done by the
network.
> My understanding is that such clarification would address your
concerns,
> if there is something else that I missed, please let me know.
> 
> thanks
> domagoj
> 
> 
authorizes
the
> > > > > > question of the ASA authorizing PMIP6 to be run from an
AR/MAG
> > in
authorizes
> > > > > store from the PMIP draft and it may be able to talk to the
MSA.
> > MAG
> > > > is
> > > > > always in the ASP, but the LMA could be either in the ASP or
in
> > > > > > > can switch to a terminal with different capabiliteis and
the
> > > > > > of Starent Networks, Corp. The information transmitted may
not