IS-IS BFD-Enabled TLV
draft-ietf-isis-bfd-tlv-03

[Ballot comment]
[moving to No Objection based on the RFC Editor Note]

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.

[Ballot comment]
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.

[Ballot discuss]
(1) This is a minor discuss, but section 3.1 includes the following:

  For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
  variable is assigned.  If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
  variable follows the BFD session state for that MTID/NLPID (UP ==
  TRUE).  Otherwise the variable is set to TRUE.

Somehow, the last sentence feels wrong.  I was expecting FALSE if
ISIS_TOPO_NLPID_BFD_REQUIRED was not TRUE.  Please double-check
and let me know you verified or changed the value).  I will clear regardless of
the decision!

(2) The authors have proposed text for the security considerations section in response
to the secdir review back on 7/27.  The text is not in the document or an RFC Editor Note,
so I am afraid it has been lost.  The proposed text was:

The TLV defined within this document describes an addition to the IS-IS
Hello protocol. Inappropriate use of this TLV could prevent an IS-IS
adjacency from forming or lead to failure to detect bidirectional
forwarding failures - each of which is a form of denial of service.
However, a party who can
manipulate the contents of this TLV is already in a position to create
such a denial of service by disrupting IS-IS routing in other ways.

[Ballot comment]
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.

[Ballot discuss]
This is a minor discuss, but section 3.1 includes the following:

  For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
  variable is assigned.  If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
  variable follows the BFD session state for that MTID/NLPID (UP ==
  TRUE).  Otherwise the variable is set to TRUE.

Somehow, the last sentence feels wrong.  I was expecting FALSE if
ISIS_TOPO_NLPID_BFD_REQUIRED was not TRUE.  Please double-check
and let me know you verified or changed the value).  I will clear regardless of
the decision!

[Ballot comment]
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!)

Please consider expanding MTID and NLPID.

I support Lars' discuss with respect to graceful restart.

[Ballot discuss]
This is a minor discuss, but section 3.1 includes the following:

  For each locally supported MTID/NLPID pair, an ISIS_TOPO_NLPID_STATE
  variable is assigned.  If ISIS_TOPO_NLPID_BFD_REQUIRED is TRUE, this
  variable follows the BFD session state for that MTID/NLPID (UP ==
  TRUE).  Otherwise the variable is set to TRUE.

Somehow, the last sentence feels wrong.  I was expecting FALSE if
ISIS_TOPO_NLPID_BFD_REQUIRED was not TRUE.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
Section 5., paragraph 1:
>    It is worth considering what if anything should be done when IS-IS is
>    gracefully restarting [RFC5306].

  DISCUSS: Since RFC5306 is already published, it is up to this document
  to specify how the proposed mechanism intersects with
  graceful-restart. The text in the remainder of this section seems to
  boil down to "we don't know", in which case I think you should
  actually say that this mechanism MUST NOT be used together with
  RFC5306 (until someone writes an ID that sorts this out in detail). It
  would probably also be good to discuss the pros and cons of when to
  use RFC5306 and when to use the proposed mechanism.

[Ballot comment]
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.

IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "isis-tlv-codepoints" registry, in the sub-registry
named "TLV Codepoints Registry", located at
:

Value: 139
Name: BFD Enabled TLV
IIH: y
LSP: n
SNP: n
Status/Reference: [RFC-ietf-isis-bfd-tlv-02]

PROTO Questionnaire and Write-up for:draft-ietf-isis-wg-extlsp-03.txt
Shepherding WG-Chair: David Ward (dward@juiper.net)

Questionnaire

Q1) Have the chairs personally reviewed this version of the
Internet Draft (ID), and in particular, do they believe
this ID is ready to forward to the IESG for publication?

A1) Yes.

Q2) Has the document had adequate review from both key WG
members and key non-WG members? Do you have any concerns
about the depth or breadth of the reviews that have been
performed?

A2) Adequately reviewed.

Q3) Do you have concerns that the document needs more review
from a particular (broader) perspective (e.g., security,
operational complexity, someone familiar with AAA, etc.)?

A3) No concerns.

Q4) Do you have any specific concerns/issues with this
document that you believe the ADs and/or IESG should be
aware of? For example, perhaps you are uncomfortable with
certain parts of the document, or have concerns whether
there really is a need for it. In any event, if your issues
have been discussed in the WG and the WG has indicated it
that it still wishes to advance the document, detail those
concerns in the write-up.

A4) No concerns.

5) How solid is the WG consensus behind this document? Does
it represent the strong concurrence of a few individuals,
with others being silent, or does the WG as a whole understand
and agree with it?

A5) Strong Consensus.

6) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarise the areas of
conflict in separate email to the Responsible Area Director.

A6) No.

7) Have the chairs verified that the document adheres to
all of the ID Checklist items ?

A7) Yes.

8) Is the document split into normative and informative
references? Are there normative references to IDs, where
the IDs are not also ready for advancement or are otherwise
in an unclear state? (note here that the RFC editor will
not publish an RFC with normative references to IDs, it
will delay publication until all such IDs are also ready
for publication as RFCs.)

A8) References are split. No IDs in normative. There are IDs
in the informative references.

9) What is the intended status of the document? (e.g.,
Proposed Standard, Informational?)

A9) Proposed Standard.

*** Write-up

** Technical Summary

This specification provides a solution for when there is an IP
forwarding failure as detected by BFD, but IS-IS control packets
continue to be delivered and so the adjacency stays up. The original
BFD specification allows for IGP adjacencies to form without paired
BFD sessions to allow for mixed-use of BFD on a link. This
specification adds a hello TLV that advertises BFD use so that
adjacency state to participating routers can depend on the state
of a paired BFD session.

** Working Group Summary

There consensus was strong for this specification.

** Protocol Quality

There are currently no implementations of this specification.