Skip to main content

Last Call Review of draft-ietf-pwe3-vccv-impl-survey-results-02

Request Review of draft-ietf-pwe3-vccv-impl-survey-results
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-23
Requested 2013-09-05
Authors Nick Del Regno , Andrew G. Malis
I-D last updated 2013-09-12
Completed reviews Genart Last Call review of -02 by Brian E. Carpenter (diff)
Secdir Last Call review of -02 by Alexey Melnikov (diff)
Assignment Reviewer Alexey Melnikov
State Completed
Request Last Call review on draft-ietf-pwe3-vccv-impl-survey-results by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 03)
Result Ready
Completed 2013-09-12

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


Most pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate
the use of the Control Word (CW) to carry information essential to
the emulation, to inhibit Equal-Cost Multipath (ECMP) behavior, and
to discriminate Operations, Administration, and Maintenance (OAM)
from Pseudowire (PW) packets.  However, some encapsulations treat the
Control Word as optional.  As a result, implementations of the CW,
for encapsulations for which it is optional, vary by equipment
manufacturer, equipment model and service provider network.
Similarly, Virtual Circuit Connectivity Verification (VCCV) supports
three Control Channel (CC) types and multiple Connectivity
Verification (CV) Types.  This flexibility has led to reports of
interoperability issues within deployed networks and associated
drafts to attempt to remedy the situation.  This survey of the PW/
VCCV user community was conducted to determine implementation trends.
The survey and results are presented in this document.

As the document is a survey of what existing implementations do in this 

area, I agree with editors that it doesn't introduce new security concerns.

Editors also clarified that they took precautions to ensure the validity 

of the sample and the data, in particular they verified email addresses 

of respondents and that they are representing different companies, not 

including equipment vendors.

I don't have any concerns about security considerations for this document.

With no disrespect to document editors, the WG and the shepherding AD, I 

am however concerns that this document doesn't contain information that 

is useful for publishing as an RFC. I would be happy to be proven wrong 

on this.

Best Regards,