Last Call Review of draft-ietf-bfd-seamless-base-08

Request Review of draft-ietf-bfd-seamless-base
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-03
Requested 2016-03-23
Authors Carlos Pignataro, David Ward, Nobo Akiya, Manav Bhatia, Santosh Pallagatti
Draft last updated 2016-05-09
Completed reviews Genart Last Call review of -08 by Dan Romascanu (diff)
Genart Telechat review of -09 by Dan Romascanu (diff)
Secdir Last Call review of -08 by Shawn Emery (diff)
Opsdir Last Call review of -08 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-ietf-bfd-seamless-base-08-opsdir-lc-kuarsingh-2016-05-09
Reviewed rev. 08 (document currently at 11)
Review result Has Issues
Review completed: 2016-05-09


    Dear Authors,

    I have reviewed this document as part of the Operational
    directorate's ongoing effort to review all IETF documents being
    processed by the IESG.  These comments were written with the intent
    of improving the operational aspects of the IETF drafts. Comments
    that are not addressed in last call may be included in AD reviews
    during the IESG review.  Document editors and WG chairs should treat
    these comments just like any other last call comments.

    Document Reviewed - Host address availability recommendations

    Link to Document -


    The document defines the based protocol specification for Seamless
    Bidirectional Forwarding Detection (S-BFD).  The S-BFD mechanism is
    aimed at providing a simplified way to enable BFD by removing many
    of the negotiation aspects that are found in the original protocol
    (BFD as defined in RFC5880)

    The optimizations provided as part of S-BFD is realized by
    shortening the time between when a network node wishes to perform a
    continuity test, and the needed protocol actions to accomplish the

    General Comments and Feedback: 

    In general, the document is well written and has already gone
    through considerable review.  Since this new version of BFD (S-BFD)
    will likely operate in mix-mode deployments along with BFD
    (RFC5880), the operational aspects, co-existence aspects were
    reviewed to ensure that implementations will not intrinsically cause

    The authors did provide consideration co-existence and operational
    text.  Section 7.1, for example, provides demultiplexing procedures
    to ensure packets are evaluatedf correctly.  Section 8 provides good
    operational considerations for S-BFD.

    I do have some review questions I would like the author team to
    comment on, to ensure the operational aspects were covered. It's
    possible the intended texts addresses these question, however a
    response is appreciated for clarity.

    Review Questions (operational aspect view)

    << Item 1 >>

    Section 4.1 notes that uniqueness of a discriminator "MUST" be
    unique within an administrative domain.  Would you consider this to
    be true even for a anycast service where you may have multiple nodes
    which can potentially use the same IP address for a given service? 
    In such a case, would a common discriminator be potentially used
    where the user may desire that from a given initiator, one or more
    responder can provide continuity to that service (IP address)?  I
    may have missed the point, so thought I would ask for operational
    clarity.  is seems the optional stateless nature of S-BFD would lend
    itself to this use case.

    << Item 2 >>

    Section 3, notes that using multiple S-BFD discriminators is
    "discouraged" until a mapping capability is defined.  Given the
    potential operational issues here, would this not be better note as
    as MUST NOT or SHOULD NOT?  This would then help ensure
    implementations avoid such options.  I would think a subsequent
    document (which updates this specification) could then update the

    << Item 3 >>

    Section 10 notes that spoofed packets can occur on S-BFD echos.  In
    addition to an echo function potential issue, would this not be
    considered a security consideration as well?

    Textual Review

    Abstract - ok


    par1 << old text >> ".. and related documents, has

    << suggested >> ".. and related documents, have

    par2 << old text >> " ..a rather simplified and largely
    stateless infrastructure for continuity testing."

    << questions >> would this not more appropriately say
    ".. a rather simplified and optionally stateless infrastructure.."?
      The S-BFD stateless operation seems to be optional.  Not a
    considered an object, just seems like that's a better reflection of
    this point.

    par3  << old text >>".. DOWN to UP are virtually
    nonexistent" may be better reflected as "... DOWN to UP are greatly
    optimized." (or "reduced").

    Section 3: Seamless BFD Overview

    par2. << old text >> "Once above setup is complete .."
    to "One the above setup is complete.."

    Section 4.1

    par1. << old text >> "One important characteristics.. "
    to "One important characteristic.."

Section 4.2

par3. << old text >> ".. values for entities,
      listened by SBFDReflector.." Did you mean to say "learned" here?