Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
draft-ietf-pwe3-vccv-15

I have to agree with Sam overall.  I have spent hours trying to understand ten pages of text so far.  
 - Many sentences are simply not complete or grammatical.
 - There's too much passive voice (not just a stylistic issue but creating ambiguity about the subject of the sentence) and generally awkward constructions even when sentences are grammatical.  
 - Many abbreviations not spelled out, others are used inconsistently.  
 - The document is organized so poorly I can't tell when some requirements are general and when they're specific to the mechanism discussed locally.
 - Some requirements are in conflict (e.g. MUST vs NOT RECOMMENDED in 5.5.).

This is a very strong abstain.  I think this document should not be
published in its current form.

The largest problem is that the document is not clear enough to lead
to interoperable implementations or to build a reasonable base for
future work.

As best I can tell the document contains the following:

* A proposed PWE3 architectural element for connectivity verification

* A mechanism for negotiating a management channel type and which connectivity verification to use for LDP.

* The same mechanism for L2TPV3

* Definitions  of various channels for carrying this OAM information.

* Definitions  of  the connectivity methods.

For all of the above except the architecture bit, the MPLS and L2TP
bits are separate.  However this is less than clear in the document.
Also, the layering is less than clear.  It's not clear to me how you
would add a new type of channel for OAM information or how you would
define a new connectivity type.  The restrictions for what works with
what are scattered everywhere.  This is not organized for
extensibility.

I think the interactions with BFD are horribly under specified.  There
is four pages of text describing BFD for V4 and V6 covering
applicability, encapsulation, initialization, etc.  This document
simply refers to BFD without the IP and UDP header.  It does not even
cite the BFD document that talks about running BFD with UDP; it cites
the base spec.  I believe that if BFD over PWE3 without a UDP header
is going to be specified, it needs to be specified with as much care
as the other BFD applications.


Everything in this spec is optional.  I understand that MPLS PSNs do
not interoperate with L2TP today.  First, even so, they may need
common connectivity verification mechanisms to meet the requirements
of MS PWE3.  It's not clear how you actually would be able to do that
with this mechanism.  You need to know what the other segments will
select before you can perform the simple negotiation in this
mechanism.  But let's ignore that for the moment.  You definitely want
two PEs that support the same PSN and PW-type to have interoperable
OAM functions.  That requires some of the options here be mandatory to
implement.

Finally, security is inadequate.  Consider for example a situation
where you are using 802 security over an ethernet PWE3.  LDP with
TCPMD5 provides signaling security.  How do you protect the OAM traffic
with this mechanism?  There needs to be some sort of security
mechanism.  One possibility would be to negotiate keys to protect BFD.


It is possible to fix these complaints.  I suspect it would require
close to a full document rewrite.  I do not have the time to dedicate
to working with the authors to accomplish this.  However I think
publication without fixing these concerns would be harmful to the
Internet.