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

[<[e-mail]>]

Thanks Fei...let me have another go at explaining what I mean here....this is a general observation and not specific to your draft:

OAM that is intended to detect defects in the traffic DP belongs to the traffic DP...it does not belong to the CP or MP per se.  Indeed, in co mode layer networks these OAM PDUs are created/removed at traffic DP trail termination points.

Further, in a co-ps/cs layer network the CP/MP protocols needs to run in an adjunct layer network to the traffic handling DP layer network. [This is not the case in the cl-ps mode...and its one (of several) key differences between the 3 network modes].

This adjunct ‘OOB CP/MP’  network is actually forced in the co-cs mode due to the fact that we don’t simply label traffic units (implicitly please note, by a known/fixed recurring position in time) but we also allocate resource (ie fixed duration of time)....in the co-ps mode labelling has to be explicit since the start epoch of a traffic unit is unknown a priori and (usually) the duration (=resource) is also variable.

This means we have to consciously impart good arch/design-principles in the co-ps mode as they don’t ‘come for free’ as in the co-cs mode.... and an OOB CP/MP network is simply one such good arch/design principle....but there are several others, eg having proper single source connections is one, realising having lots of QoS classes in a connection is a fairly useless idea is another (its all about ‘transparency’).  Ultimately (though its not always immediately obvious – TP took 10 years to start work on) violating good arch/design principles leads to unnecessary problems and costs.

Note that the CP/MP protocol PDUs that belong to the CP/DP have no need to mimic the DP PDUs...they are indeed running in a logically different/adjunct network.  So one can think of this as having a ‘network system’ here comprised of the DP layer network and its (controlling) CP/MP network.  Note also that the CP/MP network invariably uses cl-ps mode forwarding behaviour whilst the DP uses co forwarding behaviour in this network system.

When we look at the DP OAM PDUs these need to mimic the DP traffic units as much as possible.   And this is why a single bit ‘OAM indicate’ flag (which is all we need) to differentiate (i) a DP traffic unit from (ii) a DP OAM PDU needs to be part of their common PDU overhead.  DP OAM should not be further encapsulated under another reserved labelled header.....and for sure not one that should only be used for carrying the logically OOB CP/MP protocol PDUs.

So that was my point...simply one of correct arch design.   And we have failed to do as good a job here as we could have.  Is that clear now?

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



From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: 08 September 2011 03:01
To: Harrison,N,Neil,DKQ7 R; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06


Neil

Sorry, I do not catch your idea clearly.

This draft is focusing on the proactive OAM configurations by control plane. It does not, not intended to, use the CP to do the same thing as DP OAMs, which will mix
the roles as you said.

Hope this clarify my opinions.

B.R.

Fei

<[e-mail]>

2011-09-07 19:54

收件人

<[e-mail]>, <[e-mail]>

抄送

<[e-mail]>, <[e-mail]>

主题

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







Tend to agree with Tom and Giles views on this.  DP OAM for defect management is not the same as sending some MP (or even CP) protocol over an OOB adjunct layer network.  This is also why I object to having DP OAM lumped in with logically OOB/MP/CP functions.....we should not be using the same reserved label for both these functionally very different roles (though to be frank, we should not be using a reserved label for a DP OAM indicate function at all...the DP ‘OAM indicate’ bit flag should be part of the normal traffic DP header so that both DP traffic and OAM PDUs look as alike as possible).

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



From: [e-mail] [mailto:[e-mail]] On Behalf Of Thomas Nadeau
Sent: 07 September 2011 12:45
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06


On Sep 7, 2011, at 4:30 AM, [e-mail] wrote:



Hi Tom

According to my understanding, I think you are concerning about two points

(1) Synchronization between different configuration points，as you said  "Both accessors in the example I gave have permission to change the configuration (authenticated). The issue is again, that you can overwrite the other one's configuration without their knowing."

Just my two cents, This would not happen for MS-PW because that the setting up and OAM configuration of PWs are intialized by only one T-PE node, the other nodes just receive the control plane signaling and react to the events. As to SS-PW, this is a issue, but the different configuration parameters can be negotiated by the subsequent signaling messages, as described in the section 6.2

                I've already given several very plausible examples of how this could happen, but let me do so again for the sake of explaining my point. For example, if an operator in your example, has an OSS that provisions services in its network, it will have "write" configuration access to the T-PE node you give above.  Lets say that the OSS has provisioned a TP tunnel X on that box and provisioned 2 MEPs and 1 MIP along its path. If some time later I then SSH to that same T-PE box in question and access the CLI from there, and decide I don't like only 1 MIP and add one, I have changed the network's configuration state and just suddenly made it out of sync with the OSS/provisioning system.


(2)The security of the mechanisms, as you said "Consider the case of a cable MSO with different operational domains, where one operator isn't authorized to make configuration changes in the other domain"

I think every accessors have been authorized, otherwise the control plane signaling will not be sent. Furthermore, there is one WG draft in MPLS about the security, see
http://tools.ietf.org/html/draft-ietf-mpls-tp-security-framework-01, and attacks on the control plane is discussed on the secion 4.1.

                That is my point. This mechanism only assumes that authentication/authorization has been granted at the node in question not anywhere else along the TP path. Thus, I could be granted access at the head of the TP path which might be in another domain, yet make substantive configuration changes further along the path.  Worse, I could modify the running configuration of nodes downstream without their OSS knowing of these changes - or allowing me to make those changes. This is very much against the requirement originally put forth for MPLS-TP to operate without a control plane for security reasons.  If we allowed this, we violate that tenant and might as well just go back to plain old MPLS PWs over TE tunnels, right?

                --Tom





Best regards

Fei

Thomas Nadeau <[e-mail]>
发件人:  [e-mail]
2011-09-07 00:17
收件人
"Andrew G. Malis" <[e-mail]>
抄送
[e-mail]
主题
Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06








                As I mentioned during the meeting, I think this it is a bad idea to allow configuration via the OAM control channel, so I do not want this adopted as a WG draft.

                --Tom

On Sep 6, 2011, at 10:58 AM, Andrew G. Malis wrote:

> This email begins a two-week poll on the PWE3 working group adoption
> of draft-zhang-mpls-tp-pw-oam-config-06, to end on Sept. 20.
>
> You can read the draft at
> https://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-06 .
>
> The MPLS working group was bcc:ed for their information.
>
> Please respond with any comments to [e-mail] ONLY.
>
> Thanks,
> Andy
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
>

_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3