Subject: R: [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

From: "[email-masked]" <[email-masked]>
Date: Wed, 19 Oct 2011 22:48:59 +0200 (CEST)

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: [email-masked]
>Data: 26-set-2011 23.57
>A: <[email-masked]>
>Ogg: [mpls] FW: Last Call:	&lt;draft-sprecher-mpls-tp-oam-considerations-01.
txt&gt; (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: [email-masked] [mailto:ietf-announce-
>> [email-masked]] 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
>> [email-masked] mailing lists by 2011-10-24. Exceptionally, comments may be
>> sent to [email-masked] 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>_______________________________________________
>mpls mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mpls
>