Re: [sfc] Progression of use case documents in the SFC WG

Jerome Moisand <jmoisand@juniper.net> Fri, 28 March 2014 13:43 UTC

Return-Path: <jmoisand@juniper.net>
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 71B8B1A0648 for <sfc@ietfa.amsl.com>; Fri, 28 Mar 2014 06:43:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 srPmp4fzBmGM for <sfc@ietfa.amsl.com>; Fri, 28 Mar 2014 06:43:48 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 254971A0641 for <sfc@ietf.org>; Fri, 28 Mar 2014 06:43:46 -0700 (PDT)
Received: from mail63-am1-R.bigfish.com (10.3.201.244) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Mar 2014 13:43:44 +0000
Received: from mail63-am1 (localhost [127.0.0.1]) by mail63-am1-R.bigfish.com (Postfix) with ESMTP id 27C8E44012B; Fri, 28 Mar 2014 13:43:44 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -19
X-BigFish: VPS-19(zz9371Ic89bhc85dhe0eahdb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh9a9j1155h)
Received-SPF: pass (mail63-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(377454003)(189002)(199002)(51856001)(94316002)(98676001)(19580395003)(47976001)(49866001)(93516002)(83322001)(85306002)(94946001)(53806001)(54356001)(47736001)(4396001)(86362001)(69226001)(16236675002)(19300405004)(47446002)(81342001)(74366001)(50986001)(46102001)(93136001)(54316002)(76482001)(95416001)(56816005)(87936001)(87266001)(81816001)(65816001)(97186001)(92566001)(74662001)(74876001)(33646001)(74706001)(19609705001)(81686001)(15202345003)(56776001)(80022001)(15975445006)(18717965001)(83072002)(77982001)(85852003)(95666003)(2656002)(31966008)(76786001)(561944002)(97336001)(74316001)(76796001)(90146001)(66066001)(19580405001)(74502001)(80976001)(81542001)(76576001)(20776003)(63696002)(59766001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; FPR:EC6FF2E5.AFB25785.FAD17F3B.4AAAEB70.207EC; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail63-am1 (localhost.localdomain [127.0.0.1]) by mail63-am1 (MessageSwitch) id 1396014221145046_7064; Fri, 28 Mar 2014 13:43:41 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.230]) by mail63-am1.bigfish.com (Postfix) with ESMTP id 1F3784E022C; Fri, 28 Mar 2014 13:43:41 +0000 (UTC)
Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Mar 2014 13:43:40 +0000
Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Fri, 28 Mar 2014 13:43:40 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 28 Mar 2014 13:43:38 +0000
Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0898.005; Fri, 28 Mar 2014 13:43:38 +0000
From: Jerome Moisand <jmoisand@juniper.net>
To: "sfc@ietf.org" <sfc@ietf.org>, "'Hongyu Li (Julio)'" <hongyu.li@huawei.com>
Thread-Topic: [sfc] Progression of use case documents in the SFC WG
Thread-Index: AQHPSbgDEA3AATWG/kWi/n3iJI0NjZr04CuggAE+2vCAAGBfAA==
Date: Fri, 28 Mar 2014 13:43:38 +0000
Message-ID: <607dc055f33e49aca0e0af52b86d5300@CO2PR05MB716.namprd05.prod.outlook.com>
References: <CF598A14.15E56%kegray@cisco.com> <9134806f48c24248b3c0f7c550c5266d@CO2PR05MB716.namprd05.prod.outlook.com> <94C682931C08B048B7A8645303FDC9F36F544841EB@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F544841EB@PUEXCB1B.nanterre.francetelecom.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
x-forefront-prvs: 01644DCF4A
Content-Type: multipart/alternative; boundary="_000_607dc055f33e49aca0e0af52b86d5300CO2PR05MB716namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/yJZttiJFsQuVCBxnLL8M-Ipte08
Subject: Re: [sfc] Progression of use case documents in the SFC WG
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: Fri, 28 Mar 2014 13:43:55 -0000

