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

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 6 Sep 2011 22:58:34 +0800

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 [email-masked] ONLY.

Thanks,
Andy

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 6 Sep 2011 12:17:27 -0400

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:

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

---

From: Giles Heron <[email-masked]>
Date: Tue, 06 Sep 2011 17:22:22 +0100

I concur with Tom.

Giles

On 06/09/2011 17:17, "Thomas Nadeau" <[email-masked]> wrote:

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

---

From: [email-masked]
Date: Wed, 7 Sep 2011 16:30:31 +0800

Yeah/support

B.R.

Fei, as an co-author

"Andrew G. Malis" <[email-masked]> 
发件人:  [email-masked]
2011-09-06 22:58

收件人
[email-masked]
抄送

主题
[PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Thanks,
Andy

---

From: [email-masked]
Date: Wed, 7 Sep 2011 16:30:18 +0800

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

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

Best regards

Fei

Thomas Nadeau <[email-masked]> 
发件人:  [email-masked]
2011-09-07 00:17

收件人
"Andrew G. Malis" <[email-masked]>
抄送
[email-masked]
主题
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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 7 Sep 2011 07:45:09 -0400

On Sep 7, 2011, at 4:30 AM, [email-masked] wrote:

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

---

From: <[email-masked]>
Date: Wed, 7 Sep 2011 12:54:45 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: 07 September 2011 12:45
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hi Tom 

	--Tom

Best regards 

Fei 

                --Tom

---

From: [email-masked]
Date: Thu, 8 Sep 2011 09:48:50 +0800

Tom

Thanks for your response

See in line with <Fei>, hope you like my interpretation.

B.R.

Fei

2011-09-07 19:45

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hi Tom 

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

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. 

<Fei> This document is aimed to configure proactive OAM functions, which 
are end-to-end. As the example you provided, the adding or deleting MIP 
functions on the midpoints are related to the configuration of on-demand 
OAM functions, which are expected by NMS and are not inlcluded in the 
draft. 

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?

<Fei> Firstly, the MPLS-TP's requirements do not preclude the usage of 
control plane, and the OAM configurations MUST be supported by control 
plane are listed in section 2.4 in RFC5654, which are described in detail 
in section 2.3 of the draft aft-ietf-ccamp-mpls-tp-cp-framework-06.txt. 
Secondly, I just follow your argument to prove that every accessors have 
been authorized, actually every nodes along the path can be granted to be 
authorized based on the
security mechanims of signaling protocol.

--Tom

Best regards 

Fei 

收件人

                --Tom

---

From: [email-masked]
Date: Thu, 8 Sep 2011 10:01:09 +0800

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

<[email-masked]> 
2011-09-07 19:54

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
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: [email-masked] [mailto:[email-masked]] On Behalf Of 
Thomas Nadeau
Sent: 07 September 2011 12:45
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] PWE3 WG adoption of 
draft-zhang-mpls-tp-pw-oam-config-06

Hi Tom 

                 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.  

                 --Tom

Best regards 

Fei 

                --Tom

---

From: <[email-masked]>
Date: Thu, 8 Sep 2011 07:48:34 +0100

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

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

Neil

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.

B.R.

Fei

<[email-masked]>

2011-09-07 19:54

收件人

抄送

主题

regards, Neil

Hi Tom

                --Tom

Best regards

Fei

                --Tom

---

From: [email-masked]
Date: Thu, 8 Sep 2011 15:47:12 +0800

I Support.

It can simplify the configuration.

                                                                           
             "Andrew G.                                                    
             Malis"                                                        
             <agmalis@gmail                                         收件人 
             .com>                  [email-masked]                          
             发件人:                                                  抄送 
             mpls-bounces@i                                                
             etf.org                                                  主题 
                                    [mpls] PWE3 WG adoption of             
                                    draft-zhang-mpls-tp-pw-oam-config-06   
             2011-09-06                                                    
             22:58                                                         

Thanks,
Andy
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 8 Sep 2011 11:35:15 -0400

> Thomas Nadeau <[email-masked]>

	This is a slippery slope you have us going down. As I mentioned, if the mechanism you have defined here is not deployed in concert with the operator's provisioning system, you effectively have TWO configuration mechanisms, and TWO different ways to change the state of the devices along the TP tunnel path.  Besides being a configuration management nightmare in the making, you have also neglected the security aspects of this approach.  

> <Fei> This document is aimed to configure proactive OAM functions, which are end-to-end. As the example you provided, the adding or deleting MIP functions on the midpoints are related to the configuration of on-demand OAM functions, which are expected by NMS and are not inlcluded in the draft. 

	You have just explained my point: this document is used for managing a subset of the device's configuration.

> <Fei> Firstly, the MPLS-TP's requirements do not preclude the usage of control plane, and the OAM configurations MUST be supported by control plane are listed in section 2.4 in RFC5654, which are described in detail in section 2.3 of the draft aft-ietf-ccamp-mpls-tp-cp-framework-06.txt. Secondly, I just follow your argument to prove that every accessors have been authorized, actually every nodes along the path can be granted to be authorized based on the 

	They do not preclude the usage of control plane operations for sure, but should operate in the absence of any control plane too.  I am asserting that what you are doing here is effectively circumventing a control plane when one is in use, with a "mini" control plane. The other problem with this approach is that you are mixing configuration with proactive OAM operations/control/activation.   Simply put, this is a bad idea.

	--Tom

---

From: John E Drake <[email-masked]>
Date: Thu, 8 Sep 2011 18:04:26 -0700

Hi,

I support the draft.  It and its RSVP-TE and LSP Ping equivalents are designed to facilitate one-sided NMS provisioning.  This is entirely consistent with GMPLS and MPLS which both strive to reduce coordinated configuration.

Thanks,

John

Sent from my iPhone

> -----Original Message-----
> Sent: Tuesday, September 06, 2011 9:17 AM
> To: Andrew G. Malis
> Cc: [email-masked]
> 	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
>

---

From: [email-masked]
Date: Thu, 8 Sep 2011 21:16:10 -0400

Hi,

I support this draft since it allows the OAM to be configured at the same 
time that a connection is signalled/established.

Regards,

Malcolm

John E Drake <[email-masked]> 
Sent by: [email-masked]
08/09/2011 09:04 PM

To
Thomas Nadeau <[email-masked]>, "Andrew G. Malis" 
<[email-masked]>
cc
"[email-masked]" <[email-masked]>
Subject
Re: [PWE3] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Hi,

I support the draft.  It and its RSVP-TE and LSP Ping equivalents are 
designed to facilitate one-sided NMS provisioning.  This is entirely 
consistent with GMPLS and MPLS which both strive to reduce coordinated 
configuration.

Thanks,

John

Sent from my iPhone

>                As I mentioned during the meeting, I think this it is a 
bad idea

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 9 Sep 2011 08:06:39 -0400

> I support the draft.  It and its RSVP-TE and LSP Ping equivalents are designed to facilitate one-sided NMS provisioning.  This is entirely consistent with GMPLS and MPLS which both strive to reduce…

	While doing what you say, the same problems that I pointed out on this thread exist in those approaches as well. I have raised the same issues in CCAMP and MPLS. Two wrongs don't make a right. *)

	--Tom

---

From: John E Drake <[email-masked]>
Date: Fri, 9 Sep 2011 05:33:47 -0700

Tom,

I think we are agreeing to disagree.  I think this and the other IDs  
are a positive step forward.

John

Sent from my iPhone

On Sep 9, 2011, at 8:07 PM, "Thomas Nadeau" <[email-masked]>  
wrote:

>> I support the draft.  It and its RSVP-TE and LSP Ping equivalents  
>> are designed to facilitate one-sided NMS provisioning.  This is  
>> entirely consistent with GMPLS and MPLS which both strive to reduce  
>> coordinated configuration.
>
>    While doing what you say, the same problems that I pointed out on  
> this thread exist in those approaches as well. I have raised the  
> same issues in CCAMP and MPLS. Two wrongs don't make a right. *)
>
>    --Tom
>
>
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 9 Sep 2011 09:31:55 -0400

On Sep 9, 2011, at 8:33 AM, John E Drake <[email-masked]> wrote:

> Tom,
> 
> I think we are agreeing to disagree.

Yes.

>  I think this and the other IDs  

Coming from a management background and working at a big operator, I can safely say this is a really bad idea - whether or not it's in a requirement s draft or not.  What ultimately will happen is this functionality will just be disabled and not used anyways.

Tom

---

From: Luca Martini <[email-masked]>
Date: Tue, 13 Sep 2011 09:02:09 -0600

I also agree that this is a bad idea.
If we need a network management protocol , this is not the place for it.
So i do not support this document.

Luca

---

From: [email-masked]
Date: Mon, 19 Sep 2011 14:27:35 +0800

Support.

I think it's useful to have control plane configuration for proactive OAM 
function.

