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

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

(Adrian Farrel; former steering group member) Yes

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

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.

(Barry Leiba; former steering group member) (was Discuss) No Objection

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

(Benoît Claise; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Brian Haberman; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Joel Jaeggli; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Martin Stiemerling; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Pete Resnick; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Richard Barnes; former steering group member) (was Discuss) No Objection

No Objection ( for -03)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection ( for -03)
No email
send info

(Spencer Dawkins; former steering group member) No Objection

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

(Stephen Farrell; former steering group member) No Objection

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

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -03)
No email
send info