Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
draft-ietf-bfd-on-lags-04

[Ballot comment]

Sam Hartman's secdir review comment deserves to be
preserved in more than one place:

"If the universe valued good abstraction layers, entire civilizations
would crumble in disgust every time you send one of these packets.
However, it is a useful hack for performance and code re-use."

He also agreed there were no new security considerations.

[Ballot discuss]
This is an "Just want to make sure there's a cogent answer" DISCUSS: Is this really something we need to burn a port for?  It seems like you could distinguish this somewhere within the payload, e.g., by using a new version number (although I guess this would burn a version number).

[Ballot comment]
We will need to address the Routing Directorate review from Thomas Morin reproduced here for the record.

Summary:

  The document is concise, well written, and raises no major issue.
  However, bringing clarifications to a few areas should be considered
  prior to publication.

Major Issues:

  None.

Minor Issues:

- Mi.1) The document mentions the use of a specific UDP port for the
micro-BFD sessions (6784). It should probably explain what is the
behavior if BFD messages from a micro-BFD sessions are received on the
normal BFD port (3784), and vice-versa what is the behavior for BFD
messages from a non-BFD sessions is received on the micro-BFD UDP port.

- Mi.2) The document indicates in section 2.2 that "The details of how
[the destination IP address of the BFD peer] is learned are outside the
scope of this document.".  First, an example of a common practice would
be great to provide an illustration.  Second, I would find it worth
documenting how this can be done in practice on an unnumbered link

- Mi.3) The notion of "L3 continuity" is used in the introduction, but
it is not explained what this means; it would deserve being explained as
the idea of "continuity" may not be obvious to interpret in a contect
where a single L3 hop is being tested.

- Mi.4) Section 4 mentions "LMM" and "some Interface management module"
without providing any definition nor explaining the role of such modules.

- Mi.5) The behavior described in the Appendix looks very important for
smooth activation of the feature in a real network and is actually
specification text. I'm thus surprised to find it in an Appendix --
where it could be missed by implementors.  I would suggest considering
moving this text among the rest of technical specifications sections.


** Editorial comments:

- Ed.1) I would suggest removing the mention of the use of a specific
UDP port from the Abstract, which would then be more concise -- the
motivation for using a specific UDP port so could be provided in section
2.2.

- Ed.2) Section 2.3: "For the following BFD packets with Up state the
MAC address from the received BFD packets for the session MAY be used
instead of the dedicated MAC. "

    => "the _source_ MAC address from the received BFD packets" ?
(adding "source" would remove any risk of ambiguous interpretation)

- Ed.3) Section 5: "MAY remove the member link from the load balance
table only that matches the address family of the failing BFD session"

  I had issues parsing this sentence; what about: "MAY remove the
member link from only the load balance table that matches..."

  Furthermore, it would be nice to add a colon at the end of the
sentence to indicate that what follows is an illustration of what precedes.

  Last, I think it would be worth indicating explicitly that "The
member link MAY also be removed from both the L4 and L6 load balancing
table".

- Ed.4) I believe you need to update contact information for Nitin Bahadur.

[Ballot comment]
To the document shepherd:
The shepherd writeup was clear and useful, without being unnecessarily wordy.  Thanks for a good writeup.

My former DISCUSS point about the IANA registrations is handled by the RFC Editor note.  Thanks, Adrian.

