Subject: Re: [mpls] [CCAMP] [mpls-tp] Term"PSC" indraft-ietf-mpls-tp-linear-protection-01

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 2 Apr 2010 10:32:56 +0200

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, [email-masked], effective since 1 November 2009.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Adrian Farrel
> Sent: giovedì 25 marzo 2010 1.33
> To: [email-masked]; Cecil Byles
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> 
> 
> ----- Original Message -----
> From: "Huub van Helvoort" <[email-masked]>
> To: "Cecil Byles" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 24, 2010 5:14 PM
> Subject: Re: [CCAMP] [mpls-tp] [mpls] Term"PSC" 
> indraft-ietf-mpls-tp-linear-protection-01
> 
> 
> Hello Cecil,
> 
> You wrote:
> 
> > Can I therefore also asked how PSC "Protection State 
> Coordination" in the 
> > MPLS-TP parlance align with ITU-T 808.1 recommendation that 
> "defines the 
> > generic functional models, characteristics and processes 
> associated with 
> > various linear protection schemes for connection-oriented 
> layer networks; 
> > e.g., Optical Transport Networks (OTN), Synchronous Digital 
> Hierarchy 
> > (SDH) networks and Asynchronous Transfer Mode (ATM) 
> networks" and the 
> > sections covering  Terms and Definitions as well as 
> Abbreviations.  IMO 
> > all transport engineers and the general telecom community 
> understand that 
> > 1+1 or 1:1 are either SNCP or APS. Hence why introduce a 
> new TLA (three 
> > letter abbreviation) cover the same function and feature 
> for MPLS-TP.  I 
> > can only agree that this will only cause confusion.
> 
> I agree with you.
> 
> In addition to that:
> The ITU-T experts that reviewed the survivability draft had the same
> concerns, and expressed that in their reply liaison for the review of
> this draft: https://datatracker.ietf.org/liaison/618/ that was
> sent in november last year.
> This concern has not been addressed yet.
> 
> Regards, Huub.
> 
> 
> -- 
> ================================================================
> Always remember that you are unique...just like everyone else...
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp 
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>