Hi,
Here's the review I promised earlier. I still think it would be best to not
publish the draft for the reasons I mentioned earlier. In case the IETF wants
to move this document forward I think at least a number of things need to
change:
a) The document makes a number of assertions that I think are not correct. E.g.
it states that the solutions must be implementable in software. I cannot recall
that there was any assertion about whether some, all or none of the things that
the requirements documents prescribe should be build in HW or SW. A vendor
needs to build equipment that fulfills the requirements, the standard needs to
specify mechanisms that fulfill the requirements. If a vendor can build it in
SW fine, if it has to be done in HW fine. But the main point is that everything
needs to fulfill the specs which fulfill the requirements.
b) The complexity sausage needs to go. The section does not help the goal of
the document or the relevant parts are duplicated later in the text.
c) Some text passages are overly dramatic and could use a little down-toning
(e.g. " (something that would inevitably drive all customers away!)"). Others
use absolute figures for speculative things (like increases cost by a factor of
two etc.). Yet others are not very polite to certain vendors like "forces all
serious router vendors to implement both protocols". I am not sure the IETF
wants to call router vendors to be "not serious" if they only implement either
OSPF or ISIS. The basic message is the text needs a serious cleanup of language.
d) Section 6 needs to go. I do not think that these coexistence models are
agreed by the wider IETF community and I don't think they help the message of
the document.
e) The document should provide more references for some of the statements that
caused dispute on the list.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Rolf Winter
Sent: Dienstag, 4. Oktober 2011 11:17
To: Brian E Carpenter; 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
Hi,
I think Brian makes an excellent point here. RFC 1958 already contains
exactly the same basic message (just with far less (unnecessary) words).
I don't think we need this document as it doesn't really add anything
to what RFC 1958 says. I'll provide a more detailed review later.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of
Brian E Carpenter
Sent: Freitag, 30. September 2011 21:48
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf