Re: [netext] Needs of traffic spec. on MAG?

"Koodli, Rajeev" <rkoodli@cisco.com> Tue, 03 August 2010 05:27 UTC

Return-Path: <rkoodli@cisco.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 17DA53A6842 for <netext@core3.amsl.com>; Mon, 2 Aug 2010 22:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.366
X-Spam-Level:
X-Spam-Status: No, score=-10.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 uRAqVo4+ilxk for <netext@core3.amsl.com>; Mon, 2 Aug 2010 22:27:20 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A79B63A67FC for <netext@ietf.org>; Mon, 2 Aug 2010 22:27:20 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAPpFV0ytJV2d/2dsb2JhbACgB3GoLptVhTkEiz0
X-IronPort-AV: E=Sophos;i="4.55,307,1278288000"; d="scan'208";a="142610800"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 03 Aug 2010 05:27:48 +0000
Received: from exchtewks1.starentnetworks.com (starent-networks-nat-64-102-236-4.cisco.com [64.102.236.4]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o735RlwM000794; Tue, 3 Aug 2010 05:27:47 GMT
Received: from exchtewks3.starentnetworks.com ([10.2.4.31]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Aug 2010 01:25:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 03 Aug 2010 01:22:55 -0400
Message-ID: <4D35478224365146822AE9E3AD4A26661212E688@exchtewks3.starentnetworks.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [netext] Needs of traffic spec. on MAG?
Thread-Index: AcsytikYD93WVSpoQESnyWK0nAj+sQAFcS6J
References: <4c5025dc.1b768e0a.5695.6b00@mx.google.com><1280322397.4001.21.camel@acorde.it.uc3m.es><BF345F63074F8040B58C00A186FCA57F1F66885569@NALASEXMB04.na.qualcomm.com><4D35478224365146822AE9E3AD4A26661212E67F@exchtewks3.starentnetworks.com> <AANLkTiniH6k_pOw2B=n_5JhU_4ye+t2Qzu33B4Ry8Jb2@mail.gmail.com>
From: "Koodli, Rajeev" <rkoodli@cisco.com>
To: Tran Minh Trung <trungtm@etri.re.kr>
X-OriginalArrivalTime: 03 Aug 2010 05:25:58.0276 (UTC) FILETIME=[5A789440:01CB32CC]
Cc: netext@ietf.org, "Laganier, Julien" <julienl@qualcomm.com>
Subject: Re: [netext] Needs of traffic spec. on MAG?
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: Tue, 03 Aug 2010 05:27:22 -0000

Even though the logical interface can make the packets available to the MN, the main issue is whether MAG1 forwards those packets.
MAG1 needs to advertise p3 as well. It is for such cases we need signaling from LMA *whenever* the LMA decides to move the flow(s).

-Rajeev


-----Original Message-----
From: trungtm2909@gmail.com on behalf of Tran Minh Trung
Sent: Mon 8/2/2010 7:48 PM
To: Koodli, Rajeev
Cc: Laganier, Julien; cjbc@it.uc3m.es; Youn-Hee Han; netext@ietf.org
Subject: Re: [netext] Needs of traffic spec. on MAG?
 
I agree that the prefix p3, according to RFC 5213 , does not have to
be simultaneously assigned to MAG1. However when we use logical
interface at the MN, the prefix p3 should be shareable to allow flow
mobility.  In addition, the logical interface can receive packets sent
to any of its sub-interfaces as described in
draft-melia-netext-logical-interface-support-01 (property #2).

The question here is how to change RFC 5213 to support shared-prefix model?

Regards,
TrungTM


On Fri, Jul 30, 2010 at 7:45 AM, Koodli, Rajeev <rkoodli@cisco.com> wrote:
>
> Single prefix on multiple MAGs is clearly one choice.
>
> We agree that the prefix has to be valid on an interface for the corresponding flow to traverse the MAG.
> If MAG1 has prefix p1 and MAG2 has p2, then the simplest form is p1 and p2 are valid on both MAG1 and MAG2.
> However, I should also be able to assign p3 to MAG2 (for example), which you can do today with RFC 5213.
> The prefix p3 does not have to be simultaneously assigned to MAG1. This should be continued to be allowed with the flow mobility support.
>
> -Rajeev
>
>


>
> -----Original Message-----
> From: netext-bounces@ietf.org on behalf of Laganier, Julien
> Sent: Thu 7/29/2010 4:49 AM
> To: cjbc@it.uc3m.es; Youn-Hee Han
> Cc: netext@ietf.org
> Subject: Re: [netext] Needs of traffic spec. on MAG?
>
> Carlos Jesús Bernardos Cano wrote:
>>
>> Dear Youn-Hee,
>>
>> On Wed, 2010-07-28 at 21:43 +0900, Youn-Hee Han wrote:
>> > Dear Bernardos,
>> >
>> >
>> >
>> > I'd like to ask a question about
>> > "draft-bernardos-netext-pmipv6-flowmob-00."
>> >
>> > In the call procedure figure, I noticed that traffic specification is
>> > delivered to MAG from LMA.
>> >
>> > I understand that the specification should be managed at LMA to do a
>> > traffic filtering.
>> >
>> >
>> >
>> > However, is such a traffic filtering still needed at MAG?
>>
>> The MAG needs to know the flow that is gonna be routed through it, so
>> it can insert the required routing state.
>
> If a single prefix is use across all of the MN accesses then there's no need for this.
>
>> > IMHO, it is not needed at MAG. If so, why is the specification
>> > delivered to MAG?
>>
>> This is something that can be discussed. The minimum info required is
>> the MN's prefix of the moved flow, so the route is installed at the MAG.
>> If finer control is required (e.g., prevent the MN send flows through a
>> MAG that is not the one the LMA has setup flow mobility state, or other
>> purposes), then the flow mobility (traffic selector, e.g., 5-tuple)
>> should be delivered to the MAG.
>
> I don't think this is needed.
>
>> > Isn't sufficient that the home network prefix related to the traffic
>> > is delivered to MAG?
>>
>> That'd be the minimum info. As mentioned before, the MAG may need the
>> whole flow definition, and in that case the LMA has to deliver that
>> information to the MAG.
>
> If a single prefix is use across all of the MN accesses then there's no need to do this.
>
> --julien
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext
>



-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404