Rui,
Excellent point, I fully agree, we need to focus on the 99% that is
identical and not cause the 1% that is different (for good reasons) to
cause a rift that will drive further divergence.
Regards,
Malcolm
Rui Costa <RCosta(_at_)ptinovacao(_dot_)pt>
Sent by: ietf-bounces(_at_)ietf(_dot_)org
05/10/2011 11:06 PM
To
"ietf(_at_)ietf(_dot_)org" <ietf(_at_)ietf(_dot_)org>
cc
Subject
RE: [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
Sometimes when two worlds come together, you don't get common standards
right away. For the SONET/SDH example, it has been pointed out that
starting from digital voice, we had different regions of the world
choosing A-law or mu-law encoding, then 24-channel vs 30-channel PDH
hierarchies. SONET and SDH evolved originally as optimized transport for
the 24-channel and 30-channel hierarchies, but we were able to push them
into common physical layer interfaces for the various bit-rates, and today
what we call SDH is really a superset of the two multiplexing hierarchies,
so the same box can be sold anywhere in the world and can be configured to
support the hierarchy of the local network. When "data friendly" features
were added to SONET/SDH (VCAT, GFP, LCAS), these were defined once and not
in multiple regional variants. When we finally reached OTN, we were able
to agree to develop a single, global standard from the start.
For MPLS-TP, we have the coming together of the transport world with the
Internet world. We have succeeded in driving together many aspects of this
technology, but we shouldn't be too surprised that we can't get down to
one variant in the very first try at bringing these together.
Regards,
Rui
-----Original Message-----
From: mpls-bounces(_at_)ietf(_dot_)org
[mailto:mpls-bounces(_at_)ietf(_dot_)org] On Behalf Of
Adrian Farrel
Sent: segunda-feira, 26 de Setembro de 2011 22:58
To: mpls(_at_)ietf(_dot_)org
Subject: [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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf