Re: [Mpls-interop] PST.ppt

[Martin Vigoureux <[e-mail]>]

John,

I am aware of this ;-)

PST originates from the ITU-T concept of TC which is mostly used
to run OAM, but I may have missed something.
By saying that a PST can be a working or a protecting, I feel we
are going one step further (and I do not have a specific opinion
on that, just to clarify).
But if we are going that way, what is the new architectural concept?
This PST is a full blown lsp/tunnel, nothing else.

-m

Drake, John E a écrit :
> Martin,
> 
> The notion of protecting groups of LSPs for scalability has been part of LSP hierarchy since its inception.  We just never worked out the details of endpoint coordination before.
> 
> I was under the impression that working and protecting PSTs were required for MPLS TP, but I perhaps jumped to an incorrect conclusion.  Does the JWT have an opinion on this?
> 
> Thanks,
> 
> John
>> -----Original Message-----
>> From: Martin Vigoureux [mailto:[e-mail]] 
>> Sent: Wednesday, December 03, 2008 7: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
>>
>> 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