Subject: [mpls] 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: Azhar Sayeed <[email-masked]>
Date: Thu, 13 Oct 2011 12:07:06 -0400

Hi, 

I support the publication of the draft as an informational RFC. This is a
good example of providing an avenue for debate and then agreeing to a
consensus on single solution and documenting it as a reference. The debate
in SDOs has been on for a long time and every time I only get one or two
examples of how a provider has deployed the alternative solution and hence
it becomes mandatory for all SDOs to comply.

To me those are bad choices made by people cognizant of the issues. These
are the risks you take when you deploy pre-standard technology and have to
rip it or migrate to standards based technology. Just because one or two
providers deployed it does not mean it becomes mandatory on the rest of the
world. The last time I checked there are more than 500 providers in the
world. 

One solution is all that is needed for an IOT and two solutions are very
expensive from a vendor point of view and from a provider point of view. I
am sure all vendors and providers agree. From a vendor point of view they
are expensive to build and from a provider point of view managing two
domains is not easy.

Now, no one is stopping people from inventing another protocol that looks a
lot like MPLS and behaves a lot like MPLS with "better OAM" characteristics
and then standardizing that protocol. I will fully support that protocol
except that it cannot be called MPLS. It is a new protocol.

Regards, 
Azhar Sayeed 
Cisco Systems Inc.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 24 Oct 2011 10:10:38 +0200

Hi,

Please publish this RFC ! It is an important statement of the single solution principle in the IETF.

On Sep 28, 2011, at 4:02 AM, Brian E Carpenter wrote:

> Please see attached review.
> 
> <draft-sprecher-mpls-tp-oam-considerations-01-carpenter.txt>_______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Yoshinori Koike <[email-masked]>
Date: Tue, 25 Oct 2011 15:05:55 +0900

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

--
Yoshinori Koike
[email-masked]