Re: [mpls-tp] [mpls]Term"PSC" indraft-ietf-mpls-tp-linear-protection-01
BUSI ITALO <Italo.Busi <at> alcatel-lucent.com>
2010-04-02 08:32:56 GMT
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
P.S. Please note my new email address, Italo.Busi <at> alcatel-lucent.com, effective since 1 November 2009.
> -----Original Message-----
> From: ccamp-bounces <at> ietf.org [mailto:ccamp-bounces <at> ietf.org]
> On Behalf Of Adrian Farrel
> Sent: giovedì 25 marzo 2010 1.33
> To: hhelvoort <at> chello.nl; Cecil Byles
> Cc: mpls <at> ietf.org; CCAMP <at> ietf.org; mpls-tp <at> ietf.org
> Subject: Re: [CCAMP] [mpls-tp] [mpls]Term"PSC"
> 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?
> ----- Original Message -----
> From: "Huub van Helvoort" <hhelvoort <at> chello.nl>
> To: "Cecil Byles" <Cecil.Byles <at> interoute.com>
> Cc: <mpls <at> ietf.org>; <CCAMP <at> ietf.org>; <mpls-tp <at> ietf.org>
> Sent: Wednesday, March 24, 2010 5:14 PM
> Subject: Re: [CCAMP] [mpls-tp] [mpls] Term"PSC"
> 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
> > (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
> CCAMP <at> ietf.org
> CCAMP mailing list
> CCAMP <at> ietf.org
CCAMP mailing list
CCAMP <at> ietf.org