Re: [Mpls-interop] PST.ppt

Martin Vigoureux <martin.vigoureux@alcatel-lucent.fr> Wed, 03 December 2008 16:43 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 405BF3A6822; Wed, 3 Dec 2008 08:43:04 -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 65F833A6822 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:43:02 -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=[AWL=-0.000, 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 eH1uXBBWzBo6 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:43:00 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 592223A6886 for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 08:42:59 -0800 (PST)
Received: from FRVELSBHS06.ad2.ad.alcatel.com ([155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB3Ggnkg031429; Wed, 3 Dec 2008 17:42:51 +0100
Received: from [172.27.205.136] ([172.27.205.136]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 3 Dec 2008 17:42:50 +0100
Message-ID: <4936B723.3010801@alcatel-lucent.fr>
Date: Wed, 03 Dec 2008 17:43:15 +0100
From: Martin Vigoureux <martin.vigoureux@alcatel-lucent.fr>
Organization: Alcatel-Lucent Bell-Labs
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: "Drake, John E" <John.E.Drake2@boeing.com>
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> <51661468CBD1354294533DA79E85955A0148BB44@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <51661468CBD1354294533DA79E85955A0148BB44@XCH-SW-5V2.sw.nos.boeing.com>
X-OriginalArrivalTime: 03 Dec 2008 16:42:50.0599 (UTC) FILETIME=[2E254770:01C95566]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: mpls-interop-bounces@ietf.org
Errors-To: mpls-interop-bounces@ietf.org

John,

Drake, John E a écrit :
>  
> 
>> -----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.org; 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.
Conversely, I may also have :-)

> 
>> 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.
I see your point,
still, it more looks to me that it takes us farther from the
understanding I have of the original concept, but as emphasized
it may only be a question of understanding.
:-)


> 
>> -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.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