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

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 04 May 2009 13:28:54 +0300

Hi,

<as a private person>

I do support this document as a WG item. I think it has been an 
oversight that it hasn't been adopted, yet.

Cheers,

Jonne.

ext 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 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: "Premec, Domagoj" <[email-masked]>
Date: Mon, 4 May 2009 12:47:56 +0200

Hi,

I think this is a useful document and I support it as a WG document.

Domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: 29. travanj 2009 02:10
> To: [email-masked]
> 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

---

From: "Soininen, Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 04 May 2009 14:17:12 +0300

Hi,

I don't  support merging these drafts. I think the idea of using DHCP is 
not really a much inline with the PMIP concept. DHCP is more adopted for 
end-host configuration, but I don't really see any point of using it to 
configure infrastructure elements. I think there are more useful 
mechanisms for that.

I think I stated this already earlier, but I don't really see the need 
for this DHCP-based LMA discovery at least at this point. I think the 
use cases and the real need for this should be better understood before 
this is brought forward.

Cheers,

Jonne.
ext Behcet Sarikaya wrote:
> 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 
> 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
>
>
>
> On Wed, 29 Apr 2009, Behcet Sarikaya wrote:
>
> > 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
> >
> >
> > On 2009/04/28, at 17:10, Narayanan, Vidya wrote:
> >
> >> Hi,
> 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
> >> [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Mon, 4 May 2009 16:06:03 +0200

I support the adoption of this draft as a WG item.

-Raj

On 4/28/09 7:10 PM, "ext Narayanan, Vidya" <[email-masked]> wrote:

> 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: <[email-masked]>
Date: Wed, 6 May 2009 11:24:18 +0200

Hi all,

This I-D is useful as informational document for deployment considerations, so I support the adoption of this draft as a WG item.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Narayanan, Vidya
> Envoyé : mercredi 29 avril 2009 02:10
> À : [email-masked]
> Objet : [netlmm] Consensus call: Adoptingdraft-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

---

From: Christian Vogt <[email-masked]>
Date: Thu, 14 May 2009 18:46:12 -0700

I think it would be useful to publish draft-korhonen-netlmm-lma-
discovery as an informational RFC, and hence to adopt the Internet draft
as a working group item.  I understand that the deadline for input to
the working group adoption process has passed, so my vote will not be
counted.  But I thought it may be useful to post this nonetheless.

In any case, here are a few comments and revision suggestions on the
Internet draft:

- The motivation for dynamic LMA discovery in section 1 could be
   extended.  It currently mentions only the advantage of reducing
   static configuration in MAGs.  In addition, there are the advantages
   of LMA load balancing and service-specific routing.  Both are
   important:  LMA load balancing, because an LMA may occasionally run
   at its resource limits given the typical load on an LMA.  In large
   mobile networks, I expect this not to be uncommon.  Static
   pre-configuration of MAGs with different LMAs cannot prevent this,
   because it cannot be anticipated how many mobile hosts end up using
   a particular LMA, and how much traffic these mobile hosts generate.
   And service-specific routing, because a service may best (or
   exclusively) be reached via one particular set of LMAs.

- The discussion of potential issues with DNS-based LMA discovery in
   section 4 is useful and necessary, yet the particular caching issues
   may actually be less problematic than the current text suggests.
   This applies especially to the use of low TTLs in LMA resource
   records. Although it is true that a TTL reduction would cause an
   increase in the number of DNS queries, the number of queries would
   still not be higher than in any other method for LMA discovery.
   After all, a new query needs to be made whenever there is a
   potential that the LMA has changed, and this is independent of the
   mechanism being used.  Furthermore, the increased number of queries
   would affect only the authoritative DNS server (which may be
   specialized for answering LMA discovery queries) and the DNS
   resolvers (i.e., the MAGs).  It would not affect DNS servers higher
   up in the DNS hierarchy.

   This said, a problem that /is/ worth mentioning, but is currently  
not,
   is that some DNS resolvers ignore low TTLs, replacing them with a
   higher default value.  This could lead to outdated LMA information
   being around for longer than desired.  Nevertheless, this issue is
   fixable -- by making sure that the DNS resolvers in MAGs process TTLs
   correctly.

- The handover considerations in section 5 currently say:  "Obviously,
   relying on DNS during handovers is not a working solution if the
   PMIPv6 domain has more than one LMA."  Here you should add "...,
   unless the DNS consistently assigns a specific LMA for each given
   mobile host."

Best regards, Christian

On Apr 28, 2009, Narayanan, Vidya wrote:

> Hi, This is a consensus call to determine adoption of
> 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: Thu, 14 May 2009 22:19:34 -0700

Hi Christian,

>    unless the DNS consistently assigns a specific LMA for each given

When the DNS server gets a request from the MAG, there is no information in
the request that indicates that this request is associated with a specific
mobile node. So how does the DNS consistently assign the same LMA for a
given mobile node?.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Fri, 15 May 2009 17:46:21 +0200

Hi Vijay,

On Friday 15 May 2009, Vijay Devarapalli wrote:
> > - The handover considerations in section 5 currently say: 
> > "Obviously, relying on DNS during handovers is not a working
> > solution if the PMIPv6 domain has more than one LMA."  Here you
> > should add "..., unless the DNS consistently assigns a specific LMA
> > for each given mobile host."
>
> When the DNS server gets a request from the MAG, there is no
> information in the request that indicates that this request is
> associated with a specific mobile node. So how does the DNS
> consistently assign the same LMA for a given mobile node?.

Not sure what Christian had in mind, but it could be possible, when the 
LMA FQDN is constructed from a mobile node identity (such as the IMSI) 
to build the name in a way that assigns different mobile nodes to 
different LMAs.

A strawman with mobile node with IMSI 123456789 and six LMAs in the 
pool: 

1. query: 
	_lma_pool.example.com

2. receive reply:
	lma-nyc.example.com
	lma-lax.example.com
	lma-sfbay.example.com
	lma-west.example.com
	lma-east.example.com
	lma-central.example.com

3. sort the lma list in alphanumeric order:
	lma-central.example.com
	lma-east.example.com
	lma-lax.example.com
	lma-nyc.example.com
	lma-sfbay.example.com
	lma-west.example.com

4. compute IMSI MOD N_LMA:
	IMSI MOD N_LMA = 123456789 MOD 6
                       = 3

5. assign MN with LMA numbered IMSI MOD N_LMA in the ordered list:
	lma-lax.example.com

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 May 2009 08:46:38 -0700 (PDT)

Hi Cristian,
  MAG is not DNS resolver it is DNS Client in this case.
I understand the dilemma you are pointing at here. We need an LMA for MN but MN can not talk :).

Regards,

Behcet

________________________________
From: Christian Vogt <[email-masked]>
To: NETLMM Mailing List <[email-masked]>
Sent: Thursday, May 14, 2009 8:46:12 PM
Subject: Re: [netlmm] Consensus call: Adopting draft-korhonen-netlmm-lma-discovery as a WG item

  This said, a problem that /is/ worth mentioning, but is currently not,

Best regards, Christian

---

From: jouni korhonen <[email-masked]>
Date: Fri, 15 May 2009 23:26:58 +0300

Hi Christian,

Thanks for support & spending time reading the I-D.

>  mobile networks, I expect this not to be uncommon.  Static

Right, this could be added.

>  fixable -- by making sure that the DNS resolvers in MAGs process TTLs

Agree. In general, the reason I wrote text around DNS issues is to  
remind folks that how current DNS deployment behaves is not  
deterministic. You cannot build too much sophisticated logic on top of  
it and just assume it works universally like it did in a controlled  
(lab) environment.

>  unless the DNS consistently assigns a specific LMA for each given

We could add some more text here as depending on the deployment and  
deployment related "regulation" the situation might not be this black  
and white. Usually, if a MAG is not able to somehow synthesize a LMA  
specific FQDN (e.g. out of MN identity or some other parameters),  
there is no real guarantee that DNS returns always the same LMA Address.

> Best regards, Christian

Cheers,
	Jouni

---

From: Christian Vogt <[email-masked]>
Date: Mon, 18 May 2009 16:13:46 -0700

On May 14, 2009, Vijay Devarapalli wrote:

>> "Obviously,
> information in
> given mobile node?

Vijay -

A method to realize DNS-based mobile-host-specific LMA assignments is
mentioned earlier in your Internet draft.  It consists of encoding a
mobile host identifier in the DNS query name, as Julien pointed out
correctly in his email.  This is the method I was thinking of.  Given
this method, I think you should make my suggested modification to
section 5.

Now that we are discussing this:  Perhaps you could also use some text
from Julien's email to elaborate a bit on the said method for DNS-based
mobile-host-specific LMA assignments?  Julien, would that be OK?

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Tue, 19 May 2009 17:54:59 +0200

On Tuesday 19 May 2009, Christian Vogt wrote:
> >>   unless the DNS consistently assigns a specific LMA for each
> >> given mobile host."
> >

I wasn't really suggesting to encode the MN ID in the query name, 
rather, I was providing a strawman of how the MN ID can be used as an 
input to an algorithm that always pick the same LMA FQDN out of a set 
of LMA FQDNs for a given MN ID.

> Now that we are discussing this:  Perhaps you could also use some
> text from Julien's email to elaborate a bit on the said method for
> DNS-based mobile-host-specific LMA assignments?  Julien, would that
> be OK?

Sure.

--julien

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 May 2009 12:12:52 -0700

Julien -

> input to an algorithm that always pick the same LMA FQDN out of a  
> set of
> LMA FQDNs for a given MN ID.

Good; thanks for clarifying.

Now, let's get back to the reason why we started this discussion thread.
It was the text in section section 5, which currently says:  "Obviously,
relying on DNS during handovers is not a working solution if the PMIPv6
domain has more than one LMA."

I think we have some evidence now that DNS-based mechanisms for use  
during
handovers do exist -- the one you described, the one I described,  
perhaps
more.  Independent of whether these mechanisms are technically sound,  
they
do exist, and hence the text in section 5 should IMHO be adjusted.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 May 2009 12:13:00 -0700

Jouni -

> Right, this could be added.

Good.

> it and just assume it works universally like it did in a controlled

Yes, this makes sense.  At least, PMIP operators who want to use the DNS
for LMA selection would have to make sure that the DNS resolvers in MAGs
and the DNS servers authoritative for LMA records work as required.
This is possible since DNS resolvers and DNS servers are both under the
control of a PMIP operator.  But it does require some action, and it may
involve joint action of multiple PMIP operators.

> there
> is no real guarantee that DNS returns always the same LMA Address.

Good idea.

- Christian

---

From: Julien Laganier <[email-masked]>
Date: Wed, 20 May 2009 16:19:16 +0200

On Tuesday 19 May 2009, Christian Vogt wrote:
> > rather, I was providing a strawman of how the MN ID can be used as
> > an input to an algorithm that always pick the same LMA FQDN out of
> > a set of
> Now, let's get back to the reason why we started this discussion
> thread. It was the text in section section 5, which currently says: 
> "Obviously, relying on DNS during handovers is not a working solution
> if the PMIPv6 domain has more than one LMA."
>
> during handovers do exist -- the one you described, the one I
> described, perhaps more.  Independent of whether these mechanisms are
> technically sound, they do exist, and hence the text in section 5
> should IMHO be adjusted. 

Agree.

--julien