Hi,
I support Yoshinori's words. 1 solution is better than 2, but 2 are better than 3, 4, 5...
MPLS is a standard, a language, not a product, like f.i. MPLS/IP routers are.
The word "Oi", present in a modern Portuguese dictionary, wasn't crafted in Portugal but in Brazil. Although Portugal was the origin of the language, we're just a fraction of the worldwide Portuguese speaking community.
A standard is more pragmatic than a language. I can't imagine Rivest, Shamir or Adleman feeling interfered but proud, when IETF used RSA public key cryptography in SSL/TSL. Possibly, when typing "https", nobody remembers Fermat's little theorem and its Euler's extension, where RSA is grounded but, if they were alive, they would surely also be proud.
By starting T-MPLS, to serve those wishing an SDH/OTN flavored packet technology, ITU-T actually followed RFC1958. ("If a previous design, in the Internet context or elsewhere, has successfully solved the same problem [...].) It isn't a so complexity/features enamored baroque view but more KISS aiming. And this cultural background difference is perhaps a major cause for confusion between the 2 views under discussion.
No one has doubts about IETF as MPLS creator and certainly MPLS creators do have a word when someone suggests extending their work, but killing primary goals like OAM simplicity kills that view, questioning all this work.
ITU-T accepted IETF expertise and MPLS-TP project, although that would delay the Recommendations (3 years up to now), constructively proposed the development of 2 solutions, when it became clear that their supporting communities wouldn't change their minds. Although i respect the draft's authors' view, as well as their supporters', i can't agree with its publication: it's a partial view and just another tool of not constructively killing an equally important view's primary goals. It's time to build and let others build.
Best Regards,
Rui
-----Original Message-----
From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Yoshinori Koike
Sent: terça-feira, 25 de Outubro de 2011 07:06
To: ietf@xxxxxxxx
Subject: Re: Last Call: <draft-sprecher-mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC
Hi,
I would like to appreciate the editors' efforts to try to examine the
consequences of the existence of two MPLS-TP OAM solutions, however I
don't understanding the meaning to publish this draft at this stage.
I agree that one solution is desirable described. However, considering
the extraordinary efforts made by IETF and ITU-T, this case corresponds
to an unavoidable case which is described in RFC1958. That is, both OAM
solutions(G.8113.1 and G.8113.2) are worth being standardized. Positive
sides of having the second solution should be valued more in terms of
further development of MPLS-TP technology rather than the negative sides
such as complexity.
The followings are the reasons that I stated above.
1) In general, both OAM solutions(G.8113.1 and G.8113.2) seem to be
supported by two different large communities of interest
internationally. Therefore, standardization of both OAM solutions will
be best choice for the future development of MPLS-TP technology, which I
believe is a common goal/wish for both communities.
2) A lot of operators/users have been waiting for the MPLS-TP standards
for a long time, since MPLS-TP work started. Generally, no one doubt
that one solution for one functional requirement is best as mentioned in
this draft. As a result, in my understanding, a lot of efforts have been
made to achieve the goal for about 3-4 years by IETF and ITU-T, but the
consequence is what we are facing now. It should be seriously considered
that the current status is the result of extraordinary efforts.
Accordingly, limiting the solution only one (publishing the this draft)
at this stage doesn't seem to be reasonable, because all the efforts
made by experts in both parties (IETF and ITU-T) are enough to be respected.
3) It is true that MPLS-TP is a MPLS technology. It is also true that
MPLS-TP is a transport technology. What I learned so far is that both
technologies possess their own histories, experiences and established
reliabilities in OAM solutions (G.8113.2(BFD&LSP ping based) and
G.8113.1(Ethernet-based OAM) and very hard to radically change their
assets. If I quote the good expression from the draft, each side wishes
a soft transition rather than a cliff.
4) MPLS-TP is a joint work which has a great potential to create future
innovative MPLS-based transport networks for operators/users. But, I
think they will never be achieved without collaboration.
5) I understand the difficulties and complexities which were described
in this draft, but I believe it's worth challenging for both
implementers and operators.
6) There are a number of positive sides by containing the
G.8113.1(Ethernet-based OAM) solution.
-It seems that the integrity of control plane protocol on the OAM
solution (G.8113.1) can be maintained as seen in ASON & GMPLS
relationship. If necessary, it might be easy to apply the control plane
to Ethernet OAM configuration.
-Expanding Carrier Ethernet based on Ethernet OAM is considered to be
one of the major traffics for future MPLS-TP transport networks. The OAM
solution(G.8113.1) can alleviate the anxiety of some operators who would
like to migrate their networks with soft transition from Ethernet/SDH
networks, because those operators/users have doubt about the feasibility
of having the similar operational experiences with transport network
OAM(covered by Ethernet OAM) by applying G.8113.2(BFD based) OAM. This
will increase the opportunity of the deployment of MPLS-TP.
-Lately, both Ethernet OAM and MPLS-TP OAM tend to be implemented in one
box (equipment) to flexibly respond to the uses needs. In this kind of
product, the complexity of implementation will be mitigated.
Best regards,
Yoshinori
-----Original Message-----
From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-
bounces@xxxxxxxx] 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@xxxxxxxx mailing lists by 2011-10-24. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
--
Yoshinori Koike
koike.yoshinori@xxxxxxxxxxxxx
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf