Subject: [netlmm] Consensus call: Adopting draft-korhonen-netlmm-lma-discovery as a WG item

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Apr 2009 17:10:15 -0700

Hi,
This is a consensus call to determine adoption of draft-korhonen-netlmm-lma-discovery as a WG item.  This relates to the LMA discovery work in our charter.  

Please respond on whether or not you support adoption of this draft as a WG item to the list by May 6th, 2009. Please note that this document would be a starting point for the work, if adopted and the current content in the draft is by no means final. 

Thanks,
Vidya

---

From: Frank Xia <[email-masked]>
Date: Tue, 28 Apr 2009 20:21:54 -0500

Hi Vidya

I would also like to ask WG to accept our
draft http://tools.ietf.org/id/draft-xia-netlmm-lma-discovery-00.txt
which introduces LMA discovery using DHCP.

The logic is simple:
1)In some cases, LMA/HA availablity information is populated in an DHCP 
server.
   (http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt is used for a 
mobile
    node to fetch HA information from the DHCP server in Mobile IPv6)
2) MAG SHOULD be able to retrieve LMA information from the DHCP server.

BR
Frank

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, April 28, 2009 7:10 PM
Subject: [netlmm] Consensus call: Adopting 
draft-korhonen-netlmm-lma-discovery as a WG item

> Hi,
> This is a consensus call to determine adoption of 
> draft-korhonen-netlmm-lma-discovery as a WG item.  This relates to the LMA 
> discovery work in our charter.
>
> Please respond on whether or not you support adoption of this draft as a 
> WG item to the list by May 6th, 2009. Please note that this document would 
> be a starting point for the work, if adopted and the current content in 
> the draft is by no means final.
>
> Thanks,
> Vidya
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 28 Apr 2009 23:04:19 -0700

Hi Frank,

We have discussed this in the past and ruled out MAG being a DHCP client.
The MAG does not use DHCP to configure itself or obtain LMA information. It
is either a DHCP relay or a DHCP server as described in RFC 5213 and the
IPv4 support document.

Vijay

---

From: Frank Xia <[email-masked]>
Date: Wed, 29 Apr 2009 09:19:18 -0500

Hi Vijay

You NOT ME ruled out MAG being a DHCP client.

I believe it is necessary because we should solve
the necessary scenario I described in my last email.

Why not listening other guys' opinion?
I think we had enough discussion.

BR
Frank

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 29, 2009 1:04 AM
Subject: Re: [netlmm] Consensus call: Adopting 
draft-korhonen-netlmm-lma-discovery as a WG item

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 12:40:03 -0700 (PDT)

Just a clarification question on the scope of the work and
the problem statement. Not about any specific draft or
approach.

1. In RFC-5213, we require the MAG to have the shared security
    association with the LMA's that it would interact with. So,
    every MAG has a configured list of LMA's and a shared security
    association. Similarly, the LMA's are configured with the list
    of MAG's as an authorization policy.
    So, every MAG already has the list of pre-configured LMA's with
    out a need for dynamic dsicovery.

2. Lets say, the MAG has no such list of LMA's or the configured
    SA's, but it can get it from AAA, one can argue. If so, why cant
    the MAG obtain the same LMA information using the same AAA
    interface and on a per-Mobile basis. Why its more than an other
    AAA attribute.

3. In RFC-5213, the MN policy profile has the configured LMA address.
    Why this one parameter needs to be discovered dynamically ?

4. Is there a overlap of this with the scope of the other AAA interface
    documents ?

5. How does this dynamic discovery ensure the LMA assignment is
    predicable at any MAG, to avoid two different MAG's ending up at
    two different LMA's for a multihomed mobile node. How does any
    of discovery mechanisms maintain this stickiness, other than a
    mobile node's policy profile locally or in a AAA store. If so,
    its all in AAA or in policy store.

6. Is this required in WiMAX, 3GPP2 or 3GPP ? Just to be understand
    the usage scope.

I'm trying to understand where the gap is and I'm aware its in
the charter.

Regards
Sri

---

From: Frank Xia <[email-masked]>
Date: Wed, 29 Apr 2009 15:24:44 -0500

Hi Sri

Let me try to answer some of your questions...

BR
Frank
----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 29, 2009 2:40 PM
Subject: Re: [netlmm] Consensus call: Adopting 

>    out a need for dynamic dsicovery.
Frank=>Yes.  Pragmatically, we shouldn't rule out
manual configuration.  It is better to mention it even
though the charter is about automatic LMA discovery.

>    interface and on a per-Mobile basis. Why its more than an other
Frank=>AFAIK, there isn't  no other AAA attribute.

>    Why this one parameter needs to be discovered dynamically ?
Frank=>In some cases, HAAA has no any idea for choosing
a LMA for the mobile node.  Probably, VAAA needs to assign
one for the mobile node.  Also probably, these information is
populated in a DHCP server such as
http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt

> 4. Is there a overlap of this with the scope of the other AAA interface
Frank=>a lit bit overlap.  However, this WG item focuses
on the scenario that MAG can't directly get  LMA address
from AAA servers.

>    its all in AAA or in policy store.
Frank=>As long as the LMA information is centralized,
it is easy to achieve the stickiness.  The LMA information could
be managed in a central AAA/ DNS /DHCP server.

> 6. Is this required in WiMAX, 3GPP2 or 3GPP ? Just to be understand
Frank=>In 3GPP 23.402 ,   PDN GW( HA/LMA)
selection is discussed.

> I'm trying to understand where the gap is and I'm aware its in
Frank=>Hopefully, my answer is helpful.

>> draft-korhonen-netlmm-lma-discovery as a WG item.  This relates to the 
>> LMA discovery work in our charter.
>>
>> WG item to the list by May 6th, 2009. Please note that this document 
>> would be a starting point for the work, if adopted and the current 
>> content in the draft is by no means final.
>>
>> Thanks,
>> Vidya

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 29 Apr 2009 13:38:10 -0700

Hi Vidya and Vijay

draft-korhonen does not provide any protocol extensions (that's why  
this document is aiming informational).
Most of parts in this document are too obvious, but it is useful to  
summarize these stuff in this simple doc :-)
I am fine to make this document as a WG item.

Some comments  to draft-korhonen

- In RFC5213, it said LMA address must be stored in policy profile  
(Section 6.2).
After the initial acquisition of LMA address, can the new MAG get the   
address from the policy profile?
This document uses the term of remote policy profile (section2.2) and  
local database (section 3.1), but what is the relationship
with the policy profile defined in RFC5213?
For instance, MAG use AAA to get LMA's IP address. Do you assume that  
AAA manages the part of policy profile?
It might help to clarify the relationship between policy profile and  
AAA, L2 things, etc.

- The treatment of DNS caching is general one. I am not sure we need  
this in this document. There are no PMIP specific things here.

I also read draft-xia-netlmm-lma-discovery-00.
DHCP can be alternative approach to discovery LMA address.
However AAA or L2 solutions seems to be much straightforward and light- 
weight approach.
Are their any strong reasons to use DHCP for this specific function  
(LMA discovery)?

  comments to Frank's document
- In IPv4 support doc, we also uses DHCP for IPv4 address assignment.
To design the DHCP parts, we tried not to introduces any PMIP specific  
states or data at the DHCP entity.
DHCP-server just notify the IPv4 address to the DHCP client. The IPv4  
address is always assigned by LMA.
On the other hand, this document assumes DHCP server manages all the  
PMIP states such as LMA and home network prefix.
We might need some interaction between PMIP and DHCP to keep protocol  
states consistency.
- This document assumes one DHCP server per PMIP domain, because DHCP  
relay has to be configured with the same DHCP server address.
Is this reasonable assumption in terms of scalability and optimized  
management , etc. ?

regards,
ryuji

On 2009/04/28, at 17:10, Narayanan, Vidya wrote:

> Hi,
> This is a consensus call to determine adoption of draft-korhonen- 
> netlmm-lma-discovery as a WG item.  This relates to the LMA  
> Please respond on whether or not you support adoption of this draft  
> as a WG item to the list by May 6th, 2009. Please note that this  
> document would be a starting point for the work, if adopted and the  
> current content in the draft is by no means final.
>
> Thanks,
> Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Apr 2009 13:43:28 -0700

Hi Sri,

When RFC 5213 was being standardized, we left out the details on how LMA
discovery can be done automatically. For example, using DNS for discovering
the LMA was not captured in RFC 5213. To my knowledge, this is the most
widely used technique for LMA discovery. It is not always possible to
configure the LMA that needs to be used in the mobile node's policy profile.
In some cases, the LMA information does not come from the policy profile. It
would correspond to the "service name" (or the APN), that the mobile node is
trying to access.

We also did not address a critical issue on how the same LMA is discovered
by the new MAG after a handover if there is more than one LMA in the PMIPv6
domain.

We wanted to add this stuff to RFC 5213, but the WG considered it to be out
of scope and decided to work on this separately. The scope for this charter
item was presented in the Dublin IETF. See
http://www.ietf.org/proceedings/08jul/slides/netlmm-7.pdf.

Vijay

On 4/29/09 12:40 PM, "Sri Gundavelli" wrote:

>> Please respond on whether or not you support adoption of this draft as a WG
>> item to the list by May 6th, 2009. Please note that this document would be a
>> starting point for the work, if adopted and the current content in the draft
>> is by no means final.
>> 
>> Thanks,
>> Vidya

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 14:02:02 -0700 (PDT)

Hi Frank,

On Wed, 29 Apr 2009, Frank Xia wrote:

> ----- Original Message ----- From: "Sri Gundavelli" <[email-masked]>

The issue is we required the LMA to have MAG authorization policy,
and the configured SA's between MAG and LMA, some how this is
resulting in a static configuration, which I'm not able to see
how it can be avoided, even if avoided, its requring the MAG
making AAA calls.

> Frank=>AFAIK, there isn't  no other AAA attribute.

I think, this should there on a per user basis. We should add it
either way.

> http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt

Ok

> on the scenario that MAG can't directly get  LMA address

Just this one param ?

> be managed in a central AAA/ DNS /DHCP server.

Sure. AAA or local policy cant be avoided, it seems.

> Frank=>In 3GPP 23.402 ,   PDN GW( HA/LMA)

Ok

> Frank=>Hopefully, my answer is helpful.

This requirement needs to be clear. Its bit ambigous. This needs
to be scoped properly.

Thanks
Sri

---

From: Frank Xia <[email-masked]>
Date: Wed, 29 Apr 2009 16:02:45 -0500

Hi Ruji

Thank for your review, please check my inline reply...

BR
Frank

----- Original Message ----- 
From: "Ryuji Wakikawa" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, April 29, 2009 3:38 PM
Subject: Re: [netlmm] Consensus call: 
Adoptingdraft-korhonen-netlmm-lma-discovery as a WG item

> Hi Vidya and Vijay
>
> draft-korhonen does not provide any protocol extensions (that's why  this 
> document is aiming informational).
> For instance, MAG use AAA to get LMA's IP address. Do you assume that  AAA 
> manages the part of policy profile?
> It might help to clarify the relationship between policy profile and  AAA, 
> L2 things, etc.
>
> - The treatment of DNS caching is general one. I am not sure we need  this 
> in this document. There are no PMIP specific things here.
>
>
> Are their any strong reasons to use DHCP for this specific function  (LMA 
> discovery)?
Frank=>See if  the follwoing is reasonable:
1)In most cases, e.g 3GPP/WiMAX,  LMA/HA are collocated
2)In some cases, LMA/HA availablity information is stored in an DHCP
server.
3)http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt is used for a
mobile node to fetch HA information from the DHCP server in Mobile IPv6
4)So,  MAG should also be able to retrieve LMA information from the DHCP 
server.

> states or data at the DHCP entity.
Frank=>Probably, we should only focus LMA discovery. We will
delete IPv4 address assignment part.

> On the other hand, this document assumes DHCP server manages all the  PMIP 
> states such as LMA and home network prefix.
Frank=>This document only deal with the scenario that  DHCP servers
manage LMA information.  Just I mentioned before, there are also
many other scenarios.  Just Ted mentioned before, it is possible that
there is some interaction between PMIP(or AAA) and DHCP, however,
it is out the scope of  the document.

> Is this reasonable assumption in terms of scalability and optimized 
Frank=>I think it has the same scalability as AAA servers.

>> netlmm-lma-discovery as a WG item.  This relates to the LMA  discovery 
>> work in our charter.
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 14:04:27 -0700 (PDT)

Hi Vijay,

I know we discussed this and you also thought nothing else needs
to be specified, I remember that thread.

I think, specyfing one or more approaches of a service discovery
is generally ok, here we have a tight LMA/MAG coupling, which I'm
not sure, how it can be decoupled and link it through a service
discovery.

We need to scope this work, also in the context of radius/diameter
overlap.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Apr 2009 14:10:11 -0700

Hi Sri,

> not sure, how it can be decoupled and link it through a service

What do you mean by "tight MAG/LMA coupling"? LMA discovery based on the
service that the MN wants to access is not the same as "service discovery".
FWIW, folks who want to use PMIPv6 do have scenarios where the LMA that is
used for a particular mobility session is determined by the service the MN
wants to access. I am sure you already aware of this.
 
> We need to scope this work, also in the context of radius/diameter

There is no issue here. draft-korhonen-netlmm-lma-discovery describes how
the MAG obtains the LMA information from the AAA during access
authentication. The corresponding RADIUS and Diameter drafts go into more
detail including specifying the RADIUS attributes and Diameter AVPs.

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 14:18:56 -0700 (PDT)

Hi Vijay,

> wants to access. I am sure you already aware of this.

My question is, if the MAG's are not configured with the list of LMA's
and have no configured SA's, how does the security relation be built.
I've no problem making a DNS query, DHAAD, or DHCP query to find a
LMA, thats all fine. Finally, we require a SA setup, the LMA needs to
have the MAG in its authorization policy along with the SA's. I'm saying,
its the later part which is forcing a static LMA/MAG config binding or
going to a AAA store, which already has a per user MN profile.

I'm not able to see how the MAG can build the SA, or the LMA have the
MAG in authorized list, without hitting the AAA. You cant ignore this.
The problem statement has to be in relation to this assumption.

> detail including specifying the RADIUS attributes and Diameter AVPs.

I'm not talking about the solutions. Lets keep the drafts aside for the
problem scoping efforts. We can discovery the LMA using a DNS query,
those methods are fine.

Sri

---

From: Frank Xia <[email-masked]>
Date: Wed, 29 Apr 2009 16:24:01 -0500

Hi Sri

Please have a quick check my inline response.

BR
Frank

----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Frank Xia" <[email-masked]>
Cc: "Narayanan, Vidya" <[email-masked]>; <[email-masked]>
Sent: Wednesday, April 29, 2009 4:02 PM
Subject: Re: [netlmm] Consensus call: Adopting 

> how it can be avoided, even if avoided, its requring the MAG
Frank=>AFAIF, WiMAX introduces  authentication option to secure
MAG/LMA signalling.  Authentication option is per  mobile node basis.

>> on the scenario that MAG can't directly get  LMA address
Frank=>In theory, some other params are possible, such as,
home network prefix, FQDN and so on.
However, it seems to go too far.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 14:47:20 -0700 (PDT)

Hi Vijay,

On Wed, 29 Apr 2009, Vijay Devarapalli wrote:

> The MAG would use IKEv2 or any other key negotiation protocol to setup the 
> IPsec SA. Even if you do assume that the MAG has pre-configured security 
> associations with a bunch of LMAs, it would still be useful to determine 
> which LMA to use dynamically when the mobile node attaches to the MAG.
>

Sure. So, there is a shared security relation with some authorization
policy between the nodes, that cant be avoided. Once thats there, you can
certainly use IKEv2 for SA set up.

