I do not support.
Basically I think it is superfluous dedicate an RFC to state it is better
having one standard instead of two ones or many... for sure the lower are the
variants the better is for the industry (one is the ideal).
When two or more standards or de-facto standards exist it is because the
problem they solve is not exactly the same, the way they solve the problem is
optimized for different environments/boundary conditions (more efficient, more
effective, etc). Therefore a single solution does not necessarily meet the
different market requirements.
It is fundamental to enter into the problem's details before making
consideration about the best way to proceed (one solution, two solutions,
multiple solutions) whilst the document clearly declares it does not want to
make any technical evaluations.
After more than three years of debates within the IETF and major unresolved
technical concerns risen from some transport operators, the existence of this
draft is by itself the sure sign that MPLS-TP OAM is a case where a single
solution has not be found to meet all the different market requirements.
Otherwise, why are we still discussing about it....?
Therefore we must be realistic and the lessons learned from the past should
guide our decisions: if a solution cannot be found for satisfying all the
requirements it is better to have two standards and let the market decide how
to exploit them. Are we really sure the cost(many) / benefit (none) analysis
done in section 7.5 is realistic?
Via Reiss Romoli, 274 - 10148 Torino
phone: +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07
Da: mpls-bounces(_at_)ietf(_dot_)org [mailto:mpls-bounces(_at_)ietf(_dot_)org]
Per conto di Adrian Farrel
Inviato: lunedì 26 settembre 2011 23:58
Oggetto: [mpls] FW: Last Call:
<draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a
Single Solution for MPLS-TP OAM) to Informational RFC
MPLS Working Group,
Please be aware of the IETF last call as shown below. The document was
presented for publication as an individual RFC with IETF consensus and AD
This draft is clearly close and relevant to the work you do, but after
discussing with the chairs I came to the conclusion that it does not comment on
the technical or process decisions of the MPLS working groups, and it does not
attempt to make any technical evaluations or definitions within the scope of
the MPLS working group. It is more of a philosophical analysis of the way the
IETF approaches the "two solutions" problem with special reference to MPLS-TP
Thus, I am accepting the document as AD Sponsored rather than running it
through the MPLS working group. My reasoning is that the working group has got
plenty to do working on technical issues without being diverted into wider IETF
As an AD Sponsored I-D it is subject to a four week IETF last call. That is
plenty of opportunity for everyone to comment and express their views. Please
send your comments to the IETF mailing list as described below, or (in
exceptional circumstances) direct to the IESG.
From: ietf-announce-bounces(_at_)ietf(_dot_)org [mailto:ietf-announce-
bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: 26 September 2011 20:43
Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>
(The Reasons for Selecting a Single Solution for MPLS-TP OAM) to
The IESG has received a request from an individual submitter to
consider the following document:
- 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
<draft-sprecher-mpls-tp-oam-considerations-01.txt> as an
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-10-24. Exceptionally, comments
be sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
for use in transport network deployments. That is, MPLS-TP is a set
of functions and features selected from the wider MPLS toolset and
applied in a consistent way to meet the needs and requirements of
operators of packet transport networks.
During the process of development of the profile, additions to the
MPLS toolset have been made to ensure that the tools available met
the requirements. These additions were motivated by MPLS-TP, but form
part of the wider MPLS toolset such that any of them could be used in
any MPLS deployment.
One major set of additions provides enhanced support for Operations,
Administration, and Maintenance (OAM). This enables fault management
and performance monitoring to the level needed in a transport
network. Many solutions and protocol extensions have been proposed to
address these OAM requirements, and this document sets out the
reasons for selecting a single, coherent set of solutions for
The file can be obtained via
IESG discussion can be tracked via
No IPR declarations have been submitted directly on this I-D.
IETF-Announce mailing list
mpls mailing list
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
Ietf mailing list