|
RE: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>(The Reasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
2011-10-06 09:41:04
Dear Loa,
I am sorry if you regard my email is personal attacks, but I think I tell
the truth, here are evidences.
1. Draft-sprecher-mpls-tp-oam-considerations is a personal draft, it ask for
comments in ietf, I have expressed my comments on my previous emails and I
don't support it. ( You said it is a good draft, please provide the evidence!)
2. For MEAD team's decision on OAM, it was recorded in
draft-ietf-mpls-tp-oam-analysis as below, but some MEAD members don't agree it,
so they quit from this draft, you can see change from
draft-ietf-mpls-tp-oam-analysis-00 to draft-ietf-mpls-tp-oam-analysis-02.
"This document reports the conclusions of the MPLS-TP design team
discussions on the MPLS-TP OAM tools at IETF75 and the guidelines
that were agreed. The guidelines refer to a set of existing OAM
tools that need to be enhanced to fully support the MPLS-TP OAM
requirements and identify new tools that need to be defined. The
organizational structure of the documents on MPLS-TP OAM tools was
also discussed and agreed at IETF75 and is described later in this
document."
3. For MEAD team's disband, you can see liaison send to itu recorded in
TD218-wp3 (2009-9).
B.R.
Feng
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: 2011年10月6日 20:15
To: HUANG Feng F
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) toInformational RFC
Feng,
I'm not sure how to parse this, but personal attacks on ietf mailing should at
least be substantiated with evidence.
Like been said before we discuss thing over and over and come to an working
group or IETF consensus call, and then the discussion starts over again.
/Loa
On 2011-10-05 13:58, HUANG Feng F wrote:
Loa,
YES, but there are only someone (not organization-that's a individual
draft and MEAD team-not ietf mpls group or ietf group, which has been
disbanded by themselves one years ago) make decision to done a single
solution!
B.R.
Feng
-----Original Message-----
From: Loa Andersson [mailto:loa(_at_)pi(_dot_)nu]
Sent: 2011年10月5日 19:53
To: HUANG Feng F
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) toInformational RFC
Feng,
there were only one organization invbolved in the decision to develop two OAM
solutions!
/Loa
On 2011-10-05 13:29, HUANG Feng F wrote:
Dear Loa,
Life is not simple, mpls-tp is joint developed by IETF and ITU-T, so it
is complicated, the decision should be done by two orgnizations.
There are many errors about in this draft as many, for example, Rolf,
Huub, Malcolm, Tom Petch and I, point out in emails, it is a bad draft, it
should be stop.
B.R.
Feng
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of Loa Andersson
Sent: 2011年10月5日 18: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) toInformational 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|