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
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, 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"
> 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" <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"
> 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
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
> _______________________________________________
> CCAMP mailing list
> CCAMP <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
_______________________________________________
CCAMP mailing list
CCAMP <at> ietf.org
https://www.ietf.org/mailman/listinfo/ccamp
Ben
On 25/03/2010 08:52, "Alexander Vainshtein"
<Alexander.Vainshtein <at> ecitele.com> wrote:
> Adrian,
> Lots of thanks for pointing to 5513, I've missed its publication.
> IMHO and FWIW (which are not covered by 5513) it is extremely relevant for the
> MPLS-TP project.
> Do you consider 5513bis to cover MPLS-TP?
>
> Regards,
> Sasha
>
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk]
> Sent: Thursday, March 25, 2010 9:56 AM
> To: Alexander Vainshtein; Vivien Sterling
> Cc: mpls <at> ietf.org; CCAMP <at> ietf.org; mpls-tp <at> ietf.org
> Subject: Re: [CCAMP] [mpls] Term "PSC"
> indraft-ietf-mpls-tp-linear-protection-01
>
> For issues related to clashes of acronyms please see RFC 5513.
>
>
> ----- Original Message -----
> From: "Alexander Vainshtein" <Alexander.Vainshtein <at> ecitele.com>
> To: "Vivien Sterling" <vivien.sterling <at> gmail.com>
> Cc: <mpls <at> ietf.org>; <CCAMP <at> ietf.org>; <mpls-tp <at> ietf.org>
> Sent: Wednesday, March 24, 2010 8:30 AM
> Subject: Re: [CCAMP] [mpls] Term "PSC"
> indraft-ietf-mpls-tp-linear-protection-01
>
>
> Vivien and all,
> AFAIK, PSC stands for "Protection State Coordination" in the MPLS-TP
> parlance (see MPLS-TP Survivability
> Framework<
>
> --
> Cheers,
> Vivien
>
>
>
> ------------------------------------------------------------------------------
> --
>
>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP <at> ietf.org
>> 
RSS Feed