Subject: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-05.txt

From: [email-masked]
Date: Mon, 13 Sep 2010 02:45:06 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network-based Localized Mobility Management Working Group of the IETF.

	Title           : LMA Discovery for Proxy Mobile IPv6
	Author(s)       : J. Korhonen, V. Devarapalli
	Filename        : draft-ietf-netlmm-lma-discovery-05.txt
	Pages           : 9
	Date            : 2010-09-13

Large Proxy Mobile IPv6 deployments would benefit from a
functionality, where a Mobile Access Gateway could dynamically
discover a Local Mobility Anchor for a Mobile Node attaching to a
Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the
Mobile Access Gateway.  This document describes several possible
dynamic Local Mobility Anchor discovery solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-lma-discovery-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 13 Sep 2010 15:49:50 -0700 (PDT)

Hi Jouni,
  Thanks for updating the draft.
Reading it I noticed that in Section 3.3on Constructing the LMA FQDN from a 
Service Name 

can you please mention a service name in QNAME format:
"_pmip6_ipv6.example.com"
where example.com can come from MN's NAI or the operator domain.

Such a QNAME clearly specifies that the new service name is pmip6 and the 
protocol is ipv6.
This will enable the operator to setup in their DNS servers, APNs that are 
serving as LMAs (not all APNs maybe doing so, right?) as replies.

Regards,

Behcet

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 13 Sep 2010 21:09:36 -0700

> where example.com can come from MN's NAI or the operator domain.

No, PMIPv6 is not a service. So we shouldn't do this.

Vijay

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Sep 2010 08:52:36 -0700 (PDT)

----- Original Message ----
> From: Vijay Devarapalli <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Behcet Sarikaya <[email-masked]>; jouni korhonen 
><[email-masked]>; [email-masked]
> Sent: Mon, September 13, 2010 11:09:36 PM
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-05.txt
> 

Why not? mip6 IS a service name. We do need pmip6 service name as well, don't 
you think?

Also reading the draft's Section 3.3 on service name (Constructing the LMA FQDN 
from a Service Name to be precise), it totally sounds like a 3GPP document.
Remember this is IETF work. IETF defined DNS and PMIPv6. 
IETF can define a service name which is operator and SDO independent. If such a 
service name is defined, there is even no need to standardize it in other SDOs 
like 3GPP. Operators can use it immediately.

Cheers,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Tue, 14 Sep 2010 19:43:27 +0300

Hi Behcet,

> Remember this is IETF work. IETF defined DNS and PMIPv6. 

I assume you did not notice the references that were given as examples in Section 3.3? They totally seem to point in 3GPP's general direction.

> like 3GPP. Operators can use it immediately.

IETF can.. but does not have to. I like the current content of Section 7. For the record, the 3GPP boat has already sailed. Not much to do there.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 14 Sep 2010 12:37:22 -0700 (PDT)

Hi Jouni,

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> Cc: Vijay Devarapalli <[email-masked]>; [email-masked]
> Sent: Tue, September 14, 2010 11:43:27 AM
> >>> Reading it I noticed that in  Section 3.3on  Constructing the LMA FQDN from 
>
>a
> >>> Service   Name
> >>> 
> >>> 
> >>> 
> I assume you did not notice the references that  were given as examples in 
>Section 3.3? They totally seem to point in 3GPP's  general direction.

Of course I did. I know that 3GPP does favor DNS discovery, in almost everything 

they use DNS discovery. 

> IETF can.. but does not have to. I like the current content  of Section 7. For 

>the record, the 3GPP boat has already sailed. Not much to do  there.
> 

I guess you mean 
19.4.3    Service and Protocol service names for 3GPP 
in 23.003. Yes they defined service names for pmip like 3gpp-pgw:x-s8-pmip 
indicating s8 interface on a P-GW.

Of course this is good and maybe you should specifically mention this in Sec. 
3.3.

However the above service name is 3GPP specific. I think it is advisable to 
define an IETF service name so that everybody can use it.

These are my points.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Wed, 15 Sep 2010 14:51:40 +0300

Inline..

> Of course this is good and maybe you should specifically mention this in Sec. 

I don't really see a reason for that. Especially when the text in 3.3 refers to APNs as an explicit example of service names rather than S-NAPRT app-service/protocol.

> define an IETF service name so that everybody can use it.

You are now mixing stuff here.. service as a identifier for network behind a gateway is different than a role/capability of a box.

> These are my points.

.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 15 Sep 2010 12:38:36 -0700 (PDT)

> >> the record, the 3GPP boat has already sailed. Not much to  do  there.

Who should take the responsibility for this?
Look back at the mail archive, Julien and Christian pointed at the right 
direction on DNS discovery long time ago.

I have been shouting since then what should be done and having a dialogue des 
sourds with you and Jonne.

Anyways, DNS discovery is mission not accomplished in this draft.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 16 Sep 2010 00:12:19 +0300

Dear Behcet,

> Who should take the responsibility for this?

