Hi Loa,
There actually are some nuggets in the document but you have to look hard for
them. E.g. section 4.2 analyzes TDM PWs and states that even within the IETF
the exact same situation has arisen before, and three solutions have been
specified. However, the IETF made one of them the default solution, so at least
there is a baseline type to use and interoperability is guaranteed. If the IETF
has gone down that particular path, then I don't see a reason why we cannot do
the same thing again (yes, yes I know it is not optimal, I wish life was simple
but I was recently convinced of the opposite). The document makes another good
point in this regard: the party that is not using the default needs to bear all
the cost (operational and such) which is a good point to make. This whole
situation right now feels like some sort of attrition warfare and I don't think
it is efficient use of our time.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3
6BL | Registered in England 2832014
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: Mittwoch, 5. Oktober 2011 13:51
To: Rolf Winter
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
Rolf,
I don't remember saying the "sole purpose", the IETF way is to document
requirements, specifications, processes and agreements in RFCs; this is
just another document in this tradition. ANd as such a very good
document.
/Loa
On 2011-10-05 13:31, Rolf Winter wrote:
Hi Loa,
Let me answer with a counter-question. If the sole purpose of this
document is to stop the development of two OAM solutions, do you think
this RFC-to-be will achieve that? Seriously? The problem I see here is
that we start a habit of writing "politically" motivated documents. We
have this issue documented already all over the place in the form of
minutes, web sites, press releases etc. I think this is enough and the
right place. Let the I* and liaisons figure this out so that we all can
go back to protocol design and development.
Best,
Rolf
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: Mittwoch, 5. Oktober 2011 12:48
To: ietf(_at_)ietf(_dot_)org; Rolf Winter
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
Rolf,
are you saying that if we just liaise RFC1958 to the ITU-T they will
stop developing a competing OAM for MPLS?
Sometimes the life is simple, though I doubt that it is this simple.
My 2c's is that this a good draft and should be progressed.
/Lao
On 2011-10-04 11:16, Rolf Winter wrote:
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
--
Loa Andersson email:
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager loa(_at_)pi(_dot_)nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
--
Loa Andersson email:
loa(_dot_)andersson(_at_)ericsson(_dot_)com
Sr Strategy and Standards Manager loa(_at_)pi(_dot_)nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf