Re: [netlmm] Last call for draft-ietf-netlmm-lma-discovery-03

[jouni korhonen <[e-mail]>]

Hi Charlie,

Thanks a bunch for your detailed comment. See my responses inline.


On May 6, 2010, at 9:56 PM, Charles E. Perkins wrote:


> 
> -------- Original Message --------
> Subject: Re: [netlmm] Last call for draft-ietf-netlmm-lma-discovery-03
> Date: Thu, 06 May 2010 11:54:15 -0700
> From: Charles E. Perkins <[e-mail]>
> Organization: Wichorus Inc.
> To: Soininen, Jonne (NSN-FI/Espoo) <[e-mail]>,	Jouni Korhonen <[e-mail]>,	Vijay Devarapalli <[e-mail]>
> CC: <[e-mail]>
> 
> Hello Jonne,
> 
> Below, please find some initial comments on this document.
> I think it needs at least one more revision, which should
> be preceded by close proofreading.  I'll send more comments
> later.  But first I am curious about your sentence:
> 
> On 4/29/2010 1:16 AM, Soininen, Jonne (NSN-FI/Espoo) wrote:
> 
>> As it seems that new reviews are coming to the document,
>> it would be time to get this document over with.
> 
> Usually, when a document gets more and more comments,
> it's not taken as any good indication that the time
> has come to get it over with...(??)
> 
> ========================================================
> 
> About the document:
> 
> "selecting LMA" --> "selecting a LMA"
> BUT:
> "selecting {a} LMA based on desired services"
> -- are these extensions defined anywhere in
>   IETF documents?  If so, please provide
>   relevant citations.

Within IETF scope we have RFC5149. I'll put in an informative reference here.

> 
> "a number of" --> "several"

Ok.

> 
> "a number of different ways" --> "various ways"
> -- anyway, in this context no one would
>   say "a number of identical ways"
> -- and moreover the entire sentence should
>   be deleted.

Ok to delete "This document describes a number of possible dynamic LMA discovery solutions."


> 
> "discussed in this specification" -->
> 	"discussed in this document"
> 
> I don't think the document is really intended
> to be a full-blown specification.

Ok.

> 
> "LMA Address" --> "LMA IP address"

Hmm.. RFC513 terminology defines "LMA Address" as the "The global address that is configured on the interface.."
I rather keep using the LMA Address terminology.


> 
> "LMA FQDN or IP address received from the lower layers during the
>      network attachment followed by an optional DNS lookup."
> -- This sentence is wrong, because if the lower layer provides
>   an IP address, the DNS lookup would not happen.  And if the

Good catch. Will fix.

>   lower layer provides the FQDN, it's an interesting discussion
>   about why the DNS lookup is suddenly optional.

Because of local configuration i.e. the MAG knows the mapping from FQDN to IP address?


> 
>> When a MN performs a handover from one MAG to another, the new MAG
>> must use the same LMA that the old MAG was using.  This is required
>> for session continuity.  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.  This document also discusses
>> solutions for LMA discovery during a handover.
> 
> I'm surprised to see this.  Wasn't it considered controversial?

I did not understand the "controversial" part of this comment.


> 
> "support PMIPv6 functionality" --> "support PMIPv6"

Ok.

> 
> I think this document does not need to use any
> instances of the ?word? "functionality", which leads
> to additional, extraneous, excessive, unwarranted
> verbosity.  A bit too much, eh?  Oh, and did I
> mention ...?

;)

> 
> "to authenticate to the network access" -->
> "to provide authentication for network access"

Ok.

> 
> "the mobility services" --> "mobility services"

Ok.

> 
> "the Policy Profile download"
> (a) if you want this included, a citation is needed.

Would a reference to RFC5213 Appendix A be ok?


> (b) but why even bring up policy management?  It's
>    not germane to the solution except tangentially
>    insofar as AAA is often also part of policy
>    management.


In RFC5213 there are few places where it is indicated that policy profile contains the information what we are after for. 


> (c) it would be easy to argue that this procedure is
>    NOT very much like RFC 5447.  How is this helping
>    to illustrate the solution?

I have no problem to remove "The procedure for the Policy Profile download resembles largely the client Mobile IPv6 Integrated Scenario bootstrapping [RFC5447]." if that helps with your concern.

> 
>> This solution is identical to the procedure described in Section 2.1.
>> The difference is
> 
> Well, it's either identical or it's not.  How about
> "similar"?

Ok.


> 
> "LMA IP address(es)":
> -- Please describe in more detail.  Is it proposed to
>   use DNS to supply IP addresses for multiple independent
>   hosts?  What are the security implications?  Shouldn't
>   this be done by use of an anycast address?

Hmm.. a LMA may have multiple interfaces, thus multiple addresses. These all can be populated into DNS. PMIPv6 anycast support is still in under works in netext.


> -- The following discussion indicates that any such
>   multiplicity of IP addresses supplied for the LMA
>   creates the need for a new selection algorithm to
>   find the "right" LMA.  Why is this a good idea?

It might not be the best idea. Rather something that just gets deployed.


> 
>>        ...         For example, the AAA server might return a generic
>> LMA FQDN during the MN initial attach and once the LMA gets selected,
>> return the LMA IP address during the subsequent attachments to other
>> MAGs in the PMIPv6 domain.  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.
> 
> (a) It isn't at all clear why Policy Store updates are a
>    necessary precondition for this -- unless of course you
>    generalize the meaning of Policy Store beyond all useful
>    recognition
> (b) And anyway why bring it up?


Well.. this is more or less the way some infamous architectures are going to work.

> (c) How does the LMA get selected?

MAG picks up one from a set it got from DNS..

> (d) What update does the LMA perform?

..updates its IP address to the remote policy store, for this particular mobility session.

> (e) Is this discussion in any way important for someone
>    to understand how to resolve a FQDN for the LMA?

Imho it reflects how things are going to be done in real deployments.

> 
> "Lower Layers based Discovery Solutions" -->
> "Discovery Solutions based on Data from Lower Layers"

OK.


> 
> "These solution could essentially" -->
> "These solutions could essentially" -->?

OK.

> "These solution could"
> <why "essentially"??>

Would it be better if I remove "essentially" from that sentence? I would be ok to rephrase.

> 
> "without the AAA" ->> "without any AAA"

OK.

> 
> "mobile node Identity" --> "Mobile Node Identity"

OK.

> 
> "equals to the" --> "equals the" --> "is the same as"

OK (going to use the "is the same as").


> 
> "MAG receives" --> "MAG may receive"

OK.


> 
>>                        (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)
> 
> Since the subscription identity _is_ one of the
> identities of the MN, this parenthetical comment
> is not needed.  And, anyway, you didn't define
> subscription identity.  You don't need to do that.
> I don't see how it would help the explanation.

Right. I will remove "(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)" ?

> 
> "information elements that can be extracted and at
>   minimum used"
> -->
> "information that can be used"

OK.


> 
>>             Thus the MN identity in this solution cannot be a "flat"
>> identity without any structure and "clear text" parts containing the
>> hosting entity information.
> 
> This sentence should be deleted.  And, anyway, it is
> by no means required that the information which
> identifies the hosting entity has to be in clear text.

OK.


> 
> "operator owning the given subscription"
> -- I thought the subscriber owned the subscription.
>   O.K... perhaps operators act like they own the
>   subscriber, but still I must protest.

;) Now that I read it again after your "protest" it indeed sounds.. erm.. wrong. Do you have a better wording in mind?


> 
> =========================================================================
> 
> Regards,
> Charlie P.

Thanks,
	Jouni


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