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

From: [email-masked]
Date: Sun, 23 Aug 2009 14:00:01 -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-01.txt
	Pages           : 10
	Date            : 2009-08-23

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 specification describes a number of
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-01.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: Xiangsong Cui <[email-masked]>
Date: Mon, 24 Aug 2009 12:11:13 +0800

Hi,

I read the document just now, and I have some comments on
section 3.

Section 3.1,
"  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.  However,
   this solution is unlikely to scale outside a limited PMIPv6 domain."

I agree the solution "map MN id to corresponding LMA", and I
dislike the solution "construct a generic LMA FQDN" (it depends on
special assumption and precondition).
But the solution "map MN id to corresponding LMA" also need a
precondition, the MAG should know all addresses of the LMAs in the
domain. So in this case, it is not "LMA discovery" but "LMA selection".
I think the WG may rename the working item to "LMA discovery and
selection" (favorable), or remove the solution from "LMA discovery".

Section 3.2,
"  This usually means the MN is the
   originator of the LMA information and explicitly participates to the
   mobility management signaling "

In NETLMM, the principle is that the MN should not be involved in
mobility management, right?
So the solution "Receiving LMA FQDN or IP Address" should be
deleted in the netlmm WG draft.

Section 3.3,
For the MAG, is the service name enough to get out the LMA FQDN
or LMA IP address?
I don't understand how the MAG can construct the LMA FQDN only
by the service name.

Regards

Xiangsong

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 24, 2009 5:00 AM
Subject: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> implementation to automatically retrieve the ASCII version of the

--------------------------------------------------------------------------------

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

---

From: jouni korhonen <[email-masked]>
Date: Mon, 24 Aug 2009 11:56:39 +0300

Hi,

Thanks for the review. See my comments inline.

> selection" (favorable), or remove the solution from "LMA discovery".

Well.. I don't have big feelings related to the I-D name. It is  
changeable.

Related to the "selection" versus discovery we could write that:

    ...
    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 FQDN.
    ...

> deleted in the netlmm WG draft.

I would be fine deleting this section. Others?

> I don't understand how the MAG can construct the LMA FQDN only

As the text already states:

    ... If the MN
    originated service name also embeds the information of the entity
    hosting the service or the external network, then the MAG can
    construct a generic LMA FQDN (e.g., based on some pre-configured
    formatting rules) providing an access to the service or the external
    network.

The service name must have enough information in it. And later we give  
an example of such existing service name.

Cheers,
	Jouni

>
> Regards
>
> Xiangsong
>
>
> ----- Original Message ----- From: <[email-masked]>

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 24 Aug 2009 19:11:56 +0800

Hi Jouni,

> The service name must have enough information in it. And later we give  an 
> example of such existing service name.

I think the key point is not the "example of such existing service name",
but the "pre-configured formatting rules".

Does the MAG cache a formula, take the service name as the input value,
and calculate the LMA FQDN?
Could you give us an example of such "formatting rules"?

Additionally, I'm interested in "enough information", is there any 
criterion?

IMHO, this is a strange and difficult solution.

Regards

Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, August 24, 2009 4:56 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> The service name must have enough information in it. And later we give  an 
> example of such existing service name.
>
> Cheers,
> Jouni
>
>
>>
>> Regards
>>
>> Xiangsong
>>
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Aug 2009 10:47:54 -0700

Hello,

> I would be fine deleting this section. Others?

I disagree. The section explicitly says the MAG receives the LMA FQDN or IP
address from the MN in the lower layers. This is not the same as the MN
doing mobility management.

Vijay

---

From: jouni korhonen <[email-masked]>
Date: Mon, 24 Aug 2009 21:12:46 +0300

Hi,

On Aug 24, 2009, at 2:11 PM, Xiangsong Cui wrote:

>> The service name must have enough information in it. And later we  
>> give  an example of such existing service name.
>

Deployment, inter-operator agreements etc typically define the  
formatting rules. Rest is up to the implementation.

