Subject: [netlmm] Proposed text for LMA discovery

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 11:53:19 -0800

Hello folks,

Here is some text that can be added to the PMIPv6 base specification
on the subject of LMA discovery. The idea is to expand on the current
section 5.7.

We should delete the third paragraph in section 5.7. And then add
the following text to section 5.7.

   The mobile access gateway must discover the IP address of the local
   mobility anchor before it can send a Proxy Binding Update. There are
   multiple mechanisms available for the mobile access gateway to
   discover the local mobility anchor in a particular Proxy Mobile IPv6
   domain. The following describes some of the mechanisms for LMA
   discovery.

   o  Pre-configuration on the MAG - The MAG may be configured with the
      LMA information that it needs to use for a particular Proxy
      Mobile IPv6 domain .

   o  Policy profile of the mobile node - The LMA information is stored
      in the policy profile of the mobile node. The mobile node policy
      profile is obtained by the MAG when the mobile node attaches to
      the MAG.

   o  DNS discovery - The MAG may perform a DNS lookup for the LMA as
      described in [RFC 5026]. The mechanism by which the MAG obtains
      the LMA FQDN is out of scope of this document.

      The use of DNS SRV records for home agent discovery [RFC 5026]
      is not required for Proxy Mobile IPv6, since it is unlikely that
      the MAG needs to first check if Proxy Mobile IPv6 service is
      offered in the Proxy Mobile IPv6 domain it is present in.

   o  Integrated scenario bootstrapping - The MAG obtains the LMA
      information during mobile node access authentication as described
      in [I-D.ietf-mip6-bootstrapping-integrated-dhc]. The MAG assumes
      the role of NAS as described in section 4.1 of
      [I-D.ietf-mip6-bootstrapping-integrated-dhc]

Comments?

Vijay

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

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 18 Dec 2007 14:32:08 +0100

Vijay,

>       offered in the Proxy Mobile IPv6 domain it is present in.

I think DNS SRV mechanism could be useful. In roaming scenarios single MAG may connect to many LMAs from different administrative domains. A MAG may construct a DNS SRV query using the domain part of the MN's NAI (i.e [email-masked] -> _mip6._ipv6.example.com) and thus learn the LMA address in a dynamic manner. There would be no need to preconfigure the MAG with FQDNs of all the LMAs. Does it make sense?

domagoj

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 17. prosinac 2007 20:53
> To: Netlmm
> Subject: [netlmm] Proposed text for LMA discovery
> 
> Hello folks,
> 
> Here is some text that can be added to the PMIPv6 base 
> specification on the subject of LMA discovery. The idea is to 
> expand on the current section 5.7.
> 
> We should delete the third paragraph in section 5.7. And then 
> add the following text to section 5.7.
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Dec 2007 10:50:48 -0800

Premec, Domagoj wrote:
> I think DNS SRV mechanism could be useful. In roaming scenarios single MAG may connect to many LMAs from different administrative domains. 

We are not supposed to talk about roaming scenarios. NETLMM is a
local mobility management protocol. :)

> A MAG may construct a DNS SRV query using the domain part of the MN's NAI (i.e [email-masked] -> _mip6._ipv6.example.com) and thus learn the LMA address in a dynamic manner. There would be no need to preconfigure the MAG with FQDNs of all the LMAs. Does it make sense?

Sure, it can be used. I would be fine with removing the above
paragraph if some one has a use for DNS SRV records for LMA
discovery.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 18 Dec 2007 22:44:49 -0800

Hello,

If there are no issues with the text below, I suggest we add this to
section 5.7. The only change in the text below would be to remove the
paragraph on DNS SRV records.

If anyone has concerns with the text below, please let us know.

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 19 Dec 2007 10:47:52 +0100

Vijay,

> We are not supposed to talk about roaming scenarios. NETLMM 
> is a local mobility management protocol. :)

