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

"Mohana Jeyatharan" <Mohana.Jeyatharan@sg.panasonic.com> Mon, 07 September 2009 03:32 UTC

Return-Path: <Mohana.Jeyatharan@sg.panasonic.com>
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 5104D3A6359 for <netext@core3.amsl.com>; Sun, 6 Sep 2009 20:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.91
X-Spam-Level: *
X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 M-V8qN7levsJ for <netext@core3.amsl.com>; Sun, 6 Sep 2009 20:32:33 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 245E43A6840 for <netext@ietf.org>; Sun, 6 Sep 2009 20:32:33 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id n873WtL0021736; Mon, 7 Sep 2009 12:32:55 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili06) with ESMTP id n873Wtu18872; Mon, 7 Sep 2009 12:32:55 +0900 (JST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 07 Sep 2009 11:29:32 +0800
Message-ID: <5F09D220B62F79418461A978CA0921BD03879D03@pslexc01.psl.local>
In-Reply-To: <01a801ca2f67$84709c70$260ca40a@china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] [Netext] localized route optimization - roaming issue
Thread-Index: AcovZxIWCWjGnaSUQgqwsy/rei1aCAAA06rQ
From: Mohana Jeyatharan <Mohana.Jeyatharan@sg.panasonic.com>
To: Qin Wu <sunseawq@huawei.com>, Marco Liebsch <marco.liebsch@nw.neclab.eu>
Cc: netext@ietf.org
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: Mon, 07 Sep 2009 03:32:34 -0000

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