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

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

Thanks Med.

Could you work with the authors of draft-liu-sfc-use-cases and the editors of draft-ietf-sfc-problem-statement (once published; see recent email) to facilitate this change?

From: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Monday, January 27, 2014 at 8:28 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

Re-,

I meant to adopt “draft-liu-sfc-use-cases” as the use-case document. draft-liu-service-chaining-use-cases was replaced by draft-liu-sfc-use-cases.

Cheers,
Med

De : sfc [mailto:[e-mail]] De la part de [e-mail]<mailto:[e-mail]>
Envoyé : lundi 27 janvier 2014 07:51
À : Jim Guichard (jguichar); [e-mail]<mailto:[e-mail]>
Objet : Re: [sfc] Progression of use case documents within the SFC working group

Hi Jim, all,

I support the adoption of draft-liu-service-chaining-use-cases as a place to record some the use cases already discussed in this list.

As I’m the author of the "3GPP Gi Interface Service Function Chaining” section of the PS document, I’m fine to remove that text from the PS and merge it with the text of draft-liu-service-chaining-use-cases.

Cheers,
Med

De : sfc [mailto:[e-mail]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 24 janvier 2014 19:01
À : [e-mail]<mailto:[e-mail]>
Objet : [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