Subject: [netlmm] Review of draft-ietf-netlmm-lma-discovery-02

From: Qin Wu <[email-masked]>
Date: Sat, 24 Apr 2010 17:14:52 +0800

Hi,
I have been asked to review this I-D. Here is my feedback below:
---------------------------------------------------------------------
In Section 1:
1.  Introduction

   Large Proxy Mobile IPv6 (PMIPv6) [RFC5213] deployments would benefit
   from a functionality, where a Mobile Access Gateway (MAG) could
   dynamically discover a Local Mobility Anchor (LMA) for a Mobile Node
   (MN) attaching to a PMIPv6 domain.  The purpose of the dynamic
   discovery functionality is to reduce the amount of static
   configuration in the MAG.  Other drivers for the dynamic discovery of

   [Qin]: s/drivers/drives

Still in Section 1:
   There are a number of different ways for dynamically discovering the
   LMA at the MAG.  The following list briefly introduces solutions that
   will be discussed in this specification:

   o  LMA Address from AAA during the network access authentication
      procedure when the MN attaches to the MAG.

   o  LMA FQDN from AAA during the network access authentication,
      followed by a Domain Name System (DNS) lookup.

   o  LMA FQDN derived from the MN identity received from the lower
      layers during the network attachment, followed by a DNS lookup.

   o  LMA FQDN or IP address received from the lower layers during the
      network attachment followed by an optional DNS lookup.

   o  LMA FQDN derived from the service selection indication received
      from lower layers during the network attachment, followed by a DNS
      lookup.
   
   [Qin]: It seems to me the MAG has too many choices to do LMA discovery for each MN.
   I am wondering which one will be really used by MAG? or which solution will be applied
   in which scenario?
   In my personal opinion, the first solution combined with the second solution is the most efficient and simple one to
   fetch LMA address. Becos, only one step using AAA is required.In contrast with the first solution, 
   the other four solutions all needs two steps and depends on DNS apprach to obtain LMA address.
   
   [Qin]: As regarding the third solution, the LMA FQDN is derived from the MN identity received from
   the lower layers, I am wondering whether the MN identity can be received from the AAA Server and then
   derive the LMA FQDN from this MN identity.

In Section 2:
   This section presents a LMA discovery solution that requires a MAG to
   be connected to an AAA infrastructure.  The AAA infrastructure is
   also assumed to be aware of and support PMIPv6 functionality.  A MN
   attaching to a PMIPv6 domain is typically required to authenticate to
   the network access and to be authorized for the mobility service
   before the MN is allowed to send or receive any IP packets or even
   complete its IP level configuration.
   
   [Qin]: I think IP level configuration(e.g., DHCP procedure) should happen 
   before MN send or recieve any IP packets. Right?
   [Qin]: When I read "A MN attaching to a PMIPv6 domain is typically required to authenticate to the network access....
   ", I am wondering whether MN need to be authenticated for network access or the network need to be autheticated by the MN?
   which one do you want to say here?

In Section 2.1:
   Once the MAG receives the LMA IP address(es), it sends Proxy Binding
   Update (PBU) message for the newly authenticated and authorized MN.
   The MAG trusts that the LMA returned by the AAA server is able to
   provide mobility session continuity for the MN, i.e. after a handover
   the LMA would be the same the MN already has a mobility session set
   up with.

   [Qin]: s/ the same/the same one

In Section 2.2
2.2.  Receiving LMA FQDN during the Network Access Authentication

   This solution is identical to the procedure described in Section 2.1.
   The difference is that the MAG receives a Fully Qualified Domain Name
   (FQDN) of the LMA instead of the IP address(es).  The MAG has to
   query the DNS infrastructure in order to resolve the FQDN to the LMA
   IP address(es).

   The LMA FQDN might be a generic to a PMIPv6 domain resolving to one
   or more LMAs in the said domain.  
   
   [Qin]: 
   s/
   "
   The LMA FQDN might be a generic to a PMIPv6 domain resolving to one
   or more LMAs in the said domain.  
   "
   /
   "
   The LMA FQDN might be a generic one to a PMIPv6 domain being resolved to one
   or more LMAs in the said domain.  
   " 
  
   [Qin]: Why not restrict resolving one LMA FQDN into more than one LMA,
   Otherwise how do you guarantee that the LMA address resolved from the LMA FQDN is
   the same LMA that was being used by the old MAG.

   Alternatively the LMA FQDN might
   resolve to exactly one LMA within the PMIPv6 domain.  
   [Qin]:
   s/
   "
   Alternatively the LMA FQDN might  resolve to exactly one LMA within the PMIPv6 domain.  
   "
   /
   "
   Alternatively the LMA FQDN might be resolved to exactly one LMA within the PMIPv6 domain.  
   "

In Section 3.1:
3.1.  Constructing the LMA FQDN from a mobile node Identity

   Depending on the actual network access technology, the MAG may be
   able to receive a MN identity (or actually the subscription identity
   but from now on we assume that the MN identity equals to the
   subscription identity, which is a rather broad simplification) as a
   result of the network access attachment procedure.  The MN may signal
   its identity as part of the attachment signaling or alternatively the
   MAG receives the MN identity from a remote policy store.
   
   [Qin]: I am wondering whether the MN identity described in this document
   is the MN Identifier described in RFC5213?
   Once the MAG has acquired the MN identity, the MAG can use the
   information embedded in the identity to construct a generic LMA FQDN
   (based on some pre-configured formatting rules) and then proceed to
   resolve the LMA IP address(es) using the DNS.  Obviously, the MN
   identity must embed information elements that can be extracted and at
   minimum used to determine the entity hosting and operating the LMA
   for the MN.

   Thus the MN identity in this solution cannot be a "flat"
   identity without any structure and "clear text" parts containing the
   hosting entity information.  Examples of such identities are the
   International Mobile Subscriber Identity (IMSI) or Globally Unique
   Temporary User Equipment Identity (GUTI) [3GPP.23.003] that both
   contain information of the operator owning the given subscription.
 
   [Qin]: I am wondering whether IMSI need to be extended to embed FQDN related
   information elements? 
   Can you give one example to explain how to extract information from IMSI or
   GUTI and construct FQDN for LMA?

   [Qin]:Why can't you use NAI as MN identiy and extract realm part
   as input to FQDN for LMA?

   The solution discussed in this section has issues if MN's identity
   does not embed enough information.  In a case the MN identity does
   not embed any LMA hosting entity information, the MAG might use a
   local database to map MN identities to corresponding LMAs.  
   
   [Qin]: I am wondering how does MAG know if the MN identity embed FQDN related
   information? 
   [Qin]: Are MN's identity and MN identity the same thing? If so, I would like to
   suggest to use the same terminology for consistency.
-----------------------------------------------------------------------------------------------------------------

Regards!
-Qin

---

From: jouni korhonen <[email-masked]>
Date: Wed, 28 Apr 2010 10:55:34 +0300

Hi Qin,

Thanks for the review. I hope this was against the -03 version and not the -02 ;) See my responses inline.

> I have been asked to review this I-D. Here is my feedback below:

I think "drivers" is better. I could reword it "motivations" as well.

>   I am wondering which one will be really used by MAG? or which solution will be applied

It is true that there are multiple ways of discovering a LMA and one reason for the existence of this draft is to document those. Eventually it is p to the PMIP6 domain or the general deployment to select one or those that must be supported.

>   the other four solutions all needs two steps and depends on DNS apprach to obtain LMA address.

The first two bullets are more or less covered by RFC5779. The last four are actually used in a form or other in other SDOs.

>   derive the LMA FQDN from this MN identity.

It is possible. However, the third bullet could be deployed without AAA infrastructure (whether it would make sense in real deployments) and that is one reason why it is also listed/handled separately.

>   before MN send or recieve any IP packets. Right?

What we had in mind was e.g. EAP style access authentication on lower layers that takes place before PBU/PBA exchange. When a MN is in a state of sending DHCP packets, the PBU/PBA exchange has already taken place and the MAG can actually process packets received from a MN in a meaningful way.

>   which one do you want to say here?

Good point. We could say "..typically required to mutually authenticate.."

>   [Qin]: s/ the same/the same one

ok.

>   or more LMAs in the said domain.  

Hmm. How about:
"The LMA FQDN might be a generic name for a PMIPv6 domain that resolves to one
 or more LMAs in the PMIPv6 domain.
"

>   the same LMA that was being used by the old MAG.

Most of the discovery procedures here apply best to the initial attach. Once MAG has discovered a LMA, the LMA address typically gets updated to the policy profile/policy store. After the handover the LMA address found in the policy profile would be used instead of initiating a new dynamic discovery of the LMA.

>   Alternatively the LMA FQDN might be resolved to exactly one LMA within the PMIPv6 domain.  

Ok.

>   is the MN Identifier described in RFC5213?

We do not make such assumption but in some deployments those could be the same.

>   GUTI and construct FQDN for LMA?

IMSI contains MNC and MCC information. For example in 3GPP systems MNC and MCC are used to synthesize a domain name that identifies uniquely an operator. Then based on the pre-configured formatting rules you are able to come up with a FQDN that could actually be usable in order to resolve some LMA.

>   as input to FQDN for LMA?

You could but if for example the lower layer does not provide you with a NAI then you need to do something else.

>   [Qin]: I am wondering how does MAG know if the MN identity embed FQDN related

By system level configuration/implementation. For example a MAG in WiMAX system differs from a MAG in 3GPP system when it comes to system specific details.

>   suggest to use the same terminology for consistency.

Will align.

Thanks!

- Jouni

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