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

<mohamed.boucadair@orange.com> Mon, 27 January 2014 06:50 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94B81A01C9 for <sfc@ietfa.amsl.com>; Sun, 26 Jan 2014 22:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.548
X-Spam-Level:
X-Spam-Status: No, score=-1.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hz40EtUXZG1y for <sfc@ietfa.amsl.com>; Sun, 26 Jan 2014 22:50:49 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0C1A00FD for <sfc@ietf.org>; Sun, 26 Jan 2014 22:50:48 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4394422C5AA; Mon, 27 Jan 2014 07:50:46 +0100 (CET)
Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 15B7735C045; Mon, 27 Jan 2014 07:50:46 +0100 (CET)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 27 Jan 2014 07:50:45 +0100
From: mohamed.boucadair@orange.com
To: "Jim Guichard (jguichar)" <jguichar@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Date: Mon, 27 Jan 2014 07:50:44 +0100
Thread-Topic: Progression of use case documents within the SFC working group
Thread-Index: AQHPGS5B+ZYQfqbdGEGHvCjMISf9v5qYJNjA
Message-ID: <94C682931C08B048B7A8645303FDC9F36F473607AF@PUEXCB1B.nanterre.francetelecom.fr>
References: <CF08148E.148BC%jguichar@cisco.com>
In-Reply-To: <CF08148E.148BC%jguichar@cisco.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR
Content-Type: multipart/alternative; boundary="_000_94C682931C08B048B7A8645303FDC9F36F473607AFPUEXCB1Bnante_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.26.232114
Subject: Re: [sfc] Progression of use case documents within the SFC working group
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 06:50:52 -0000

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:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoyé : vendredi 24 janvier 2014 19:01
À : sfc@ietf.org
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