Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)
draft-ietf-bfd-mpls-07

[Ballot discuss]
Section 6 says:
  >
  > A BFD session is boot-strapped using LSP-Ping. This specification
  > describes procedures only for BFD asynchronous mode.
  >
  As raised during Last Call by Brian Carpenter in his Gen-ART Review,
  it is unlcear whether BFD Demand mode is allowed.  Please clarify.

  Concerns about som text in Section 7 were raised during Last Call by
  Brian Carpenter in his Gen-ART Review, but the document has not been
  updated and the RFC Editor note deals with a different topic.  The
  text in Section 7 says:
  >
  > The BFD control packet sent by the ingress LSR MUST be a UDP packet
  > with a well known destination port 3784 [BFD-IP] and a source port
  > assigned by the sender as per the procedures in [BFD-IP]. The source
  > IP address is a routable address of the sender. The destination IP
  > address is randomly chosen from the 127/8 range,
  >
  This is written in IPv4 terms. What is supposed to happen in an
  IPv6-only environment?  Brian Carpenter  noted that there is not a
  range of loopback addresses to borrow in IPv6, but one might use a
  ULA prefix.

[Ballot discuss]
Carlos Pignataro submitted some IETF Last Call comments, and the only
  response to them that I see is one that promises to consider them.
  I do not actually see a response that deals with the content of the
  comments.  Did it happen?  What mail list was used for the discussion?

  Section 6 says:
  >
  > A BFD session is boot-strapped using LSP-Ping. This specification
  > describes procedures only for BFD asynchronous mode.
  >
  As raised during Last Call by Brian Carpenter in his Gen-ART Review,
  it is unlcear whether BFD Demand mode is allowed.  Please clarify.

  Concerns about som text in Section 7 were raised during Last Call by
  Brian Carpenter in his Gen-ART Review, but the document has not been
  updated and the RFC Editor note deals with a different topic.  The
  text in Section 7 says:
  >
  > The BFD control packet sent by the ingress LSR MUST be a UDP packet
  > with a well known destination port 3784 [BFD-IP] and a source port
  > assigned by the sender as per the procedures in [BFD-IP]. The source
  > IP address is a routable address of the sender. The destination IP
  > address is randomly chosen from the 127/8 range,
  >
  This is written in IPv4 terms. What is supposed to happen in an
  IPv6-only environment?  Brian Carpenter  noted that there is not a
  range of loopback addresses to borrow in IPv6, but one might use a
  ULA prefix.

[Ballot discuss]
Section 6 says:
  >
  > A BFD session is boot-strapped using LSP-Ping. This specification
  > describes procedures only for BFD asynchronous mode.
  >
  As raised during Last Call by Brian Carpenter in his Gen-ART Review,
  it is unlcear whether BFD Demand mode is allowed.  Please clarify.

  Concerns about som text in Section 7 were raised during Last Call by
  Brian Carpenter in his Gen-ART Review, but the document has not been
  updated and the RFC Editor note deals with a different topic.  The
  text in Section 7 says:
  >
  > The BFD control packet sent by the ingress LSR MUST be a UDP packet
  > with a well known destination port 3784 [BFD-IP] and a source port
  > assigned by the sender as per the procedures in [BFD-IP]. The source
  > IP address is a routable address of the sender. The destination IP
  > address is randomly chosen from the 127/8 range,
  >
  This is written in IPv4 terms. What is supposed to happen in an
  IPv6-only environment?  Brian Carpenter  noted that there is not a
  range of loopback addresses to borrow in IPv6, but one might use a
  ULA prefix.

[Ballot discuss]
First, a minor thing: s/TTL/TTL or Hop Limit/

Then, I agree with Pasi's Discuss. I would like to add that I do
not think removing the RFC 1122 requirement on not using 127/8
on the wire is appropriate in general. It has been done for
a particular MPLS scenario earlier, and I believe we can do it
in a similar situation (like here) again. However, I think it
would be inappropriate for BFD to use 127/8 in other contexts
than MPLS. Does it use 127/8 elsewhere? bfd-1hop is unclear about
the specific addresses that should be used.

[Ballot discuss]
Using 127/8 addresses violates a MUST in RFC 1122 (a full standard).
An explanation similar to RFC 4379 (possibly referencing text when
appropriate) and "Updates: RFC 1122" is needed.

The base document says BFD Echo packet format is specified in the
appropriate application document -- but I can't find text saying how
BFD Echo works in MPLS?

Proto writeup by Dave Ward (as WG co-chair and author):

1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes


  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes. BT had brought together multiple vendors and implementors a year before publishing the docs to make sure every issue was cleared up and intention documented.


    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?
   
    No.


3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No


  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No concerns


  5. 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?

It represents strong consensus of a large group of implementors.


6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No


  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

    Yes


8. Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with 
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

    Yes, No


  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

    Proposed Standard


10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following 
    sections:

    * Technical Summary:

BFD and the corollary documents define a mechanism for layer 3 forwarding plane failure detection. There are multiple modes (async, echo, demand) for different circumstances. One interesting aspect of BFD is that it has adaptive timers thus, parameters can be modified without tearing down adjacencies. In addition, the amount of BW and overhead incurred by the network and network nodes is completely under the control of the operator.

  * Working Group Summary

There was no opposition to this document.

    * Protocol Quality

The protocol is widely implemented and deployed and has become
part of default deployments on the internet. The drafts reflect the
lessons learned from the deployed and operation.

IANA Last Call comments:

IANA has a question:

- What does "[LSP-Ping]" refer to?

Upon approval of this document, the IANA will make the following
assignment in the "Multi-Protocol Label Switching (MPLS) Label
Switched Paths (LSPs) Parameters - per [RFC4379]" registry located
at http://www.iana.org/assignments/mpls-lsp-parameters
sub-registry "TLVs"

Type Sub-Type Value Field Reference
----- -------- --------------------------------- ---------
tbd(15) BFD Discriminator [RFC-bfd-mpls-05]

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