Brian,
I think that points that Huub is raising are:
a) The text quoted from page 113 RFC 5317 "the architecture allows for a
single OAM technology for LSPs, PWs" is being used as (part of) the
rational for only having a single OAM solution, however page 12 of RFC
5317 states that the subsequent slides represent an agreed starting point
for the work.
b) The IETF have developed two different solutions, one for LSP and
another for PWs and this confirms that the quoted text was just a starting
point.
I agree with you that, in some cases for good reasons, more than one
solution is developed and deployed.
Regards,
Malcolm
Brian E Carpenter <brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
30/09/2011 03:47 PM
To
huubatwork(_at_)gmail(_dot_)com
cc
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
Huub,
On 2011-09-30 20:19, Huub van Helvoort wrote:
All,
Section 1,1 also contains the text:
[RFC5317] includes the analysis that "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."
This is a quote from slide 113 in the PDF version of RFC5317 and should
be read in realtion to the statement on slide 12 of the same RFC:
"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"
So the quoted text in the draft is one of the assumptions.
The fact that there are currently *two* OAM mechanisms (and not a
*single*), i.e. one for PW and one for LSP proves that the assumption
was not correct.
I'm sorry, I don't understand your logic. You seem to be saying that
the fact that two solutions have been designed proves that the assumption
that a single solution is possible was false. That doesn't follow at
all. The engineering profession has a long history of producing multiple
solutions where a single one was possible, and this seems to be just
another such case.
This isn't news. I quote from RFC 1958 (June 1996):
" 3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution unless
there is a good technical reason not to. Duplication of the same
protocol functionality should be avoided as far as possible, without
of course using this argument to reject improvements."
Brian
_______________________________________________
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