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

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 25 Sep 2015 16:49:18 +0000

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?

---

From: aldrin ietf <[email-masked]>
Date: Fri, 25 Sep 2015 10:02:37 -0700

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-masked]> wrote:
> 
> Hi!
> 
> 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?

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 25 Sep 2015 17:53:42 +0000

On 9/25/15, 1:02 PM, "aldrin ietf" <[email-masked]<mailto:[email-masked]>> wrote:

Sam:

Hi!  How are you?

Haven’t read the review comments, but would like to respond to general comments.

My opinion is general, but there are also specific reasons applicable to this document.

The work shouldn’t be discouraged!  Use cases clearly serve as motivation for problems to be solved, which is important to frame and scope the work to be done in any WG.  However, I think that the usefulness in many cases stops there: once the solution has been developed.

There are specific actions being taken, but as you can imagine one size doesn’t fit all.  As an example, take a look at the charter for detnet [1] (still not approved).  In there it is clear that the work on use cases (for example) is important to guide the WG and help newcomers, but that it may not be published.  Note that the work is not changing, the expectations for publication are — those are two very different things.

[1] https://datatracker.ietf.org/doc/charter-ietf-detnet/

Coming back to this specific document..  I’m asking the WG to consider not publishing, not telling it what to do.  In fact, if you look at the WG charter, even though there is a specific Milestone, the WG is chartered to “define a mechanism..” (not to produce use cases).  Nonetheless, because the work has already been done, the WG can make the decision whether it still wants to publish or not.

