Re: [netext] [Netext] localized route optimization - roaming issue

Marco Liebsch <liebsch@nw.neclab.eu> Wed, 09 September 2009 15:15 UTC

Return-Path: <Marco.Liebsch@nw.neclab.eu>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3C928C2D8 for <netext@core3.amsl.com>; Wed, 9 Sep 2009 08:15:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level:
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_26=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKvUYyayCXnn for <netext@core3.amsl.com>; Wed, 9 Sep 2009 08:15:29 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0762328C238 for <netext@ietf.org>; Wed, 9 Sep 2009 08:15:29 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 7DE442C0004E6; Wed, 9 Sep 2009 17:16:01 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN5ePZnD3Qp8; Wed, 9 Sep 2009 17:16:01 +0200 (CEST)
Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 4B7032C0004DB; Wed, 9 Sep 2009 17:15:46 +0200 (CEST)
Received: from [10.1.2.175] ([10.1.2.175]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 17:15:46 +0200
Message-ID: <4AA7C6A2.8080003@nw.neclab.eu>
Date: Wed, 09 Sep 2009 17:15:46 +0200
From: Marco Liebsch <liebsch@nw.neclab.eu>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Qin Wu <sunseawq@huawei.com>
References: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local> <4AA64EA8.7030008@nw.neclab.eu> <06bc01ca312a$0369e720$260ca40a@china.huawei.com>
In-Reply-To: <06bc01ca312a$0369e720$260ca40a@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Sep 2009 15:15:46.0204 (UTC) FILETIME=[67D3DDC0:01CA3160]
Cc: netext@ietf.org, Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
Subject: Re: [netext] [Netext] localized route optimization - roaming issue
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2009 15:15:30 -0000

Hi Qin,

Qin Wu wrote:
> Hi, Marco:
> I think roaming case is very usful. It help us to better understanding
> on how local routing works when MN roams over PMIPv6 domain.
> So I support to add a new section to talk about roaming section. 
>   
Yes, I am ok with this.
> In this sense, we can loose requirements on PMIPv6 components distribution.
> i.e., MN's LMA and CN's LMA need not stay with MN and CN within the same
> PMIPv6 domain, But it is required that MN and CN should connect to corresponding MAGs
> within the same PMIPv6 domain,  am I right?
>   
I think your text fits better when talking about administrative domains ;-)
I'd propose to take the last picture about the roaming case and take this as
base for the discussion. In my opinion, we need to talk about administrative
domains to resolve this. I also see the need to define (according to 
David's comment)
what's an administrative domain this the context of this discussion.

marco

> Based these loose requirements or assumption, I think use case with two LMAs can be supported.
>
> As regarding protocol desgin, I think there is no reason to delay this work if folks have arrived at common understanding.
>
> Regards!
> -Qin
> ----- Original Message ----- 
> From: "Marco Liebsch" <liebsch@nw.neclab.eu>
> To: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com>
> Cc: "Qin Wu" <sunseawq@huawei.com>; "Marco Liebsch" <marco.liebsch@nw.neclab.eu>; <netext@ietf.org>
> Sent: Tuesday, September 08, 2009 8:31 PM
> Subject: Re: [netext] [Netext] localized route optimization - roaming issue
>
>
>   
>> Hi Mohana, Qin,
>>
>> ok, we can take a section "Roaming Aspects" into account for the PS and 
>> discuss
>> applicability of localized routing. We can add this section to the 
>> initial WG draft
>> of the PS. If folks consider this later as not useful, we can take it 
>> out again.
>>
>> Btw, I think this discussion can happen in parallel to protocol design, 
>> just to address
>> some folks' concern with a PS to delay the protocol design.
>>
>> From the discussion we had so far, obviously it's common understanding that
>> use cases with two LMAs should be supported, right?
>>
>> Thanks,
>> marco
>>
>>
>> Mohana Jeyatharan wrote:
>>     
>>> Hi Qin, Marco and all,
>>>
>>>   
>>>       
>>>> I am wondering whether we need to write something to address roaming
>>>>     
>>>>         
>>> issue
>>>   
>>>       
>>>> or what we talk about here is just to clarify how to understand local
>>>>     
>>>>         
>>> MAG
>>>   
>>>       
>>>> routing applicability.
>>>>     
>>>>         
>>> Yes, I agree. The PS needs to mention about some deployment scenarios
>>> wherevthe local MAG routing can be applied (ex bcos of SA available) and
>>> scenarios where cannot be applied (SA cannot be established so cannot
>>> perform). 
>>> *The scenarios Marco attached previously can be used. 
>>> *Perhaps some terminilogy such as PMIPv6 domain, administrative domain
>>> etc in the PS will be helpful. I mean PMIPv6 doamin is already well
>>> defined but re-emphasizing it w.r.t. to the work in local MAG routing
>>> will be useful.
>>>
>>> I guess these canbe captured without any details of solutions in the PS
>>> draft. Such capturing is useful to identify whether the solution drafts
>>> we have address all such cases of local MAG route optimization
>>> Again this is my opinion.
>>>
>>> Thanks.
>>>
>>> BR,
>>> Mohana
>>>
>>>
>>>   
>>>       
>>>> -----Original Message-----
>>>> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On
>>>>     
>>>>         
>>> Behalf
>>>   
>>>       
>>>> Of Qin Wu
>>>> Sent: Monday, September 07, 2009 11:02 AM
>>>> To: Mohana Jeyatharan; Marco Liebsch
>>>> Cc: netext@ietf.org
>>>> Subject: Re: [netext] [Netext] localized route optimization - roaming
>>>> issue
>>>>
>>>> Hi,Mohana and Marco:
>>>> I am wondering whether we need to write something to address roaming
>>>>     
>>>>         
>>> issue
>>>   
>>>       
>>>> or what we talk about here is just to clarify how to understand local
>>>>     
>>>>         
>>> MAG
>>>   
>>>       
>>>> routing applicability.
>>>> As for me, I think it is beneficial to have some explaination
>>>>     
>>>>         
>>> text/section
>>>   
>>>       
>>>> addressing this in the PS draft.
>>>>
>>>> Regards!
>>>> -Qin
>>>> ----- Original Message -----
>>>> From: "Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com>
>>>> To: "Marco Liebsch" <marco.liebsch@nw.neclab.eu>
>>>> Cc: "Qin Wu" <sunseawq@huawei.com>; "Sri Gundavelli"
>>>>     
>>>>         
>>> <sgundave@cisco.com>;
>>>   
>>>       
>>>> "Cypher, David E." <david.cypher@nist.gov>; <netext@mail.mobileip.jp>
>>>> Sent: Friday, September 04, 2009 4:44 PM
>>>> Subject: RE: [Netext] localized route optimization - roaming issue
>>>>
>>>>
>>>> Hi Marco,
>>>>
>>>> Such disussion we had is more to understand the local MAG routing
>>>> applicability.
>>>>
>>>>     
>>>>         
>>>>> Or should we provide additional info in the
>>>>> PS?
>>>>>       
>>>>>           
>>>> So, I think in PS we need not talk about SA between MAG. Or LMA or
>>>>     
>>>>         
>>> some
>>>   
>>>       
>>>> other entity helping in creating the security association between
>>>>     
>>>>         
>>> MAGs.
>>>   
>>>       
>>>> Thanks.
>>>>
>>>> BR,
>>>> Mohana
>>>>     
>>>>         
>>>>> -----Original Message-----
>>>>> From: Marco Liebsch [mailto:marco.liebsch@nw.neclab.eu]
>>>>> Sent: Friday, September 04, 2009 4:19 PM
>>>>> To: Mohana Jeyatharan
>>>>> Cc: Marco Liebsch; Qin Wu; Sri Gundavelli; Cypher, David E.;
>>>>> netext@mail.mobileip.jp
>>>>> Subject: Re: [Netext] localized route optimization - roaming issue
>>>>>
>>>>> Hi Mohana,
>>>>>
>>>>> Mohana Jeyatharan schrieb:
>>>>>       
>>>>>           
>>>>>> Hi Marco and all,
>>>>>>
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we
>>>>>>> do not talk about the scope of a single MN's mobility, but the
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> relation
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> between mobility management components of two MNs.
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> I agree on this.
>>>>>>
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> solution: PMIPv6 components, which exchange signaling in the
>>>>>>>           
>>>>>>>               
>>>> context
>>>>     
>>>>         
>>>>>> of
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> route optimization, must share a security association. Everything
>>>>>>>           
>>>>>>>               
>>>> else
>>>>     
>>>>         
>>>>>> is
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> deployment specific.
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> Here we can probably explain which entities need security
>>>>>>         
>>>>>>             
>>>> association
>>>>     
>>>>         
>>>>>> for RO to be succussful. This is more towards solution space tied
>>>>>>         
>>>>>>             
>>> to
>>>   
>>>       
>>>>>> different local MAG RO scenarios. I think the current localized RO
>>>>>> solution drafts have captured these.
>>>>>>
>>>>>>         
>>>>>>             
>>>>> We can only provide examples. To establish a forwarding tunnel
>>>>>       
>>>>>           
>>> between
>>>   
>>>       
>>>>> MAGs does not mean
>>>>> we need an SA between them. Only if we perform signaling between
>>>>>       
>>>>>           
>>> MAGs,
>>>   
>>>       
>>>>> the SA is required.
>>>>> As you said, this is solution specific. So, to be on the safe side,
>>>>>       
>>>>>           
>>> we
>>>   
>>>       
>>>>> could discuss the
>>>>> picture and indicate that the solution may need an SA between the
>>>>>       
>>>>>           
>>> two
>>>   
>>>       
>>>>> associated LMAs
>>>>> and the two associated MAGs. Or should we provide additional info in
>>>>>       
>>>>>           
>>>> the
>>>>     
>>>>         
>>>>> PS?
>>>>>
>>>>> marco
>>>>>
>>>>>       
>>>>>           
>>>>>> BR,
>>>>>> Mohana
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: Marco Liebsch [mailto:liebsch@nw.neclab.eu]
>>>>>>> Sent: Thursday, September 03, 2009 11:56 PM
>>>>>>> To: Qin Wu
>>>>>>> Cc: Sri Gundavelli; Cypher, David E.; Mohana Jeyatharan; Marco
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> Liebsch;
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> netext@mail.mobileip.jp
>>>>>>> Subject: Re: [Netext] localized route optimization - roaming
>>>>>>>           
>>>>>>>               
>>> issue
>>>   
>>>       
>>>>>>> Now coming back to my original opinion that I don't see benefit
>>>>>>>           
>>>>>>>               
>>> in
>>>   
>>>       
>>>>>>> mandating support for or ruling out any particular roaming
>>>>>>>           
>>>>>>>               
>>>> scenarios.
>>>>     
>>>>         
>>>>>>> The picture I proposed could be used in the Problem Statement
>>>>>>>           
>>>>>>>               
>>> (PS)
>>>   
>>>       
>>>>>>> at the most to discuss *issues* when components being associated
>>>>>>> with MN1 and MN2 are distributed between administrative domains.
>>>>>>> The PMIPv6 domain term does not fit in here, in my opinion, as we
>>>>>>> do not talk about the scope of a single MN's mobility, but the
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>> relation
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> between mobility management components of two MNs.
>>>>>>>
>>>>>>>  From that picture I see that only one requirement derives for
>>>>>>>           
>>>>>>>               
>>> the
>>>   
>>>       
>>>>>>> protocol
>>>>>>> solution: PMIPv6 components, which exchange signaling in the
>>>>>>>           
>>>>>>>               
>>>> context
>>>>     
>>>>         
>>>>>> of
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> route optimization, must share a security association. Everything
>>>>>>>           
>>>>>>>               
>>>> else
>>>>     
>>>>         
>>>>>> is
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> deployment specific.
>>>>>>>
>>>>>>> marco
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Qin Wu wrote:
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>>>> Thank for your clarification.
>>>>>>>> In this sense, no matter which domain the MN's MAG belongs to,
>>>>>>>>             
>>>>>>>>                 
>>> as
>>>   
>>>       
>>>>>> long
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> as the MN does not change LMA and MN's current MAG can setup SA
>>>>>>>           
>>>>>>>               
>>>> with
>>>>     
>>>>         
>>>>>> MN's
>>>>>>
>>>>>>         
>>>>>>             
>>>>>>> LMA, MN is still in the same PMIP6 domain as its LMA. Right?
>>>>>>>
>>>>>>>           
>>>>>>>               
>>>>>>>> Regard!
>>>>>>>> -Qin
>>>>>>>> ----- Original Message -----
>>>>>>>> From: "Sri Gundavelli" <sgundave@cisco.com>
>>>>>>>> To: "Qin Wu" <sunseawq@huawei.com>
>>>>>>>> Cc:
>>>>>>>>             
>>>>>>>>                 
>>>> _______________________________________________
>>>> netext mailing list
>>>> netext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netext
>>>>     
>>>>