Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
draft-ietf-pwe3-vccv-15
Yes
(Mark Townsley)
No Objection
(Cullen Jennings)
(David Ward)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Abstain
Note: This ballot was opened for revision 15 and is now closed.
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
(2007-09-06)
Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-21)
Unknown
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 Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-24)
Unknown
> 5. Only a single BFD CV Type can be seleced and used. s/seleced/selected/
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
(2007-05-24)
Unknown
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.
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-05-22)
Unknown
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?
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
Abstain
Abstain
(2007-05-23)
Unknown
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 Former IESG member
Abstain
Abstain
(2007-05-23)
Unknown
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.