Skip to main content

Last Call Review of draft-ietf-isis-bfd-tlv-
review-ietf-isis-bfd-tlv-secdir-lc-kent-2010-07-30-00

Request Review of draft-ietf-isis-bfd-tlv
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-07-26
Requested 2010-07-15
Authors Christian Hopps , Les Ginsberg
I-D last updated 2010-07-30
Completed reviews Secdir Last Call review of -?? by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Request Last Call review on draft-ietf-isis-bfd-tlv by Security Area Directorate Assigned
Completed 2010-07-30
review-ietf-isis-bfd-tlv-secdir-lc-kent-2010-07-30-00
Title: 

review of
draft-ietf-isis-bfd-tlv-02




I reviewed this
document as part of the security directorate's ongoing effort to
review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.







This is a very
brief (8-page) document that is generally well written. It defines a
TLV (an acronym not defined in the document, but I'm guessing
type-length-value) value for use in IS-IS, for bidirectional
forwarding detection (BFD). The abstract says that this TLV is needed
because, in some scenarios, IS-IS fails to detect a forwarding plane
failure based on BFD as described in ietf-bfd-generic]. Section 2 of
this (the reviewed) document describes a class of scenarios in which
the BFD mechanism cited above would not work properly, thus motivating
the proposal contained here. The simple solution proposed here is for
a router to advertise its ability to perform BFD on an interface via
its IS-IS IIH (an acronym not defined in the document), hence the need
to define this TLV.  My biggest complaint with the document
overall is that it uses several acronyms without first defining them,
an easy problem to fix.





The Security Considerations section is just one paragraph, which
states that the addition of this feature does not adversely affect the
security mechanism (sic) of IS-IS. I'm not questioning this assertion,
based on reading this document, but I think a couple of additional
sentences are needed here, to justify the assertion.