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

[Ballot comment]
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.

[Ballot comment]
I largely agree with the 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 in this case.

I do think an IESG note summarizing the concerns of the IESG would be appropriate and improve the document.

[Ballot discuss]
After reading this several times, I have to agree with Sam and Ron and others. The document really needs to be cleaned up. It might be understandable by someone who participated in the WG discussions and also is in the middle of implementing VCCV, but the document is very hard for others to follow. Unfortunately this is a rather difficult "DISCUSS" that will take work to address, but it would be highly desirable to have something along the lines of:

- a review of failure modes
- a functional description of tools required to detect/diagnose failures
described above (what tools are available, and how they relate to each other)
- implementation details for tools described above.

[Ballot discuss]
I do not believe this document provides a clear basis for implementation by a
reader without the insight that comes from WG participation.  While I am sure
the technical content is accessible for someone that has a long history in the WG,
I could not  follow it, and the Secdir and Gen-ART reviewers expressed similar
difficulties.  I am also concerned that technical flaws in the content have been
overlooked due to the structural problems.

I believe the document would benefit greatly from an editing pass with the
non-WG reader in mind.

[Ballot discuss]
Parts of the document indicate that it is capable of
both IPv4 and IPv6 operation. However, the parts that
employ ICMP Ping only talk about IPv4 and associated
ICMP RFCs. Is this a bug or was there some reason
for this?

[Ballot comment]
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.

[Ballot comment]
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.).

[Ballot discuss]
I agree with most of Sam's comments. However, I encourage the authors to fix the document and would be glad to offer any help that I can.

[Ballot comment]
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.

[Ballot discuss]
It is quite unclear on the amount of bandwidth resources that are consumed by the VCCV. It seems to be possible to vary within quite large intervals. This makes me wonder about the need for congestion controlling VCCV, especially in cases when dedicated resources are not used. I would like to have some clear understanding on how much resources may be consumed. Is this below a full suppressed TCP connection or is it more? If more then the document needs specification on how a peer can throttle the peers emission of VCCV messages.

Also in the case dedicated resources are available, there are no discussion on the need to consider both VCCV and the actual PW data when assigning the resources.

Third some discussion are needed in the document about how you can restrict the amount of VCCV traffic. This also ties into the security consideration warning about throttling due to limited control plane resources in peers. There need to be some discussion on what is reasonable to do, and how one prioritize different type of VCCV messages to achieve minimal performance impact when performing operation over resource limited channels.

[Ballot comment]
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?

[Ballot discuss]
This is a discuss DISCUSS which I may clear after receiving the appropriate clarification. This document heavily relies on draft-ietf-bfd-base, which rigthly is listed as a Normative Reference, which means that it cannot should wait for the approval (at least) of draft-ietf-bfd-base before being published. My question is whether the approval of this document does not come too early, taking into account that draft-ietf-bfd-base did not even get consensus for submission in the WG, and later changes in the BFD specification cannot possibly have impact here.

[Ballot comment]
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

Secdir review

-------- Original Message --------
Subject: secdir review of draft-ietf-pwe3-vccv-13.txt
Date: Mon, 14 May 2007 13:20:41 -0400
From: David Harrington
To: , , "'Sam Hartman'" ,
CC: , ,


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.

The security considerations section discusses a number of denial of
service vulnerabilities and man-in-the-middle vulnerabilities. "All of
the attacks above ... may be countered by ..." - why are countering
technologies not REQUIRED or RECOMMENDED as part of compliance to this
standards track document? There seem to be lots of vulnerabilities,
but no required or recommended responses to the identified
vulnerabilties (e.g., mandatory to implement solutions). The
vulnerabilities are identified at a per-device level, but I the
security considerations doesn't go into any detail on the impact on
the security and stability of the network.

I found it difficult to do a security review of this document. There
seem to be options on options on options in this draft, including lots
of "MUST use in combination" and "MUST NOT use in combination.". PWE3
is an area in which I am not experienced, and experience might have
helped.

The security considerations section might need a state table to chart
the potential vulnerabilities of each combination of options,
including all the options that one MUST NOT do in combination, which
an attacker might deliberately do in combination.

The document has a lot of redundant text, but it is unclear to me
whether it is actually redundant or simply required to be restated
within each of the conditional hierarchies. I found a lot of grammar
mistakes in this document, and they tend to be typographical errors
(e.g., sentences missing verbs) and not mistakes commonly made by
non-native English speakers (e.g. articles, plurality). I suspect this
document has not been reviewed as thoroughly as it should be by the
WG, and that makes me concerned that the security considerations for
all the complex choices may not have been adequately reviewed by
people who have a good understanding of PWE technologies.

I recommend two things. One - the WG should review this document again
to determine if all the redundant text is necessary and whether a
state table or reorganization of the text could greatly simplify this
document so the security implications can be clarified. Two - a
security reviewer with PWE3 background should review this document.

David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net

IANA Last Call Comments:

[ Note: there is a typo in 8.3.4, "Connectifity" should
probably be "Connectivity". I've made the assumption
that this is a typo and not an intentional misspelling
of the word. ]

[ Question: Section 8.3.4 seems to request two sub-
registries but it calls it a single sub-registry.
Does the author want them combined? I've made the
assumption that the author wants two new sub-
registries created. ]


Upon approval of this document, the IANA will take
the following Actions:

Action 1:

Upon approval of this document, the IANA will in
the following registry "Pseudo Wires Name Spaces"
located at

http://www.iana.org/assignments/pwe3-parameters

create a new sub-registry "VCCV Control Channel Types"
Initial contents of this sub-registry will be:

Bit 0 (0x01) - Type 1: PWE3 control word with 0001b
as first nibble as defined in
[RFC4385]. [RFC-pwe3-vccv-13]
Bit 1 (0x02) - Type 2: MPLS Router Alert Label.
[RFC-pwe3-vccv-13]
Bit 2 (0x04) - Type 3: MPLS PW Demultiplexor Label
TTL = 1 (Type 3). [RFC-pwe3-vccv-13]
Bit 3 (0x08) - Reserved [RFC-pwe3-vccv-13]
Bit 4 (0x10) - Reserved [RFC-pwe3-vccv-13]
Bit 5 (0x20) - Reserved [RFC-pwe3-vccv-13]
Bit 6 (0x40) - Reserved [RFC-pwe3-vccv-13]
Bit 7 (0x80) - Reserved [RFC-pwe3-vccv-13]

The remaining bitfield values (0x08, 0x10, 0x20,
0x40 and 0x80) are to be assigned by IANA using
the "IETF Consensus" policy defined in [RFC2434].

See section 8.1.1

Action 2:

Upon approval of this document, the IANA will in
the following registry "Pseudo Wires Name Spaces"
located at

http://www.iana.org/assignments/pwe3-parameters

create a new sub-registry "VCCV Control Verification Types"
Initial contents of this sub-registry will be:

Bit 0 (0x01) - ICMP Ping. [RFC-pwe3-vccv-13]
Bit 1 (0x02) - LSP Ping. [RFC-pwe3-vccv-13]
Bit 2 (0x04) - BFD for PW Fault Detection Only.
[RFC-pwe3-vccv-13]
Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling. [RFC-pwe3-vccv-13]
Bit 4 (0x10) - BFD for PW Fault Detection Only. Carrying
BFD payload without IP headers. [RFC-pwe3-vccv-13]
Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling. Carrying BFD payload
without IP headers. [RFC-pwe3-vccv-13]
Bit 6 (0x40) - Reserved [RFC-pwe3-vccv-13]
Bit 7 (0x80) - Reserved [RFC-pwe3-vccv-13]

The remaining bitfield values (0x40 and 0x80) are to
be assigned by IANA using the "IETF Consensus" policy
defined in [RFC2434].

See section 8.1.2

Action 3:

[Section 8.2]

Upon approval of this document, the IANA will make
the following assignments in the "Pseudo Wires Name
Spaces" registry located at

http://www.iana.org/assignments/pwe3-parameters

sub-registry "Pseudowire Associated Channel Types"

Value (in hex) Protocol Name Reference
-------------- ------------------------------- ---------

PW-ACT-TBD BFD Without IP/UDP Header [RFC-pwe3-vccv-13]


Action 4:

[Section 8.3.1]

Upon approval of this document, the IANA will make
the following assignments in the "Layer Two Tunneling
Protocol "L2TP"" registry located at

http://www.iana.org/assignments/l2tp-parameters

sub-registry "Control Message Attribute Value Pairs"

Attribute
Type Description Reference
--------- ---------------------------------- ---------
AVP-TBD VCCV Capability AVP [RFC-pwe3-vccv-13]


Action 5:

[Section 8.3.2]

Upon approval of this document, the IANA will make
the following assignments in the "Layer Two Tunneling
Protocol "L2TP"" registry located at

http://www.iana.org/assignments/l2tp-parameters

sub-registry "Default L2-Specific Sublayer bits"

Bit 0 - V (VCCV) bit [RFC-pwe3-vccv-13]

Action 6:

[Section 8.3.3]

Upon approval of this document, the IANA will make
the following assignments in the "Layer Two Tunneling
Protocol "L2TP"" registry located at

http://www.iana.org/assignments/l2tp-parameters

sub-registry "ATM-Specific Sublayer bits"

Bit 0 - V (VCCV) bit [RFC-pwe3-vccv-13]

Action 7:

[Section 8.3.4]

