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

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 10 Sep 2007 23:43:48 -0700

A new revision of the Proxy Mobile IPv6 draft, based on the
inpiuts received ...

Change log:

- Text related to allowing alternate security mechanisms for
  protecting PMIP6 signaling messages (WG discussion)

- Retransmissions (Shyam's comments)

- Seq diagram for handoff. 

- Fixed the idnits warnings.

- References to 4283 NAI option (Genadi's comments)

- Minor editorial

Should close all the open issues in the issue tracker.

Please comment on any issues or nits.

Thanks
Sri

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 11:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Network-based Localized 
> Mobility Management Working Group of the IETF.
> 
> 
> 	Title           : Proxy Mobile IPv6
> 	Author(s)       : S. Gundavelli, et al.
> 	Filename        : draft-ietf-netlmm-proxymip6-04.txt
> 	Pages           : 57
> 	Date            : 2007-09-11
> 
> This specification describes a network-based mobility management
> protocol.  It is called Proxy Mobile IPv6 and is based on Mobile IPv6
> [RFC-3775].  This protocol enables mobility support to a host without
> requiring its participation in any mobility related signaling.  The
> design principle in the case of network-based mobility management
> protocol relies on the network being in control of the mobility
> management.  The mobility entities in the network are responsible for
> tracking the movements of the host and initiating the required
> mobility signaling on its behalf.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-netlmm-proxymip6-04.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-04.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-04.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: "Premec, Domagoj" <[email-masked]>
Date: Wed, 12 Sep 2007 14:28:53 +0200

Hi Sri,

A couple of comments...

section 5.3
>   o  The local mobility anchor MUST ignore the check, specified in
>      Section 10.3.1 [RFC-3775], related to the presence of Home Address
>      destination option in the Proxy Binding Update request.

For the sake of completness, the draft should also state that the MAG shall not add the Home address destination option to the PBU. Otherwise, the compliant MAG would still be free to put it into the PBU.

section 5.5.1
>     Implementations MAY choose to use static
>      tunnels as supposed to dynamically creating and tearing them down
>      on a need basis.

typo, s/as supposed/as opposed/

>6.3.  Supported Access Link Types
>
>   This specification supports only point-to-point access link types and
>   thus it assumes that the mobile node and the mobile access gateway
>   are the only two nodes on the access link.  The link is assumed to
>   have multicast capability.

I understand that the decision to use per-MN prefix model was motivated by the need to emulate the point-to-point link at the IP layer. As the IP layer is configured in such a way that there are exactly two nodes on the link, we're actually independet of the underlaying link layer technology. I think the intent of the spec is to support any access link type, including for example 802.11. The first sentence, claiming support only for point-to-point link types, is too restrictive. Maybe it could be reformulated to make it clear that point-to-point property is realized at the IP layer.

section 6.4
>   However,
>   the advertised flags with respect the address configuration will be

typo: add "to" between "respect" and "the address"

section 6.14
>   Upon obtaining the mobile node's profile after a successful access
>   authentication and after a policy consideration, the mobile access
>   gateway MUST determine if the network based mobility service should
>   be offered to that mobile node. 

This sounds like the MAG looks only at MN's profile and policy to determine the mobility mode of the MN. Looking at the MN's profile only is too restrictive, the user can change his terminal or update it with a MIP implementation and might prefere to use client based MIP. So I think the language hier should keep the door open for deciding about the MN's mobility mode in a more dynamic manner. The MAG could learn about the MN's capabilities and preferences through link-layer or some future enhancements at the IP layer. Would it be possible to add following sentence at the end of the cited paragraph:
"The MAG's decision can be influenced by the mobile node's MIP capabilities and preferences. The MAG may learn about the MN's capabilites and preferences through link-layer exchange or by some other means out of the scope of this specificaton."

section 7.3
>   [...] the newly learnt default-router
>   as supposed to the previously known default-router.

typo: s/as supposed/as opposed/

section 7.3
>   There are other solutions possible for this problem, including the
>   assignment of a unique link-local address for all the mobile access
>   gateways [...]

IMO "same link-local address" instead of "unique link-local address" would be more clear.

domagoj

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: 11. rujan 2007 08:44
> To: 'netlmm'
> Subject: FW: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.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.
> > 
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 12 Sep 2007 18:00:36 -0700

Hi Domagoj,

Thanks for reviewing the doc. Please see inline ..

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 5:29 AM
> To: Sri Gundavelli
> Cc: netlmm
> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt 
> 
> Hi Sri,
> 
> A couple of comments...
> 
> section 5.3
> For the sake of completness, the draft should also state that 
> the MAG shall not add the Home address destination option to 
> the PBU. Otherwise, the compliant MAG would still be free to 
> put it into the PBU.
> 
> section 5.5.1

Will rephrase it, if this is not clear.

> I understand that the decision to use per-MN prefix model was 
> motivated by the need to emulate the point-to-point link at 
> the IP layer. As the IP layer is configured in such a way 
> that there are exactly two nodes on the link, we're actually 
> independet of the underlaying link layer technology. I think 
> the intent of the spec is to support any access link type, 
> including for example 802.11. The first sentence, claiming 
> support only for point-to-point link types, is too 
> restrictive. Maybe it could be reformulated to make it clear 
> that point-to-point property is realized at the IP layer.
> 

Ok. This is a good comment. I see what you mean from the 802.11
point of view. We will rephrase this. If you can provide some
text that will be good.

> typo: add "to" between "respect" and "the address"

Ok

> This sounds like the MAG looks only at MN's profile and 
> policy to determine the mobility mode of the MN. Looking at 
> the MN's profile only is too restrictive, the user can change 
> his terminal or update it with a MIP implementation and might 
> prefere to use client based MIP. So I think the language hier 
> should keep the door open for deciding about the MN's 
> mobility mode in a more dynamic manner. The MAG could learn 
> about the MN's capabilities and preferences through 
> link-layer or some future enhancements at the IP layer. Would 
> it be possible to add following sentence at the end of the 
> cited paragraph:
> "The MAG's decision can be influenced by the mobile node's 
> MIP capabilities and preferences. The MAG may learn about the 
> MN's capabilites and preferences through link-layer exchange 
> or by some other means out of the scope of this specificaton."
> 

Fine.

> typo: s/as supposed/as opposed/

Will rephrase this, if its not clear.

> address" would be more clear.

ok.

Thanks
Sri

---

From: Julien Laganier <[email-masked]>
Date: Thu, 13 Sep 2007 10:10:48 +0200

Hi Domagoj,

I disagree with one of your comment below:

On Wednesday 12 September 2007, Premec, Domagoj wrote:
> >   This specification supports only point-to-point access link types
> > and thus it assumes that the mobile node and the mobile access
> > gateway are the only two nodes on the access link.  The link is
> > assumed to have multicast capability.
>
> motivated by the need to emulate the point-to-point link at the IP
> layer. 

Not true. 

Use of a per-MN prefix model has been motivated by the need to avoid 
multilink subnet issues [RFC4903].

Following that prefix model choice, we have discussed at length on that 
mailing list what are the implication of that model on the supported 
underlying link (i.e. below IP). The per-MN prefix on a pt-to-pt link 
has no issue. It is not clear however if it would work well on a shared 
link. The consensus of the WG has been that the current spec will be 
limited to support of pt-to-pt links.

Support for shared link can be added later in another specification.

> As the IP layer is configured in such a way that there are 
> exactly two nodes on the link, we're actually independet of the
> underlaying link layer technology. 

No configuration of the IP layer can restrict the number of nodes on a 
link. The link properties are independent from those of the IP layer.

> I think the intent of the spec is to support any access link type,
> including for example 802.11. 

I think the intent of the spec is to support only pt-to-pt links for now 
since that's the only type of link where the per-MN prefix model has no 
known issues.

> The first sentence, claiming support only for point-to-point link
> types, is too restrictive. 

That has been the consensus of the WG. You might disagree.

> Maybe it could be reformulated to make it clear that point-to-point
> property is realized at the IP layer. 

There's no way to realize a property of the link at the IP layer. A link 
is below IP...

Best,

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 13 Sep 2007 07:32:17 -0700

Hi Julien, 

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Thursday, September 13, 2007 1:11 AM
> To: [email-masked]
> Cc: Premec, Domagoj; Sri Gundavelli
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt
> 
> Hi Domagoj,
> 

May be I misunderstood what Domagoj comment. My point is that
we do allow access links such as 802.11, as long as the p2p
requirement is met from L3 perspective, implies, there are only
two nodes on the access link. A multicast RA sent by the MAG is
received just by one node, as long as the link meets this requirement
we are ok. 

Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 13 Sep 2007 17:48:52 +0200

Hi Julien, Sri,

Julien's interpretation of my comment is right, but I don't want to trigger the discussion about the link model type. I would be fine if following clarification sentence could be added to section 6.3 Supported Access Link Types:

"This protocol may be used also with other access link types, such as multi-access links, as long as the access link is configured in such a way that it guarantees a point-to-point delivery between the MAG and the MN for all types of traffic." 

Would that be acceptable?

domagoj

> Sent: 13. rujan 2007 16:32
> To: 'Julien Laganier'; [email-masked]
> Cc: Premec, Domagoj
> Behalf Of 
> > Julien Laganier
> > Following that prefix model choice, we have discussed at length on 
> > that mailing list what are the implication of that model on the 
> > supported underlying link (i.e. below IP). The per-MN prefix on a 
> > pt-to-pt link has no issue. It is not clear however if it 
> would work 
> > well on a shared link. The consensus of the WG has been that the 
> > current spec will be limited to support of pt-to-pt links.
> > 
> > > As the IP layer is configured in such a way that there 
> are exactly 
> > > two nodes on the link, we're actually independet of the 
> underlaying 
> > > link layer technology.
> > 
> > I think the intent of the spec is to support only pt-to-pt 
> links for 
> > now since that's the only type of link where the per-MN 
> prefix model 
> > has no known issues.
> > 
> 
> requirement is met from L3 perspective, implies, there are 
> only two nodes on the access link. A multicast RA sent by the 
> MAG is received just by one node, as long as the link meets 
> this requirement we are ok. 
> 
> Sri
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 13 Sep 2007 08:56:48 -0700

Hi Domagoj,

> Sent: Thursday, September 13, 2007 8:49 AM
> To: Sri Gundavelli; Julien Laganier
> Cc: [email-masked]
> Julien's interpretation of my comment is right, but I don't 
> want to trigger the discussion about the link model type. I 
> would be fine if following clarification sentence could be 
> added to section 6.3 Supported Access Link Types:
> 
> "This protocol may be used also with other access link types, 
> such as multi-access links, as long as the access link is 
> configured in such a way that it guarantees a point-to-point 
> delivery between the MAG and the MN for all types of traffic." 
> 

Exactly, this was my point.

> Would that be acceptable?

I'm ok with this. This still meets the P2P link model requirement
as agreed upon by the WG.

Sri

> > > Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-proxymip6-04.txt
> > > 
> > > Hi Domagoj,
> > >

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Sep 2007 13:40:03 +0200

Hi Sri,

On Thursday 13 September 2007, Sri Gundavelli wrote:
> > > >   This specification supports only point-to-point access
> >
> > link types
> >
> > > motivated by the need to emulate the point-to-point link at the
> > > IP layer.
> >
> > Not true.
> >
> > Use of a per-MN prefix model has been motivated by the need to
> > avoid multilink subnet issues [RFC4903].
> >
> > mailing list what are the implication of that model on the
> > pt-to-pt link has no issue. It is not clear however if it would
> > work well on a shared
> > link. The consensus of the WG has been that the current spec will
> > be limited to support of pt-to-pt links.
> >
> > > I think the intent of the spec is to support any access link
> > > type, including for example 802.11.
> >
> > links for now

That's fine with me.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 17 Sep 2007 13:40:38 +0200

Hi Domagoj,

On Thursday 13 September 2007, Premec, Domagoj wrote:
> Hi Julien, Sri,
>
> Julien's interpretation of my comment is right, but I don't want to
> trigger the discussion about the link model type. I would be fine if
> following clarification sentence could be added to section 6.3
> Supported Access Link Types:
>
> "This protocol may be used also with other access link types, such as
> multi-access links, as long as the access link is configured in such
> a way that it guarantees a point-to-point delivery between the MAG
> and the MN for all types of traffic."
>

That would be fine with me.

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 17:42:44 -0700

>> or by some other means out of the scope of this specificaton."

I don't like this new text. We seemed to have added an explicit 
reference to an exchange of mobile node capabilities and preferences. We 
also seemed to have added some text that says if the mobile node 
implements Mobile IPv6, PMIPv6 can be turned off. For the base PMIPv6 
document, it is assumed that we are providing network-based mobility for 
a mobile node without the mobile node being aware of PMIPv6 being used 
in the network.

We should move all this text to the PMIPv6 - MIPv6 interactions 
document. Scenario B and C in that document try to capture this.

Sri, can we please go back to the earlier text? The earlier text only 
said that the MAG should check if the mobile node is authorized for 
PMIPv6 before sending a proxy BU.

    Upon obtaining the mobile node's profile after a successful access
    authentication and after a policy consideration, the mobile access
    gateway MUST determine if the network based mobility service should
    be offered to that mobile node.  If the mobile node is entitled for
    such service, then the mobile access gateway must ensure the mobile
    node believes it is on its home link, as explained in various
    sections of this specification.

This check is needed anyway if the MAG sends a proxy BU on behalf of the 
mobile node.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 18 Sep 2007 18:48:08 -0700

Vijay,

> a mobile node without the mobile node being aware of PMIPv6 

We are not mandating any approach. Its just stating few possibilities,
that can be the basis for the MAG's decision. Capability exchange in
the ND messages is probably the most reasonable approach. The HA
service flags or the "R" flag in the Home Agent info Option ..all fall
in line with this approach. We are only listing possibilities and there
is no way the draft is recommending that approach.  I do know Domagoj
and others have drafts on this approach, but this is not endorsing that
approach, as there are other approaches as well. We can take this text
out if any one else also thinks, this text goes into a solution space.

Sri

---

From: "John.zhao" <[email-masked]>
Date: Wed, 19 Sep 2007 10:20:26 +0800

Hi,Sri and Vijay

	See my comments inline.
	Best Rgds,
Thanks,

John.zhao

> out if any one else also thinks, this text goes into a solution space.
[John.zhao] I support the new text. I also think this didn't mandating and
introducing any approach. Only leaving the detail or specify approach for
implementation or out of current scope, for example the DHCP or RD protocol.
And as a basis document, it should can compatible with those important
features. So in my opinion, the new version is better.

	My two cents.

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 19:21:51 -0700

That is not the point Sri. The text that has been added has a lot of 
implications. A capability exchange becomes relevant only when you talk 
about co-existence of PMIPv6 and MIPv6.

The problem is that we had some text earlier that said, the MAG may want 
to check if the MN is authorized for PMIPv6 service before sending a 
proxy BU. That text has been completely re-written to say that the MAG 
should provide PMIPv6 service only after figuring out MN capabilities. 
That is completely unacceptable.

Sri Gundavelli wrote:
> the ND messages is probably the most reasonable approach. 

That is irrelevant.

> The HA
> in line with this approach. 

We haven't even discussed that document.

Vijay

> We are only listing possibilities and there

---

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

John,

> features. So in my opinion, the new version is better.

It does not really matter, having that reference does not really
enable or disable that approach. So, no worries, it wont hurt
any of the drafts on this topic. We will review this carefully
to make sure, it does not change the basic assumptions on the
access link. If there are no implications, we will keep it, else
we will have some very simple text, as before. 

Thanks
Sri

---

From: "John.zhao" <[email-masked]>
Date: Wed, 19 Sep 2007 11:02:41 +0800

Hi, Sri

> John,

[John.zhao] 
> we will have some very simple text, as before.
[John.zhao] OK. I'm fine.

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 18 Sep 2007 22:46:11 -0500

Vijay,

I don't see a problem in indicating to the MN that the AR that it is
attached to is a MAG and PMIP6 capable.
This will allow the MN to determine which prefix to use sent in the RA.

I agree that the MAG need not check MN capability, but it makes sense to
provide AR capability information to the MN via the RA. This allows the MN
to decide which prefix to use (assuming the home prefix from the LMA and the
local prefix of the MAG are both included in the RA).

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 21:13:27 -0700

> local prefix of the MAG are both included in the RA).

We need to discuss this in more detail. I guess you are now talking 
about Scenario B in the PMIPv6 - MIPv6 interactions document. In 
scenario B, the MAG/AR announces only one prefix to the mobile node. If 
PMIPv6 is being used to provide mobility for the mobile node, the MAG 
advertises the PMIPv6 home network prefix. If MIPv6 is being used by the 
mobile node for mobility, the AR advertises a visited link prefix for 
the mobile node to configure a care-of address.

For the base PMIPv6 specification we have assumed that it is a regular 
IPv6 host that requires mobility management using PMIPv6. It has no 
capability to figure out which prefix to use as you described above.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 19 Sep 2007 00:51:19 -0500

Vijay,

> capability to figure out which prefix to use as you described above.

I-D draft-damic-netlmm-pmip6-ind-discover-01 proposes an extension to the
Router advertisements by which you can indicate to the MN which is the
prefix from an LMA and differentiate it from the local prefix. Given that
the router advertisments options are being extended by the IPv6 WG, this is
plausible and hence possible.

In the context of the base PMIP6 I-D, I agree that an MS has no way of
differentiating the prefixes contained in an RA.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Sep 2007 22:53:39 -0700

> differentiating the prefixes contained in an RA.

IMO, this topic belongs in the PMIPv6 - MIPv6 interactions document and 
not in the base PMIPv6 spec.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 19 Sep 2007 10:39:01 +0200

Hi Vijay,

> A capability exchange becomes relevant 
> only when you talk about co-existence of PMIPv6 and MIPv6.

The section "6.14.  Allowing network access to other IPv6 nodes", to which the text was added, talks about MAG acting also as a regular AR. Regular AR is used for both simple IP and CMIP so this section seems to be the right place for the added text.
 
> That text has been 
> completely re-written to say that the MAG should provide 
> PMIPv6 service only after figuring out MN capabilities. 

No, the new text says that the MAG _may_ take into account the MN's preferences and capabilites when making decision about the mobility mode. As Sri also points out, the added text does not go into solution space. 

I just wanted to have it explicitely stated that there may be other factors influencing the decision of the mobility mode besides the AAA profile. And that's what the added text does, nothing more. I don't see how this is harmful to the base spec.

domagoj

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 19. rujan 2007 04:22
> To: Sri Gundavelli
> Cc: Premec, Domagoj; 'netlmm'
> That is not the point Sri. The text that has been added has a 
> lot of implications. A capability exchange becomes relevant 
> only when you talk about co-existence of PMIPv6 and MIPv6.
> 
> The problem is that we had some text earlier that said, the 
> MAG may want to check if the MN is authorized for PMIPv6 
> service before sending a proxy BU. That text has been 
> completely re-written to say that the MAG should provide 
> PMIPv6 service only after figuring out MN capabilities. 
> > We are only listing possibilities and there is no way the draft is 
> > recommending that approach.  I do know Domagoj and others 
> have drafts 
> > on this approach, but this is not endorsing that approach, as there 
> > are other approaches as well. We can take this text out if any one 
> > else also thinks, this text goes into a solution space.
> > 
> > Sri
> > 
> > 
> >   
> 
>

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Wed, 19 Sep 2007 16:03:18 +0200

Hi Vijay, Raj,

while I can understand deployments where there's no interaction between network based and client based mobility, I don't think the PMIP6 base specification should ignore that these interactions exist
Maybe what would be appropriate is to add a reference to the interactions document

So, based on the previous text (as forwarded by Vijay), I would propose following modification:
"Upon obtaining the mobile node's profile after a successful access authentication and after a policy consideration, the mobile access gateway MUST determine if the network based mobility service should be offered to that mobile node. If the mobile node is entitled for such service, then the mobile access gateway should also address interactions with client based mobility solutions as described in REF-Interactions-DOC. If the outcome of these interactions is network based mobility, then the mobile access gateway must ensure the mobile node believes it is on its home link, as explained in various sections of this specification."

Regards

federico

-----Message d'origine-----
De : Vijay Devarapalli [mailto:[email-masked]] 
Envoyé : mercredi 19 septembre 2007 06:13
À : Basavaraj Patil
Cc : 'netlmm'
Objet : Re: [netlmm] I-D Action:draft-ietf-netlmm-proxymip6-04.txt

Basavaraj Patil wrote:
> I agree that the MAG need not check MN capability, but it makes sense 
> to provide AR capability information to the MN via the RA. This allows 
> the MN to decide which prefix to use (assuming the home prefix from 
> the LMA and the local prefix of the MAG are both included in the RA).

We need to discuss this in more detail. I guess you are now talking about Scenario B in the PMIPv6 - MIPv6 interactions document. In scenario B, the MAG/AR announces only one prefix to the mobile node. If
PMIPv6 is being used to provide mobility for the mobile node, the MAG advertises the PMIPv6 home network prefix. If MIPv6 is being used by the mobile node for mobility, the AR advertises a visited link prefix for the mobile node to configure a care-of address.

For the base PMIPv6 specification we have assumed that it is a regular
IPv6 host that requires mobility management using PMIPv6. It has no capability to figure out which prefix to use as you described above.

Vijay

>> implications. A capability exchange becomes relevant only when you 
>> talk about co-existence of PMIPv6 and MIPv6.
>>
>> The problem is that we had some text earlier that said, the MAG may 
>> want to check if the MN is authorized for PMIPv6 service before 
>> sending a proxy BU. That text has been completely re-written to say 
>> that the MAG should provide PMIPv6 service only after figuring out MN capabilities.
>>> We are not mandating any approach. Its just stating few 
>>> possibilities, that can be the basis for the MAG's decision. 
>>> Capability exchange in the ND messages is probably the most reasonable approach.
>> That is irrelevant.
>>
>>> The HA
>>> service flags or the "R" flag in the Home Agent info Option ..all 
>>> fall in line with this approach.
>>> recommending that approach.  I do know Domagoj and others have 
>>> drafts on this approach, but this is not endorsing that approach, as 
>>> there are other approaches as well. We can take this text out if any 
>>> one else also thinks, this text goes into a solution space.
>>>
>>> Sri
>>>
>>>
>>>   
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Sep 2007 07:34:37 -0700

Hi Federico,

This text may fit in the PMIPv6 - MIPv6 interactions document. Not in 
the base PMIPv6 document.

Vijay