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

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Yaakov Stein
Sent: 22 September 2011 09:12
To: David Allan I; Thomas Nadeau
Cc: [e-mail]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

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



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: [e-mail] [mailto:[e-mail]] On Behalf Of David Allan I
Sent: Wednesday, September 21, 2011 03:08
To: John E Drake; Thomas Nadeau
Cc: [e-mail]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

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