> Could you give us an example of such "formatting rules"?

The text gives a reference of "example of such existing service name"  
to 23.003.

> Additionally, I'm interested in "enough information", is there any  

The same text says:

    "..If the MN
    originated service name also embeds the information of the entity
    hosting the service or the external network, then the MAG can"

So the service name just have to data/information that can be used to  
identify the entity (e.g. the operator) hosting the LMA. That is the  
criterion.

> IMHO, this is a strange and difficult solution.

I don't think so. It might not be the most fabulous solution but  
already selected some by SDOs.

Cheers,
	Jouni

>
>
> Regards
>
> Xiangsong
>
> ----- Original Message ----- From: "jouni korhonen" <[email-masked] 
> >
>> The service name must have enough information in it. And later we  
>> give  an example of such existing service name.
>>
>> Cheers,
>> Jouni
>>
>>
>>>
>>> Regards
>>>
>>> Xiangsong
>>>
>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Aug 2009 12:06:46 -0700 (PDT)

Folks,
  Service name based LMA discovery is covered in:
http://tools.ietf.org/id/draft-sarikaya-netlmm-lma-dnsdiscovery-01.txt

I think everybody wants this (see mails from Julien, Christian, etc.)
I am hoping that the chairs will hear it and make this draft a WG draft somehow.

Regards,

Behcet

----- Original Message ----
> From: jouni korhonen <[email-masked]>
> To: Xiangsong Cui <[email-masked]>
> Cc: [email-masked]
> Sent: Monday, August 24, 2009 1:12:46 PM
> Deployment, inter-operator agreements etc typically define the formatting rules. 
> Rest is up to the implementation.
> 
> The text gives a reference of "example of such existing service name" to 23.003.
> 
> > 
> > Additionally, I'm interested in "enough information", is there any criterion?
> 
> The same text says:
> 
>   "..If the MN
> So the service name just have to data/information that can be used to identify 
> the entity (e.g. the operator) hosting the LMA. That is the criterion.
> 
> > 
> I don't think so. It might not be the most fabulous solution but already 
> selected some by SDOs.
> 
> Cheers,
>     Jouni
> 
> > 
> > 
> > Regards
> > 
> > Xiangsong
> > 
> > ----- Original Message ----- From: "jouni korhonen" 
> > To: "Xiangsong Cui" 
> > Cc: 
> >> Well.. I don't have big feelings related to the I-D name. It is changeable.
> >> 
> >>> ----- Original Message ----- From: 
> >>> To: 
> >>> Cc:

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 25 Aug 2009 09:53:20 +0800

Hi,

Since most fellows like this solution, I will accept it too.

But I still want this solution to be introduced more clearly.
We need state what is the operation defined in this document
and what is out of scope(e.g. formatting rules is out of scope).
So the implementors can know what to do for this solution,
and how to do it, base on this document.

Regards

Xiangsong

----- Original Message ----- 
From: "Behcet Sarikaya" <[email-masked]>
To: "jouni korhonen" <[email-masked]>; "Xiangsong Cui" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 25, 2009 3:06 AM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

Folks,

I think everybody wants this (see mails from Julien, Christian, etc.)
I am hoping that the chairs will hear it and make this draft a WG draft 
somehow.

Regards,

Behcet

----- Original Message ----
> identify

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 25 Aug 2009 10:12:52 +0800

Hi Vijay,

In my understanding, LMA is a functional element of mobility
management, the mobile node with only simple IP stack can't
recognize the information of LMA and can't transmit it to MAG.

If the mobile node can't send this information to MAG,
MAG can't receive this information from mobile node.

Regards/Xiangsong

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "jouni korhonen" <[email-masked]>; "Xiangsong Cui" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 25, 2009 1:47 AM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

Hello,

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 26 Aug 2009 20:32:19 -0400

You are right. I am not disagreeing that the mobile node knows that
PMIPv6 is being used in the network when it sends the LMA information to
the MAG. But we have a sort of working assumption that the MN is able to
supply certain information to the MAG at L2, for example, attach versus
handover indication. This would be similar to that.

Vijay

> -----Original Message-----
> From: Xiangsong Cui [mailto:[email-masked]] 
> Sent: Monday, August 24, 2009 7:13 PM
> To: Vijay Devarapalli; jouni korhonen
> Cc: [email-masked]
> Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-lma-discovery-01.txt
> 
> Hi Vijay,
> 
> Subject: Re: [netlmm] I-D 
> Action:draft-ietf-netlmm-lma-discovery-01.txt
> 
> 
> Hello,
>

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 27 Aug 2009 10:11:29 +0800

Hi Vijay,

I think I got your point, but I still have some questions.

1, NETLMM WG is about mobility management, so the item
    of LMA discovery is of course in scope of mobility management,
    is it right?

2, MN provides LMA information to MAG, is a *MN-assistant*
    LMA discovery, is it right?

3, MN-assistant LMA discovery means MN involves in the mobility
    management, is it right?

Regards

Xiangsong

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "jouni korhonen" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 27, 2009 8:32 AM
Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

Vijay

---

From: jouni korhonen <[email-masked]>
Date: Thu, 27 Aug 2009 11:15:00 +0300

Hi,

>   of LMA discovery is of course in scope of mobility management,

ok.

>   LMA discovery, is it right?

We are a bit on a grey area here. Like the text says such information  
may come from lower layers. If such information delivery is e.g. part  
of the normal L2 attach procedure independent whether there is PMIP or  
not, I would not call it in that case MN assisted LMA discovery.

> 3, MN-assistant LMA discovery means MN involves in the mobility

Continuing from the above. If the information that MN provides is  
configured into MNs and this configuration is independent whether  
there is PMIP or not, I would not say that MN is involved in the  
mobility management. The content of the configuration data might then  
be different depending whether PMIP is used but that is transparent to  
MNs.

Cheers,
	Jouni

>
> Regards
>
> Xiangsong
>
>
> ----- Original Message ----- From: "Vijay Devarapalli" <[email-masked] 
> >
> To: "Xiangsong Cui" <[email-masked]>; "jouni korhonen" <[email-masked] 
> >
> Cc: <[email-masked]>
>> ----- Original Message ----- From: "Vijay Devarapalli" <[email-masked] 
>> >

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 27 Aug 2009 16:57:27 +0800

Hi Jouni,

Let's take a precise analyse on this issue.

You said such information may come from lower layers,
but who generate this information?

Does lower layer generate the LMA information or the
LMA information does depend on the link type?

I think it is not.

Maybe it is the user who configures the LMA information
in the mobile node (i.e. the device), but in the MAG perspective,
the initiator of the message which contains the LMA information,
the initiator is the MN, the MAG gets the LMA information from
the mobile node.

For example, the MAG gets LMA information from AAA server,
and the LMA information in AAA server is configured by the administrator.
We can say MAG gets LMA information from AAA server but nobody
says MAG gets LMA information from the administrator.

So I think it is a MN-assist solution.

Regards/Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 27, 2009 4:15 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> We are a bit on a grey area here. Like the text says such information  may 
> come from lower layers. If such information delivery is e.g. part  of the 
> normal L2 attach procedure independent whether there is PMIP or  not, I 
> would not call it in that case MN assisted LMA discovery.
>
>>
> configured into MNs and this configuration is independent whether  there 
> is PMIP or not, I would not say that MN is involved in the  mobility 
> management. The content of the configuration data might then  be different 
> depending whether PMIP is used but that is transparent to  MNs.
>
> Cheers,
> Jouni
>
>
>>
>> Regards
>>
>> Xiangsong
>>
>>
>> <[email-masked]
>> Subject: RE: [netlmm] I-D Action:draft-ietf-netlmm-lma- discovery-01.txt
>>
>>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 27 Aug 2009 16:12:38 +0300

