Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
RFC 5085

Note: This ballot was opened for revision 15 and is now closed.

(Mark Townsley) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2007-05-24)
No email
send info
>    5. Only a single BFD CV Type can be seleced and used.

s/seleced/selected/

(Ron Bonica) (was Discuss) No Objection

(Ross Callon) (was Discuss) No Objection

(Russ Housley) No Objection

Comment (2007-05-22 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Both the Gen-ART Reviewer and the SecDir Reviewer found this document
  difficult.  There seem to be options on options on options, including
  lots of "MUST use in combination" and "MUST NOT use in combination."
  Is it possible to add a table to make these interrelationships
  obvious?

(Cullen Jennings) No Objection

(Chris Newman) No Objection

Comment (2007-09-06 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I largely agree with other IESG comments.  Given how flawed this
document is, I believe it's unlikely to deploy and/or interoperate and
thus unlikely to cause any significant harm.  However, this document has
WG consensus and the domain-expert area director believes it has IETF
consensus (implicit in his yes vote).  Unless the authors/WG want to do
extensive reworking on this document based on the IESG comments, I
would prefer to error on the side of publication.

I do think an IESG note summarizing the concerns of the IESG would be appropriate and worth modest effort.

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

Comment (2007-05-21)
No email
send info
a few mostly editorial comments: 

1. A number of acronyms are not expanded at the first occurence - PSV, OAM

2. In Section 4 the text mentions 'procedures defined in Section 5.2 of [RFC4447]. I could not find anything in Section 5.2 of [RFC4447] that matches this, I suspect that the reference is inaccurate. 

3. Section 4.1 - dupplicated instance of [BFD] [BFD]

4. Section 5 - there is something missing in the second phrase - a verb maybe

(David Ward) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2007-05-24)
No email
send info
I agree with Sam's abstain comments and think the document would greately benefit from going back to the WG and likely to go to abstain after my discuss has been resolved.

(Lisa Dusseault) Abstain

Comment (2007-05-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.).

(Sam Hartman) Abstain

Comment (2007-05-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.