IETF Logo Mail Archive

Re: [Mpls-interop] Who will be in Geneva?

"BUSI ITALO" <Italo.Busi@alcatel-lucent.it> Wed, 03 December 2008 12:14 UTC

Return-Path: <mpls-interop-bounces@ietf.org>
X-Original-To: mpls-interop-archive@ietf.org
Delivered-To: ietfarch-mpls-interop-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD94C3A67E5; Wed, 3 Dec 2008 04:14:02 -0800 (PST)
X-Original-To: mpls-interop@core3.amsl.com
Delivered-To: mpls-interop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E5D528C11F for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 04:14:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 H5nxzgYwT3zP for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 04:14:00 -0800 (PST)
Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 42CF228C13A for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 04:13:59 -0800 (PST)
Received: from FRVELSBHS02.ad2.ad.alcatel.com ([155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB3CDsJQ029968; Wed, 3 Dec 2008 13:13:54 +0100
Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 3 Dec 2008 13:13:54 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 3 Dec 2008 13:13:49 +0100
Message-ID: <6FD21B53861BF44AA90A288402036AB401BF2647@FRVELSMBS21.ad2.ad.alcatel.com>
In-Reply-To: <2095F13194CC41BDB8FE61BC7A8187AB@your029b8cecfe>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] Who will be in Geneva?
Thread-Index: AclUcU/5oIARMhvmQv2uz2GlNr/CRAAXkYLg
References: <A79C9B7D57B940FF802C8395F15E232E@your029b8cecfe> <C55A12D2.EB1D%benjamin.niven-jenkins@bt.com> <43284B5A95E36B4AB4A91EBA4E0FC31EFE09F2@DEMUEXC030.nsn-intra.net><43284B5A95E36B4AB4A91EBA4E0FC31EFE09F3@DEMUEXC030.nsn-intra.net><49350F0B.8060605@alcatel-lucent.com><43284B5A95E36B4AB4A91EBA4E0FC31EFE0C10@DEMUEXC030.nsn-intra.net><493512FC.70700@alcatel-lucent.com><43284B5A95E36B4AB4A91EBA4E0FC31EFE0C35@DEMUEXC030.nsn-intra.net> <2095F13194CC41BDB8FE61BC7A8187AB@your029b8cecfe>
From: "BUSI ITALO" <Italo.Busi@alcatel-lucent.it>
To: "Adrian Farrel" <adrian@olddog.co.uk>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>, "VIGOUREUX MARTIN" <Martin.Vigoureux@alcatel-lucent.com>
X-OriginalArrivalTime: 03 Dec 2008 12:13:54.0246 (UTC) FILETIME=[9C213660:01C95540]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Who will be in Geneva?
X-BeenThere: mpls-interop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF MPLS Interoperability Design Team <mpls-interop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mpls-interop>
List-Post: <mailto:mpls-interop@ietf.org>
List-Help: <mailto:mpls-interop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-interop>, <mailto:mpls-interop-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org

Adrian,

I partially agree with you.

LSP hierarchy can be used to:
A) aggregate OAM for a set of LSPs that are parallel for part of their
paths
B) aggregate protection for a set of LSPs that are parallel 
for part of their paths.

TC (or whatever name you wish to give it) can be used to:
A) provide OAM for a part of an LSP path
B) provide protection for a part of an LSP pat

Italo

> -----Original Message-----
> From: mpls-interop-bounces@ietf.org 
> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Tuesday, December 02, 2008 12:30 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); VIGOUREUX MARTIN
> Cc: mpls-interop@ietf.org
> Subject: Re: [Mpls-interop] Who will be in Geneva?
> 
> > First, protection switching in MPLS-TP is independent of the control
> > plane...we can have protection switching even in the 
> absence of a CP.
> 
> Yes
> 
> > Second, GMPLS segment protection really uses LSP hierarchy for
> > protecting a segment......
> 
> No!
> 
> There are many solutions.
> I have warned about using the term "segment protection".
> I will warn again.
> 
> GMPLS "Segment protection" (RFC 4873) does NOT (that is, not, 
> not, not) use 
> hierarchy.
> (Did I say "not"?)
> 
> > TC (or what ever name you select) provides you a clean architectural
> > way to initiate and terminate messages for a part of a path 
> (segment).
> > This can be used for OAM, protection and maybe other purposes in
> > the future as well.
> 
> I also wish you would stop using the term TC because it is 
> just confusing 
> things.
> 
> If what you want to say is that hierarchcial agregation is 
> useful, then we 
> will agree.
> It can be used to provide OAM for a part of an LSP path.
> It can be used to aggregate OAM for a set of LSPs that are 
> parallel for part 
> of their paths.
> It can be used to aggregate protection for a set of LSPs that 
> are parallel 
> for part of their paths.
> 
> This is LSP hierarchy. No need for other terms.
> 
> Adrian
> 
> 
> _______________________________________________
> Mpls-interop mailing list
> Mpls-interop@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls-interop
> 
_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop

v2.8.7 | Report a Bug | By Email