Re: [Mpls-interop] PST.ppt

"Drake, John E" <John.E.Drake2@boeing.com> Wed, 03 December 2008 16:23 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 660493A67E9; Wed, 3 Dec 2008 08:23: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 D1E0D3A68A2 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:23:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 R41pmqdaO6w4 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:23:36 -0800 (PST)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 56E933A67E9 for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 08:23:36 -0800 (PST)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id mB3GNNCC014803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 08:23:23 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id mB3GNNuf013915; Wed, 3 Dec 2008 08:23:23 -0800 (PST)
Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id mB3GNN74013906; Wed, 3 Dec 2008 08:23:23 -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 08:23:23 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 3 Dec 2008 08:23:21 -0800
Message-ID: <51661468CBD1354294533DA79E85955A0148BB44@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <4936AEC3.8040300@alcatel-lucent.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] PST.ppt
Thread-Index: AclVYTOFHa0HsYX6TqiKX3Hft2TMfAAAaNOQ
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> <51661468CBD1354294533DA79E85955A0148BB1D@XCH-SW-5V2.sw.nos.boeing.com> <4936AEC3.8040300@alcatel-lucent.fr>
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: "Martin Vigoureux" <martin.vigoureux@alcatel-lucent.fr>
X-OriginalArrivalTime: 03 Dec 2008 16:23:23.0535 (UTC) FILETIME=[768571F0:01C95563]
Cc: mpls-interop@ietf.org, "Weingarten, Yaacov \(NSN - IL/Hod HaSharon\)" <yaacov.weingarten@nsn.com>
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

 

>-----Original Message-----
>From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.fr] 
>Sent: Wednesday, December 03, 2008 8:08 AM
>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,
>
>I am aware of this ;-)

JD:  I suspected that you might 8->.

>
>PST originates from the ITU-T concept of TC which is mostly 
>used to run OAM, but I may have missed something.
>By saying that a PST can be a working or a protecting, I feel 
>we are going one step further (and I do not have a specific 
>opinion on that, just to clarify).

JD:  As I said, I may have jumped to an incorrect conclusion.

>But if we are going that way, what is the new architectural concept?
>This PST is a full blown lsp/tunnel, nothing else.

JD:  I think what we are adding is the notion of protecting groups of LSPs using LSP hierarchy.  These groups could be either segment protected, which is PST protection, or even end-to-end, which I haven't seen mentioned yet.

>
>-m
>
>Drake, John E a écrit :
>> Martin,
>> 
>> The notion of protecting groups of LSPs for scalability has 
>been part of LSP hierarchy since its inception.  We just never 
>worked out the details of endpoint coordination before.
>> 
>> I was under the impression that working and protecting PSTs 
>were required for MPLS TP, but I perhaps jumped to an 
>incorrect conclusion.  Does the JWT have an opinion on this?
>> 
>> Thanks,
>> 
>> John
>>> -----Original Message-----
>>> From: Martin Vigoureux [mailto:martin.vigoureux@alcatel-lucent.fr]
>>> Sent: Wednesday, December 03, 2008 7:45 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
>>>
>>> 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.orgorg; 
>>>>> 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