Re: [Mpls-interop] PST.ppt

[Martin Vigoureux <[e-mail]>]

if using p&r mechanisms then I agree that it should more be 4872 than
4873 (I introduced 4873 earlier and should have talked about 4872 in
place).
While talking about p&r, then I guess the bypass tunnel of the FRR
facility backup mode is a good candidate to be PST as well as. no?

-m

Drake, John E a écrit :
> Julien,
> 
> I actually think that PST protection would follow the model of RFC 4872, where the PST is an e2e LSP.  Doing segment protection of a PST hurts my head, but it would probably work.
> 
> Thanks,
> 
> John
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] 
>> Sent: Wednesday, December 03, 2008 9:14 AM
>> To: [e-mail]; Drake, John E
>> Cc: [e-mail]
>> Subject: RE: [Mpls-interop] PST.ppt
>>
>> Hi.
>>
>> Let me try to rephrase what I've understood (correct me if I'm wrong).
>>
>> Your intend is to do segment recovery (RFC 4873) on a group of 
>> contained LSPs (from a PST1 to PST2) and NOT e2e recovery (RFC 
>> 4872) on PSTs, right? Would it be consistent with the 
>> procedure applying segment recovery to a piece of my PST? I 
>> fear it might be a mess in some cases, for instance when 
>> having a PST head end node (recovering at LSP level) being 
>> also a segment branching node (recovering at PST level)... 8-|
>>
>> Regards,
>>
>> Julien
>>
>>
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Martin Vigoureux
>>
>> 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]]
>>>>
>>>> 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