IS-IS BFD-Enabled TLV
RFC 6213
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert (was Discuss) No Objection
Section 3., paragraph 1: > A simple solution to this problem is for an IS-IS router to advertise > that it has BFD enabled on a given interface. It can do this through > the inclusion of a TLV in its IIHs, and indeed that is our proposal. Since this isn't at the proposal stage anymore, please rephrase for RFC publication.
(Jari Arkko; former steering group member) Yes
Agree with the discusses though, in particular with the graceful restart interaction issue.
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I believe [I-D.ietf-bfd-base] and [I-D.ietf-bfd-generic] (which are now RFCs) should be normative references for this work. The note in section 8: Note to RFC Editor: this section may be removed on publication as an RFC. should be removed since it is normal for non-null IANA sections to remain in place in published RFCs. Can the responsible AD please confirm with IANA that expert review for the codepoint allocation has happened.
(Alexey Melnikov; former steering group member) No Objection
It looks like [I-D.ietf-bfd-base] is actually a Normative reference, as a reader is expected to understand it in order to implement this extension.
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
1. Please expand acronyms on first use ("IIH", "TLV", "MITD", "NLPID", "PDU", etc.) or add a section on Terminology that points to the appropriate specifications.
2. Section 3.3. has the sentence: "If ISIS_TOPO_USEABLE is FALSE then the topology specific neighbor is NOT advertised." The capitalized term "NOT" is decidedly not an RFC2119 keyword, so please lowercase it. (The capitalized logical terms and system states "TRUE", "FALSE", "AND", "OR", "UP", and "DOWN" are slightly less confusing, although they could be put in scare quotes for improved readability.)
3. Removing the IANA Considerations section on publication is not standard practice.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I support Tim and Lars discuss positions.
(Tim Polk; former steering group member) (was Discuss) No Objection
I support Lars' discuss with respect to graceful restart. It would have been helpful if the goal of each state definition was explained in section 3.1. (It probably would have avoided my discuss!) Three of the six state variables defined in 3.1 are never mention in sections 3.2, 3.3, or 4. Apparently, these variables were only needed to compute the three state variables: ISIS_BFD_REQUIRED; ISIS_NEIGHBOR_USEABLE; and ISIS_TOPO_USEABLE. Differentiating the interim values from the values that impact adjacency establishment/maintenance, topology advertisement, and transition might also enhance clarity. Please consider expanding IIH, MTID, and NLPID.