I guess it is the evil telecom companies to blame here for coming up with a solution where they could use existing DNS specifications without even bothering IANA.

> direction on DNS discovery long time ago.

I assume you are referring to: http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html

We did add the main body of the MN ID based deterministic FQDN selection idea to Section 4 (was earlier Section 5). Since then above guys seem to have been OK, at least that is how I interpreted the silence.

> sourds with you and Jonne.

I assume you are referring to: http://www.ietf.org/mail-archive/web/netlmm/current/msg06468.html

We did follow the suggestion to drop the Section 4 ;) Btw, I still don't understand what is the problem if a MAG behaves as "an ordinary host makes a DNS query". The simpler the better.

> Anyways, DNS discovery is mission not accomplished in this draft.

Go ahead and actually _propose_ text on DNS based discovery that a) does not cause IANA actions and b) aligns with Section 3 (e.g. where the Service Name != RFC2782 _Service).

- Jouni

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 15 Sep 2010 15:35:07 -0700

Behcet Sarikaya wrote:
> > >>
> > >> IETF  can.. but does not have to. I like the current content  of
> > >> Section 7.
> > >>
> > >> For the record, the 3GPP boat has already sailed. Not much to  do
> > >> there.
> 

I am happy to take my share of responsibility for this. (and I bet Jouni as well, and some other people, too)

The 3GPP system architecture required LMA discovery features that are specific to that system architecture.

Thus neither of 3GPP relying on an IETF specification of these features, nor the IETF specifying features that are specific to the 3GPP system architecture made sense.

> Look back at the mail archive, Julien and Christian pointed at the
> right direction on DNS discovery long time ago.

I did not point at the *right* direction. 

I used *once*, for the sake of discussion, a strawman of a stateless DNS-based LMA discovery scheme that would deterministically load balance different MNs onto different LMAs.
 
> I have been shouting since then what should be done and having a
> dialogue des sourds with you and Jonne.

Isn't it usually the case that the one who shouts is the one that is hearing impaired? ;-)

>From my perspective this informational document fulfils its goal.

--julien

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 16 Sep 2010 12:07:28 -0700 (PDT)

Hi Jouni,
  Thank you for your reply.
Please see inline.

----- Original Message ----
> Cc: [email-masked]
> Sent: Wed, September 15, 2010 4:12:19 PM
> >>>> IETF  can.. but does  not have to. I like the current content  of Section 

>7. 
> >> For 
> I guess it is the evil telecom  companies to blame here for coming up with a 
>solution where they could use  existing DNS specifications without even 
>bothering IANA.
> 
> I assume you are referring to:  
>http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html
> 
> We did  add the main body of the MN ID based deterministic FQDN selection idea 

>to  Section 4 (was earlier Section 5). Since then above guys seem to have been 
>OK,  at least that is how I interpreted the silence.
> 

I like the second paragraph in Section 4 as well! Except that you don't let the 
reader know what  the LMA FQDNs via SRV [RFC2782] query is?
If you did (maybe in Section 3.3) the case would be closed on DNS discovery.
Please see below.

> I assume you are referring to:  
>http://www.ietf.org/mail-archive/web/netlmm/current/msg06468.html
> 
> We did  follow the suggestion to drop the Section 4 ;) Btw, I still don't 
>understand  what is the problem if a MAG behaves as "an ordinary host makes a 
>DNS query".  The simpler the better.
> 
> > 
> Go ahead and actually _propose_ text on  DNS based discovery that a) does not 
>cause IANA actions and b) aligns with  Section 3 (e.g. where the Service Name != 
>
>RFC2782 _Service).
> 

I already did. Give the QNAME in Section 3.3 that will be it. I think that the 
document can stay as informational.
In Section 3.3, you mention APN as service name for LMA. This contradicts with 
your v6ops draft which says APN is used to identify P-GW for a (GTP) MN. Not all 
P-GW's could be LMAs.

In Section 3.3 you mention names agreed on among    operators that belong to the 
same inter-operator roaming consortium like 

3gpp-pgw:x-s8-pmip S-NAPRT app-service/protocol. This seems to be PMIPv6 related 
because it has pmip but I think such names are out of scope for your draft, they 
address different needs. 

So my conclusion is that Sec. 3.3 on service names fails short of coming up with 
one and yet it is somehow assumed in Section 4 2nd paragraph.
What a mystery.

Cheers,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 17 Sep 2010 00:20:48 +0300

Behcet,

On Sep 16, 2010, at 10:07 PM, Behcet Sarikaya wrote:

[snip]

> document can stay as informational.

   Once the MAG has the FQDN it can proceed to resolve the LMA IP
   address(es) using the DNS.  An example of such service or external
   network name is the Access Point Name (APN) [3GPP.23.003] that
   contain information of the operator providing the access to the given
   service or the external network. For example, an FQDN for an 'ims' APN
   could be 'ims.apn.epc.mnc015.mcc234.3gppnetwork.org'.

[snap]

> What a mystery.

It indeed is a mystery.

- Jouni