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?
