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

"LEVRAU, LIEVEN (LIEVEN)" <llevrau@alcatel-lucent.com> Tue, 02 December 2008 09:45 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 C70933A6829; Tue, 2 Dec 2008 01:45:34 -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 05B6F3A6BE9 for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 01:45:34 -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 6DVtZyRbisE6 for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 01:45:33 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id D48543A6829 for <mpls-interop@ietf.org>; Tue, 2 Dec 2008 01:45:31 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB29jOb8008128 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Dec 2008 10:45:24 +0100
Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 2 Dec 2008 10:45:24 +0100
From: "LEVRAU, LIEVEN (LIEVEN)" <llevrau@alcatel-lucent.com>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>, Adrian Farrel <adrian@olddog.co.uk>, "hhelvoort@chello.nl" <hhelvoort@chello.nl>
Date: Tue, 2 Dec 2008 10:45:24 +0100
Thread-Topic: [Mpls-interop] Who will be in Geneva?
Thread-Index: AclUX0GU08L0XtjcRbebnmVsK88glAAAeXsgAABgTRA=
Message-ID: <4D3F2B2A3FE4B54DBF449418B192A1FE74693681@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com>
References: <A79C9B7D57B940FF802C8395F15E232E@your029b8cecfe> <C55A12D2.EB1D%benjamin.niven-jenkins@bt.com> <43284B5A95E36B4AB4A91EBA4E0FC31EFE09F2@DEMUEXC030.nsn-intra.net> <4934FCC2.7030305@chello.nl> <5D6BC3F282284834A176BD399603BD23@your029b8cecfe> <43284B5A95E36B4AB4A91EBA4E0FC31EFE0B70@DEMUEXC030.nsn-intra.net>
In-Reply-To: <43284B5A95E36B4AB4A91EBA4E0FC31EFE0B70@DEMUEXC030.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
Cc: "mpls-interop@ietf.org" <mpls-interop@ietf.org>, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <yaacov.weingarten@nsn.com>
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

All,
So this is for the "protection LSP" or is this for the working TCtunnels?
In any case, assume that there is only a single TCTunnel between the two clouds (in the picture Nurit provided -thanks for the pics) how is the head-end informed about any malfunctioning detected via OAM of the intermediated TCTunnel?
There should then be an OAM interworking between the S-PEs and the head-end?
Assume that the intermediate TCTunnel has multiple different LSPs that termiate at different PEs? How are they informed of any failures?
In the both cases that could work via AIS but then we would need potentially need more information in the AIS.

./
Lieven

-----Original Message-----
From: mpls-interop-bounces@ietf.org [mailto:mpls-interop-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: 02 December 2008 10:37
To: Adrian Farrel; hhelvoort@chello.nl
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon); mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi,
I agree that we need to find a better name......
What about the figure in the second slide of the attached?
If multiple LSPs transmit via the same physical path in the first domain and have the same constraints, why cannot we aggregate them and run OAM per the aggregated in the first domain?
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Tuesday, December 02, 2008 11:20
To: hhelvoort@chello.nl; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: ext Ben Niven-Jenkins; mpls-interop@ietf.org
Subject: Re: [Mpls-interop] Who will be in Geneva?

Hi Huub.

> The TC aggregate is not a TC anymore, it should IMHO be referred to as 
> a tunnel.

Yes!

Which is not to say that it is not a useful construct for reducing OAM overhead.

I think (OK, I know) that I suggested we avoid using the TC language as I thought we would find it unhelpful. Perhaps when we meet to go through this, we can draw pictures and work out the language later?

A 


_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop