Last Call Review of draft-ietf-bfd-seamless-base-08
review-ietf-bfd-seamless-base-08-opsdir-lc-kuarsingh-2016-05-09-00

  
  
    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 - 

https://tools.ietf.org/html/draft-ietf-bfd-seamless-base-09








    Summary:
    





    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
    test.





    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
    issues.





    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
    MUST/SHOULD NOT.





    << 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





    Introduction





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


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





    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?