Re: [Mpls-interop] PST.ppt

[Ben Niven-Jenkins <[e-mail]>]

My understanding is the same as Martin's - that the point of a PST(/TC) is
to monitor part of and end to end path, no more.

Although TCM has been part of ITU Recs for a long time, I'm not sure how
many operators actually implement it.  I'm pretty sure BT doesn't because it
makes the operations too complex but I don't look after our transport
networks so I could be wrong.

Ben



On 03/12/2008 17:09, "Drake, John E" <[e-mail]> wrote:

> Very good - it's a question for the group
> 
>> -----Original Message-----
>> From: Martin Vigoureux [mailto:[e-mail]]
>> Sent: Wednesday, December 03, 2008 8:45 AM
>> To: Drake, John E
>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>> [e-mail]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>> Subject: Re: [Mpls-interop] PST.ppt
>> 
>> 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:[e-mail]]
>>>> Sent: Wednesday, December 03, 2008 8:00 AM
>>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>> Cc: Drake, John E; [e-mail]; Weingarten, Yaacov (NSN -
>>>> IL/Hod HaSharon)
>>>> Subject: Re: [Mpls-interop] PST.ppt
>>>> 
>>>> 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:[e-mail]]
>>>>> Sent: Wednesday, December 03, 2008 17:45
>>>>> To: Drake, John E
>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>> [e-mail];
>>>>> 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:[e-mail]]
>>>>>>> Sent: Wednesday, December 03, 2008 6:55 AM
>>>>>>> To: Drake, John E
>>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>> [e-mail];
>>>>>>> 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:[e-mail]]
>>>>>>>>> Sent: Wednesday, December 03, 2008 6:42 AM
>>>>>>>>> To: Drake, John E
>>>>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>> [e-mail];
>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>> Sent: Wednesday, December 03, 2008 6:15 AM
>>>>>>>>>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>>>>>>>>> Cc: [e-mail]; 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:[e-mail]]
>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 16:08
>>>>>>>>>>>> To: Adrian Farrel
>>>>>>>>>>>> Cc: Sprecher, Nurit (NSN - IL/Hod HaSharon);
>>>>>>> [e-mail];
>>>>>>>>>>>> Weingarten, Yaacov (NSN - IL/Hod HaSharon);
>>>> [e-mail]
>>>>>>>>>>>> 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"
>>>> <[e-mail]>
>>>>>>>>>>>> To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>> Cc: "Adrian Farrel" <[e-mail]>uk>;
>>>>>>>>> <[e-mail]>nl>;
>>>>>>>>>>>> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
>>>>>>>>>>>> <[e-mail]>om>; <[e-mail]>
>>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>> Sent: Wednesday, December 03, 2008 14:21
>>>>>>>>>>>> To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
>>>>>>>>>>>> Cc: Adrian Farrel; [e-mail]; Weingarten,
>>>>>>>>>>> Yaacov (NSN -
>>>>>>>>>>>> IL/Hod HaSharon); [e-mail]
>>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>> Sent: Tuesday, December 02, 2008 11:20
>>>>>>>>>>>> To: [e-mail]; Sprecher, Nurit (NSN - IL/Hod
>>>>>>>>>>> HaSharon)
>>>>>>>>>>>> Cc: ext Ben Niven-Jenkins; [e-mail]
>>>>>>>>>>>> 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 [e-mail]
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>>>>>>>>>>> --
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Loa Andersson                         email:
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> Sr Strategy and Standards Manager            [e-mail]
>>>>>>>>>>>> Redback Networks                      phone: +46
>>>> 8 632 77 14
>>>>>>>>>>>> An Ericsson Company
>>>>>>>>>>>> --
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Loa Andersson                         email:
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> Sr Strategy and Standards Manager            [e-mail]
>>>>>>>>>>>> Redback Networks                      phone: +46
>> 8 632 77 14
>>>>>>>>>>>> An Ericsson Company
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Mpls-interop mailing list
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/mpls-interop
>>>>>>>>>>> 
>>> 
>> 
> _______________________________________________
> Mpls-interop mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-interop

_______________________________________________
Mpls-interop mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-interop