hmm... given the definition of PMIP6 domain in the current draft, there is no constraint on PMIP6 to be used only for local mobility management. The only requirement is that MAG and LMA can establish a SA. 

domagoj

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: 18. prosinac 2007 19:51
> To: Premec, Domagoj
> Cc: Netlmm
> Subject: Re: [netlmm] Proposed text for LMA discovery
> 
> Premec, Domagoj wrote:
> > Vijay,
> > 
> > I think DNS SRV mechanism could be useful. In roaming 
> scenarios single MAG may connect to many LMAs from different 
> administrative domains. 
> 
> We are not supposed to talk about roaming scenarios. NETLMM 
> is a local mobility management protocol. :)
> 
> > A MAG may construct a DNS SRV query using the domain part 
> of the MN's NAI (i.e [email-masked] -> 
> _mip6._ipv6.example.com) and thus learn the LMA address in a 
> dynamic manner. There would be no need to preconfigure the 
> MAG with FQDNs of all the LMAs. Does it make sense?
> 
> paragraph if some one has a use for DNS SRV records for LMA discovery.
> 
> Vijay
> 
> 
> > 
> > domagoj
> > 
> specification 
> >> We should delete the third paragraph in section 5.7. And 
> then add the 
> >> following text to section 5.7.
> >>
> >>    o  Pre-configuration on the MAG - The MAG may be 
> configured with 
> >> the

---

From: Frank Xia <[email-masked]>
Date: Wed, 19 Dec 2007 12:22:42 -0600

Hi Vijay

IMHO,It is not proper to expand section 5.7.

Firstly,  it is about bootstraping which is better to 
deal with in other documents  other than in the basic protocol.
I think it is better that 5.7 keeps the same granularity as section 
5.8 ( Mobile Prefix Discovery Considerations), section
5.9(Route Optimizations Considerations)

Secondly,  I have some inline comments as to the technical proposal...

BR
Frank
----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Netlmm" <[email-masked]>
Sent: Monday, December 17, 2007 1:53 PM
Subject: [netlmm] Proposed text for LMA discovery

>       the LMA FQDN is out of scope of this document.
Frank=>Just I said before,  MN performs DNS lookup because MN is
a host in which DNS lookup is the basic function.  MAG is a router which
is different from a host.  In fact, I can't find DNS lookup funtion in WiMAX
ASN-GW.  Anyway, I am open to discuss with this issue.

>       [I-D.ietf-mip6-bootstrapping-integrated-dhc]
Frank=>From implementaion perspective, MAG should be act as a DHCP client.
The behavior of the MAG should be detailed.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2007 10:34:45 -0800

> IMHO,It is not proper to expand section 5.7.

What do you mean by it is not proper? Section 5.7 is about LMA
discovery. The text that is being proposed completes the section.

> ASN-GW.  Anyway, I am open to discuss with this issue.

Of course routers can do DNS lookup. Anyway, MAG is a PMIPv6
function and its behavior is documented in the base PMIPv6
specification.

> The behavior of the MAG should be detailed.

In draft-ietf-mip6-boostrapping-integrated-dhc, the home agent
information is delivered to the mobile node. In Proxy MIPv6,
the LMA information need not be sent to the mobile node. So
there is no need to use the DHCP functionality as specified in
draft-ietf-mip6-boostrapping-integrated-dhc between the mobile
node and the MAG. The only requirement is for the MAG to
implement the NAS functionality (RADIUS or Diameter client) to
obtain the LMA information from the AAA.

Hope that clarifies.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Wed, 19 Dec 2007 13:09:07 -0600

Hi Vijay

I just copied  my main points from my previous email.

" it is about bootstraping which is better to 
deal with in other documents  other than in the basic protocol.
I think it is better that 5.7 keeps the same granularity as section 
5.8 ( Mobile Prefix Discovery Considerations), section
5.9(Route Optimizations Considerations)"

Please refer to other inline replies...

BR
Frank
----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Netlmm" <[email-masked]>
Sent: Wednesday, December 19, 2007 12:34 PM
Subject: Re: [netlmm] Proposed text for LMA discovery

> function and its behavior is documented in the base PMIPv6
Frank=>I know router can do.  What I wonder is if  it is a feasible solution.
Anyway, DNS  lookup is not built-in function of PMIPv6, while it is 
an external service provided for PMIPv6

> obtain the LMA information from the AAA.
Frank=>I don't agree with this solution because it does not support
dynamic LMA discovery using DHCP protocol.
 In fact, I support applying draft-ietf-mip6-boostrapping-integrated-dhc to 
PMIPv6 scenario, but I don't think the section is the right place to detail.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Dec 2007 11:32:26 -0800

I am not in favor of adding any text about LMA discovery after WGLC.
This has been always considered out of scope from the beginning of this
work and it does not make any sense to add a new functionality at this
moment. This would definitely delay the publication of the base
specification as shown by the number of mails on this about the proposed
text...and note that this time it was not me who raised the issues :-)

I think however this is a work we need to do as it is important for the
deployment of the protocol and we should consider it as one of the main
rechartering items.

>From a technical perspective, I think there are some questions we should
answer before jumping to the conclusion that any MIPv6 bootstrapping
solution is used also for PMIPv6:

- how the handover case impacts the LMA discovery? Should we have
different mechanisms for initial LMA discovery and LMA discovery at the
handover time?

- for MIPv6 we defined two solutions, split scenario and integrated
scenario. Does the split scenario make sense for PMIPv6? And the
integrated?  Are both solutions applicable and needed also to the PMIPv6
case? 

Thanks
Gerardo

> Sent: Monday, December 17, 2007 11:53 AM
> To: Netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2007 11:43:44 -0800

> deal with in other documents  other than in the basic protocol.

Frank, I know your preference is to have a separate document
on this. It was clear in your first email itself.

But IMO, there isn't much here for a separate document. LMA
discovery based on DNS lookup and the integrated scenario
(assigned by the AAA or some other entity) is quite
straight forward. It does not require any additional
specification, just references to existing MIPv6 bootstrapping
documents. This is what the text I sent does.

> 5.9(Route Optimizations Considerations)"

5.8 says Mobile Prefix discovery is not used for PMIPv6. 5.9
says route optimization is out of scope.

> an external service provided for PMIPv6

Frank, it is a non-issue.

> dynamic LMA discovery using DHCP protocol.

If you want to support "dynamic LMA discovery using DHCP" you need to
write a separate document on this. When the integrated scenario is
applied to PMIPv6, it means that the LMA information is delivered to
the MAG (the NAS) when the mobile node attaches to it. In the MIPv6
integrated scenario bootstrapping DHCP is used to deliver the
information to the mobile node. Since we don't need to deliver the
LMA information to the mobile node, DHCP need not be used.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Wed, 19 Dec 2007 13:52:12 -0600

Hi Gerardo

See my inline comments..

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Netlmm" <[email-masked]>
Sent: Wednesday, December 19, 2007 1:32 PM
Subject: RE: [netlmm] Proposed text for LMA discovery

Frank=> I agree.

answer before jumping to the conclusion that any MIPv6 bootstrapping
solution is used also for PMIPv6:
Frank=>I don't agree that  any MIPv6 bootstrapping is applicable for PMIPv6.

- how the handover case impacts the LMA discovery? Should we have
different mechanisms for initial LMA discovery and LMA discovery at the
handover time?
Frank=>In handover, there is possible that MAG does not interact with AAA server,
so it is different from initial  LMA discovery.
I think LMA information can be transfered between PMAG and NMAG during 
handover.

- for MIPv6 we defined two solutions, split scenario and integrated
scenario. Does the split scenario make sense for PMIPv6? And the
integrated?  Are both solutions applicable and needed also to the PMIPv6
case? 
Frank=>It is similar to integrated one.  But I recommend that we should
not use the concept which is confusing in PMIPv6 scenario.

Thanks
Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2007 11:49:08 -0800

Giaretta, Gerardo wrote:
> moment. 

I consider LMA discovery to be a basic function of PMIPv6.

> This would definitely delay the publication of the base

Only from Frank so far. I believe those have been addressed.
Let me know if you have any technical issues. :)

> different mechanisms for initial LMA discovery and LMA discovery at the

We discussed this before. The LMA discovery is done during the
initial attach. After that the LMA address is available in the
MN policy profile. No need to perform LMA discovery during a
handover. This is kind of already described in the base PMIPv6
specification. Which part of this is not clear?

> integrated?  Are both solutions applicable and needed also to the PMIPv6

Yes, they are both applicable. In fact I know that the 3GPP
specifications that use PMIPv6 use both DNS discovery and
delivery of the LMA information to the MAG during access
authentication. I don't see any reason to prohibit either of
them.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Dec 2007 14:14:55 -0600

> This has been always considered out of scope from the 
> beginning of this work and it does not make any sense to add 
> a new functionality at this moment. This would definitely 
> delay the publication of the base specification as shown by 
> the number of mails on this about the proposed text...and 
> note that this time it was not me who raised the issues :-)

[Ahmad]
Yes. I agree with Gerardo!
This is a new functionality and should be kept out of the base PMIPv6
protocol. We also have agreed and achieved consensus on this long time
ago and it odes not make sense to delay this document by initiating this
new discussion at this point of the document publication.

I believe we need to give Sri sometime to publish the new revision 08 in
order for this document to proceed forward for publication.

Best Regards,
Ahmad

> 
> I think however this is a work we need to do as it is 
> important for the deployment of the protocol and we should 
> consider it as one of the main rechartering items.
> 
> answer before jumping to the conclusion that any MIPv6 
> bootstrapping solution is used also for PMIPv6:
> 
> - how the handover case impacts the LMA discovery? Should we 
> have different mechanisms for initial LMA discovery and LMA 
> discovery at the handover time?
> 
> - for MIPv6 we defined two solutions, split scenario and 
> integrated scenario. Does the split scenario make sense for 
> PMIPv6? And the integrated?  Are both solutions applicable 
> and needed also to the PMIPv6 case? 
> 
> Thanks
> Gerardo
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 19 Dec 2007 13:18:33 -0800

Hi Vijay,

Last email from my side on this topic.

> Sent: Wednesday, December 19, 2007 11:49 AM
> To: Giaretta, Gerardo
> Cc: Netlmm

This was not the WG idea when the charter was done. And it seems it is
not now.

> Let me know if you have any technical issues. :)

There is a list of unanswered questions below.

> MN policy profile. 

This is nonsense (as you usually say :-)

The LMA discovery is a way to populate the MN policy profile in the MAG.
In PMIPv6 the nMAG may not even know if the MN is performing a handover
or an initial attach; therefore the LMA discovery happens both at the
initial attach and at the handover. 

> No need to perform LMA discovery during a

See above. The discovery must be defined so that different MAG can
discover the same LMA. The input information for this discovery must
also be defined

> authentication. I don't see any reason to prohibit either of

Split scenario is not defined as a scenario where DNS discovery is
possible. Split scenario is defined as the scenario where ASA and MSA
are different. Can be ASA and MSA different in a PMIPv6 approach? 

Also the integrated scenario solution is based on DHCPv6. You are
proposing that the MAG just receives the LMA address from the AAA and
DHCPv6 is not involved at all. This is clearly a different solution from
the integrated scenario solution. 

I think this email shows quite clearly that there are issues we cannot
solve after the WGLC (unless you are proposing to delay the publication
of the protocol which would be at least unpopular :-)

Gerardo

