Re: [Mpls-interop] PST.ppt

["Drake, John E" <[e-mail]>]

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