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

If one is using signaling to instantiate an LSP or PW, the necessary parameters are carried in signaling.  Since OAM is adding new capabilities, the parameters necessary to configure these new capabilities needs to be added to signaling.   In this model, the complete set of parameters is configured at one end of the LSP or PW.

You seem to be arguing that the right model is to pass some parameters in signaling and use coordinated configuration to set other parameters.   This seems counter-intuitive.

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, September 20, 2011 9:45 AM
To: John E Drake
Cc: Elisa Bellagamba; pwe3@ietf.org
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

          How does this mechanism eliminate coordinated provisioning?  You still need to provision the other %99 of the device configuration parameters/etc... right?  That is the point I am making. What this mechanism does is potentially duplicate the provisioning/control of a sub-set of the entire configuration, which is most often controlled by a single provisioning system that is part of the OSS.

          --Tom

On Sep 20, 2011, at 8:26 AM, John E Drake wrote:

Tom,

I think these mechanisms actually alleviate some of the issues you are describing because they eliminate coordinated provisioning, which is always a bad idea, in favor of single sided provisioning.

Thanks,

John

From: pwe3-bounces@ietf.org<mailto:pwe3-bounces@ietf.org> [mailto:pwe3-bounces@ietf.org] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 20, 2011 7:56 AM
To: Elisa Bellagamba
Cc: 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