On 9/25/15, 2:48 PM, "aldrin ietf" <[email protected]<mailto:[email protected]>> 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. 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? 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. 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. 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].” 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. 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.
