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

From: Elisa Bellagamba <[email-masked]>
Date: Tue, 20 Sep 2011 12:46:08 +0200

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.

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.

Cheers,
Elisa

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Sep 2011 07:55:36 -0400

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

	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…

	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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Sep 2011 05:26:50 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 20, 2011 7:56 AM
To: Elisa Bellagamba
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hello,

          --Tom

Cheers,
Elisa
_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: David Sinicrope <[email-masked]>
Date: Tue, 20 Sep 2011 08:47:26 -0400

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 <[email-masked]<mailto:[email-masked]>>
Date: Tue, 20 Sep 2011 07:55:36 -0400
To: Elisa Bellagamba <[email-masked]<mailto:[email-masked]>>
Cc: "IETF.PWE3" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hello,

--Tom

Cheers,
Elisa

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Sep 2011 09:45:13 -0400

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

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 20 Sep 2011 09:57:24 -0400

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

	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…

	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

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 20 Sep 2011 10:49:33 -0400

yes/support

    Regards,
        Greg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elisa Bellagamba
Sent: Tuesday, September 20, 2011 3:46 AM
To: [email-masked]
Subject: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hello,

Cheers,
Elisa

---

From: Daniele Ceccarelli <[email-masked]>
Date: Tue, 20 Sep 2011 17:09:45 +0200

yes/support

BR
Daniele

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gregory Mirsky
Sent: martedì 20 settembre 2011 16.50
To: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

yes/support

    Regards,
        Greg

Hello,

Cheers,
Elisa

---

From: John E Drake <[email-masked]>
Date: Tue, 20 Sep 2011 08:23:30 -0700

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:[email-masked]]
Sent: Tuesday, September 20, 2011 9:45 AM
To: John E Drake
Cc: Elisa Bellagamba; [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

          --Tom

Tom,

Thanks,

John

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Tuesday, September 20, 2011 7:56 AM
To: Elisa Bellagamba
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hello,

          --Tom

Cheers,
Elisa

---

From: David Allan I <[email-masked]>
Date: Tue, 20 Sep 2011 20:08:07 -0400

IMO I prefer the trust model of using the CP to set this up and coordinate the end points, and OAM is about trust.

so I support adoption of the draft, it is a move in the right direction

cheers
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Tuesday, September 20, 2011 11:24 PM
To: Thomas Nadeau
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

          --Tom

Tom,

Thanks,

John

Hello,

          --Tom

Cheers,
Elisa

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 22 Sep 2011 08:11:53 +0000

Dave

I actually am closer to Tom on this issue,
but didn't see any reason to fight windmills on this one.

But was surprised at both clauses of your statement.

First, from a pure security PoV, all the management systems I have seen are more trustworthy than most control planes.
And since this is for TP which doesn't even assume an IP forwarding plane let alone IPsec,
then I have to assume that someone is going to start configuring everything using GACh payloads,
which frankly scares me, unless you have armed guards physically viewing all of your network elements.
(You may recall my rants on the lack of any security in MPLS and my futile attempts at pwsec
a few years back.)

Second, "OAM is about trust". Well yes, it is about how much the client layer trusts the server layer
or the customer trusts the service provider, or the boxes trust the fibers.
Or in many cases how little trust there is and how to check up so that you can prove your case of SLA noncompliance.
In any case I don't see the connection between this kind of "trust"
and the kind I think you are talking about in comparing control and management planes.

I trust that you will explain.

Y(J)S

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Wednesday, September 21, 2011 03:08
To: John E Drake; Thomas Nadeau
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

cheers
Dave

---

From: David Allan I <[email-masked]>
Date: Thu, 22 Sep 2011 04:29:15 -0400

Hi Yaakov:

No argument on management plane configuration.

I was thinking more of the LSP-PING bootstrapping to establish binding. I'd rather move that function to a more trusted adjacency and in the case of LDP signalling for PWs, a configuring east west exchange already exists.

My statement about trust was more along the lines that auto-discovery and trust are somewhat orthogonal concepts. A chain of trust needs to be introduced. A CP adjancency to me scales much better from the point of view of the number of security associations required, as it is one SA for the aggregate of the PWs served by the adjacency....

I'll be the first to admit I've not checked the security provisions in LSP-PING, but if if there is significant provisions, I have signalling and LSP-PING bootstrapping I now require a minimum of two SAs to establish the chain of trust to configure a PW, worse if it is an SA per ME, nightmare if it is an SA per MEP/MIP pair (not relevant to bootstrapping but mentioned the slippery slope we are discussing). We went into some of this in the security section of the TP OAM framework (now RFC 6371)

I hope that is clearer...

Dave

________________________________
From: Yaakov Stein [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 4:12 PM
To: David Allan I; Thomas Nadeau
Cc: [email-masked]
Subject: RE: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Dave

Y(J)S

cheers
Dave

---

From: <[email-masked]>
Date: Thu, 22 Sep 2011 10:03:20 +0100

Hi Yaakov,  I largely agree with what you have written below, but I want to expand on a few points.  Please see in-line:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: 22 September 2011 09:12
To: David Allan I; Thomas Nadeau
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Dave

First, from a pure security PoV, all the management systems I have seen are more trustworthy than most control planes.
NH=> This is true.  But don't forget that 'routing' and 'signalling' functions have merely been given the special name of 'CP' (and not MP) since they are the key devolved/automated functions of providing a connectivity service to a client in a co-cs/ps mode layer network...so get this special CP badging.

Wrt to the security angle, it is a forced consequence of the regular resource time-slice partitioning/labelling in the co-cs mode that all the CP/MP functions must be taken logically OOB wrt the traffic DP.  There is no choice here.

In the co-ps mode we have irregular time-slices of resource and so we have to consciously engineer this OOB CP/MP behaviour...as indeed we are doing in MPLS-TP now, albeit rather late in the day and not that well (I'll come back on this shortly).

So we have a 'network system' in the co-cs and (hopefully) the co-ps mode, ie there is an adjunct logically OOB CP/MP layer network that operates in concert with the *client carrying DP layer network* ....and to be explicit:  we do not carry client traffic, of either DP/MP/CP origin, in the server CP/MP network.

In the cl-ps mode this does not happen...DP/CP/MP functions all use the same logical layer network, ie it carries both the client traffic and the control/management of itself.  And this is one reason why security is a far larger concern here.

And since this is for TP which doesn't even assume an IP forwarding plane
NH=> What you have written above is that IP (a cl-ps mode layer network protocol) can operate in the *same DP* as the traffic...here co-ps of mode.  This is a serious architectural error...and its why LDP has generated so many problems (including our good friend of PWs).  There is nothing wrong with using IP in the adjunct CP/MP layer network (of a co-cs or co-ps mode layer network), but this is very different to allowing the serious architectural error of allowing different types of traffic unit to appear in the same client carrying DP.

 let alone IPsec,
then I have to assume that someone is going to start configuring everything using GACh payloads,
which frankly scares me, unless you have armed guards physically viewing all of your network elements.
(You may recall my rants on the lack of any security in MPLS and my futile attempts at pwsec
a few years back.)
NH=> The OAM that we use to detect DP defects belongs to the DP...indeed it should be generated/terminated at the DP trail termination points.  It has nothing to do with the CP or MP.  That is, we should never, ever be using a DP OAM protocol to configure the network in a MP (or CP) sense.

Aside=> One only requires very simple OAM for defect detection anyway.  Those who generate all the complex OAM functions (eg TCM) are just generating unnecessary complexity, cost and potential problems (inc security).  For defect detection in the co-ps mode all one really needs is CV and BDI...and that's it.

And this is a key reason why I objected to having the same reserved label being assigned to both the CP/MP functions and the indicator for DP OAM.  Its logically/architecturally just plain wrong.  Note also that the DP OAM should use a single bit flag of the normal DP traffic unit OH...it should not appear under an extra labelled header.  This is all just bad architecture/design....and it could have been avoided but has consciously not been.  So these sort of mistakes are inexcusable IMO (along with others like carrying over MS PWs into MPLS-TP).

Second, "OAM is about trust". Well yes, it is about how much the client layer trusts the server layer
NH=> To some extent...but 2 points:

-      recall what I wrote above wrt to where OAM should be generated/terminated, ie at server layer trail termination points...we should not be having OAM messages that can be acted on in layer N coming down from (the higher) layer N-1.  All client data (whether DP/MP/CP) must pass transparently in the server...something else we have not really got right IMO.

-      A far bigger security problem is peer-interworking (and not client/server).  And this is why in a TOS public layer network we have a different specification for the E-NNI and I-NNI.  In general we restrict the scope of the CP functions (of routing/signalling) and don't even allow MP interfaces.  Note carefully that I mentioned a 'TOS layer network' here.  There is no reason whatsoever to peer in layer networks that are not TOS..and this is trivially easy to prove.  So if one peers at a non-TOS layer network then one is just creating unnecessary work, cost and potential problems....like security.

regards, Neil
This email contains BT information, which may be privileged or confidential.
It's meant only for the individual(s) or entity named above. If you're not the intended
recipient, note that disclosing, copying, distributing or using this information
is prohibited. If you've received this email in error, please let me know immediately
on the email address above. Thank you.
We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

Y(J)S

cheers
Dave

---

From: <[email-masked]>
Date: Thu, 22 Sep 2011 10:18:24 +0100

Hi  Dave....one remark in-line:

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: 22 September 2011 09:29
To: Yaakov Stein; Thomas Nadeau
Cc: [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hi Yaakov:

I was thinking more of the LSP-PING bootstrapping to establish binding.
NH=> This mistake arises because LDP is not a proper co-ps mode layer network.  LDP creates many problems, but here the key point is that there is no proper CP function of signalling that sets-up/tears-down LSPs...the merging LSPs (which are not connections anyway) 'self nucleate'.

Aside=> The CP/MP should tell the trail termination points of a connection that is about to be created what identifier (=SA) to expect in the DP CV OAM messages.  Similarly, the CP/MP should remove this condition when the connection is taken down.  We should not attempt such configuration via the DP OAM messages themselves.

regards, Neil

 I'd rather move that function to a more trusted adjacency and in the case of LDP signalling for PWs, a configuring east west exchange already exists.

Dave

Y(J)S

cheers
Dave

---

From: David Allan I <[email-masked]>
Date: Thu, 22 Sep 2011 05:34:03 -0400

Hi Neil:

WIld agreement!, hence my belief that CP/MP options are useful and deprecating DP in the longer term is the end goal...

best
D

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, September 22, 2011 5:18 PM
To: David Allan I; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hi Yaakov:

regards, Neil

Dave

Y(J)S

cheers
Dave