Re: [Mpls-interop] PST.ppt

"Drake, John E" <John.E.Drake2@boeing.com> Wed, 03 December 2008 15:58 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 E37133A68C3; Wed, 3 Dec 2008 07:58:23 -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 7A23328B23E for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 07:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.482
X-Spam-Level:
X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 92fKUy9uq7g5 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 07:58:22 -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 125AE3A6AA9 for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 07:58:22 -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 mB3Fw91k026461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 Dec 2008 07:58:09 -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 mB3Fw9Wd009536; Wed, 3 Dec 2008 07:58:09 -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 mB3Fw8Xa009493; Wed, 3 Dec 2008 07:58:09 -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 07:58:08 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 3 Dec 2008 07:58:06 -0800
Message-ID: <51661468CBD1354294533DA79E85955A0148BB1C@XCH-SW-5V2.sw.nos.boeing.com>
In-Reply-To: <4936A997.90103@alcatel-lucent.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Mpls-interop] PST.ppt
Thread-Index: AclVXh5bYD4rhMbsRomGvPAJNfenGgAAG17g
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>
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: "Martin Vigoureux" <martin.vigoureux@alcatel-lucent.fr>
X-OriginalArrivalTime: 03 Dec 2008 15:58:08.0991 (UTC) FILETIME=[EFC85EF0:01C9555F]
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

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