I do not support the publication of this draft.
As indicated by many technical comments already raised on this topic, what the
MPLS WG has defined is not a single solution but encopasses a variety of
incompatible options none of which meet the requirements of major transport
operators. The draft is therefore technically incorrect unless the concept of
"single soution" is defined as anything but what meets the requirements of
major transport operators.
Looking at the precedents provided in the draft, I can see at least a couple
which were a great market success (e.g., OSPF/IS-IS and SONET/SDH). I wonder
whether the real motivaiton for the selection of a "single solution" as defined
above is to manipulate the market to avoid MPLS-TP being as successfull as
these precedents.
In order to make comments according to the "IETF tradition", my text change
proposal is very simple: replace the whole document with the text provided by
draft-fang-mpls-tp-oam-considerations. draft-fang-mpls-tp-oam-considerations
provides considerations from operators that have field experience with large
scale deployments of MPLS-TP which are more relevant that incorrect
phylosophical considerations.
----Messaggio originale----
Da: adrian(_at_)olddog(_dot_)co(_dot_)uk
Data: 26-set-2011 23.57
A: <mpls(_at_)ietf(_dot_)org>
Ogg: [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 sponsorship.
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
OAM.
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
philosophy.
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.
Thanks,
Adrian
-----Original Message-----
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
To: IETF-Announce
Subject: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt>
(The
Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational
RFC
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 Informational
RFC
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 may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
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
standardization.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
mpls mailing list
mpls(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/mpls
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf