Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces
RFC 7130
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Adrian Farrel; former steering group member) Yes
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
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
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
(Richard Barnes; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
Thank you for producing this clearly written doc!
(Stephen Farrell; former steering group member) No Objection
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