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

"Drake, John E" <John.E.Drake2@boeing.com> Tue, 02 December 2008 15:42 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 B09603A67D7; Tue, 2 Dec 2008 07:42:16 -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 8A9913A6902 for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 07:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 R0X9LruaMFZS for <mpls-interop@core3.amsl.com>; Tue, 2 Dec 2008 07:42:14 -0800 (PST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 547A83A69D3 for <mpls-interop@ietf.org>; Tue, 2 Dec 2008 07:41:23 -0800 (PST)
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mB2Ff2Pe010788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Dec 2008 07:41:11 -0800 (PST)
Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mB2Ff2Oe013945; Tue, 2 Dec 2008 09:41:02 -0600 (CST)
Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mB2Ff17Y013914; Tue, 2 Dec 2008 09:41:02 -0600 (CST)
Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Dec 2008 07:41:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 2 Dec 2008 07:41:00 -0800
Message-ID: <51661468CBD1354294533DA79E85955A0148B779@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <79F2E2FA3D134DCA85251132D1311BA3@your029b8cecfe>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] Who will be in Geneva?
Thread-Index: AclUkd8SncU8D9btSVCrB2n+rv/6HAAAbrLA
References: <A79C9B7D57B940FF802C8395F15E232E@your029b8cecfe> <C55A12D2.EB1D%benjamin.niven-jenkins@bt.com><43284B5A95E36B4AB4A91EBA4E0FC31EFE09F2@DEMUEXC030.nsn-intra.net><4934FCC2.7030305@chello.nl> <51661468CBD1354294533DA79E85955A0148B763@XCH-SW-5V2.sw.nos.boeing.com> <79F2E2FA3D134DCA85251132D1311BA3@your029b8cecfe>
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <hhelvoort@chello.nl>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.com>
X-OriginalArrivalTime: 02 Dec 2008 15:41:01.0472 (UTC) FILETIME=[60EBAA00:01C95494]
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,

Upon reflection, do we really need either the term 'tandem connection'
or the term 'path segment tunnel'?  We have the terms 'hierarchical
LSP', 'containing LSP', and 'contained LSP'.  All we are talking about
is adding an OAM channel to an LSP.

That said, how about 'path segment LSP (PSL)' which is defined to be a
containing hierarchical LSP with an associated inband OAM channel?

Thanks,

John

>-----Original Message-----
>From: Adrian Farrel [mailto:adrian@olddog.co.uk] 
>Sent: Tuesday, December 02, 2008 7:22 AM
>To: Drake, John E; hhelvoort@chello.nl; Sprecher, Nurit (NSN - 
>IL/Hod HaSharon)
>Cc: mpls-interop@ietf.org
>Subject: Re: [Mpls-interop] Who will be in Geneva?
>
>The term that is crystallizing is "path segment tunnel" (PST)
>
>Does that do the job?
>
>Adrian
>
>----- Original Message -----
>From: "Drake, John E" <John.E.Drake2@boeing.com>
>To: <hhelvoort@chello.nl>nl>; "Sprecher, Nurit (NSN - IL/Hod HaSharon)" 
><nurit.sprecher@nsn.com>
>Cc: <mpls-interop@ietf.org>
>Sent: Tuesday, December 02, 2008 3:13 PM
>Subject: Re: [Mpls-interop] Who will be in Geneva?
>
>
>> If we say that the OAM channel is associated with the containing LSP,
>> then we could have a tandem connection as currently defined 
>(1:1 with an
>> LSP) while having the benefits of 1 OAM channel for N contained LSPs.
>>
>>>-----Original Message-----
>>>From: Huub van Helvoort [mailto:hhelvoort@chello.nl]
>>>Sent: Tuesday, December 02, 2008 1:16 AM
>>>To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>Cc: mpls-interop@ietf.org
>>>Subject: Re: [Mpls-interop] Who will be in Geneva?
>>>
>>>Hi Ben and Nurit,
>>>
>>>We definitly have to have a f-2-f discussion about TC, I think
>>>there is still some confusion.
>>>
>>>> Scalability of TC (or whatever we call it) is basically if you have
>>>> 1:1 mapping between TC and LSP. But if you have 1:n mapping TC and
>>>> many LSPs the main concern can be solved.
>>>
>>>TC is 1:1 related to a single LSP, this is how TC is defined
>>>in the Transport environment. A TC can be created either by
>>>stacking or by using the MEG level methodology (also used in
>>>the transport ethernet)
>>>
>>>> If you define TC in reasonable areas (e.g. across a domain in a
>>>> multi-domain network) and the TC aggregate multiple LSPs
>>>then IMO the
>>>> construction of TC is the cleanest one and works well with OAM and
>>>> with protection.
>>>
>>>The TC aggregate is not a TC anymore, it should IMHO be
>>>referred to as a tunnel.
>>>
>>>Cheers, Huub.
>>>
>>>> -----Original Message-----
>>>> From: mpls-interop-bounces@ietf.org
>>>> [mailto:mpls-interop-bounces@ietf.org] On Behalf Of ext Ben
>>>> Niven-Jenkins
>>>> Sent: Tuesday, December 02, 2008 00:17
>>>> To: Adrian Farrel; mpls-interop@ietf.org
>>>> Subject: Re: [Mpls-interop] Who will be in Geneva?
>>>>
>>>> Adrian,
>>>>
>>>> On 27/11/2008 22:27, "Adrian Farrel" <adrian@olddog.co.uk> wrote:
>>>>> I ended up with a modest list of MPLS-TP design team folk
>>>willing to
>>>>> squander their evenings in Geneva working on drafts. Must
>>>be that the
>>>> Swiss
>>>>> night life is too exciting!
>>>>
>>>> Or that there is no Q.Whisky in SG15 ;-)
>>>>
>>>>> Lastly, I would like to see if I can understand the 
>issues with the
>>>> OAM
>>>>> techniques proposed. Can we continue to use TTL? Does the idea of
>>>> using
>>>>> nesting for all OAM segments really hold up? Is the OAM cart in
>>>>> danger
>>>> of
>>>>> driving the protection hobbyhorse (pardon my mixed metaphore).
>>>>
>>>> I'm no OAM expert (I leave that to Tom :-) ) but I am yet to be
>>>> convinced by nesting all OAM segments for the reason that it sounds
>>>> complicated and that means to me that it will be expensive
>>>to run and
>>>> to scale.  It also sounds like I'd have to have my network
>>>constructed
>>>> in a particular way to be able to use OAM which means even
>>>in the best
>>>> run network I will at some point not be able to run OAM when
>>>I need it
>>>> (and the customer is screaming at me) because the network wasn't
>>>> constructed correctly (either by design or actual configuration !=
>>>> design).
>>>>
>>>> Ben
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>--
>>>================================================================
>>>                   http://www.van-helvoort.eu/
>>>================================================================
>>>Always remember that you are unique...just like everyone else...
>>>
>>>_______________________________________________
>>>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 
>
>
>
_______________________________________________
Mpls-interop mailing list
Mpls-interop@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-interop