>>  have the MAG in its authorization policy along with the SA's. 
>
> In case you are referring to the IPsec PAD entries, the MAG can have a PAD 
> entry with a wild card, something like, _lma*.example.com. This would 
> authorize all the LMAs in the PMIPv6 domain example.com. If you have roaming 
> relationship with a bunch of domains, then you can have _lma*.example1.com, 
> _lma*.example2.com, etc...
>

What is that wild card security ? One one hand we require LMA to have
list of MAG's authorized to send proxy binding updates and here we
authorize every node to decouple that static binding ? :)

Sri

---

From: jouni <[email-masked]>
Date: Thu, 30 Apr 2009 01:13:16 +0300

Hi Ryuji,

Thanks for reading the I-D! See some comments/responses inline.

> summarize these stuff in this simple doc :-)

A lot of things on many protocols are obvious for people working  
closely on them. As you said, the aim is to summarize a number of  
techniques in an informational way in one place. I believe it has  
value for people especially outside regular IETFers (having gone  
through one exercise to include PMIP6 in one SDO specs).

> I am fine to make this document as a WG item.

Great!

> After the initial acquisition of LMA address, can the new MAG get  
> the  address from the policy profile?

Yes. And that policy profile might be stored in local or remote policy  
store.

>
> This document uses the term of remote policy profile (section2.2)  
> and local database (section 3.1), but what is the relationship

Section 2.2. actually uses "remote policy store", not "remote policy  
profile". Remote policy store is not used in the draft in any place.  
On that part the terminology is inline with RFC5213 Section 6.2.

Section 3.1. refers local database in a case where the MAG would need  
to map MN identities to LMAs. For example have a MAC-address to LMA  
mappings. That information is not part of the RFC5213 policy profile,  
thus we used a (separate) database here.

>
> For instance, MAG use AAA to get LMA's IP address. Do you assume  
> that AAA manages the part of policy profile?

Hmm.. Section 2. says:

   "...
    infrastructure.  The PMIPv6 parameters bootstrapping involves the
    Policy Profile download over the AAA infrastructure to the MAG.  The
    ..."

Section 5. says:

   "
    ...
    in the Policy Store (or the AAA server).  The LMA information is
    conveyed to the policy store by the LMA after the initial attachment
    is completed [I-D.ietf-dime-pmip6].
   "

So typically (on some architectures I know) the AAA server is the  
remote policy store or a front end to one. Probably the AAA role and  
relation to remote policy store could be stated even more clearly.

I am not sure what you would like to see regarding L2 relation to  
policy store? How I see it, L2 can provide required information a) to  
locate a remote policy profile or b) locate a LMA directly.

> this in this document. There are no PMIP specific things here.

You would be surprised.. ;) Anyway, having a reminder here does not  
make harm, especially for people who try to build more "realtime"  
intelligence on top of DNS-based LMA discovery.

Cheers,
	Jouni

> However AAA or L2 solutions seems to be much straightforward and  
> light-weight approach.
> To design the DHCP parts, we tried not to introduces any PMIP  
> specific states or data at the DHCP entity.
> DHCP-server just notify the IPv4 address to the DHCP client. The  
> IPv4 address is always assigned by LMA.
> We might need some interaction between PMIP and DHCP to keep  
> protocol states consistency.
> - This document assumes one DHCP server per PMIP domain, because  
> DHCP relay has to be configured with the same DHCP server address.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Apr 2009 15:28:50 -0700 (PDT)

Hi Ryuji,
  Please see my replies below.

Regards,

Behcet

________________________________

I also read draft-xia-netlmm-lma-discovery-00.
DHCP can be alternative approach to discovery LMA address.
However AAA or L2 solutions seems to be much straightforward and light-weight approach.
Are their any strong reasons to use DHCP for this specific function (LMA discovery)?

[behcet] The charter Item 6 is the answer, I think.

comments to Frank's document
- In IPv4 support doc, we also uses DHCP for IPv4 address assignment.
To design the DHCP parts, we tried not to introduces any PMIP specific states or data at the DHCP entity.

[behcet] As Frank said we are assuming something similar to (DS)MIPv6. I don't think a lot of state is needed, in most cases a single record would be enough.
MAG access to DHCP is on the other hand is stateless which will probably make you happy.

DHCP-server just notify the IPv4 address to the DHCP client. The IPv4 address is always assigned by LMA.
On the other hand, this document assumes DHCP server manages all the PMIP states such as LMA and home network prefix.
We might need some interaction between PMIP and DHCP to keep protocol states consistency.
[behcet] No not really, please see above. If several LMAs are in the same domain then a few more.

- This document assumes one DHCP server per PMIP domain, because DHCP relay has to be configured with the same DHCP server address.
Is this reasonable assumption in terms of scalability and optimized management , etc. ?

[behcet] I agree with you on this. Please provide some text and help us improve the draft.

regards,
ryuji

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 16:02:46 -0700 (PDT)

Hi Jouni,

Few comments.

The informational doc on listing the discovery approaches is
fine, as Ryuji also suggested.

However, as I said in my first email, there is some overlap
with the AAA related work. We need to ensure both are alternative
approaches. Secondly, the discovery approach should lead to
bringing up the required security and authorization relation
as specified in 5213. Here, I'm not able to see how this can
be achieved without going to AAA. But, the solution needs to
address this.

Also, you may have to solve the issue of LMA/MN stickiness,
specially with the multihoming.

Any case, any extensions to PMIP are good, I've no issue with
this work.

Thanks
Sri

On Thu, 30 Apr 2009, jouni wrote:

> A lot of things on many protocols are obvious for people working closely on 
> them. As you said, the aim is to summarize a number of techniques in an 
> informational way in one place. I believe it has value for people especially 
> outside regular IETFers (having gone through one exercise to include PMIP6 in 
> one SDO specs).
>
>> 
>> - In RFC5213, it said LMA address must be stored in policy profile (Section 
>> 6.2).
> Yes. And that policy profile might be stored in local or remote policy store.
>
>> 
>> This document uses the term of remote policy profile (section2.2) and local 
>> database (section 3.1), but what is the relationship
> profile". Remote policy store is not used in the draft in any place. On that 
> part the terminology is inline with RFC5213 Section 6.2.
>
> Section 3.1. refers local database in a case where the MAG would need to map 
> MN identities to LMAs. For example have a MAC-address to LMA mappings. That 
> information is not part of the RFC5213 policy profile, thus we used a 
> (separate) database here.
>
>> 
> So typically (on some architectures I know) the AAA server is the remote 
> policy store or a front end to one. Probably the AAA role and relation to 
> remote policy store could be stated even more clearly.
>
> I am not sure what you would like to see regarding L2 relation to policy 
> store? How I see it, L2 can provide required information a) to locate a 
> remote policy profile or b) locate a LMA directly.
>
>> 
> You would be surprised.. ;) Anyway, having a reminder here does not make 
> harm, especially for people who try to build more "realtime" intelligence on 
> top of DNS-based LMA discovery.
>
> Cheers,
> 	 Jouni
>
>
>
>> 
>> - This document assumes one DHCP server per PMIP domain, because DHCP relay 
>> has to be configured with the same DHCP server address.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 29 Apr 2009 16:04:31 -0700 (PDT)

Not sure, if you guys cant merge and come out with a single
doc. Since, the issue is well defined, the specific approach
can be decided as part of this work. My 2c.

Sri

---

From: jouni <[email-masked]>
Date: Thu, 30 Apr 2009 02:11:32 +0300

Hi Sri,

See some comments inline.

>   out a need for dynamic dsicovery.

The use of dynamic security association setup has not been ruled out  
when e.g. the MAG discovers a LMA that it has no prior security  
association with. E.g. current rfc4301 security architecture provides  
required tools for this.

>   interface and on a per-Mobile basis. Why its more than an other

A MAG would get assigned LMA address/FQDN per MN basis over the AAA  
interface. That's the approach e.g. worked on in Dime PMIP6 support.

I did not really understand the "more than an other AAA attribute" part.

>   Why this one parameter needs to be discovered dynamically ?

