Re: [Mpls-interop] PST.ppt

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

 

>-----Original Message-----
>From: Sprecher, Nurit (NSN - IL/Hod HaSharon) 
>[mailto:[e-mail]] 
>Sent: Wednesday, December 03, 2008 7:53 AM
>To: ext Martin Vigoureux; Drake, John E
>Cc: [e-mail]; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
>Subject: RE: [Mpls-interop] PST.ppt
>
>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.

JD:  There could a working/protecting PW pair, each of which is bound to a working/protecting LSP pair.  An LSP protection switch underneath the working PW would be transparent to it, so the only time there would be a PW protection switch would be when both the working and protecting LSPs underneath the working PW failed.

>I think we have working PST and protection PST to protect the 
>LSPs that are tunneled via the PSTs......

JD:  This sounds like you are agreeing with me.

>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: [phone]
>>>>>>>>>> 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