specification

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 19 Dec 2007 14:09:16 -0800 (PST)

> new discussion at this point of the document publication.

I agree.

Vijay: I suggest, we go with the text what we have. The spec
says, how the MAG obtains the LMAA or other operational
params is out of scope. Now, if the current boot strapping solution
can be applied as it is and with out a need for a new document,
or we need a new specification is a different debate. I see your
point that this is just some clarification text, but since we passed
the LC, I think we should not try to add more text here and loose
the time.

Thanks every one for the input on this. If all agree, we will close
this issue.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 19 Dec 2007 14:38:28 -0800

> Last email from my side on this topic.

I would be disappointed if you don't continue the technical
discussion.

> This was not the WG idea when the charter was done. And it seems it is

The NETLMM WG charter was written with the assumption that the
base NETLMM protocol (before PMIPv6) can be done within a year
with the extensions to follow soon after. Its been almost three
years since the charter was written. Using this as an argument
is pretty lame. IMO, the charter should have been updated when
it was decided to pursue PMIPv6 in the NETLMM WG.

> This is nonsense (as you usually say :-)

It works.

> initial attach and at the handover. 

Wrong. My understanding is that MN policy profile is populated
once with the LMA address when the mobile node first attaches
to the PMIPv6 domain and from then on used by every MAG. By LMA
discovery I am talking about the first time the mobile node
attaches to the PMIPv6 domain, not after every handover.

> are different. Can be ASA and MSA different in a PMIPv6 approach? 

I didn't mention split scenario anywhere. The DNS based discovery
can be used both for split and integrated scenario.

> Also the integrated scenario solution is based on DHCPv6. 

Wrong. DHCPv6 is used to deliver the HA information to the mobile
node. The essential part of the integrated scenario is that the
access router obtains the home agent information from the MSP when
the mobile node attaches it. We are re-using that part. Not DHCPv6
since there is nothing to deliver to the mobile node.

> You are

It is easy to bring up issues that look like the ones that delay
the document. It is very unfortunate, when we already have the
solution for LMA discovery.

Vijay

---

From: <[email-masked]>
Date: Thu, 20 Dec 2007 07:44:28 +0100

> > ago and it odes not make sense to delay this document by initiating 
> > this new discussion at this point of the document publication.
> >
> 
> I agree.

I agree on here too.

Jouni

> params is out of scope. Now, if the current boot strapping 
> solution can be applied as it is and with out a need for a 
> new document, or we need a new specification is a different 
> debate. I see your point that this is just some clarification 
> text, but since we passed the LC, I think we should not try 
> to add more text here and loose the time.
> 
> Thanks every one for the input on this. If all agree, we will 
> close this issue.
> 
> Regards
> Sri
> 
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Dec 2007 13:04:46 +0100

On Wednesday 19 December 2007, Vijay Devarapalli wrote:
> Giaretta, Gerardo wrote:
> > I am not in favor of adding any text about LMA discovery after
> > WGLC. This has been always considered out of scope from the
> > beginning of this work and it does not make any sense to add a new
> > functionality at this moment.
>

The fact that a supposedly *basic* function of a protocol has to be 
added to that protocol spec *after* it completed WGLC speaks volume 
about how basic that function is, IMHO.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 20 Dec 2007 13:05:55 +0100

Vijay Devarapalli wrote:
> > This was not the WG idea when the charter was done. And it seems it
> > is not now.
>

Relevance of our charter is irrelevant to that discussion I think. It 
might well be that we should have updated our charter, or not. That is 
is also irrelevant to that discussion. 

Bottom line is, we do have a charter and we should abide by it. We can 
of course discuss about updating it. Until then...

--julien

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Dec 2007 07:49:00 -0800

> about how basic that function is, IMHO.

Actually I was under the impression LMA discovery is already explained
in sufficient detail in the base spec, until recently when Sri and
Gerardo told me it is not. :)

Vijay