It’s interesting that you mention a requirements document because there isn’t one.  That is exactly one of the points I’m trying to make:  the solution that addresses the use cases is S-BFD (as documented in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in fact solves the use cases without clear requirements?

To me, the bottom line is this: if we’re going to publish this document, let’s make it valuable by clearly stating what is needed in each use case that BFD can’t do.

[2] That draft in fact says so in the Introduction: "This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case].”

Thanks!

Alvaro.

---

From: aldrin ietf <[email-masked]>
Date: Fri, 25 Sep 2015 11:48:19 -0700

Hi Alvaro,

Comments inline with %sam.
> On Sep 25, 2015, at 10:53 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> On 9/25/15, 1:02 PM, "aldrin ietf" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Sam:
> 
> Hi!  How are you?
I am fine thank you. Hope the same with you. Thanks again for your reply.
> The work shouldn’t be discouraged!  Use cases clearly serve as motivation for problems to be solved, which is important to frame and scope the work to be done in any WG.  However, I think that the…
%sam - The same could be argued against, problem statement, framework, requirement, etc. Once solution is done, they serve no practical purpose. Any enhancement work, will only cite the shortcomings of solution document and not requirement or problem statement.
> [1] https://datatracker.ietf.org/doc/charter-ietf-detnet/ <https://datatracker.ietf.org/doc/charter-ietf-detnet/>
I don’t have a problem, if the ask of not proceed was made much earlier in the process and not late in the game.
For SFD work, there is no requirement document and usecase document provides the need to enhance BFD protocol to be extended.

> Coming back to this specific document..  I’m asking the WG to consider not publishing, not telling it what to do.  In fact, if you look at the WG charter, even though there is a specific Milestone,…

If that is the case, it shouldn’t even be a WG document right?
Also, the deliverable was tracked as part of milestone isn’t it?
Does that mean, milestones truly doesn’t reflect the deliverable but only Charter does?

Do not know all the semantics of the IETF WG processes. Clarification helps.

> It’s interesting that you mention a requirements document because there isn’t one.  That is exactly one of the points I’m trying to make:  the solution that addresses the use cases is S-BFD (as doc…
You may not agree to what I think, but let me put that out anyway.
BFD protocol itself is much smaller and the usecases are very narrow in scope that, they by themselves are better than some of them the requirements we’ve seen in actual requirement documents. What I expected to see was for solutions to reference usecases in their respective documents and why it is being enhanced.
> [2] That draft in fact says so in the Introduction: "This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case].”
I am ok to enhance the text to clear any ambiguity of what is needed for BFD to enhance. 
But the grey area in that case will be, how not to propose implicit solution.

cheers
-sam

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 25 Sep 2015 20:31:31 +0000

On 9/25/15, 2:48 PM, "aldrin ietf" <[email-masked]<mailto:[email-masked]>> wrote:

Sam:

Let’s talk about this draft.
. . .
- 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.

I don’t necessarily disagree with that, but let’s talk specifics:

3.6.  BFD for Anycast Address

   BFD protocol requires two endpoints to host BFD sessions, both
   sending packets to each other.  This BFD model does not fit well with
   anycast address monitoring, as BFD packets transmitted from a network
   node to an anycast address will reach only one of potentially many
   network nodes hosting the anycast address.

That’s the whole description of that use case..as you said: small and narrow in scope.  However (as I said in my comments), what does that mean?   How do you want the system to behave?  What is the requirement?  I’m not asking about the solution, but about the expected behavior.  For example, is the requirement here that a BFD packet reach all the potential anycast nodes in the network?  Would you want that to be a point-to-multipoint type behavior or is several point-to-point packets ok?

>From what you said above, if someone wants to reference this use case to justify an enhancement they should be able to easily identify what the expected behavior or requirement is.  If the use case is not clear, then how can a solution/enhancement be justified?

In the end that I’m asking for: clarity.

As with the example above, generically say what you want to do: “reach all the anycast nodes with one BFD packet”, for example.  You don’t have to go into details of how the anycast nods are identified, what are the discriminators used, what IP addresses are used, packet replication, etc.  All that is part of the solution.

Thanks!

Alvaro.

---

From: Sam Aldrin <[email-masked]>
Date: Fri, 25 Sep 2015 13:45:14 -0700

Hi Alvaro,

Sorry for the top post.

I am fine with enhancing the text and will definitely review your comments as well.

But the question is, will this still be dropped? :D :D

Sam

Sent from my iPhone

> On Sep 25, 2015, at 1:31 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> On 9/25/15, 2:48 PM, "aldrin ietf" <[email-masked]> wrote:
> 
> Sam:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 29 Sep 2015 11:43:10 -0400

Sam (and to a bigger extent, Alvaro),

> Do not know all the semantics of the IETF WG processes. Clarification helps.

Adopting the document within the WG basically means the working group "owns"
the document and that we're motivated to get work on it done.  This includes
things like tracking it via a milestone.

Not all WG documents will be published as RFCs.

The bigger question to argue IETF-wide is when we have these short-lived
documents, should we just start in something like a wiki especially if the
information is to be maintained long-term?  Possibly.  But as other people
have noted in different forums, the "IETF workflow" moves around the
publication life-cycle of Internet-Drafts.

I'm not completely sold on the maintenance of the use cases long-term in the
wiki.  In my opinion, the primary purpose of use case documents is to help
clarify and move forward protocol work.  Ideally a portion of the use cases
are clear in the actual protocol documentation, just not their individual
breakdowns.

-- Jeff

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 29 Sep 2015 10:07:28 -0700

Hi Jeff and Alvaro,

Inline for my comments.

> On Sep 29, 2015, at 8:43 AM, Jeffrey Haas <[email-masked]> wrote:
> 

I’d like to see that clarified across IETF, at the lease RTG area which I am focussed on.
Secondly, would like to see what the definition of short lived documents are.
Why are problem statement, requirements etc, which are short lived and more or less like use case document as well, made as RFC’s?

As long as there is consistency and definition, IETF as a community shouldn’t have a problem.
That way folks have choice on where to invest time.

-sam

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 29 Sep 2015 19:46:53 +0000

On 9/29/15, 12:07 PM, "Sam Aldrin" <[email-masked]> wrote:

Sam:

Hi!

>>>> Coming back to this specific document..  I¹m asking the WG to
>>>>consider not publishing, not telling it what to do.  In fact, if you
>>>>look at the WG charter, even though there is a specific Milestone, the
>>>>WG is chartered to ³define a mechanism..² (not to produce use cases).
>>>>Nonetheless, because the work has already been done, the WG can make
>>>>the decision whether it still wants to publish or not.
>>> 
>>> If that is the case, it shouldn¹t even be a WG document right?
>>> Also, the deliverable was tracked as part of milestone isn¹t it?
>>> Does that mean, milestones truly doesn¹t reflect the deliverable but
>>>only Charter does?
>>> 
>I¹d like to see that clarified across IETF, at the lease RTG area which I
>am focussed on.

This ³change² has been brewing in the IESG for a while, where many ADs
have been expressing their opinion about the need (or lack thereof) for
publishing some short-lived documents which have already met their useful
lifetime.

However, there is no one-size-fits-all statement that can be made.  For
example, use cases may inform the community of work that should be done
later or of issues to be addressed elsewhere ‹ I think a good example of
may be the documentation of the use cases that are seriously affected by
multicast issues in wireless networks (which the IEEE may solve).

Note that even though the different ADs express their opinion about the
lack of need to publish documents, the ballots are always ³No Objection² ‹
this (in my case) is due to the fact that if the document got to the IESG
for publication then it already has WG and IETF consensus.  However, we
have been making some explicit changes in some charters ‹ I pointed you
before to the detnet charter as an example.

All this comes back to me asking the WG to *consider* not publishing (vs
just deciding myself).  I (personally) still think we don¹t need to
publish this document, but if the WG has a different opinion then I¹m ok
with being on the rough side of the consensus.

The other reason for making the ³change² slowly and not just issuing a
wide-reaching statement is that, as Jeff mentioned above, the work moves
around IDs/RFCs ‹ we (as a community) are not ready and/or don¹t have the
tools to consistently move sustaining documents somewhere else (as in a
Wiki).

For now, it is a case-by-case consideration.  At least in my case I will
continue to ask the WGs I¹m responsible for to *consider* not publishing
short-lived documents.  [As I said above, I can be in the rough.]

>Why are problem statement, requirements etc, which are short lived and
>more or less like use case document as well, made as RFC¹s?

In general, I think that those other types of documents also fit the
short-lived definition.

Another example of a short-lived document is an implementation report.
These are used to reflect the current implementation status of an ID, and
is used in many cases to prove that the required implementations do exist
and how they comply with the RFC-to-be.  Not only is the lifetime limited,
but if an implementation comes later (or changes), then it is not
documented anywhere.  The idr WG is not publishing implementation reports
anymore, they are being put on a wiki.  The first draft to go through this
is ADD_PATH [1] [2]. :-)

Thanks!

Alvaro.

[1] 
https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/
[2] 
https://tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-add-paths%20implemen
tations

---

From: aldrin ietf <[email-masked]>
Date: Tue, 29 Sep 2015 16:10:32 -0700

Hi Alvaro,

Like I said in my earlier emails, it would be good to have proper guidance, at the early stage of the document. 
When the milestone was set to propose to make it standard, I believed that is something WG was tasked to do, not drop/orphan it.

[Not specific to this doc]
I have a different take to the point of, short lived documents loosing relevancy.
Whenever a solution is proposed, it is always asked, why and where this is asked and used. 
Solutions may or may not capture entirety of problem/requirement/where it is used, etc..
Applied against timeline, it could spread over the time and beyond solution becoming standard.
Referring to those documents and the work related to that is useful, which I believe, ‘informational’ track is for.

If the goal is not to have these numbered as RFC, rather something else, it is good to have that discussion across IETF happen and agreed upon, before making any choices/decisions. I haven’t seen much on that, thus far. Also, this should apply to all short lived documents.

cheers
-sam

> On Sep 29, 2015, at 12:46 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
>

---

From: Loa Andersson <[email-masked]>
Date: Wed, 30 Sep 2015 12:46:58 +0800

Jeff, Sam and Alvaro,

I guess that thing are different from wg to wg, given some hard core of
IETF wide wg process. I believe this is a good thing, and that practice
in one wg does not define IETF process.

> things like tracking it via a milestone.

We talk about this as taking over the revision control. The motivation
point is important, when a document stops being individual and becomes a
working group document, there is a real difference for the authors / 
editors.
> Not all WG documents will be published as RFCs.
yes but that does not necessarily stop them from being wg documents.
Actually the status of wiki text is a bit ambivalent, at least if it is
possible for anyone to change it (that is often what is said to be the
benefit of the wiki).

> publication life-cycle of Internet-Drafts.

I know that wiki's are popular, but I from one point of view they are
only one more thing to maintain.

Actually between the wg doucments page, the wg milestones and wiki-based
material, I frequently find that the document page need everything I
need, if maintained properly. The rest is mostly redundant.

Over a year and half I worked very hard to maintain milestones and found
that this was extra work, the document pae, including document history
give me what I need.

> are clear in the actual protocol documentation, just not their individual

I guess that "not completely sold on" is an understatement?

/Loa