Upon approval of this document, the IANA will in
the following registry "Layer Two Tunneling Protocol
"L2TP"" located at

http://www.iana.org/assignments/l2tp-parameters

create a new sub-registry
"VCCV Capability AVP Values - Control Channel (CC) Types"
Initial contents of this sub-registry will be:


Bit 0 (0x01) - L2-Specific Sublayer with V-bit set.
[RFC-pwe3-vccv-13]
Bit 1 (0x02) - Reserved [RFC-pwe3-vccv-13]
Bit 2 (0x04) - Reserved [RFC-pwe3-vccv-13]
Bit 3 (0x08) - Reserved [RFC-pwe3-vccv-13]
Bit 4 (0x10) - Reserved [RFC-pwe3-vccv-13]
Bit 5 (0x20) - Reserved [RFC-pwe3-vccv-13]
Bit 6 (0x40) - Reserved [RFC-pwe3-vccv-13]
Bit 7 (0x80) - Reserved [RFC-pwe3-vccv-13]

The allocations must be done using the "IETF Consensus"
policy defined in [RFC2434]. A VCCV CC Type description
and a reference to an RFC approved by the IESG are
required for any  assignment from this registry.

Action 8:

[Section 8.3.4]

Upon approval of this document, the IANA will in
the following registry "Layer Two Tunneling Protocol
"L2TP"" located at

http://www.iana.org/assignments/l2tp-parameters

create a new sub-registry
"VCCV Capability AVP Values - Connectivity Verification
(CV) Types"

Initial contents of this sub-registry will be:

Bit 0 (0x01) - ICMP Ping [RFC-pwe3-vccv-13]
Bit 1 (0x02) - Reserved [RFC-pwe3-vccv-13]
Bit 2 (0x04) - BFD for PW Fault Detection Only.
[RFC-pwe3-vccv-13]
Bit 3 (0x08) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling. [RFC-pwe3-vccv-13]
Bit 4 (0x10) - BFD for PW Fault Detection Only. Carrying
BFD payload without IP headers. [RFC-pwe3-vccv-13]
Bit 5 (0x20) - BFD for PW Fault Detection and AC/PW Fault
Status Signaling. Carrying BFD payload
without IP headers. [RFC-pwe3-vccv-13]
Bit 6 (0x40) - Reserved [RFC-pwe3-vccv-13]
Bit 7 (0x80) - Reserved [RFC-pwe3-vccv-13]

The allocations must be done using the "IETF Consensus"
policy defined in [RFC2434]. A VCCV CV Type description
and a reference to an RFC approved by the IESG are
required for any  assignment from this registry.

We understand the above to be the only IANA Actions
for this document.

PROTO Write-up

1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Stewart Bryant (stbryant@cisco.com) PWE3 co-chair.
I have read this version of the document and it is
now ready for IEFT Last Call.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been thoroughly reviewed by the PWE3 WG. The
use of BFD without UDP was discussed with the BFD authors
but not formally presented to the BFD WG. However I propose
that we address this by CCing the BFD WG list when we send
this to IETF Last Call.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

See (1.b). I have no other concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

There are no issues that the chairs are aware of.

Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

An IPR statement was filed by Cisco a few days ago.
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=814
Cisco originally submitted an IPR statement in August 2006,
but for some unkown reason this did not get recorded on the IPR page.

I sent an email to the PWE3 list explaining the position.

http://www1.ietf.org/mail-archive/web/pwe3/current/msg08837.html

I propose that we proceed with the publication process and
address any IPR comments as part of IETF last call.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong consensus for the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No one has threatened to appeal.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits?

Yes

http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes

(1.h) Has the document split its references into normative and
informative?

Yes
Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection", draft-ietf-bfd-base-05 (work in progress),
June 2006.

Strategy is to work with the new Routing AD to ensure its
expeditious completion.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

Yes

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?

Yes

Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Shepard is one of the Experts that need to do the review. There
is on very minor policy that I need to confer on, but otherwise
the IANA requirements are in good shape.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document describes a protocol that provides a control channel
that is associated with a Pseudowire (PW), and its use for
operations and management functions such as connectivity
verification to be used over that control channel. VCCV
applies to all supported access circuit and transport types
currently defined for PWs.

Working Group Summary

This document has been reviewed by the experts in the PWE3 WG
and there are no outstanding issues.

Document Quality
Are there existing implementations of the protocol?

Yes

Have a significant number of vendors indicated their plan to
implement the specification?

Yes

Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

Not applicable.

Personnel

Who is the Document Shepherd for this document?

Stewart Bryant (stbryant@cisco.com)

Who is the Responsible Area Director?

Mark Townsley (townsley@cisco.com)

Is an IANA expert needed?

Yes. The PWE3 chairs are the experts for the registry
concerned.