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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Huub van Helvoort
Sent: 2011年10月9日 18:58
To: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf