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) Yes
Comment (2013-12-04 for -03)
No email
send info
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.
(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
send info
Thank you for producing this clearly written doc!
(Stephen Farrell) No Objection
Comment (2013-12-05 for -03)
No email
send info
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
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.