Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)
draft-ietf-pwe3-vccv-bfd-07

[Ballot discuss]
This is a point for discussion with the ADs at the telechat. I will clear after this discussion.

I'd like to talk briefly about references to the PDF version of 5317

[Ballot discuss]
Section 6: BFD congestion control response are under discussion. However, it it clear that the VCCV congestion control and BFD's has the potential for bad interactions. That issue must be documented. Unfortuntately it can't be documented properly until the discussion for BFD has completed.

The interaction between VCCV and BFD appears to be that any limitation of the VCCV channel will affect all VCCV traffic that will include BFD control and test messages when encapsulated in the VCCV channel. Thus the BFD congestion control might react to these external limitations in such a way BFD fails to verify the connectivity despite it existing. However, any real analysis in the behavior can't be completed until we know the BFD algorithms.

[Ballot comment]
Nice to remove the word "new" from the Abstract as this work will
(hopefully) persist.

I don't believe that [RFC5317] is a good reference for MPLS-TP
requirements or solutions. I suggest referencing
draft-ietf-mpls-tp-requirements and draft-ietf-mpls-tp-framework
Maybe also, draft-ietf-mpls-tp-oam-requirements.

IANA Last Call Comments:

Upon approval of this document, the IANA will make the following
changes in "Pseudowire Name Spaces (PWE3)" registry located at
http://www.iana.org/assignments/pwe3-parameters

=============================================================
sub-registry "MPLS VCCV Connectivity Verification (CV) Types"

OLD:
Bit (Value) Description Reference
----------- -------------------- ---------
0 (0x01) ICMP Ping [RFC5085]
1 (0x02) LSP Ping [RFC5085]
2 (0x04) Reserved [RFC5085]
3 (0x08) Reserved [RFC5085]
4 (0x10) Reserved [RFC5085]
5 (0x20) Reserved [RFC5085]
6 (0x40) Reserved [RFC5085]
7 (0x80) Reserved [RFC5085]


NEW:
Bit (Value) Description Reference
----------- -------------------- ---------
0 (0x01) ICMP Ping [RFC5085]
1 (0x02) LSP Ping [RFC5085]
2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
[RFC-pwe3-vccv-bfd-05]
3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
[RFC-pwe3-vccv-bfd-05]
AC/PW Fault Status Signaling
4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
[RFC-pwe3-vccv-bfd-05]
5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
[RFC-pwe3-vccv-bfd-05]
AC/PW Fault Status Signaling
6 (0x40) Reserved [RFC5085]
7 (0x80) Reserved [RFC5085]


=============================================================
sub-registry "Pseudowire Associated Channel Types"

OLD:

Value Description TLV Follows
Reference
------------- ------------------------------------------ -----------
---------
0x21 Associated Channel carries an IPv4 packet No
[RFC4385]
0x57 Associated Channel carries an IPv6 packet No
[RFC4385]
0x7ff8-0x7fff Reserved for Experimental Use
[RFC5586]

NEW:

Value Description TLV Follows
Reference
------------- ------------------------------------------ -----------
---------
0x0007 BFD Control, PW-ACH encapsulation No
[RFC-pwe3-vccv-bfd-05]
(without IP/UDP Headers)
0x21 Associated Channel carries an IPv4 packet No
[RFC4385]
0x57 Associated Channel carries an IPv6 packet No
[RFC4385]
0x7ff8-0x7fff Reserved for Experimental Use
[RFC5586]



Upon approval of this document, the IANA will also make the following
changes in 'Layer Two Tunneling Protocol "L2TP"' registry located at
http://www.iana.org/assignments/l2tp-parameters
=============================================================
sub-registry "VCCV Capability AVP (Attribute Type 96) Values"

OLD:
L2TPv3 Connectivity Verification (CV) Types
Bit (Value) Description Reference
----------- -------------------------------------- ----------
0 (0x01) ICMP Ping [RFC5085]
1 (0x02) Reserved [RFC5085]
2 (0x04) Reserved [RFC5085]
3 (0x08) Reserved [RFC5085]
4 (0x10) Reserved [RFC5085]
5 (0x20) Reserved [RFC5085]
6 (0x40) Reserved [RFC5085]
7 (0x80) Reserved [RFC5085]

NEW:
L2TPv3 Connectivity Verification (CV) Types
Bit (Value) Description
Reference
----------- --------------------------------------
----------
0 (0x01) ICMP Ping [RFC5085]
1 (0x02) Reserved [RFC5085]
2 (0x04) BFD IP/UDP-encapsulated, for PW Fault Detection only
[RFC-pwe3-vccv-bfd-05]
3 (0x08) BFD IP/UDP-encapsulated, for PW Fault Detection and
[RFC-pwe3-vccv-bfd-05]
AC/PW Fault Status Signaling
4 (0x10) BFD PW-ACH-encapsulated, for PW Fault Detection only
[RFC-pwe3-vccv-bfd-05]
5 (0x20) BFD PW-ACH-encapsulated, for PW Fault Detection and
[RFC-pwe3-vccv-bfd-05]
AC/PW Fault Status Signaling
6 (0x40) Reserved [RFC5085]
7 (0x80) Reserved [RFC5085]

Updatred proto shepherd doc...



Document Shepard 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?



Matthew Bocci (matthew.bocci@alcatel-lucent.com)

        Yes, I have reviewed the document and I believe it is ready for ?        forwading to the IESG.





    (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?



        Yes, the document has received adequate review. The document ?        received a number of detailed comments during WG 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?



      No.





    (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. 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.



      No specific concerns.





    (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?



      I am comfortable that the document represents WG consensus and has?      been reviewed by a reasonable number of active WG aprticipants. It

      has been devloped over a long period in the WG and has received comment

      and review from in excess of 12 individuals.



    (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.)



      None indicated.





    (1.g) Has the Document Shepherd personally verified that the

          document satisfies all ID nits? (See

          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?





      The document passes ID nits.

      This document is not subject to MIB doctor or other reviews.



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

          informative? 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, the references are split appropriately. There are normative references ?      to a number of drafts from the BFD working group that are currently in IESG review.

      The dependencies are:  draft-ietf-bfd-base-09.txt, draft-ietf-bfd-generic-05.txt

      and draft-ietf-bfd-v4v6-1hop-09.txt.

      This draft will need to be held in the RFC Editor's queue until those have been approved.

     



    (1.i) Has the Document Shepherd verified that the document IANA

          consideration section exists and is consistent with the body

          of the document? If the document specifies protocol

          extensions, are reservations requested in appropriate IANA

          registries? 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 [RFC5226]. 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?



      The IANA considerations section exists, is consistent with the rest of the document, and with the style of the IANA registries that it requests allocations from. It does not request any new registries or new processes for allocations from registries.





    (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?



      There are no sections that use a formal language.





    (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 new Connectivity Verification (CV) types

  using Bidirectional Forwarding Detection (BFD) with Virtual Circuit

  Connectivity Verification (VCCV).  VCCV provides a control channel

  that is associated with a Pseudowire (PW), as well as the

  corresponding operations and management functions such as

  connectivity verification to be used over that control channel.



  This document is a product of the PWE3 working group.



  This document is STANDARDS TRACK.



Working Group Summary

The draft originated as a part of the VCCV work, originally being developed as a part of draft-ietf-pwe3-vccv.

The VCCV-BFD text was then split out from that draft (which later became RFC5085). The proposed protocol in draft-ietf-pwe3-vccv-bfd-05.txt has therefore been widely reviewed over a long period by many experts in PWE3. A number

reviewers were also apponited by the WG chairs during the WG last call process.





Document Quality

There are no concerns about protocol quality. There are understood to be implementations of this protocol.



Personnel

  Who is the Document Shepherd for this document?



Matthew Bocci (matthew.bocci@alcatel-lucent.com)



Who is the Responsible Area Director?

Ralph Droms

draft-ietf-pwe3-vccv-bfd-05.txt



Document Shepard 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?



Matthew Bocci (matthew.bocci@alcatel-lucent.com)

        Yes, I have reviewed the document and I believe it is ready for ?        forwading to the IESG.





    (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?



        Yes, the document has received adequate review. The document ?        received a number of detailed comments during WG 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?



      No.





    (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. 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.



      No specific concerns.





    (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?



      I am comfortable that the document represents WG consensus and has?      been reviewed by a reasonable number of active WG aprticipants. It

      has been devloped over a long period in the WG and has received comment

      and review from in excess of 12 individuals.



    (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.)



      None indicated.





    (1.g) Has the Document Shepherd personally verified that the

          document satisfies all ID nits? (See

          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?





      The document passes ID nits.

      This document is not subject to MIB doctor or other reviews.



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

          informative? 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, the references are split appropriately. There are normative references ?      to a number of drafts from the BFD working group that are currently in IESG review.

      The dependencies are:  draft-ietf-bfd-base-09.txt, draft-ietf-bfd-generic-05.txt

      and draft-ietf-bfd-v4v6-1hop-09.txt.

      This draft will need to be held in the RFC Editor's queue until those have been approved.

     



    (1.i) Has the Document Shepherd verified that the document IANA

          consideration section exists and is consistent with the body

          of the document? If the document specifies protocol

          extensions, are reservations requested in appropriate IANA

          registries? 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 [RFC5226]. 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?



      The IANA considerations section exists, is consistent with the rest of the document, and with the style of the IANA registries that it requests allocations from. It does not request any new registries or new processes for allocations from registries.





    (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?



      There are no sections that use a formal language.





    (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:



  This document describes new Connectivity Verification (CV) types

  using Bidirectional Forwarding Detection (BFD) with Virtual Circuit

  Connectivity Verification (VCCV).  VCCV provides a control channel

  that is associated with a Pseudowire (PW), as well as the

  corresponding operations and management functions such as

  connectivity verification to be used over that control channel.



  This document is a product of the PWE3 working group.



  This document is STANDARDS TRACK.