Skip to main content

IS-IS BFD-Enabled TLV
RFC 6213

Yes

(Stewart Bryant)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)

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

Lars Eggert (was Discuss) No Objection

Comment (2010-10-26)
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)
Agree with the discusses though, in particular with the graceful restart interaction issue.

(Stewart Bryant; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-10-28)
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)
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 ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

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

No Objection (2010-10-26)
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 ()

                            

(Robert Sparks; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) No Objection

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

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

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