Hi Alvaro, Thanks for the comments. Haven’t read the review comments, but would like to respond to general comments.
- Whether to stop Use case document to proceed further or nor, is the comment specific to this document or general comment applicable to all use case documents? - If use you think use case documents has limited purposes, then it should be discouraged at the beginning and shouldn’t even be adopted in the first place. It is not prudent to invest time, for individual/group, for the things which are going to be dropped. - I do not think use case has to document requirements explicitly. If it has to, then what should requirement document contain? If the plan is to merge both, this should be discussed across, not just BFD, to get an agreement. I see there are lot of use case, requirement docs in various WG’s. cheers -sam > On Sep 25, 2015, at 9:49 AM, Alvaro Retana (aretana) <[email protected]> > wrote: > > 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: > 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: > 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." > 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. > 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: > 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…" > Section 3. (Use Cases). “…some of the use cases also be identify the need > for…” ?? > Section 3.5. (BFD Efficient Operation Under Resource Constraints) “?” > 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 > Section 4. (Security Considerations) The statement made seems right, but at > least mention why. Related: are there no new security requirements/use cases?