Hi,

> So I think it is a MN-assist solution.

The MN is only doing what it would do independent of PMIP being  
deployed or not and the MAG just makes advantage of it. Some existing  
systems & MNs already do this.

Based on the discussion we have had I think it is now worth keeping  
this solution in the I-D. I would, however, reword it like:

    The solution described in this section is similar to the solution
    discussed in Section 3.1.  Instead of deriving the LMA FQDN from the
    MN identity, the MAG receives explicit LMA FQDN or IP address
    information from lower layers, for example, as a part of the normal
    lower layer signaling when the MN attaches to the network.  This
    usually means the MN is also the originator of the LMA information.
    However, the LMA information content as such can be transparent to
    the MN, meaning the MN has no knowledge it being anything LMA
    related.

Cheers,
	Jouni

>> We are a bit on a grey area here. Like the text says such  
>> information  may come from lower layers. If such information  
>> delivery is e.g. part  of the normal L2 attach procedure  
>> independent whether there is PMIP or  not, I would not call it in  
>> that case MN assisted LMA discovery.
>>
>>>
>> mobility management. The content of the configuration data might  
>> then  be different depending whether PMIP is used but that is  
>> transparent to  MNs.
>>
>> Cheers,
>> Jouni
>>
>>
>>>
>>> Regards
>>>
>>> Xiangsong
>>>
>>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 27 Aug 2009 07:41:57 -0700 (PDT)

Hi,
  
  MAG making a DNS query for a service name and randomly selecting one LMA from among the returned replies is a good way of discovering LMA for each MN:
- it does not require MN providing input so it works with unmodified hosts,
- LMA load balancing is achieved.

Regards,

Behcet

----- Original Message ----
> Sent: Thursday, August 27, 2009 8:12:38 AM
> The MN is only doing what it would do independent of PMIP being deployed or not 
> and the MAG just makes advantage of it. Some existing systems & MNs already do 
> this.
> 
> Based on the discussion we have had I think it is now worth keeping this 
> solution in the I-D. I would, however, reword it like:
> 
> > Cc: "Vijay Devarapalli" ; 
> come from lower layers. If such information delivery is e.g. part  of the normal 
> L2 attach procedure independent whether there is PMIP or  not, I would not call 
> it in that case MN assisted LMA discovery.
> >> 
> >>> 
> >> Continuing from the above. If the information that MN provides is configured 
> into MNs and this configuration is independent whether  there is PMIP or not, I 
> would not say that MN is involved in the  mobility management. The content of 
> the configuration data might then  be different depending whether PMIP is used 
> but that is transparent to  MNs.
> >> 
> >> Cheers,
> >> Jouni
> >> 
> >> 
> >>> 
> >>> Regards
> >>> 
> >>> Xiangsong
> >>> 
> >>> 
> >>> ----- Original Message ----- From: "Vijay Devarapalli" > >>> >
> >>> To: "Xiangsong Cui" ; "jouni korhonen" 
> > >>> >
> >>> Cc: 
> >>>> ----- Original Message ----- From: "Vijay Devarapalli" > >>>> >
> >>>> To: "jouni korhonen" ; "Xiangsong Cui"
> >>>> 
> >>>> Cc:

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 28 Aug 2009 10:11:30 +0800

Hi Jouni,

>    the MN, meaning the MN has no knowledge it being anything LMA

If the MN don't know what the information is, why does it include the
content in the transmitted message?

I can't understand this situation: some information content is included
in the signal message, but the origin and the destination do take different
comprehension on this content.

Regards
Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Thursday, August 27, 2009 9:12 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> The MN is only doing what it would do independent of PMIP being  deployed 
> or not and the MAG just makes advantage of it. Some existing  systems & 
> MNs already do this.
>
>> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma- discovery-01.txt
>>
>>
>>> Hi,
>>>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 28 Aug 2009 11:05:35 +0300

Hi,

> content in the transmitted message?

