Hi,
I have concern about statement on section 9 in RFC5317 by Russ:
> it is technically feasible that the
> existing MPLS architecture can be extended to meet the requirements
> of a Transport profile, and that the architecture allows for a single
> OAM technology for LSPs, PWs, and a deeply nested network.
> Since the publication of RFC 5317, the MPLS WG consensus continues to be that only one OAM solution should become a standard.
As I said in my previous email, it means use same architecture (GACH) for LSP and PW OAM not deduce only one OAM solution should become a standard, and this is no consensus in mpls group. for OAM analysis, which is captured in draft-ietf-mpls-tp-oam-analysis, it is still a draft.
and in section 2 of RFC 5860 (Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks):
>The way in which those protocols are operated and the way
>in which a network operator can control and use the MPLS-TP OAM
>functions SHOULD be as similar as possible to the mechanisms and
>techniques used to operate OAM in other transport technologies.
this requirement is not satisfied by RFCs published.
I fully agree "All MPLS-TP OAM tools should comply with RFC5586" and should satisfy with RFC5860, and provider can pick up subset of them.
finally, I still don't support publish draft-sprecher-mpls-tp-oam-considerations-01.txt as RFC.
B.R.
Feng
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Huub van Helvoort
Sent: 2011年10月9日 18:58
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM)to Informational RFC
Hello Russ,
You write:
> RFC 5317 calls for one, and only one, protocol solution.
> At least that is how I read JWT Agreement.
How the JWT report should be read is written on slide 9 in the PDF:
"This presentation is a collection of *assumptions*, discussion points
and decisions that the combined group has had during the months of
March and April, 2008
This represents the *agreed upon starting point* for the technical
analysis of the T-MPLS requirements from the ITU-T and the MPLS
architecture to meet those requirements"
> The most relevant text seems to be in Section 9:
This text is one of the assumptions, that is why we wrote:
"*They stated that in their view*":
> it is technically feasible that the
> existing MPLS architecture can be extended to meet the requirements
> of a Transport profile, and that the architecture allows for a single
> OAM technology for LSPs, PWs, and a deeply nested network.
The "OAM technology" in this text refers to to way the OAM frames can be detected in a data-stream.
The text you quote is from the summary section, it summarizes the slides 19 - 22: "*MPLS-TP Major Solution Constructs*" which address the GAL-GAch solution.
We now have the GAL-GAch technology (RFC5586) to detect OAM frames and this technology will be used in PW and LSP, and enables the use of OAM in deeply nested networks.
> Since the publication of RFC 5317, the MPLS WG consensus continues
> to be that only one OAM solution should become a standard.
All MPLS-TP OAM tools should comply with RFC5586.
A service provider can now pick any set or sub-set of the available OAM tools and use them without fear to disrupt the internet.
Looking at the current discussions, there is no consensus (yet) on whether we need a comprehensive set of OAM tools, or a very limited set of OAM tools.
Best regards, Huub (JWT, Ad-Hoc, MEAD member).
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf