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

On Sep 20, 2011, at 8:47 AM, David Sinicrope wrote:

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

	No. What I am doing is to try to prevent the introduction of an additional mechanism that results in the addition of potentially more complexity in the configuration management process.  Sure, given enough thrust even pigs can fly, and in this case it too is possible that an operator could coordinate provisioning from two different portals. However, the point I am making is whether or not this is really a direction we want to go given that what we are doing here is only enabling provisioning of a small subset of parameters. Or are we saying that as a WG and organization (IETF), that we have designed a new provisioning mechanism and therefore should start to progress the introduction of the remainder of provisioning parameters into the signaling protocols?

> 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 invite you go make the case to service providers that the way they do provisioning today is broken, and that they should employ this new provisioning mechanism that is embedded in a few networking signaling protocols. Then tell them they can do the rest of their provisioning using their existing mechanisms. Please report back to us on your findings. 8)

> 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"?

	No. Architecturally speaking, there is no reason you could not do provisioning inside of all the signaling protocols.  What I am trying to force is the debate/discussion within the working group as to whether or not this is something we really want to do (or should be doing).   What we have not done as an organization (or in PWE3, CCAMP and MPLS) is agree that what we want to do is provide operators with yet another provisioning mechanism called Control Protocols - or that they even want one. This seems to be an accidental thing that has come out of a small requirement that appears within the MPLS-TP requirements that is now having ramifications in a bunch of other non-MPLS-TP areas. 

	--Tom

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