It can be part of a lower layer attach procedure and the MN does what  
it is specified to do.

> comprehension on this content.

For example, the MN has some operator provisioned information that the  
MN knows it needs to signal to the network during the attach procedure  
in order to get access & reach certain desired service. The  
information happens to be in a FQDN format that maps to a specific  
LMA. The MAG knows this fact but the MN does not care/know about it.  
This is analogous to 3G/EPC attach procedure under certain conditions.

Cheers,
	Jouni

>> deployed or not and the MAG just makes advantage of it. Some  
>> existing  systems & MNs already do this.
>>
>> Based on the discussion we have had I think it is now worth  
>> keeping  this solution in the I-D. I would, however, reword it like:
>>

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 28 Aug 2009 16:25:11 +0800

Hi,

please see inline.

Regards/Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Friday, August 28, 2009 4:05 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> It can be part of a lower layer attach procedure and the MN does what  it 
> is specified to do.
>
>
>>
> For example, the MN has some operator provisioned information that the  MN 
> knows it needs to signal to the network during the attach procedure
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In these cases, MN knows what the information is, and knows the
information should be transimitted to the network, and then it does signal
the information to the network.

> in order to get access & reach certain desired service. The  information 
> happens to be in a FQDN format that maps to a specific  LMA. The MAG knows 
> this fact but the MN does not care/know about it.  This is analogous to 
> 3G/EPC attach procedure under certain conditions.
>
> Cheers,
> Jouni
>
>>
>> Regards
>> Xiangsong
>>
>>>>> information may come from lower layers. If such information   delivery 
>>>>> is e.g. part of the normal L2 attach procedure   independent whether 
>>>>> there is PMIP or not, I would not call it in   that case MN assisted 
>>>>> LMA discovery.
>>>>>
>>>>>>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 28 Aug 2009 11:44:16 +0300

Hi,

On Aug 28, 2009, at 11:25 AM, Xiangsong Cui wrote:

>> It can be part of a lower layer attach procedure and the MN does  
>> what  it is specified to do.
>>
>>
>>>
>> For example, the MN has some operator provisioned information that  
>> the  MN knows it needs to signal to the network during the attach  
>> procedure

And what's the problem with that if it is part of the normal lower  
layer attach procedure? The MN has a blob of information that it knows  
what to do with to get an access, but does not know/care about its  
content. Yet, we have not changed anything in the MN that it would do  
normally in any case.

Jouni

>> LMA. The MAG knows this fact but the MN does not care/know about  
>> it.  This is analogous to 3G/EPC attach procedure under certain  
>> conditions.
>>
>> Cheers,
>> Jouni
>>
>>>
>>> Regards
>>> Xiangsong
>>>
>>>>>> independent whether there is PMIP or not, I would not call it  
>>>>>> in   that case MN assisted LMA discovery.
>>>>>>
>>>>>>>
>>>>>> Continuing from the above. If the information that MN provides  
>>>>>> is configured into MNs and this configuration is independent  
>>>>>> whether there is PMIP or not, I would not say that MN is  
>>>>>> involved in the mobility management. The content of the  
>>>>>> configuration data might then be different depending whether  
>>>>>> PMIP is used but that is transparent to MNs.
>>>>>>
>>>>>> Cheers,
>>>>>> Jouni
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Xiangsong
>>>>>>>
>>>>>>>
>>>>>>>> >> In NETLMM, the principle is that the MN should not be  
>>>>>>>> involved
>>>>>>>> in

---

From: Xiangsong Cui <[email-masked]>
Date: Fri, 28 Aug 2009 17:19:18 +0800

Hi Jouni,

> And what's the problem with that if it is part of the normal lower  layer 
> attach procedure? The MN has a blob of information that it knows  what to 
> do with to get an access, but does not know/care about its  content. Yet, 
> we have not changed anything in the MN that it would do  normally in any 
> case.

I don't know what kind of MN or OS can achieve this operation,
maybe you can give me some example.

