Re: [sfc] Progression of use case documents within the SFC working group

["Jim Guichard (jguichar)" <[e-mail]>]

Hi Med,

Good timing! Thomas and I will be sending out an email shortly with suggestions on how to proceed with use cases based upon WG feedback and our London meeting. Stay tuned!

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 26, 2014 at 8:49 AM
To: Jim Guichard <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [sfc] Progression of use case documents within the SFC working group

Dear chairs,

Are there any conclusions for this poll?

Thank you.

Cheers,
Med

________________________________
From: [e-mail]<[e-mail]<mailto:[e-mail][e-mail]>>
To: [e-mail]<[e-mail]<mailto:[e-mail][e-mail]>>
Sent: Friday, January 24, 2014
Subject: [sfc] Progression of use case documents within the SFC working group
Greetings,

The documentation and applicability of use cases for the SFC WG was discussed during both the Berlin and Vancouver BOFs. The main purpose of those discussions was to show support for our work and subsequent formation of a working group.

As we move forward with our work we would like to solicit opinions of how best to approach use cases within the WG. The SFC charter left it open as to whether we should have a single problem statement that includes use cases or whether to separate out the use cases.

Some background:

1) An important purpose for having use cases is to connect a problem or solution to a real concrete scenario. On the problem side, a use case can highlight requirements for any solution. Hence, having SFC use cases is important. Lack of use cases could lead to missed requirements.

2) Having just one use case is probably not enough, but having too many quickly leads to diminishing returns. The sweet spot is a relatively small number (3? 4?) that are different enough that they flesh out the (different) key requirements. We know that more use cases aren't helping when they simply reaffirm requirements that have already been made apparent by other use cases.

3) Some use cases may be detailed and complicated , i.e., because the scenario or technology involved is complicated. Or they may be oriented towards a particular community. Such use cases may warrant having their own standalone document.

4) If we try to put all use cases into a single document, we run the risk that folk will continue to ask that additional scenarios be added, making it difficult to close out and finish the document.

With that in mind, the WG needs to make some choices. We propose:

1) Have the WG develop one use case document that documents a small number of representative use cases. The document presented by Hongyu Li at the Vancouver BOF could serve for this purpose (http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases).

2) Remove "Section 4. Service Function Chaining Use Cases” from draft-quinn-sfc-problem-statement. At present, one section is TBD, and the other section "3GPP Gi Interface Service Function Chaining” would need significant expansion, and that expansion probably makes more sense in a separate document. If there was a simple use case that could be explained (to an IETF reader) in 1-2 pages, we could consider putting it here, but we'd need a proposal. (Any takers?)

3) For additional use cases not covered in 1) above, allow for a small number of documents that are applicable to specific environments (e.g. mobility, data center, broadband, and so forth.) These documents would provide more detailed information and applicability of SFC to these specific environments, and would need to go beyond what is covered in the general use case document (1). Note that it is not the intention to have every potential use case documented.

Comments? Does the above approach seem reasonable to folks on the list? Any objections?

Jim & Thomas