Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

Note: This ballot was opened for revision 02 and is now closed.

(Adrian Farrel) Yes

Comment (2013-12-04 for -03)
No email
send info
We will need to address the Routing Directorate review from Thomas Morin reproduced here for the record.


   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:


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

- 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

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

(Jari Arkko) No Objection

(Richard Barnes) (was Discuss) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Spencer Dawkins No Objection

Comment (2013-11-30 for -02)
No email
send info
Thank you for producing this clearly written doc!

(Stephen Farrell) No Objection

Comment (2013-12-05 for -03)
No email
send info
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.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) (was Discuss) No Objection

Comment (2013-12-04 for -03)
No email
send info
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.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection