Rolf,
I agree with the points that you have raised, we need to make more
efficient use of our time to address the real technical issues.
To expand on this point, one major factor that has not been considered in
this draft is that significant deployments (300,000+ nodes) of a second
solution already exist. This second solution is based on the Ethernet tool
OAM tool set, see draft-fang-mpls-tp-oam-considerations for further
details.
Given the current situation the pragmatic engineering approach is to:
- Acknowledge these deployments:
- Define a method for interconnecting between domains that deploy the
tools identified in draft-ietf-mpls-tp-oam-analysis and the Ethernet based
tool set that avoids the need for an interworking function:
- Take steps to avoid a proliferation of further options (i.e. a third of
fourth or nth solution).
I do not want to expend energy on debating how we arrived at this
situation, its document on various email threads and in Internet drafts.
History has shown that we all have our own interpretation of these events
and repeating this debate is unlikely to cause the protagonists to change
their opinions. We need to focus on how we manage the situation in which
we find ourselves.
Regards,
Malcolm
Rolf Winter <Rolf(_dot_)Winter(_at_)neclab(_dot_)eu>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
05/10/2011 10:52 AM
To
Loa Andersson <loa(_at_)pi(_dot_)nu>
cc
"ietf(_at_)ietf(_dot_)org" <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 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf