Re: [Mpls-interop] PST.ppt

Martin Vigoureux <martin.vigoureux@alcatel-lucent.fr> Wed, 03 December 2008 16:00 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 F016A3A67E9; Wed, 3 Dec 2008 08:00:51 -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 67A933A67E9 for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:00:50 -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 L04qXDM9Azux for <mpls-interop@core3.amsl.com>; Wed, 3 Dec 2008 08:00:49 -0800 (PST)
Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 5457F3A690B for <mpls-interop@ietf.org>; Wed, 3 Dec 2008 08:00:48 -0800 (PST)
Received: from FRVELSBHS02.ad2.ad.alcatel.com ([155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id mB3Fxs2Q016014; Wed, 3 Dec 2008 16:59:54 +0100
Received: from [172.27.205.136] ([172.27.205.136]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Wed, 3 Dec 2008 16:59:54 +0100
Message-ID: <4936AD12.6080208@alcatel-lucent.fr>
Date: Wed, 03 Dec 2008 17:00:18 +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: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <nurit.sprecher@nsn.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> <43284B5A95E36B4AB4A91EBA4E0FC31E01010C0B@DEMUEXC030.nsn-intra.net>
In-Reply-To: <43284B5A95E36B4AB4A91EBA4E0FC31E01010C0B@DEMUEXC030.nsn-intra.net>
X-OriginalArrivalTime: 03 Dec 2008 15:59:54.0348 (UTC) FILETIME=[2E9492C0:01C95560]
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

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