Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in Linear Protection]

[Greg Mirsky <[e-mail]>]

Once again I've went over the limit and had to cut part of discussion.
Resending ...

On Mon, Apr 5, 2010 at 2:32 PM, Greg Mirsky <[e-mail]> wrote:

> Dear Nurit,
> it could be that I've jumped the gun - my apologies.
> I'm thinking of coordinated automatic protection switching without tying it
> to a particular topology. The topology, linear or ring, allows us certain
> optimization of generic principle, method. And I think that the discussion
> stepped up from the linear topology to survivability, protection in MPLS-TP
> in general. If in any MPLS-TP topology coordination between the end-points
> is required, then, I think, that is that common that we can capture in the
> terminology we use when describing protection switching in MPLS-TP. I agree
> that APS might imply SONET/SDH APS, but it is the latter that carries ITU-T
> logo, not the former (my understanding of the history of these).
> It could be M-APS - not most important to me. More important, and I think
> that is what you're advocating, agree on sufficiently descriptive and clear
> terminology. Hope I didn't miss it this time.
>
> Regards,
> Greg
>
>
> On Mon, Apr 5, 2010 at 2:10 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
> [e-mail]> wrote:
>
>>  Hi Greg,
>>
>> I think you misunderstood me…….Did you miss the “*and we **refer to the
>> IETF draft in work in progress on linear protection.”*
>>
>> *In the framework we refer to the linear protection document* in which
>> the protocol elements and procedures are being defined………
>>
>> Whether the Linear protection document refers and uses the ITU-T APS
>> mechanism or utilizes the GMPLS messages’ elements or defines and use a new
>> protocol is open for a discussion…….and any feedback is much appreciated…..
>>
>> I do not think the purpose of the Rosetta Stone document is to describe
>> the ITU-T mechanisms but to “translate” between ITU-T and IETF acronyms and
>> definitions……..
>>
>> Best regards,
>>
>> Nurit
>>
>>
>>
>>
>>
>> *From:* ext Greg Mirsky [mailto:[e-mail]]
>> *Sent:* Tuesday, April 06, 2010 12:00 AM
>> *To:* Sprecher, Nurit (NSN - IL/Hod HaSharon)
>> *Cc:* [e-mail]; Adrian Farrel; Cecil Byles; BUSI ITALO;
>> [e-mail]
>>
>> *Subject:* Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was:
>> in Linear Protection]
>>
>>
>>
>> Dear Nurit,
>> I thought that adding to the Rosetta Stone a description of APS as
>> principle, paradigm of predetermined, coordinated, and implementation
>> non-specific protection might set correct context within MPLS-TP documents.
>> If you disagree, may I suggest CAPS (my favorite because of CRAPS for
>> rings), or ACPS ("C" - for coordinated).
>>
>> Regards,
>> Greg
>>
>> On Mon, Apr 5, 2010 at 1:41 PM, Sprecher, Nurit (NSN - IL/Hod HaSharon) <
>> [e-mail]> wrote:
>>
>> Hi Malcolm,
>>
>> I am not happy to use the acronym APS because one can think that we refer
>> to a specific mechanism used by the ITU-T…it is also the protocol name?
>> isn’t it? At least this is what I can recall from linear and ring
>> protection….(APS and R-APS).
>>
>> I would support any name that hints for the purpose and objective of the
>> protocol.: to *coordinate* the recovery states between the edges of the
>> recovery domain….and please note that this may be used also in mesh
>> protection as well, etc…..………..I think it is better to use the general
>> recovery term…….
>>
>> *I am surprised* to see your words “In terms of biasing the outcome of
>> the discussion I would note that the framework has already suggested the use
>> of the RSVP-TE notify message…..”….*this is misleading*……
>>
>> Since the protection switching should fully operate also in the absence of
>> a control plan, and in order to achieve 50ms protection switching when a
>> control plane exists but does not apply to the performance requirements, we
>> recommend in the framework to use *in-band data-plane driven signaling
>> protocol*……*and we **refer to the IETF draft in work in progress on
>> linear protection. *
>>
>> We also refer to the *GMPLS procedures and messages’ elements** *defined
>> in (RFC 4426, RFC4872 and RFC4873) that are used coordinate the protection
>> states between the edges of the protection domain…..and we also indicate
>> which capabilities *are still missing in these messages*. Section 6.5
>> that *discusses the aspects of the control plane (GMPLS which is the
>> protocol of choice for MPLS-TP)* and refers to existing message that is
>> already defined in GMPLS that can be used for this purpose *if the
>> control plane is used for this sake*……still it written…….: “however,
>> specific message field values remain to be defined for this operation. A
>> further piece of work in needed to allow ………”.
>>
>> *I find it **very correct** that a framework in the IETF refers to
>> existing protocols in the IETF (or protocols that are still in work in
>> progress) that can be used*…….. and indicates what is missing in these
>> protocols and need to be extended...
>>
>> Best regards,
>>
>> Nurit
>>
>>
>>
>>
>>
>> *From:* [e-mail] [mailto:[e-mail]] *On
>> Behalf Of *ext [e-mail]
>> *Sent:* Friday, April 02, 2010 7:37 PM
>> *To:* Adrian Farrel
>> *Cc:* Cecil Byles; [e-mail]; BUSI ITALO
>>
>>
>> *Subject:* Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was:
>> in Linear Protection]
>>
>>
>>
>>
>> All,
>>
>> I have concerns with using the phrase Recovery State Coordination and
>> consequently the acronym RSC.  The term Recovery applies to both protection
>> switching and restoration.  The use of RSC implies that they both need to
>> use the same coordination protocol.  This is clearly not true, in general
>> restoration implies the establishment or activation of a new path.  I
>> therefore support the use of the acronym APS, since it is an abstract
>> protocol that is clearly scoped to protection switching and avoids ambiguity
>> that it may also be applied to restoration.  In terms of biasing the outcome
>> of the discussion I would note that the framework has already suggested the
>> use of the RSVP-TE notify message, so that should be removed as well.
>>
>> Regards,
>>
>> Malcolm
>>
>>   *"Adrian Farrel" <[e-mail]>*
>> Sent by: [e-mail]
>>
>> 02/04/2010 05:54 AM
>>
>> Please respond to
>> Adrian Farrel <[e-mail]>
>>
>> To
>>
>> "BUSI ITALO" <[e-mail]>, <[e-mail]>,
>> "Cecil Byles" <[e-mail]>
>>
>> cc
>>
>> [e-mail]
>>
>> Subject
>>
>> Re: [mpls-tp] Term"PSC" in the Survivability Framework [Was: in
>>  Linear Protection]
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> It's not my job to judge consensus on this list. But as one of the editors
>>
>> of the Survivability Framework I have to move the draft forward.
>>
>> What I think I see is:
>> - Most people prefer not to use the acronym PSC because they
>>  fear people will be confused especially by the expansion Packet
>>  Switch Capable.
>> - A number of people prefer to use the term APS because this is
>>   an established abstract protocol that provides the function needed
>> - A number of people prefer to avoid the term APS for two reasons:
>>   - they don't want the framework to constrain even the abstract
>>      solution
>>   - they fear that using the term will constrain the solution to a
>>      specific message flow/format
>>
>> I can see that the answer in draft-ietf-mpls-tp-linear-protection may be
>> very different from the answer for the Survivability Framework. The Linear
>>
>> Protection draft is expressing a solution and must engage in state
>> machines,
>> message flows, and bits&bytes. The Survivability Framework, on the other
>> hand, is at a very high level; it does not go into the details of a state
>> machine, but simply says that some form of state coordination will be
>> needed
>> through a protocol.
>>
>> At this stage I propose to use the acronym "RSC" (Recovery State
>> Coordination) to identify the protocol that will be used. IMHO this does
>> not
>> prohibit in any way the use of the APS abstract protocol, nor the
>> realisation of an MPLS-TP APS. On the other hand, it also does not
>> prejudge
>> the value of using APS in this situation. It seems to me to be reasonable
>> to
>> phase our work, and this is one way of splitting the decisions points.
>>
>> So (for the Survivability Framework only) I am seeking consensus that we
>> use
>> "RSC".
>>
>> Thanks,
>> Adrian
>>
>> ----- Original Message -----
>> From: "BUSI ITALO" <[e-mail]>
>> To: "Adrian Farrel" <[e-mail]>; <[e-mail]>;
>> "Cecil Byles" <[e-mail]>
>> Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
>> Sent: Friday, April 02, 2010 9:32 AM
>> Subject: RE: [CCAMP] [mpls-tp]
>> [mpls]Term"PSC"indraft-ietf-mpls-tp-linear-protection-01
>>
>>
>> Adrian,
>>
>> I think that this thread discussion is actually proving that the idea to
>> re-define a new term for what everybody in the world known as APS was not
>> a
>> good idea.
>>
>> We therefore better come back and adopt the widely known concept rather
>> than
>> inventing a new term and confuse the whole industry.
>>
>> Regarding your references, I think it is worth clarifying that:
>>
>> - APS is a generic term for the coordination protocol and does not imply
>> any
>> specific protocol implementation;
>>
>> - Ethernet APS is a specific protocol specification of APS in Ethernet
>> networks and it is defined in G.8031;
>>
>> - SONET/SDH APS is a specific protocol specification of APS in SONET/SDH
>> networks and it is defined in G.841;
>>
>> - OTN APS is a specific protocol specification of APS in OTN networks and
>> it
>> is defined in G.873.1
>>
>> What IETF actually should define the specific realization of APS in
>> MPLS-TP
>> networks.
>>
>> I do not see any value in calling PSC such a specific realization while I
>> can see a huge value in calling it as "MPLS-TP APS".
>>
>> Italo
>>
>> P.S. Please note my new email address, [e-mail],
>> effective since 1 November 2009.
>>
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]]
>> > On Behalf Of Adrian Farrel
>> > Sent: giovedì 25 marzo 2010 1.33
>> > To: [e-mail]; Cecil Byles
>> > Cc: [e-mail]; [e-mail]; [e-mail]
>> > Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC"
>> > indraft-ietf-mpls-tp-linear-protection-01
>> >
>> > Huub,
>> >
>> > You will note that the comment in the liaison you reference said:
>> >
>> > "The acronyms PSC and APS are used, in ITU-T APS is a generic
>> > term used in different methodologies and does not provide a solution."
>> >
>> > This was neither a question nor a request for any change. And
>> > it is not really clear that it is a "concern".
>> >
>> > APS is an abstract protocol (G.808.1) with specific
>> > characteristics and behaviors.
>> >
>> > The Survivability Framework deliberately does not prejudge
>> > the abstract protocol or solution protocol that is required.
>> > Instead, it picked another acronym to avoid any assumptions.
>> > This frees the people working in the solution space to choose
>> > the necessary abstract model for the problems they need to
>> > solve, and to develop a protocol realisation that meets the model.
>> > This neither precludes nor forces the use of APS.
>> >
>> > If you like, PSC is simply a generalisation that allows
>> > freedom of interpretation. Viz.
>> >
>> >    In some protection switching schemes (such as bidirectional
>> >    protection switching), it is necessary to coordinate the protection
>> >    state between the edges of the recovery domain.  An MPLS-TP
>> >    Protection State Coordination (PSC) protocol may be used as an in-
>> >    band (i.e., data plane-based) control protocol to align
>> > both ends of
>> >    the protected domain.  Control plane-based mechanism can
>> > also be used
>> >    to coordinate the protection states between the edges of the
>> >    protection domain.
>> >
>> > In the view of the authors, the term "APS" has become
>> > synonymous with specific protocol realisations. For example,
>> > in the working copy of G.8131 I have infront of me, section
>> > 10 describes the "APS Protocol" setting out byte formats and
>> > defining messages to go on the wire. While we can interpret
>> > "APS Protocol" as the technology-specific realisation of
>> > "APS", there are sufficient overtones that if the
>> > Survivability Framework used the term "APS"
>> > it might be construed as support for a specific protocol
>> > realisation. Y.1731 defines APS PDUs for Ethernet which gives
>> > us another competing interpretation of the term. (It is
>> > notable that the term "APS Protocol" is used in G.870 to mean
>> > the abstract protocol, which is subtly different from its use
>> > in G.8131 and Y.1731.)
>> >
>> > Surely the working group would prefer to derive the correct
>> > protocol solution without being constrained except at a
>> > functional level?
>> >
>> > Adrian
>> >
>> >
>>
>>