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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]