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

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] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 20, 2011 7:56 AM
To: Elisa Bellagamba
Cc: 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