Because people don't want to nor really cannot to hardcode all their  
roaming partner LMA information in their MAGs. In some cases the  
policy profile downloaded from the remote policy store would contain  
the LMA address. Still from the MAG point of view, the assignment/ 
discovery of the LMA for a specific MN was dynamic.

> 4. Is there a overlap of this with the scope of the other AAA  

Those AAA documents provide a selected solution for implementations (a  
subset of what this I-D presents), where as this I-D summarized many  
discovery approaches and discusses tradeoffs related to them.

>   its all in AAA or in policy store.

Good question. Current text says that the policy profile is e.g.  
downloaded during the initial attach & authentication to the PMIP6  
domain. Once the LMA has been selected for the UE there is no need to  
discover one.. unless the "service selection" is used as well. This  
part needs to be clarified further.

> 6. Is this required in WiMAX, 3GPP2 or 3GPP ? Just to be understand

Some, quite many actually, of these documented LMA discovery  
mechanisms are to be deployed in various SDOs. Not in a uniform way  
though, of course ;)

> I'm trying to understand where the gap is and I'm aware its in

Thanks for spending time on this I-D.

Cheers,
	JOuni

---

From: jouni <[email-masked]>
Date: Thu, 30 Apr 2009 02:16:06 +0300

Hi Sri,

> specially with the multihoming.

Yes, this part definitely needs more work. Current text is thin, if  
non-existent, regarding possible multi-homing implications.

Cheers,
	JOuni

>>> draft-korhonen does not provide any protocol extensions (that's  
>>> why this document is aiming informational).
>>> Most of parts in this document are too obvious, but it is useful  
>>> to summarize these stuff in this simple doc :-)
>>
>> Section 2.2. actually uses "remote policy store", not "remote  
>> policy profile". Remote policy store is not used in the draft in  
>> any place. On that part the terminology is inline with RFC5213  
>> Section 6.2.
>>
>> Section 3.1. refers local database in a case where the MAG would  
>> need to map MN identities to LMAs. For example have a MAC-address  
>> to LMA mappings. That information is not part of the RFC5213 policy  
>> profile, thus we used a (separate) database here.
>>
>>> It might help to clarify the relationship between policy profile  
>>> and AAA, L2 things, etc.
>>
>> Hmm.. Section 2. says:
>>
>> "...
>> remote policy store or a front end to one. Probably the AAA role  
>> and relation to remote policy store could be stated even more  
>> clearly.
>>
>> policy store? How I see it, L2 can provide required information a)  
>> to locate a remote policy profile or b) locate a LMA directly.
>>
>>> - The treatment of DNS caching is general one. I am not sure we  
>>> need this in this document. There are no PMIP specific things here.
>>
>>> On the other hand, this document assumes DHCP server manages all  
>>> the PMIP states such as LMA and home network prefix.
>>> > This is a consensus call to determine adoption of > draft- 
>>> korhonen-netlmm-lma-discovery as a WG item.  This relates to the >  
>>> > > Please respond on whether or not you support adoption of this  
>>> draft as a > WG item to the list by May 6th, 2009. Please note  
>>> that this document > would be a starting point for the work, if  
>>> adopted and the current > content in the draft is by no means final.
>>> > > Thanks,
>>> > Vidya

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 30 Apr 2009 07:38:18 -0700 (PDT)

Hi Sri,
  We are OK with merging the two drafts.

Regards,

Behcet

________________________________
From: Sri Gundavelli <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Ryuji Wakikawa <[email-masked]>; "Narayanan, Vidya" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Wednesday, April 29, 2009 6:04:31 PM
Subject: Re: [netlmm] Consensus call: Adopting draft-korhonen-netlmm-lma-discovery as a WG item

Sri

On Wed, 29 Apr 2009, Behcet Sarikaya wrote:

>> Please respond on whether or not you support adoption of this draft as a WG item to the list by May 6th, 2009. Please note that this document would be a starting point for the work, if adopted and the current content in the draft is by no means final..
>>
>> Thanks,
>> Vidya
> https://www.ietf..org/mailman/listinfo/netlmm
>
>
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 30 Apr 2009 07:38:18 -0700 (PDT)

Hi Sri,

Regards,

Behcet

Sri