Re: [Mpls-interop] PST.ppt
"Drake, John E" <John.E.Drake2@boeing.com> Wed, 03 December 2008 17:28 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 3D27028C1BF;
Wed, 3 Dec 2008 09:28:39 -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 DD9793A6844
for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 09:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.533
X-Spam-Level:
X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066,
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 N0UwiLQw4aEj for <mpls-interop@core3.amsl.com>;
Wed, 3 Dec 2008 09:28:29 -0800 (PST)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com
[130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id 3E7683A67ED
for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 09:28:29 -0800 (PST)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4])
by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with
ESMTP id mB3HS2xn005269
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Wed, 3 Dec 2008 11:28:02 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1])
by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id
mB3HS1dV011222; Wed, 3 Dec 2008 09:28:01 -0800 (PST)
Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com
[129.172.192.157])
by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id
mB3HS0wB011117; Wed, 3 Dec 2008 09:28:01 -0800 (PST)
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);
Wed, 3 Dec 2008 09:28:01 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 3 Dec 2008 09:27:58 -0800
Message-ID: <51661468CBD1354294533DA79E85955A0148BBD0@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026060DED9E@ftrdmel2>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] PST.ppt
Thread-Index: AclVZptZ+RMqnLdbTNGFEestu6Ar6QAAXVxgAADlfeA=
References: <43284B5A95E36B4AB4A91EBA4E0FC31E01010A6F@DEMUEXC030.nsn-intra.net> <49367E70.5040900@pi.nu> <F7868E2F4547486A89715B01B2B2CC38@your029b8cecfe> <49368C2E.9090802@pi.nu> <132D3444FA314908B2997D63471534D3@your029b8cecfe> <493692D8.8000808@pi.nu><43284B5A95E36B4AB4A91EBA4E0FC31E01010B53@DEMUEXC030.nsn-intra.net><4936945F.9050600@alcatel-lucent.fr><51661468CBD1354294533DA79E85955A0148BADA@XCH-SW-5V2.sw.nos.boeing.com><49369AB8.5060203@alcatel-lucent.fr><51661468CBD1354294533DA79E85955A0148BADF@XCH-SW-5V2.sw.nos.boeing.com><49369DCE.60908@alcatel-lucent.fr><51661468CBD1354294533DA79E85955A0148BB06@XCH-SW-5V2.sw.nos.boeing.com><4936A997.90103@alcatel-lucent.fr><43284B5A95E36B4AB4A91EBA4E0FC31E01010C0B@DEMUEXC030.nsn-intra.net><4936AD12.6080208@alcatel-lucent.fr><51661468CBD1354294533DA79E85955A0148BB3D@XCH-SW-5V2.sw.nos.boeing.com>
<4936B784.5030008@alcatel-lucent.fr>
<7DBAFEC6A76F3E42817DF1EBE64CB026060DED9E@ftrdmel2>
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <julien.meuric@orange-ftgroup.com>, <martin.vigoureux@alcatel-lucent.fr>
X-OriginalArrivalTime: 03 Dec 2008 17:28:01.0000 (UTC)
FILETIME=[7DABA680:01C9556C]
Cc: mpls-interop@ietf.org
Subject: Re: [Mpls-interop] PST.ppt
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org
Julien, I actually think that PST protection would follow the model of RFC 4872, where the PST is an e2e LSP. Doing segment protection of a PST hurts my head, but it would probably work. Thanks, John >-----Original Message----- >From: julien.meuric@orange-ftgroup.com >[mailto:julien.meuric@orange-ftgroup.com] >Sent: Wednesday, December 03, 2008 9:14 AM >To: martin.vigoureux@alcatel-lucent.fr; Drake, John E >Cc: mpls-interop@ietf.org >Subject: RE: [Mpls-interop] PST.ppt > >Hi. > >Let me try to rephrase what I've understood (correct me if I'm wrong). > >Your intend is to do segment recovery (RFC 4873) on a group of >contained LSPs (from a PST1 to PST2) and NOT e2e recovery (RFC >4872) on PSTs, right? Would it be consistent with the >procedure applying segment recovery to a piece of my PST? I >fear it might be a mess in some cases, for instance when >having a PST head end node (recovering at LSP level) being >also a segment branching node (recovering at PST level)... 8-| > >Regards, > >Julien > > >-----Original Message----- >From: mpls-interop-bounces@ietf.org >[mailto:mpls-interop-bounces@ietf.org] On Behalf Of Martin Vigoureux > >John, > >I think we are indeed down to the point of having to answer >the question you raise: >Should the PSTs be protected or not? >My understanding is the following: >PSTs are entities used to monitor the liveliness and >performance of the LSPs they tunnel. >PSTs do so by in fact monitoring their own liveliness/performance. >In case a defect occurs the recovery is done at the LSP level. > >As such my understanding was that PSTs need not be protected >but if my understanding is incorrect and/or we decide they >should be, I am fine :-) > >-m > >Drake, John E a écrit : >> Martin, >> >> It will be some combination of new work, RFC 4873, the LSP >hierarchy RFC, and the end to end recovery RFC. As I >indicated in a crossing e-mail, perhaps I am incorrect in >saying that PST protection switching is required for MPLS TP, >in which case we wouldn't work on it. >> >> Thanks, >> >> John >>> -----Original Message----- >>> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.fr] >>> >>> Nurit, John, >>> >>> so as to make sure I correctly understand your aim, do you plan to >>> use rfc4873 to establish the second PST? >>> thanks >>> >>> -m >>> >>> Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit : >>>> You could say the same ting for PWs that are transmitted via LSPs. >>>> You do not protect the LSP, there is no protection and >>> working LSPs but there are working tunneled PWs and protection PWs. >>>> I think we have working PST and protection PST to protect >>> the LSPs that are tunneled via the PSTs...... >>>> I hope this clarifies...... >>>> >>>> -----Original Message----- >>>> From: ext Martin Vigoureux >>> [mailto:martin.vigoureux@alcatel-lucent.fr] >>>> Sent: Wednesday, December 03, 2008 17:45 >>>> To: Drake, John E >>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); >mpls-interop@ietf.orgorg; >>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon) >>>> Subject: Re: [Mpls-interop] PST.ppt >>>> >>>> John >>>> >>>> ok, then what I am saying is that there should not be a notion of >>>> working and protecting PST. >>>> There should be working LSPs tunnelled in a PST and >protecting LSPs >>>> tunnelled in some other PST but I do not believe that this >>> second PST >>>> should be the protecting of the first. >>>> Hope this clarifies. >>>> >>>> -m >>>> >>>> Drake, John E a écrit : >>>>> Martin, >>>>> >>>>> There could be working and protecting LSPs as well, but >>> that would be completely transparent to the PSTs, and the operation >>> of the PST protection switch would be completely transparent to the >>> contained LSPs. I.e., if the working PST fails and the contained >>> LSPs are moved to the protecting PST, none of the contained LSPs >>> would be aware of the move and none of them would initiate a >>> protection switch to their protecting LSPs. >>>>> The PST endpoints need to be aware of the individual LSPs, >>> so there would need to be some coordination between them as the set >>> of contained LSPs changes. >>>>> Thanks, >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Martin Vigoureux >[mailto:martin.vigoureux@alcatel-lucent.fr] >>>>>> Sent: Wednesday, December 03, 2008 6:55 AM >>>>>> To: Drake, John E >>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); >>> mpls-interop@ietf.org; >>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) >>>>>> Subject: Re: [Mpls-interop] PST.ppt >>>>>> >>>>>> John, >>>>>> >>>>>> if I read you correctly does this mean that the switch-over is >>>>>> performed at the PST level and not anymore at the LSP >>> level (and so >>>>>> that there are no more working and protecting LSPs, only >>> LSPs which >>>>>> are transparently switched when the PST that tunnels them is >>>>>> switched from primary to secondary)? >>>>>> >>>>>> -m >>>>>> >>>>>> Drake, John E a écrit : >>>>>>> Martin, >>>>>>> >>>>>>> There is a working PST, a protecting PST, and a set of one >>>>>> or more LSPs (or PWs). When the working PST is up, it >>> contains the >>>>>> set of one or more LSPs (or PWs). When the working PST is >>> down, the >>>>>> protecting PST contains the set of one or more LSPs (or PWs). >>>>>>> Thanks, >>>>>>> >>>>>>> John >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Martin Vigoureux >>> [mailto:martin.vigoureux@alcatel-lucent.fr] >>>>>>>> Sent: Wednesday, December 03, 2008 6:42 AM >>>>>>>> To: Drake, John E >>>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); >>> mpls-interop@ietf.org; >>>>>>>> Weingarten,Yaacov (NSN - IL/Hod HaSharon) >>>>>>>> Subject: Re: [Mpls-interop] PST.ppt >>>>>>>> >>>>>>>> John, >>>>>>>> >>>>>>>> I understand but I do not understand the need for dual >>> protection >>>>>>>> (i.e. having working and protecting LSPs and in addition >>> a working >>>>>>>> and a protecting PST) I think we only need working and >>> protecting >>>>>>>> LSPs and PSTs around them. The difference may be subtle >>> but may be >>>>>>>> not in terms of operations. >>>>>>>> By reading working and protecting I implicitly read that >>> a switch >>>>>>>> over will happen between the two and I guess we want to >>> swith LSPs >>>>>>>> from a PST to another one but we do not need (want) to >>> switch a PST >>>>>>>> to another PST. Do we? >>>>>>>> If I am not clear enough, let me know. :-) >>>>>>>> >>>>>>>> -m >>>>>>>> >>>>>>>> >>>>>>>> Drake, John E a écrit : >>>>>>>>> I think there would be a working and a protecting PST, both >>>>>>>> with an inband OAM channel. When the working PST is >up, it will >>>>>>>> contain a set of one or more LSPs (or PWs). When the >>> working PST >>>>>>>> fails, the set of one or more LSPs is moved to the >>> protecting PST. >>>>>>>>> Presumably, the inband OAM channel on the working PST is >>>>>>>> used to detect its failure and the inband OAM channel on the >>>>>>>> protecting PST is used to coordinate the movement of the >>> LSPs (or >>>>>>>> PWs) to it. >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Martin Vigoureux >>> [mailto:martin.vigoureux@alcatel-lucent.fr] >>>>>>>>>> Sent: Wednesday, December 03, 2008 6:15 AM >>>>>>>>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon) >>>>>>>>>> Cc: mpls-interop@ietf.org; Weingarten,Yaacov (NSN - IL/Hod >>>>>>>>>> HaSharon) >>>>>>>>>> Subject: Re: [Mpls-interop] PST.ppt >>>>>>>>>> >>>>>>>>>> Nurit, >>>>>>>>>> >>>>>>>>>> clarification question :-) >>>>>>>>>> is the intent to protect the PST or to protect to LSPs and >>>>>>>> be able to >>>>>>>>>> run OAM (at large) on segments of the protecting LSPs once >>>>>>>> the switch >>>>>>>>>> over has been done? >>>>>>>>>> thanks >>>>>>>>>> >>>>>>>>>> -m >>>>>>>>>> >>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) a écrit : >>>>>>>>>>> The intention is to protect the PST....and switch over the >>>>>>>> tunneled >>>>>>>>>>> LSPs into a protected PST when there is a fault condition >>>>>>>> along the >>>>>>>>>>> working PST. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>>>>>>>> Sent: Wednesday, December 03, 2008 16:08 >>>>>>>>>>> To: Adrian Farrel >>>>>>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon); >>>>>> hhelvoort@chello.nl; >>>>>>>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon); >>> mpls-interop@ietf.org >>>>>>>>>>> Subject: Re: PST.ppt >>>>>>>>>>> >>>>>>>>>>> Adrian, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Adrian Farrel wrote: >>>>>>>>>>>>> I don't think that it should any different. >>>>>>>>>>>> Good >>>>>>>>>>>> >>>>>>>>>>>>> So 2nd PE from the left pops the tunnel label and swaps >>>>>>>> the inner >>>>>>>>>>>>> label and then pushes the new tunnel label. Is that >>>>>> what you say? >>>>>>>>>>>> Yup. Normal LSR behavior. >>>>>>>>>>>> >>>>>>>>>>>>> Same for the 3rd PE? >>>>>>>>>>>> Why would this be any different from normal LSR >>> behavior? :-) >>>>>>>>>>> I don't look for or hope for any difference ;). >>>>>>>>>>> >>>>>>>>>>> Assuming there is a PST from the 3rd to the 4th PE also? >>>>>>>>>>> >>>>>>>>>>> What is protected from e.g. 3rd PE to the 4th PE the entire >>>>>>>>>> containing >>>>>>>>>>> tunnel or the each separate contained tunnel? >>>>>>>>>>> >>>>>>>>>>> /Loa >>>>>>>>>>> >>>>>>>>>>>> A >>>>>>>>>>>> >>>>>>>>>>>>> Adrian Farrel wrote: >>>>>>>>>>>>>> Loa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why would this be any different from normal LSR behavior? >>>>>>>>>>>>>> >>>>>>>>>>>>>> P1 sees only the PST labels PEs pop the PST >label and see >>>>>>>>>>>>>> the e2e label and >>> process it as >>>>>>>>>>> normal. >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Adrian >>>>>>>>>>>>>> ----- Original Message ----- From: "Loa Andersson" >>> <loa@pi.nu> >>>>>>>>>>>>>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" >>>>>>>>>>> <nurit.sprecher@nsn.com> >>>>>>>>>>>>>> Cc: "Adrian Farrel" <adrian@olddog.co.uk>uk>; >>>>>>>> <hhelvoort@chello.nl>nl>; >>>>>>>>>>>>>> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" >>>>>>>>>>>>>> <yaacov.weingarten@nsn.com>om>; <mpls-interop@ietf.org> >>>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 12:41 PM >>>>>>>>>>>>>> Subject: Re: PST.ppt >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Nurit, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ok fine, however ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In your figure will the 2nd and 3rd PEs label swap >>>>>>>> the label on >>>>>>>>>>>>>>> E2E tunnels LSP? Or is the same label showing up at >>>>>>>> the 4th PE? >>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: >>>>>>>>>>>>>>>> Oops......my mistake.......here is the updated >>> figure...... >>>>>>>>>>>>>>>> The intention was to refer to a SS-PW. Accidentally I >>>>>>>>>> referred to >>>>>>>>>>> T-PE >>>>>>>>>>>>>>>> and S-PE. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We can provide also another figure for the MS-PW case. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Note also that the figure is adapted with the >>> new term - PST >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: ext Loa Andersson [mailto:loa@pi.nu] >>>>>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 14:21 >>>>>>>>>>>>>>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon) >>>>>>>>>>>>>>>> Cc: Adrian Farrel; hhelvoort@chello.nl; Weingarten, >>>>>>>>>> Yaacov (NSN - >>>>>>>>>>>>>>>> IL/Hod HaSharon); mpls-interop@ietf.org >>>>>>>>>>>>>>>> Subject: PST question: Was (Re: [Mpls-interop] Who >>>>>> will be in >>>>>>>>>>> Geneva?) >>>>>>>>>>>>>>>> Renaming the thread - a little late but anyway ... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> at risk asking the obvious, since I'm still reading >>>>>>>> through the >>>>>>>>>>>>>>>> thread? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Nurit, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In your figure will the S-PEs label swap the label on >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> E2E tunnels LSP? Or is the same label showing up at the >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> second T-PE? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> /Loa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Loa Andersson email: >>>>>>>>>>> loa.andersson@redback.com >>>>>>>>>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>>>>>>>>> Redback Networks phone: +46 >>> 8 632 77 14 >>>>>>>>>>>>>>> An Ericsson Company >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Loa Andersson email: >>>>>>>>>>> loa.andersson@redback.com >>>>>>>>>>>>> Sr Strategy and Standards Manager loa@pi.nu >>>>>>>>>>>>> Redback Networks phone: +46 >8 632 77 14 >>>>>>>>>>>>> An Ericsson Company >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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
- [Mpls-interop] PST.ppt Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] PST.ppt Loa Andersson
- Re: [Mpls-interop] PST.ppt Adrian Farrel
- Re: [Mpls-interop] PST.ppt Loa Andersson
- Re: [Mpls-interop] PST.ppt Adrian Farrel
- Re: [Mpls-interop] PST.ppt Loa Andersson
- Re: [Mpls-interop] PST.ppt Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Loa Andersson
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Adrian Farrel
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] PST.ppt Loa Andersson
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt julien.meuric
- Re: [Mpls-interop] PST.ppt Drake, John E
- Re: [Mpls-interop] PST.ppt Martin Vigoureux
- Re: [Mpls-interop] PST.ppt Ben Niven-Jenkins
- Re: [Mpls-interop] PST.ppt BRUNGARD, DEBORAH A, ATTLABS
- Re: [Mpls-interop] PST.ppt Huub van Helvoort
- [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Adrian Farrel
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Adrian Farrel
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Luyuan Fang (lufang)
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Loa Andersson
- Re: [Mpls-interop] MPLS over MPLS-TP hejia 48726
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Shah, Himanshu
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Shah, Himanshu
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Shah, Himanshu
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Shah, Himanshu
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Shah, Himanshu
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Adrian Farrel
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP George Swallow
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Sprecher, Nurit (NSN - IL/Hod HaSharon)
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP BRUNGARD, DEBORAH A, ATTLABS
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Eric Gray
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Ben Niven-Jenkins
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E
- Re: [Mpls-interop] MPLS over MPLS-TP Rahul Aggarwal
- Re: [Mpls-interop] MPLS over MPLS-TP Stewart Bryant
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Malis, Andrew G. (Andy)
- Re: [Mpls-interop] MPLS over MPLS-TP Loa Andersson
- Re: [Mpls-interop] MPLS over MPLS-TP Drake, John E