Even the MN exists, you are now designing a new container, and putting
special new information block in it, the MN must read and include the
newly-added additional information block in the signal message.
Does it not need extension or enhancement?

Regards
Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Friday, August 28, 2009 4:44 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> And what's the problem with that if it is part of the normal lower  layer 
> attach procedure? The MN has a blob of information that it knows  what to 
> do with to get an access, but does not know/care about its  content. Yet, 
> we have not changed anything in the MN that it would do  normally in any 
> case.
>
> Jouni
>
>
>>

---

From: jouni korhonen <[email-masked]>
Date: Fri, 28 Aug 2009 13:56:29 +0300

Hi,

On Aug 28, 2009, at 12:19 PM, Xiangsong Cui wrote:

>> layer attach procedure? The MN has a blob of information that it  
>> knows  what to do with to get an access, but does not know/care  
>> about its  content. Yet, we have not changed anything in the MN  
>> that it would do  normally in any case.
>

As I said in an earlier mail, this procedure is analogous to 3G/EPS  
attach procedure under certain conditions. There's a bunch of such MNs  
out there.. but that is not relevant from the I-D point of view.

> Even the MN exists, you are now designing a new container, and putting

Hmm.. If such MN & lower layer exists then I could not possibly be  
designing any new container as it is already there.

> special new information block in it, the MN must read and include the

If the information blob were transparent to the MN, the MN would not  
see anything special in it.

> newly-added additional information block in the signal message.

And the MN would do the same even if PMIP was not deployed.

Cheers,
	Jouni

>>>> For example, the MN has some operator provisioned information  
>>>> that  the MN knows it needs to signal to the network during the  
>>>> attach  procedure
>> layer attach procedure? The MN has a blob of information that it  
>> knows  what to do with to get an access, but does not know/care  
>> about its  content. Yet, we have not changed anything in the MN  
>> that it would do  normally in any case.
>>
>> Jouni
>>
>>
>>>
>>>> information happens to be in a FQDN format that maps to a  
>>>> specific LMA. The MAG knows this fact but the MN does not care/ 
>>>> know about  it. This is analogous to 3G/EPC attach procedure  
>>>> under certain  conditions.
>>>>
>>>> Cheers,
>>>> Jouni
>>>>
>>>>>
>>>>> Regards
>>>>> Xiangsong
>>>>>
>>>>>>>> independent whether there is PMIP or not, I would not call  
>>>>>>>> Continuing from the above. If the information that MN  
>>>>>>>> provides  is configured into MNs and this configuration is  
>>>>>>>> independent  whether there is PMIP or not, I would not say  
>>>>>>>> that MN is  involved in the mobility management. The content  
>>>>>>>> of the  configuration data might then be different depending  
>>>>>>>> whether  PMIP is used but that is transparent to MNs.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Jouni
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Xiangsong
>>>>>>>>>
>>>>>>>>>

---

From: Xiangsong Cui <[email-masked]>
Date: Sat, 29 Aug 2009 09:16:50 +0800

Hi Jouni,

Please see inline.

Regards
Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Friday, August 28, 2009 6:56 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

> designing any new container as it is already there.

We need some existing examples for this. The solution can not depend on
any nonexistent assumption.

> If the information blob were transparent to the MN, the MN would not  see 
> anything special in it.

The precondition is a problem, another problem is that the MN does do
the action related to mobility management.

Even the action (i.e. offering LMA information ) is not in the
consciousness of the MN, the fact does still exist,
the action is done by the MN and the MN is involved in the mobility
management.

The principle of NETLMM WG is "MN not *involved* in the mobility
management", but not "MN not *active* in the mobility management",
right?

>>>>> LMA. The MAG knows this fact but the MN does not care/ know about  it.

---

From: jouni korhonen <[email-masked]>
Date: Mon, 31 Aug 2009 12:25:43 +0300

Hi Xiangsong,

On Aug 29, 2009, at 4:16 AM, Xiangsong Cui wrote:

>>>> And what's the problem with that if it is part of the normal  
>>>> lower layer attach procedure? The MN has a blob of information  
>>>> that it  knows what to do with to get an access, but does not  
>>>> know/care  about its content. Yet, we have not changed anything  
>>>> in the MN  that it would do normally in any case.
>>>
>> attach procedure under certain conditions. There's a bunch of such  
>> MNs out there.. but that is not relevant from the I-D point of view.
>>
>>>

  If it makes folks happy, we can add a reference to one example of  
such functionality.

    The solution described in this section is similar to the solution
    discussed in Section 3.1.  Instead of deriving the LMA FQDN from the
    MN identity, the MAG receives a LMA FQDN or an IP address  
information
    from lower layers, for example, as a part of the normal lower layer
    signaling when the MN attaches to the network.  One existing example
    of such lower layer functionality is the Access Point Name
    Information Element (APN IE) in 3GPP radio's network access  
signaling
    capable of carrying a FQDN [3GPP.24.008].  However, in general this
    means the MN is also the originator of the LMA information.  The LMA
    information content as such can be transparent to the MN, meaning  
the
    MN has no knowledge it being anything LMA related.

>> If the information blob were transparent to the MN, the MN would  
>> not  see anything special in it.
>

Well.. the charter talks about "specifying any changes to mobile hosts  
is out of scope", which in most cases realizes to no host involvement  
or similar that would require code changes etc. However, in this  
particular case, when we talk about MNs that have desired capabilities  
at lower layers (e.g. in network access signaling), we are not  
changing the mobile host but just taking advantage of the existing  
functionality on the _network_ side.

 From my side, I am done now ;)

Cheers,
	Jouni

>>>>>> It can be part of a lower layer attach procedure and the MN  
>>>>>> does what it is specified to do.
>>>>>>
>>>>>>
>>>>>>>
>>>> And what's the problem with that if it is part of the normal  
>>>> lower layer attach procedure? The MN has a blob of information  
>>>> that it  knows what to do with to get an access, but does not  
>>>> know/care  about its content. Yet, we have not changed anything  
>>>> in the MN  that it would do normally in any case.
>>>>
>>>> Jouni
>>>>
>>>>
>>>>>
>>>>>>>> The MN is only doing what it would do independent of PMIP  
>>>>>>>> being deployed or not and the MAG just makes advantage of it.  
>>>>>>>> Some existing systems & MNs already do this.
>>>>>>>>
>>>>>>>>>> that MN is involved in the mobility management. The  
>>>>>>>>>> content  of the configuration data might then be different  
>>>>>>>>>>>> I disagree. The section explicitly says the MAG receives  
>>>>>>>>>>>> the
>>>>>>>>>>>> LMA FQDN or IP
>>>>>>>>>>>> address from the MN in the lower layers. This is not the  
>>>>>>>>>>>> same
>>>>>>>>>>>> as the MN

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 01 Sep 2009 09:31:04 +0800

Hi Jouni,

It is not only about modification, but also involvement.

In NETLMM WG charter, there is clear statement:

Description of Working Group:

"This working
group is tasked with defining a network-based local mobility
management protocol, where local IP mobility is handled without
                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^
involvement from the mobile node."
^^^^^^^^^^^^^^^^^^^^^^^^^

And as I said before, in this solution, MN is involved in the
mobility management.

So my comment is to remove this solution from the WG draft.

Thank you for your discussion.

Regards
Xiangsong

----- Original Message ----- 
From: "jouni korhonen" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Monday, August 31, 2009 5:25 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

