IS-IS BFD-Enabled TLV
RFC 6213

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

Lars Eggert (was Discuss) No Objection

Comment (2010-10-26)
No email
send info
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

Yes (2010-10-28 for -)
No email
send info
Agree with the discusses though, in particular with the graceful restart interaction issue.

(Stewart Bryant; former steering group member) Yes

Yes ( for -)
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-10-28 for -)
No email
send info
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

No Objection (2010-10-23 for -)
No email
send info
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

No Objection ( for -)
No email
send info

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2010-10-26 for -)
No email
send info
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

No Objection ( for -)
No email
send info

(Robert Sparks; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Sean Turner; former steering group member) No Objection

No Objection (2010-10-27 for -)
No email
send info
I support Tim and Lars discuss positions.

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection (2010-10-27)
No email
send info
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.