BRs,
Xiao Min

"Andrew G. Malis" <[email-masked]> 
发件人:  [email-masked]
2011/09/06 22:58

收件人
[email-masked]
抄送

主题
[mpls] PWE3 WG adoption of draft-zhang-mpls-tp-pw-oam-config-06

Thanks,
Andy

---

From: [email-masked]
Date: Tue, 20 Sep 2011 10:10:14 +0800

Yes/Support

Best Regards,

Xihua Fu

ZTE Corporation
Mobile: +86-15802921223
Phone: +86-029-88458058

收件人
[email-masked]
抄送

主题

Thanks,
Andy

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 21 Sep 2011 19:59:02 +0900

A weird idea on that oam configurations through the oam channel. I
don't think that it is good idea.

cheers,
--satoru

---

From: [email-masked]
Date: Thu, 22 Sep 2011 15:18:34 +0800

Hi Satoru

The OAM functions are configured by control plane, not through the oam 
channel (in other word, ACh)

B.R.

Fei

Satoru Matsushima <[email-masked]> 
发件人:  [email-masked]
2011-09-21 18:59

收件人
[email-masked]
抄送

主题

cheers,
--satoru

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 22 Sep 2011 18:49:40 +0800

It's now been two weeks since the call to discuss the adoption of
draft-zhang-mpls-tp-pw-oam-config as a PWE3 working group draft.

There has been spirited discussion and opinions both for and against
working group adoption. However, while a good number of individuals
commented on the draft, the comments were concentrated from a
relatively small number of organizations (I know that we're not
supposed to pay attention to these things, but of course we do).

I would like to remind the WG that this draft was not done in a vacuum,
but was derived from requirements in RFCs 5654 and 5860. The base
requirement is from RFC 5654:

 51  The MPLS-TP control plane MUST support the configuration and
     modification of OAM maintenance points as well as the activation/
     deactivation of OAM when the transport path or transport service
     is established or modified.

There is a similar requirement in section 2.1.6 of RFC 5860.

The draft addresses two separate issues:

- OAM capability advertisement to handle the new OAM tools from MPLS-TP.
- Configuration of those tools using the control plane.

We already do the first for VCCV using tLDP, so presumably this is
noncontroversial.

There is already precedent for the second part, notably OAM
configuration in LSP signaling in CCAMP.

There also seemed to be a bit of confusion on what's actually in the
draft. There were some comments that we shouldn't be sending OAM down
the control channel. That's not in the draft, so that's an orthogonal
issue. There was also a comment that we don't need a new management
protocol, but that's not in the draft either.

I am going to keep the call for adoption open for a few more days,
with the hope that more WG participants will (re-)read the draft and
speak up. There is also the possibility of splitting the draft in
two, to separately address the capability advertisement and the OAM
configuration. I would like to hear opinions on this as well.

Thanks,
Andy

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 23 Sep 2011 17:54:16 +0100

I have been watching this discussion as it developed, and
I think it would be helpful if the supporters could produce
a more detailed requirement than the four lines from RFC5654,
including reminding everyone of the operational reasons for
including the statement in that RFC.

Remember that just because we thought that it was a good
idea to add a requirement in an RFC at the time of writing,
does not mean that in the we were, with hindsight, correct.
However if we were correct, then the arguments for
including it will stand the test of time and can easily be
re-iterated. It might be best if the case could be produced
in draft format with a view to discussing in at the next
IETF in six weeks time.

Way back in the thread there were some arguments against
this proposal set down by the opponents, and I think that
it would be useful if these were re-iterated and the
details discussed on the list by both sides.

A large number of people simply saying that they
support (or oppose) a draft  does not move anything forward.
Remember we do not vote in the IETF, we develop a
rough consensus on practical approaches to real problems.
So please can we focus on exactly what is needed, why
it is needed, and the pros and cons of acceptable
technical solutions.

- Stewart

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 28 Sep 2011 10:01:24 -0400

So we're a little late on ending this call, but for good reason. There
was more discussion than we've seen in a long time regarding WG
adoption of a draft.

Matthew and I have discussed the results of the WG call for adoption
of this draft, and given the more recent discussion on the list, and
private verification that at least two vendors plan to implement the
draft, we have agreed that there is rough consensus to adopt the draft
as a WG item. As has already been noted, there's nothing in the draft
that doesn't have precedence either in the WG itself or in related
work on MPLS-TP.

Authors, please re-issue the draft as draft-ietf-pwe3-oam-config-00.

Thanks,
Andy and Matthew