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: mpls-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of Adrian Farrel
Sent: 2011年9月27日 5:58
To: mpls(_at_)ietf(_dot_)org
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: 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-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
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