Subject: 答复: 答复: [mpls] FW: LastCall:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

From: [email-masked]
Date: Wed, 5 Oct 2011 21:50:14 +0800

FYI ...

zhangp7 <[email-masked]> 
2011-10-05 19:47

收件人
<[email-masked]>, <[email-masked]>
抄送

主题
答复: [mpls] FW: 
LastCall:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons 
for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

Hi, All:
 
I also don’t support this draft. 
 
For MPLS-TP OAM solution as described in Section 3.6, we think it should 
be good news for operators to have two parallelled solutions, which could 
satisfy different application scenarios and requirements. 

Pei Zhang
China Unicom Network Communications Group Company Limited
Tel: +86-10-66257021
E-Mail: [email-masked]

发件人: [email-masked] [mailto:[email-masked]] 代表 
[email-masked]
发送时间: 2011年10月5日 15:31
收件人: [email-masked]
主题: FW: [mpls] FW: 
LastCall:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons 
for Selecting a Single Solution for MPLS-TP OAM) toInformational RFC

Hi all, 

I do not support approval of this draft either. 

"3.1.  MPLS-TP is an MPLS Technology" 

MPLS-TP is also a transport technology and used to add connection oriented 
packet transport capability which is deployed and operated in a manner 
that is similar to the existing transport network. 

"3.6.  Selection of a Single OAM Solution When There is a Choice" 

We have heard the voices from different SPs in previous discussions and 
known their seletion. So, selection is not a problem for SP. 
What vendors do is to meet providers' requirements. The deployment in 
large quantities has made the cost of developing two solutions very small. 

"4.  Examples of Inter-Working Issues in the Internet"&" 5.  Other 
Examples of Inter-Work Issues" 

What the authors want to say here? Offer criticism to the technologies 
defined by other experts or organizations? 

B.R. 
Yuxia 

-----Original Message-----
From: HUANG Feng F
Sent: 2011年10月5日 7:56
To: [email-masked]'
Subject: RE: [mpls] FW: Last 
Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons for 
Selecting a Single Solution for MPLS-TP OAM) toInformational RFC
Importance: High

Hi,

1.

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.

MPLS-TP is subset of "MPLS", "MPLS" is old mpls developed before MPLS-TP 
in 2008 or include MPLS-TP developed this years and in the future?
MPLS-TP is for transport network, SDH/OTN/Etherent is transport network, 
it should be shown capability to transport network.

1.1
  The standardization process within the IETF allows for the continued
  analysis of whether the OAM solutions under development meet the
  documented requirements, and facilitates the addition of new
  requirements if any are discovered.  It is not the purpose of this
  document to analyze the correctness of the selection of specific OAM
  solutions.  This document is intended to explain why it would be
  unwise to standardize multiple solutions for MPLS-TP OAM, and to show
  how the existence of multiple solutions would complicate MPLS-TP
  development and deployment making networks more expensive to build,
  less stable, and more costly to operate.

According to JWT report, MPLS-TP is joint standardized by IETF and ITU-T, 
it is not right for someone decide solution for IETF and ITU-T.
 
    An analysis of the technical options for OAM solutions was carried
  out by a design team (the MEAD team) consisting of experts from both
  the ITU-T and the IETF.  The team reached an agreement on the
  principles of the design and the direction for the development of
  an MPLS-TP OAM toolset.  A report was subsequently submitted to the
  IETF MPLS Working Group at the Stockholm IETF meeting in July 2009.
  The guidelines drawn up by the design team have played an important
  role in the creation of a coherent MPLS-TP OAM solution.

MEAD team's decision has never been send to ITU-T for comments, ITU-T have 
got nothing information about it.

1.2.  The Development of a Parallel MPLS-TP OAM Solution
 
The first of these was discussed within the IETF's MPLS working group
  where precedence was given to adherence to the JWT's recommendation
  to select a solution that reused as far as possible pre-existing MPLS
  tools.  Additionally, it was considered that consistency with
  encodings and mechanisms used in MPLS was of greater importance.

Many operators ask MPLS-TP OAM shown capacity to Ethernet, you can see 
draft-bhh-mpls-tp-oam-y1731. at least 9 provdiders support it.
JWT report don't said anything about one solution, it is a start point to 
develop solution, IETF and ITU-T don't explore to public, one solution 
should be taken.

3.6

It should be noted that, in the long-run, it is the end-users who pay
  the price for the additional development costs and any network
  instability that arises.

authors are come from vendors, they are not end users, which some venders 
want to push their own solutions.
we should hear opinons from providers? let providers show their 
consideration on OAM, there is a IETF providers' draft about OAM 
consideration, you can refer to draft-fang-mpls-tp-oam-considerations, it 
is a pure providers' draft, some considerations are listed there!

5.1 for SDH/SONET as example, it work well in the network, phone call 
between Europe to US work very well, I am wondering author should known 
some history about SDH and SONET. 

6.  Potential Models For Coexistence 

   In transport network, overlay model is usually used, it work very well.

B.R.

Feng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Adrian Farrel
Sent: 2011年9月27日 5:58
To: [email-masked]
Subject: [mpls] FW: Last 
Call:<draft-sprecher-mpls-tp-oam-considerations-01.txt> (TheReasons for 
Selecting a Single Solution for MPLS-TP OAM) toInformational 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-considerati
> ons/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerati
> ons/
> 
> 
> 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