>>>>> knows what to do with to get an access, but does not  know/care  about 
>>>>> its content. Yet, we have not changed anything  in the MN  that it 
>>>>> would do normally in any case.
>>>>
>  If it makes folks happy, we can add a reference to one example of  such 
> functionality.
>
>    MN identity, the MAG receives a LMA FQDN or an IP address  information
>    Information Element (APN IE) in 3GPP radio's network access  signaling
>    information content as such can be transparent to the MN, meaning  the
> Well.. the charter talks about "specifying any changes to mobile hosts  is 
> out of scope", which in most cases realizes to no host involvement  or 
> similar that would require code changes etc. However, in this  particular 
> case, when we talk about MNs that have desired capabilities  at lower 
> layers (e.g. in network access signaling), we are not  changing the mobile 
> host but just taking advantage of the existing  functionality on the 
> _network_ side.
>
>>>>> knows what to do with to get an access, but does not  know/care  about 
>>>>> its content. Yet, we have not changed anything  in the MN  that it 
>>>>> would do normally in any case.
>>>>>
>>>>> Jouni
>>>>>
>>>>>
>>>>>>
>>>>>>> LMA. The MAG knows this fact but the MN does not care/  know about

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Aug 2009 21:34:24 -0700

Hi Xiangsong,

> management protocol, where local IP mobility is handled without

I disagree. Passing the LMA information at L2 is not the same the MN doing
mobility management. So this shouldn't be removed from the draft.

Vijay

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 01 Sep 2009 13:05:46 +0800

Hi Vijay,

I'm not saying the MN does mobility management,
I'm saying the MN, which does the action related to mobility
management, is involved in the mobility management.
I think the mobility management, in this solution, is achieved by
multiple elements, including the MN and the MAG and others.

In my understanding, passing the LMA information at L2 is a
manner of offering the LMA information.
Passing is subset of offering, while offering is a subset of
involvement, which conflicts with the charter.

Regards
Xiangsong

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>; "jouni korhonen" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 01, 2009 12:34 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

>>>>>>> about
>>>>> MNs
>>> is
>>>>>>>>>> If the MN don't know what the information is, why does it 
>>>>>>>>>> include
>>>>>>>>>> the
>>>>>>>>>> in the signal message, but the origin and the destination do 
>>>>>>>>>> take
>>>>>>>>>> different
>>>>>>>>> that
>>>>>>>> information should be transimitted to the network, and then it 
>>>>>>>> does
>>>>>>>> signal
>>>>>>> about
>>>>>>>>> specific
>>>>>>>>>>>>> provides
>>>>>>>>>>>>> the MAG. But we have a sort of working assumption that  the 
>>>>>>>>>>>>> MN
>>>>>>>>>>>>> is able to

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 31 Aug 2009 22:12:56 -0700

Hi Xiansong,

> management, is involved in the mobility management.

No. Again, passing some information at L2 is not the same being "involved"
in mobility management. This is a slippery slope, trying to define when you
can say the MN is "involved" in mobility management.

I think the existing text is fine for an Informational document.

So can we please move on?

Vijay

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 01 Sep 2009 14:10:05 +0800

Hi Vijay,

I am sorry I can't agree on this.
I think this is a dangerous overflow.

For example, let's take a look on MIP4 protocol, which is
host-based. I am sure you know it better than me.

When the MIP4 node sends Registration Request to the network,
it encapsulates the mobility signal in UDP payload.
This mechanism, which offers the binding information, is in scope
of mobility management, is in CMIP scope.

While in this case, the MN sends the LMA information to the network.
In my understanding, binding information and LMA information
are both mobility related information.

If you say the solution of passing LMA information to the network
is in scope of PMIP, could you kindly tell me, where is the boundary
between CMIP and PMIP?

Regards
Xiangsong

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Xiangsong Cui" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 01, 2009 1:12 PM
Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-01.txt

>>>>>>>>> lower
>>>>> such
>>>>>>>>>>>>> However, the LMA information content as such can be 
>>>>>>>>>>>>> transparent
>>>>>>>>>>>>> to
>>>>>>>>> lower
>>>>>>>>>>>>> being
>>>>>>>>>>>>> However, the LMA information content as such can be 
>>>>>>>>>>>>> transparent
>>>>>>>>>>>>> to