Subject: Re: [netlmm] (WGLC) Review of I-D: draft-ietf-netlmm-lma-discovery-02

From: jouni korhonen <[email-masked]>
Date: Fri, 4 Dec 2009 13:14:00 +0200

Hi Raj,

Thanks a lot for the review. See my late comments inline.

On Nov 17, 2009, at 11:40 PM, <[email-masked]> <[email-masked]> wrote:

> 
> Hello,
> 
> I have reviewed the I-D: LMA Discovery for Proxy Mobile IPv6
> <draft-ietf-netlmm-lma-discovery-02.txt> and my comments are as
> follows:
> 
> 1. s/Large Proxy Mobile IPv6 deployments would benefit from a
>   functionality, where a Mobile Access Gateway could dynamically
>   discover/Large Proxy Mobile IPv6 deployments would
>   benefit from the functionality which enables a Mobile Access Gateway
>   to dynamically discover

OK. Will change this.

> 
> 2. Clarify what is meant by:
>   "selecting LMA based on desired services (i.e. allowing
>   service-specific routing of traffic)."

How about:

   ...
   a LMA include LMA load balancing solutions and selecting LMA based on
   desired services (i.e. allowing service-specific routing of traffic,
   where MNs using a certain service are assigned LMA(s) and prefixes
   from a pool of dedicated LMAs).

> 
> 3. s/There are a number of different ways for dynamically discovering the
>   LMA at the MAG/There are a number of different ways for dynamically
>   discovering the LMA to be assigned to an MN at the MAG.

OK. Will change this.

> 
> 4. s/The LMA discovery mechanism used by the new
>   MAG should be able to return the information about the same LMA that
>   was being used by the old MAG./The LMA discovery mechanism used by
>   the new MAG MUST be able to return the information about the same
>   LMA that was used by the old MAG w.r.t the MN.

Would be OK with wording like.

"The LMA discovery mechanism used by the new MAG must be able to return the
information about the same LMA that was used by the old MAG."

> 
> 5. s/is typically required to authenticate to the network access
>   and/is typically required to authenticate with the access network
>   and

OK. Will change this.

> 
> 6. s/for the network access/for network access

OK. Will change this.

> 
> 7. In Sec 2. (AAA based discovery) it would be good to add a sentence
>   that the address of the LMA to be assigned to the MN is included in
>   the policy profile that is downloaded to the MAG.

Right. How about:

   ...
   infrastructure.  The PMIPv6 parameters bootstrapping involves the
   Policy Profile download over the AAA infrastructure to the MAG and
   the assigned LMA IP address can be included in the downloaded Policy
   Profile. The procedure for the Policy Profile download resembles
   largely the client Mobile IPv6 Integrated Scenario bootstrapping
   [RFC5447].

> 
> 8. s/authenticated for the network access/authenticated for network
>   access

OK. Will change this.

> 
> 9. s/might be a generic/may be generic

OK. Will change this.

> 
> 10. I-D states:
> "   In order for this to work, the resolved
>   and selected LMA IP address must be updated to the remote Policy
>   Store.  For example, the LMA could perform the update once it
>   receives the initial PBU from the MAG for the new mobility
>   session."
> 
>   Is the LMA updating the policy store? And what procedure exists to
>   perform such an update? Should there be a reference to some
>   Diameter specification for this?

We can add a reference to draft-ietf-dime-pmip6 that defines the said update.

> 
> 11. s/from lower layers below the IP layer/from lower layers, i.e
>    below the IP layer

OK. Will change this.

> 
> 12. s/These solution/This solution

OK. Will change this.

> 
> 13. Section 3 is discussing lower-layer solutions. The same section
> also includes the following text:
> "and tunneling solutions such as IKEv2 [RFC4306] IPsec tunnel
> [RFC4303]."
> 
> IKEv2 and IPsec are not lower layer solutions. Hence the text in the
> section needs to be rephrased.

Hmm.. tunneling can be seen as a "lower layer" and IKEv2 in general provides a lot of functionality that some link layers do during the network attachment. I would keep these here.

> 
> 14. s/as a result of the network access attachment procedure/via the
>    network access attachment procedure.

OK. Will change this.

> 
> 15. Section 3.2 needs to be explained a bit further to make it
>    understandable by readers not familiar with APN and 3GPP
>    architectures.

Here, I would actually change the example to use IKEv2.. the IDr payload is commonly used for the exactly same purpose as the existing 3GPP/APN text explain.

> 
> 16. In section 4, it would be useful to mention the type of DNS
>    records that are returned to the MAG as a result of a
>    query. 

We can add a reference to A and AAAA records here.

> 
> 17. s/is not generally a working solution/is generally not a good
>    solution

OK. Will change this.

> 
> 18. "the situation might not be this desperate."
>    desperate??? Really?

Do you have a proposal for a better phrasing here? :)

> 
> 
> In summary, I believe the I-D is ready to be progressed after at
> least one more revision that would take care of the above comments
> and any others.

Thanks.

Cheers,
	Jouni

> 
> -Basavaraj
> 
> 
> On 11/17/09 2:23 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:
> 
>> All,
>> This WGLC has had zero comments so far and we cannot progress the document to
>> the IESG in its current state.  I am extending the last call on this document
>> until Nov 25, 2009.  If you think the document is complete and is ready to be
>> sent to the IESG, please state so on the mailing list.  Or, if you have
>> comments, please post a review.  If we get no responses, we will be forced to
>> drop the document.
>> 
>> Thanks,
>> Vidya
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm