Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

So Tom, are we now in the business of saving service providers from themselves?

The scenario you lay out seems like a procedural issue with the provider.  A similar argument could be made against having PW signaling and static PW provisioning.  While Network Provisioning presumes total control of the PWs provisioned, Network Troubleshooting goes in and changes the config though the static provisioning interface or the CLI to circumvent a problem.

I would think that Cplane configuration is a tool to be used by a service provider.  Like any tool MPLS / PWE3 provides, you can do  harm with it if not careful.  Is that a reason not to provide it to those who know how to use it "safely"?

-Dave

From: Thomas Nadeau <tnadeau@lucidvision.com<mailto:tnadeau@lucidvision.com>>
Date: Tue, 20 Sep 2011 07:55:36 -0400
To: Elisa Bellagamba <elisa.bellagamba@ericsson.com<mailto:elisa.bellagamba@ericsson.com>>
Cc: "IETF.PWE3" <pwe3@ietf.org<mailto:pwe3@ietf.org>>
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

On Sep 20, 2011, at 6:46 AM, Elisa Bellagamba wrote:

Hello,

I support the WG adoption for draft-zhang-mpls-tp-pw-oam-config-06.

I think it would be useful having the OAM configuration taken care automatically by the control plane. Regarding some comments raising the fact that this was traditionally done by the NMS, this doesn't prevent to keep doing that in the traditional way. Moreover, the described configuration method is backward compatible.

No one is saying that anyone should preclude the traditional way. The issue is that having multiple ways is potentially dangerous, especially if different departments of an operator do not realize this is possible.  Imagine one department runs Network Provisioning, and assumes it has total control of the boxes.  This is quite common in service providers today.  Then another department called Network Troubleshooting, comes along in response to a trouble ticket and decides to setup some MIPs/MEPs for testing as well as trigger some OAM tests.  Suddenly the configurations have been changed unbeknownst to the Provisioning Department. This is a simple case, but there are more complex ones, especially the more and more we allow configuration elements into the OAM protocols.

 We addressed the same problematic within CCAMP where we extended RSVP-TE for MPLS-TP OAM configuration but still keeping the possibility to do that via NMS. We even extended lsp-ping for such kind of configuration. All the 3 methods are simply working following a trivial precedence rule which prevents the risk of any overlapping between the 3.

Yes, and I pointed out a number of times why this is similarly a bad idea there.  Apparently you guys don't want to take the input from people who have worked at (or do work at) network service providers who are pointing out the dangers of such a solution.

--Tom

Cheers,
Elisa
_______________________________________________
pwe3 mailing list
pwe3@ietf.org<mailto:pwe3@ietf.org>
https://www.ietf.org/mailman/listinfo/pwe3