AD Review of draft-ietf-bfd-seamless-use-case

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

In general I believe that use case documents have a very limited purpose and lifetime.  While guiding the WG in the type of problems that need to be solved is very valuable, the usefulness mostly ends there.

I would like to ask the WG to consider not publishing this document.  Some of the reasons behind me asking for this consideration are that not all the use cases seem to add new requirements, they are just examples of different instances of expressing the same need, and that there may be many more similar examples — this last point from some of the text in the Introduction [1].  I think that it would then be better to keep them all in a place where the WG can easily update them (without going through the publication process), a wiki or a long-lived ID, for example.

I’m talking about requirements because even though this document says that “certain requirements could be derived to be used as reference”, the S-BFD base document says that it “extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case].”  If solutions are created then it would be nice to clearly know what the requirements are.

If there is still WG consensus to publish this document, I would like to see the readability improved and the requirements clarified.  See my detailed comments below.  I will keep the document in AD Evaluation (and not return it to the WG) at least until a decision has been made.

Thanks!

Alvaro.

[1] “…use cases could be used as reference for certain requirements, it is outside the scope of this document to identify all of the requirements for all possible enhancements."


Major:

  1.  Requirements.  If there are going to be requirements listed in this document, please be specific on what they are.  It would be helpful for tracking if they were also clearly identified.  No need for normative language, I’m mostly looking for clarity and ease.  Some comments:
     *   3.1. (Unidirectional Forwarding Path Validation) "The primary requirement in this use case is to enable session establishment from source network entity to target network entity.”  If this is the primary requirement, what are the other ones?  Is the requirement itself that only the source should have to be provisioned beforehand?
     *   3.2. (Validation of forwarding path prior to traffic switching)  “It will be desirable to perform BFD validation very quickly to allow applications to utilize dynamically created LSPs in a timely manner.”  Is that the requirement that comes out of this use case?  Is it optional (“desirable”)?  What do “very quickly” and “in a timely manner" mean?  This section starts with a generic description of the use case, I’m assuming the requirement is general as well and not just applicable to “dynamically created LSPs”.
        *   The use case in Section 3.3. (Centralized Traffic Engineering) seems to also be calling for the ability "to instantly verify a forwarding path”.  What does “instantly” mean?  Are there other requirements that come from this section?
     *   3.4. (BFD in Centralized Segment Routing) “In validating this use case, one of the requirements is to ensure the BFD packet's behavior is according to the requirement and monitoring of the segment…”  I-D.geib-spring-oam-usecase doesn’t mention BFD — I know it implies it in a more generic way.  For the purposes of this document, I don’t think it’s enough to to just say that “one of the requirements..is according to the requirements..of the segment” — in essence it seems like this document is just pointing the reader to the other document to figure out what needs to be done.  Maybe a better reference for requirements is draft-ietf-spring-sr-oam-requirement.  It would also be nice to at least highlight the places where this use case introduces new requirements and why.
     *   3.5. (BFD Efficient Operation Under Resource Constraints) “…it is desirable for BFD to…”  and 3.9. (MPLS BFD Session Per ECMP Path) "it may be desirable to run in-band monitoring…”    Optional?
     *   3.6. (BFD for Anycast Address)  The requirement here is ???
     *   3.7. (BFD Fault Isolation)  "If BFD had built-in fault isolation capability…”  and 3.8. (Multiple BFD Sessions to Same Target) "if a node was to run multiple BFD sessions to targets…”   Conditional form..

Minor:

  1.  Some of the text needs to be cleaned up because it is repetitive.
     *   Introduction: "Bidirectional Forwarding Detection (BFD) is a lightweight protocol…used to detect forwarding failures.  Various protocols and applications rely on BFD for failure detection.  Even though the protocol is simple and lightweight, there are certain use cases, where faster setting up of sessions…This document identifies use cases…BFD was designed to be a lightweight "Hello" protocol to detect data plane failures…speed at which these sessions could be established…This document specifically identifies those cases…”
     *   Section 2. (Introduction to Seamless BFD): “In order for BFD to be able to initially verify that a connection is valid…such that this information can be used to verify that the connection is valid."
  2.  Solutions are outside the scope of this document.  There are several places where the text starts to describe the (potential at this point) behavior of S-BFD.  That should be left to the solution document.  Some examples:
     *   2. (Introduction to Seamless BFD): "As an example of how Seamless BFD (S-BFD) might work…”
     *   3.1. (Unidirectional Forwarding Path Validation): "But with unidirectional BFD,..”, and "This translates to…”
     *   3.2. (Validation of forwarding path prior to traffic switching): "This use case does not require to have sequences…”, and "When these sequences for handshake…”
     *   3.9. (MPLS BFD Session Per ECMP Path)  "One way to achieve BFD session per ECMP path of LSP is…"
     *   Note that if this document was maintained as a sustaining reference, then it would be easier to edit and add the specifics of how the requirements are satisfied.
  3.  Section 3. (Use Cases): “This section outlines some use cases where the existing mechanism may not be able to satisfy the requirements.”  May not?  Does that mean that for some of the use cases the existing mechanisms can satisfy the requirements?  Which ones?

Nits:

  1.  Missing references.
     *   1.1 "The reader is expected to be familiar with the BFD, IP, MPLS and Segment Routing (SR) terminology and protocol constructs."
     *   3.7 "BFD multi-hop and BFD MPLS…"
  2.  Section 3. (Use Cases).  “…some of the use cases also be identify the need for…”  ??
  3.  Section 3.5. (BFD Efficient Operation Under Resource Constraints) “?”
  4.  Section 3.8. (Multiple BFD Sessions to Same Target)  s/as relevant network nodes continuously transmitting BFD packets at negotiated rate/as relevant network nodes continuously transmit BFD packets at negotiated rates
  5.  Section 4. (Security Considerations)  The statement made seems right, but at least mention why.  Related: are there no new security requirements/use cases?