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

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Fri, 24 Jan 2014 18:01:06 +0000

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

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 24 Jan 2014 13:10:26 -0500

This approach sounds very reasonable to me.

From: [email-masked]<[email-masked]>
To: [email-masked]<[email-masked]>
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.

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.

Jim & Thomas

---

From: "Hongyu Li (Julio)" <[email-masked]>
Date: Sun, 26 Jan 2014 08:31:44 +0000

Fully agree on this approach. We can collect and leach use cases in sight into draft-liu-service-chaining-use-cases, and leave other new use cases for later drafts.

Hongyu

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, January 25, 2014 2:01 AM
To: [email-masked]
Subject: [sfc] Progression of use case documents within the SFC working group

Greetings,

Some background:

Jim & Thomas

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Sun, 26 Jan 2014 09:06:58 +0000

I support and hope that we can receive more interests and  comments for the use case draft. We will modify it accordingly.

Regards,
Shucheng (Will)

Greetings,

Some background:

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?)

Jim & Thomas

---

From: "Cao,Zhen" <[email-masked]>
Date: Sun, 26 Jan 2014 21:11:06 +0800

Thanks for framing out the way forward.

> 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).

Better to refer to
http://tools.ietf.org/html/draft-liu-sfc-use-cases-00, some minor
difference between the two.

-cz

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 26 Jan 2014 15:05:17 +0000

Jim, Thomas,

I support this approach.

Thanks,

-- Carlos.

On Jan 24, 2014, at 1:01 PM, Jim Guichard (jguichar) <[email-masked]> wrote:

> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Ron Parker <[email-masked]>
Date: Sun, 26 Jan 2014 15:07:17 +0000

Jim,

I am in favor of this approach, too.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, January 26, 2014 10:05 AM
To: Jim Guichard (jguichar)
Cc: [email-masked]
Subject: Re: [sfc] Progression of use case documents within the SFC working group

Jim, Thomas,

I support this approach.

Thanks,

-- Carlos.

On Jan 24, 2014, at 1:01 PM, Jim Guichard (jguichar) <[email-masked]<mailto:[email-masked]>> wrote:

Greetings,

Some background:

Jim & Thomas
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Mon, 27 Jan 2014 07:50:44 +0100

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:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 24 janvier 2014 19:01
À : [email-masked]
Objet : [sfc] Progression of use case documents within the SFC working group

Greetings,

Some background:

Jim & Thomas

---

From: <[email-masked]>
Date: Mon, 27 Jan 2014 14:28:13 +0100

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:[email-masked]] De la part de [email-masked]
Envoyé : lundi 27 janvier 2014 07:51
À : Jim Guichard (jguichar); [email-masked]
Objet : Re: [sfc] Progression of use case documents within the SFC working group

Hi Jim, all,

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 24 janvier 2014 19:01
À : [email-masked]<mailto:[email-masked]>
Objet : [sfc] Progression of use case documents within the SFC working group

Greetings,

Some background:

Jim & Thomas

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 27 Jan 2014 20:19:28 +0000

Support the approach.

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, January 25, 2014 2:01 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Progression of use case documents within the SFC working group

Greetings,

Some background:

Jim & Thomas

---

From: "Jim Guichard (jguichar)" <[email-masked]>
Date: Wed, 29 Jan 2014 14:16:04 +0000

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, January 27, 2014 at 8:28 AM
To: Jim Guichard <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 27 janvier 2014 07:51
À : Jim Guichard (jguichar); [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] Progression of use case documents within the SFC working group

Hi Jim, all,

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

Greetings,

Some background:

Jim & Thomas

---

From: <[email-masked]>
Date: Wed, 29 Jan 2014 15:40:37 +0100

Hi Jim,

Will do.

Cheers,
Med

De : Jim Guichard (jguichar) [mailto:[email-masked]]
Envoyé : mercredi 29 janvier 2014 15:16
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [sfc] Progression of use case documents within the SFC working group

Thanks Med.

Re-,

Cheers,
Med

Hi Jim, all,

Cheers,
Med

Greetings,

Some background:

Jim & Thomas