Subject: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05

From: [email-masked]
Date: Wed, 27 Jul 2011 06:30:33 +0800

Hi PWEers

This document is about the MPLS-TP PW proactive OAM capability negotiation 
and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM 
function they support, then configure the corresponding OAM parameters.

We will be highly appreciated if you can review and give any comments.

Below is the link

http://tools.ietf.org/html/draft-zhang-mpls-tp-pw-oam-config-05

Thanks and best regards

The authors

---

From: [email-masked]
Date: Wed, 27 Jul 2011 06:41:26 +0800

Hi Tom

Sorry I do not catch your interpretation clearly in the meeting.

As Matthew said, here the negotiation is about the CV functions, 
especially for the newly developed MPLS-TP OAM functions, and it is done 
before the setting up of PWs.

When the negotiation finished, this will not changed during PW lifetimes 
since the equipment will not change the OAM function it supported 
frequently.

Do I answer your question or there are still some misunderstanding?

Best regards

Fei

[email-masked] 
发件人:  [email-masked]
2011-07-27 06:30

收件人
[email-masked]
抄送

主题
[PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05

Hi PWEers 

Below is the link 

Thanks and best regards 

The authors_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 27 Jul 2011 08:33:05 -0400

My concerns about this document (and the other related "configuration via control protocols" documents) are the following:

	1) Network configuration is a complicated matter. If you take a quick look at NETCONF or any other configuration/provisioning apparatus/protocols, you will see that provisioning is no simple matter requiring all sorts of things to function including security, synchronization, versioning control, etc... None are covered in your draft - nor should they.  The issue is that your draft is designing a new means of configuration.

	2) Synchronization between different configuration points. Consider this case: the SP's OSS decides to provision a device and alters some of the parameters pertaining to MIP/MEP configuration. Then later, someone goes to the CLI of the same device and changes some of those same parameters. Suddenly you are out-of-sync with the master provisioning data base the service provider keeps within the OSS. Then later, someone from *a different* device decides to make a different change that suddenly appears at this device via the control plane signaling. Viola, the configuration is even further out-of-sync. 

	3) You are making the issue of option coordination that Nick describes in the recent survey that he conducted potentially worse by opening up a new can of optional configuration types and options that operators will further have to coordinate and rationalize. This retards the deployments at best, and in the worst cases, makes them plain not work.

	--Tom

On Jul 26, 2011, at 6:41 PM, [email-masked] wrote:

> As Matthew said, here the negotiation is about the CV functions, especially for the newly developed MPLS-TP OAM functions, and it is done before the setting up of PWs. 
> 
> When the negotiation finished, this will not changed during PW lifetimes since the equipment will not change the OAM function it supported frequently. 
> 
> This document is about the MPLS-TP PW proactive OAM capability negotiation and configuration, firstly the two T-PEs negotiate what MPLS-TP OAM function they support, then configure the corresponding OAM parameters. 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]

---

From: [email-masked]
Date: Thu, 28 Jul 2011 08:43:39 +0800

Hi Tom

You are talking about a general question...

Below is the understanding from side with mark <Fei>. If it is wrong, 
please let me know

Thanks

Fei

Thomas Nadeau <[email-masked]> 
2011-07-27 20:33

收件人
[email-masked]
抄送
[email-masked], [email-masked], [email-masked]
主题
Re: [PWE3] Request comments on draft-zhang-mpls-tp-pw-oam-config-05

My concerns about this document (and the other related "configuration via 
control protocols" documents) are the following:

1) Network configuration is a complicated matter. If you take a quick look 
at NETCONF or any other configuration/provisioning apparatus/protocols, 
you will see that provisioning is no simple matter requiring all sorts of 
things to function including security, synchronization, versioning 
control, etc... None are covered in your draft - nor should they.  The 
issue is that your draft is designing a new means of configuration.

<Fei> Not totally a new design, the motivation of this work is to 
alleviate the labor of NMS, and avoid misconnection. So it is not used to 
replace NMS, just as a complement.

2) Synchronization between different configuration points. Consider this 
case: the SP's OSS decides to provision a device and alters some of the 
parameters pertaining to MIP/MEP configuration. Then later, someone goes 
to the CLI of the same device and changes some of those same parameters. 
Suddenly you are out-of-sync with the master provisioning data base the 
service provider keeps within the OSS. Then later, someone from *a 
different* device decides to make a different change that suddenly appears 
at this device via the control plane signaling. Viola, the configuration 
is even further out-of-sync. 

<Fei> I am not sure whether I understand your issue. Just my two cents, 
this SHOULD be a general security question. Consider that the transport 
path is set up by control plane with OAM configurations, someone can also 
goes to the CLI to change some parameters. 

3) You are making the issue of option coordination that Nick describes in 
the recent survey that he conducted potentially worse by opening up a new 
can of optional configuration types and options that operators will 
further have to coordinate and rationalize. This retards the deployments 
at best, and in the worst cases, makes them plain not work.

<Fei> I do not think so, Nick's survey is about the CC(control channel), 
there are two many options. But the generic Ach defined in RFC5586 is 
always be used in MPLS-TP world. Furthermore, we do not define new 
mechanism to coordinate the control channel in our draft, and the OAM 
negotiation is done in the initializaiton message. In contrast, it will 
quicken the deployment by configuring the OAM functions in the signaling 
message, since two steps is compacted into one step. In the old 
procedures, the transport path MUST be set up firstly, then OAM functions 
are configured by NMS. 

--Tom

Hi Tom 

Best regards 

Fei 

[email-masked] 

收件人
[email-masked] 
抄送

主题

Hi PWEers 

Below is the link 

Thanks and best regards

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 28 Jul 2011 13:26:46 -0400

On Jul 27, 2011, at 8:43 PM, [email-masked] wrote:

> Below is the understanding from side with mark <Fei>. If it is wrong, please let me know 
> 
> Thanks 
> 
> Fei 
> 
> 
> <Fei> Not totally a new design, the motivation of this work is to alleviate the labor of NMS, and avoid misconnection. So it is not used to replace NMS, just as a complement. 

TOM: The issue is that you are alleviating the labor of the NMS only in a small portion of potential configuration. That is why this raises the potential for mis-cordination.

> <Fei> I am not sure whether I understand your issue. Just my two cents, this SHOULD be a general security question. Consider that the transport path is set up by control plane with OAM configurations, someone can also goes to the CLI to change some parameters. 

TOM: This is not a security issue. 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.

> <Fei> I do not think so, Nick's survey is about the CC(control channel), there are two many options. But the generic Ach defined in RFC5586 is always be used in MPLS-TP world. Furthermore, we do not define new mechanism to coordinate the control channel in our draft, and the OAM negotiation is done in the initializaiton message. In contrast, it will quicken the deployment by configuring the OAM functions in the signaling message, since two steps is compacted into one step. In the old procedures, the transport path MUST be set up firstly, then OAM functions are configured by NMS. 

TOM: This again, has nothing to do with the CC or VCCV. The point I am making is that the survey revealed that operators are experiencing a lot of pain having multiple options in terms of PW OAM.  This draft makes the situation worse rather than better (simpler).

	--Tom