[Ballot discuss]
This is a really trivial point, but as the IANA review didn't pick it up we need to make sure it's called out to them:

  IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see
  [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding
  Detection (BFD) on Link Aggregation Group (LAG) Interfaces.

The IANA review says that no IANA actions are required.  In fact, the early registrations do need to have their references updated to point to this RFC (they currently point to this draft's predecessor, draft-mmm-bfd-on-lags).  Adding two paragraphs to the above that say something like this should do it:

ADD
In the IANA Multicast 48-bit MAC Addresses registry
http://www.iana.org/assignments/ethernet-numbers#ethernet-numbers-3
IANA is asked to change the reference for the registration of 90-00-01 to [RFC-to-be].

In the Service Name and Transport Protocol Port Number registry
http://www.iana.org/assignments/service-names-port-numbers
IANA is asked to change the reference for the registration of port 6784 to [RFC-to-be].
END

[Ballot comment]
To the document shepherd:
The shepherd writeup was clear and useful, without being unnecessarily wordy.  Thanks for a good writeup.

A very minor comment to the editors:
This document actually is an Applicability Statement, as described in RFC 2026.  It doesn't make a lot of difference, but it might be reasonable to say that in the introduction, as something like this:

In the Abstract:
OLD
  This document defines a mechanism to run BFD on Link Aggregation
  Group (LAG) interfaces.
NEW
  This Applicability Statement defines a mechanism to run BFD on Link
  Aggregation Group (LAG) interfaces.
END

In the Introduction:
OLD
  The approach taken in this document is to run a Asynchronous mode BFD
  session over each LAG member link
NEW
  The approach taken in this document is to run a Asynchronous mode BFD
  session over each LAG member link
END

I ask this because there's a lack of understanding of what Applicability Statements are, and calling it out might be useful.  But this is truly minor, and if you'd rather not do that, it's fine.  Thanks for considering it.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-bfd-on-lags-02, which is currently in Last
Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA
Actions that need completion. IANA requests that the IANA
Considerations section of the document remain in place upon
publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces) to Proposed Standard

The IESG has received a request from the Bidirectional Forwarding
Detection WG (bfd) to consider the following document:
- 'Bidirectional Forwarding Detection (BFD) on Link Aggregation Group
  (LAG) Interfaces'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document proposes a mechanism to run BFD on Link Aggregation
  Group (LAG) interfaces.  It does so by running an independent
  Asynchronous mode BFD session on every LAG member link.

  This mechanism allows the verification of member link continuity,
  either in combination with, or in absence of, LACP.  It provides a
  shorter detection time than what LACP offers.  The continuity check
  can also cover elements of layer 3 bidirectional forwarding.

  This mechanism utilizes a well-known UDP port distinct from that of
  single-hop BFD over IP.  This new UDP port removes the ambiguity of
  BFD over LAG packets from BFD over single-hop IP.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags/ballot/


The following IPR Declarations may be related to this I-D:
  http://datatracker.ietf.org/ipr/2084/

The BFD Working Group requests that

  Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG)
                              Interfaces
                      draft-ietf-bfd-on-lags-02

Is published as an RFC on the standards track.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

    Requested RFC type: Proposed Standard

    The document header says: Standards Track

    This document specifies new protocol elements and procedures, and clearly
    need to be on the standards track.

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

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

    This document proposes a mechanism to run BFD on Link Aggregation
    Group (LAG) interfaces.  It does so by running an independent
    Asynchronous mode BFD session on every LAG member link.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

    Blurred L2/L3 line stemmed several interesting discussions. Is it
    layer violation for BFD operating at layer 3 to make layer 2 decision?
    How does it interact with LACP? How does it influence LAG member link
    usability? The desire and need for rapid detection of LAG member link
    usability, as well as similar solutions already implemented by multiple
    vendors, resulted in consensus to push this technology forward. WG was
    satisfied with very careful wordings of the document to ensure that
    solution does not tread into IEEE turf.

    In addition, remote IP address discovery was a controversial topic.
    There were multiple ideas to do this dynamically, which WG couldn't
    reach consensus. Thus this aspect was taken out into a separate draft.
    That spin-off draft died, since people lost interest due to statically
    configuring remote IP address working good enough.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? 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?

    There are multiple implementations of the protocol. Even was held to
    interoperate the implementations.
   
    The document has been reviewed through the normal WG process.

    No  MIB Doctor, Media Type or other expert review been performed or
    requested.


Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

    Nobo Akiya is the document Shepherd.

    Adrian Farrel is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    The document Shepherd reviewed the document at multiple stages of the
    document, including when it was accepted as a BFD WG document and as
    part of WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

    No such concerns.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    IEEE liaison for this work has been completed.
    http://datatracker.ietf.org/liaison/1192/

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

    As described in (2), dynamic remote IP address discovery topic is
    an open end with very little interests. However, it is a topic which
    comes up from time to time.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    One IPR exists.
    http://datatracker.ietf.org/ipr/2084/
    Each author has stated on the working group mailing list that they are
    un-aware of any IPR that relates to this document, beyond the one
    mentioned above.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    One IPR exists.
    http://datatracker.ietf.org/ipr/2084/

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

    The working group is behind this document. 

(10) 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 publicly available.)

    No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    The document passes the ID nits tool clean, with two minor exceptions.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    No such reviews required.

(13) Have all references within this document been identified as
either normative or informative?

    There are normative and informative references in this document.
    All but one are existing RFC's. One is a reference to IEET document:
    [IEEE802.1AX].

    All references are listed and all are referenced correctly.

(14) 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 plan for their completion?

    All normative references are to existing RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    There are no downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    No existing RFCs will be changed by the publication of this document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    The Shepherd have reviewed the IANA Considerations.

    > IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see
    > [RFC7042]) as well as UDP port 6784 for UDP encapsulated micro BFD
    > sessions.

    For dedicated MAC address, confirmed the IANA page.
    http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml

    For UDP port, confirmed the IANA page.
    http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6784

    The IANA considerations are roughly written, but given that allocations
    have already been completed, it seems fine.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    No such needed.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    No such review.