IETF Logo Mail Archive

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

"Adrian Farrel" <adrian@olddog.co.uk> Tue, 02 December 2008 11:30 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 0F7763A6C24; Tue, 2 Dec 2008 03:30:00 -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 A405C28C125 for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 03:29:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
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 LVuZiKsllsXL for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 03:29:57 -0800 (PST)
Received: from protext01.itu.ch (protext01.itu.ch [156.106.192.41]) by core3.amsl.com (Postfix) with ESMTP id 9D2CA3A6C24 for <mpls-interop@ietf.org>; Tue, 2 Dec 2008 03:29:57 -0800 (PST)
Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2008 12:29:51 +0100
Received: From mail6.itu.ch ([156.106.192.22]) by protext01.itu.ch (WebShield SMTP v4.5 MR3) id 1228217390453; Tue, 2 Dec 2008 12:29:50 +0100
Received: from your029b8cecfe ([156.106.216.176]) by mail6.itu.ch (8.14.3/8.14.3) with ESMTP id mB2BThQp352834; Tue, 2 Dec 2008 12:29:44 +0100 (MET)
Message-ID: <2095F13194CC41BDB8FE61BC7A8187AB@your029b8cecfe>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "Sprecher, Nurit \(NSN - IL/Hod HaSharon\)" <nurit.sprecher@nsn.com>, "ext Martin Vigoureux" <martin.vigoureux@alcatel-lucent.com>
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>
Date: Tue, 2 Dec 2008 11:29:40 -0000
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mail6.itu.ch [156.106.192.22]); Tue, 02 Dec 2008 12:29:50 +0100 (MET)
X-OriginalArrivalTime: 02 Dec 2008 11:29:51.0046 (UTC) FILETIME=[4A3F2660:01C95471]
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
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org

> 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

v2.8.7 | Report a Bug | By Email