Hey Med,

Well, this is indeed the general idea, but it is a tad more complicated than that, because BBF has this rule that contributions and Study Documents (work in progress or finalized) are *by default* not public. Point being to allow industry players to speak more freely and protect IPR (well, I think? I never bought in this line of thinking to be honest, but it is the way it is!).

So BBF reps have to go through a few hoops to be able to liaise material to IETF that can indeed be shared in a public manner. We did a first round with the liaison that you guys have already seen. Since the BBF study document is a work in progress, we expect to send updates through subsequent liaisons.
https://datatracker.ietf.org/liaison/1304/

So I would suggest that the 'core' use case document (e.g. http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases, if I properly followed the chairs proposal) would indeed include a citation, but a citation to the latest BBF liaison, instead of the BBF Study Document itself. And such citation/pointer (+ a few words of context) would become *the* reference for fixed-broadband use cases, removing the need for a specialized I-D in this respect.

Those are just technicalities though, at the end, we're saying the same thing.

Tx
Jerome

PS. hey Hongyu, since you're on both sides of the fence, maybe we could work together to create a short section in draft-liu to provide proper context + such citation?


From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Friday, March 28, 2014 3:44 AM
To: Jerome Moisand; sfc@ietf.org
Subject: RE: [sfc] Progression of use case documents in the SFC WG

Hi Jérome,

I fully agree there is no need to duplicate work.

If there is already text/document in the BBF side, wouldn't be efficient to cite those document rather than editing another with the IETF stamp?

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jerome Moisand
Envoyé : jeudi 27 mars 2014 13:55
À : sfc@ietf.org<mailto:sfc@ietf.org>
Objet : Re: [sfc] Progression of use case documents in the SFC WG

Agreed with the chairs proposal.

There is no point duplicating work performed by other std bodies, it is much better to use it as a an input, while letting specialized discussions occur between groups of corresponding specialists. BBF leverages IETF work all the time, well, it's time to have IETF leverage BBF work.

Being co-editor of the BBF work, I'll make sure that new use cases identified by BBF will be communicated in a reasonably timely fashion to IETF. We do have a few new ones in the works. And we'll work with the authors of draft-meng-sfc-broadband-usecases to consolidate with BBF work.

Tx
Jerome

Side note: draft-meng-sfc-broadband-usecases seems to cover two topics:

1.       a basic form of service chaining ('BNAS' -I guess this means BRAS/BNG- to CGNAT) which is already covered by BBF use cases

2.       then a lot of material about IP v4/v6 transition matters (DS-Lite, MAP, etc), which doesn't seem to have a direct relationship with service chaining per se. Anyhoo, it turns out that there is another BBF work item in this respect, so corresponding material should find its rightful place.


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray)
Sent: Thursday, March 27, 2014 8:28 AM
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; Jim Guichard (jguichar); sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] Progression of use case documents in the SFC WG

I'd give a +1 to the chairs ...

If there is going to be more than one document (and we seemed hell bent on more than one at the BoF ... we could, as a group, settle on "a small number"), that they have some focus.

I don't find the focus or organization described by the chairs onerous - in fact, GIVEN that we have the liaison(s) in place and that they do want a voice here, and that at least one of them has a "domain focus" I find it logical to start with broadband and develop use cases in a set of non-trivial domains.

They had to define "a small number" ...or "a small number" becomes a big number.  Now we know how many "a small number" is.

If draft-liu is stripped of enough content by the categorization of the "small number" it's efficacy should be questioned.  To your specific point, as a group we can decide on moving the specific text you mention back to Problem or otherwise re-home it.  It shouldn't be the sole reason draft-liu exists.

I would have gone a bit further than the chairs, frankly.

There is SO much use case literature out there right now, I frankly don't want to see the IETF repeat any more than it has to.  I would hazard that most of us have read these things before in one of several forums.

So, IMO, the use cases should provide support for the problem statement and the development of a proposed header functionality (solution), and as such should illustrate significantly unique requirements ...so that we can assess the efficacy of the proposed solutions.  I hope the "owner by area" described by the chairs will take on the responsibility of making sure that their examples are significantly unique for  consideration and addressable in the solution.

Because their work represents the work of many (whole organizations) and is hopefully further distilled by the author here into unique examples, in fairness their contributions should probably be credited to "various" with a nod to their organization.

And, because these use cases have been reviewed in other forums by many people, the process should be more expeditious.




From: "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Thursday, March 27, 2014 3:07 AM
To: "Jim Guichard (jguichar)" <jguichar@cisco.com<mailto:jguichar@cisco.com>>, "sfc@ietf.org<mailto:sfc@ietf.org>" <sfc@ietf.org<mailto:sfc@ietf.org>>
Subject: Re: [sfc] Progression of use case documents in the SFC WG

Dear chairs,

Some comments below:

·         The proposed actions are not aligned with the feedback received in this thread (Progression of use case documents within the SFC working group). Answers to that poll are in favor of having a generic use case document. IMHo, it is not fair to ignore what was voiced for by wg members in the mailing list as part of a formal call with clear questions.

·         Some of the text that was adopted by the WG as part of the Problem Statement (use case as part of the Problem statement) has been moved to the generic use case. That text is governed by this charter text: "1. Problem Statement: This document will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining.". What to do for that text?

·         Having the generic use case document and some few detailed ones do not conflict. It is only a matter of scoping.

Given what is stated above, I disagree with your proposal.

If I have to choose (again), I would vote for having one single use cases document. Having one single document will help focusing on core aspects and would simplify the wg activity: review, last calls, etc.

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
Envoyé : mercredi 26 mars 2014 18:54
À : sfc@ietf.org<mailto:sfc@ietf.org>
Objet : [sfc] Progression of use case documents in the SFC WG

WG:

In a message back in January, we (the chairs) proposed that the SFC WG handle the topic of use case documents as follows:

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

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.

Since then, and based on the presentations/discussion in London, it appears that we have a number of documents that warrant being developed as standalone documents. Specifically:

1) A use case document on mobility, e.g., http://datatracker.ietf.org/doc/draft-haeffner-sfc-use-case-mobility/

2) A use case document on Data Centers, e.g., http://datatracker.ietf.org/doc/draft-kumar-sfc-dc-use-cases/

3) Possibly a use case document on Broadband scenarios. However, use cases from a broadband perspective are being developed in the BBF (see the liaison statement at https://datatracker.ietf.org/liaison/1304/). We also have http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/.  It does not seem appropriate to adopt a WG document on the topic of broadband (at least at this time) without clarifying the relationship between draft-meng-sfc-broadband-usecases and the BBF work. In addition, we would need to understand why two efforts - one in BBF and one in the IETF -- on the same topic would be appropriate. Hence, at the present time, we do not intend to adopt a WG document on broadband scenarios, and expect to receive primary guidance on this topic from the BBF.

That leaves: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/, a more general document. But that document includes text on three topics that would be covered in more detail elsewhere (broadband, mobile, and DC). While this document could contain pointers to the other documents, that leaves the document with very little standalone content -- raising the question of what should be done with it, or what content it could incorporate in order to be worthwhile as a standalone document.

Thus, the chairs recommendation at this time is:

1) Call for WG adoption of draft-haeffner-sfc-use-case-mobility-00.txt and draft-kumar-sfc-dc-use-cases-00.txt as WG documents (target: informational).

2) Defer action on draft-liu-service-chaining-use-cases<http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cases>  and draft-meng-sfc-broadband-usecases<http://datatracker.ietf.org/doc/draft-meng-sfc-broadband-usecases/> per the above discussion.

Does this make sense?

Jim & Thomas