From nobody Mon Sep 1 06:04:08 2014 Return-Path: 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 B1CAB1A03C5 for ; Mon, 1 Sep 2014 06:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 XfNA-cr7P34v for ; Mon, 1 Sep 2014 06:04:03 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3121C1A03C4 for ; Mon, 1 Sep 2014 06:04:02 -0700 (PDT) Received: from qdezc2.de.t-internal.com ([10.125.181.10]) by tcmail31.telekom.de with ESMTP; 01 Sep 2014 15:03:58 +0200 X-IronPort-AV: E=Sophos;i="5.04,442,1406584800"; d="scan'208,217";a="128760719" Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES128-SHA; 01 Sep 2014 15:03:31 +0200 Received: from HE111543.emea1.cds.t-internal.com ([10.125.90.96]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%14]) with mapi; Mon, 1 Sep 2014 15:03:30 +0200 From: To: , Date: Mon, 1 Sep 2014 15:03:29 +0200 Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vsR+/w Message-ID: <9762ACF04FA26B4388476841256BDE02012FE995F0E0@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_9762ACF04FA26B4388476841256BDE02012FE995F0E0HE111543eme_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ls3DcqyWWo7447BPhyLO_FORBP4 Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 13:04:07 -0000 --_000_9762ACF04FA26B4388476841256BDE02012FE995F0E0HE111543eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jim Guichard (jguicha= r) Gesendet: Dienstag, 26. August 2014 13:41 An: sfc@ietf.org Betreff: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is exp= ected to modify the document's content until there is WG consensus that the= content is solid. Therefore, please don't oppose adoption just because you= want to see changes to its content. 2. If you have objections to adoption of the document, please state your = reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues a= nd we can begin a dialog about how best to address them. --_000_9762ACF04FA26B4388476841256BDE02012FE995F0E0HE111543eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 

=

Von: sfc [mailto:sfc-bounces@ietf.org] = Im Auftrag von Jim Guichard (jguichar)
Gesendet: Dienstag, 26= . August 2014 13:41
An: sfc@ietf.org
Betreff: [sfc] Cal= l for WG adoption of draft-merged-sfc-architecture-02

=

 

Greetings WG:

 

This message begins a two week call for WG adoption of draft-merged-sfc-a= rchitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architectu= re/] ending September 9th 2014.

 

Please respond to the SFC mailing list with any statements of= approval or disapproval.

 

A= s always, please note:

    This is not WG Last Call. T= he document is not final, and the WG is expected to modify the documentR= 17;s content until there is WG consensus that the content is solid. Therefo= re, please don’t oppose adoption just because you want to see changes= to its content.
  1. If you have objections to adoption of the document, please st= ate your reasons why, and explain what it would take to address your concer= ns.
  2. If you have issues with the content, by all means raise those issues and w= e can begin a dialog about how best to address them.
    3. =
= --_000_9762ACF04FA26B4388476841256BDE02012FE995F0E0HE111543eme_-- From nobody Mon Sep 1 23:51:36 2014 Return-Path: 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 301D61A8730 for ; Mon, 1 Sep 2014 23:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 d6ikoTTfJz7B for ; Mon, 1 Sep 2014 23:51:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44D11A86F1 for ; Mon, 1 Sep 2014 23:49:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIY98433; Tue, 02 Sep 2014 06:49:24 +0000 (GMT) Received: from SZXEMA404-HUB.china.huawei.com (10.82.72.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Sep 2014 07:49:24 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA404-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0158.001; Tue, 2 Sep 2014 14:49:17 +0800 From: "Liushucheng (Will)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vtcaRw Date: Tue, 2 Sep 2014 06:49:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF69B96SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/B59PVys45ZPjsXfVtOFYqa6pbUw Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 06:51:35 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF69B96SZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. Regards, Will From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Tuesday, August 26, 2014 7:41 PM To: sfc@ietf.org Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_C9B5F12337F6F841B35C404CF0554ACB5FF69B96SZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.

 <= /p>

Regards,

Will

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, August 26, 2014 7:41 PM
To: sfc@ietf.org
Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture= -02

 

Greetings WG:

 

This message begins a two we= ek call for WG adoption of draft-merged-sfc-architecture-02 [http://datatra= cker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

 

Please respond to the SFC ma= iling list with any statements of approval or disapproval.

 

As always, please note:

1.  &nbs= p; This is not WG Last= Call. The document is not final, and the WG is expected to modify the docu= ment’s content until there is WG consensus that the content is solid. Therefore, please don’t oppose adoption just because you w= ant to see changes to its content.

2.  &nbs= p; If you have objecti= ons to adoption of the document, please state your reasons why, and explain= what it would take to address your concerns.

3.  &nbs= p; If you have issues = with the content, by all means raise those issues and we can begin a dialog= about how best to address them.<= /span>

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF69B96SZXEMA509MBSchi_-- From nobody Tue Sep 2 00:28:49 2014 Return-Path: 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 89A1D1A8545 for ; Tue, 2 Sep 2014 00:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 C8w71x_9OgW2 for ; Tue, 2 Sep 2014 00:28:44 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB31A7034 for ; Tue, 2 Sep 2014 00:28:37 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7D7653700EF; Tue, 2 Sep 2014 09:28:34 +0200 (CEST) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 61EB23700EB; Tue, 2 Sep 2014 09:28:34 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 2 Sep 2014 09:28:33 +0200 Received: from DB3PR06MB252.eurprd06.prod.outlook.com (10.141.5.153) by DB3PR06MB251.eurprd06.prod.outlook.com (10.141.5.146) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Tue, 2 Sep 2014 07:28:32 +0000 Received: from DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) by DB3PR06MB252.eurprd06.prod.outlook.com ([10.141.5.153]) with mapi id 15.00.1015.018; Tue, 2 Sep 2014 07:28:32 +0000 From: DIEGO LOPEZ GARCIA To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPxn9/AVC4KgYaBESc+g4oUrkG0A== Date: Tue, 2 Sep 2014 07:28:32 +0000 Message-ID: <2A00923E-F13A-44B1-968A-E04A83F32744@telefonica.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [176.83.120.226] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0322B4EDE1 x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(24454002)(199003)(31966008)(15202345003)(74662001)(21056001)(76482001)(16236675004)(101416001)(106116001)(107046002)(99396002)(19580395003)(83322001)(19580405001)(87936001)(105586002)(77982001)(83072002)(230783001)(92566001)(92726001)(15975445006)(110136001)(74502001)(2656002)(106356001)(20776003)(85852003)(64706001)(80022001)(46102001)(66066001)(76176999)(95666004)(50986999)(36756003)(19617315012)(85306004)(81542001)(90102001)(54356999)(33656002)(86362001)(4396001)(81342001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR06MB251; H:DB3PR06MB252.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2A00923EF13A44B1968AE04A83F32744telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NKu5z5qr-GBchUl_dnevOgqKMJs Cc: "sfc@ietf.org" Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 07:28:47 -0000 --_000_2A00923EF13A44B1968AE04A83F32744telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support WG adoption -- Likely to be brief and not very elaborate as sent from my mobile Diego R. Lopez Telefonica I+D On 26 Aug 2014, at 13:41, "Jim Guichard (jguichar)" > wrote: Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document=E2=80=99s content until there is WG consensus= that the content is solid. Therefore, please don=E2=80=99t oppose adoption= just because you want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_2A00923EF13A44B1968AE04A83F32744telefonicacom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I support WG adoption

--
Likely to be brief and not very
elaborate as sent from my mobile
Diego R. Lopez
Telefonica I+D


On 26 Aug 2014, at 13:41, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last Cal= l. The document is not final, and the WG is expected to modify the document= =E2=80=99s content until there is WG consensus that the content is solid. T= herefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.
  2. If you have objections to adoption of= the document, please state your reasons why, and explain what it would tak= e to address your concerns.
  3. If you have issues with the content, by all means raise tho= se issues and we can begin a dialog about how best to address them.<= /li>
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_2A00923EF13A44B1968AE04A83F32744telefonicacom_-- From nobody Tue Sep 2 00:49:33 2014 Return-Path: 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 8B41B1A00C0 for ; Tue, 2 Sep 2014 00:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 Z7Wvm1pQ6lgp for ; Tue, 2 Sep 2014 00:49:30 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.173]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1497F1A0083 for ; Tue, 2 Sep 2014 00:49:29 -0700 (PDT) Received: from [85.158.138.179:49989] by server-13.bemta-3.messagelabs.com id 16/B4-01569-88675045; Tue, 02 Sep 2014 07:49:28 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-7.tower-169.messagelabs.com!1409644167!9775194!1 X-Originating-IP: [195.232.224.74] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17269 invoked from network); 2 Sep 2014 07:49:28 -0000 Received: from mailout05.vodafone.com (HELO mailout05.vodafone.com) (195.232.224.74) by server-7.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Sep 2014 07:49:28 -0000 Received: from mailint05.vodafone.com (localhost [127.0.0.1]) by mailout05.vodafone.com (Postfix) with ESMTP id 947B4200BD for ; Tue, 2 Sep 2014 09:49:27 +0200 (CEST) Received: from VOEXC03W.internal.vodafone.com (voexc03w.dc-ratingen.de [145.230.101.23]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint05.vodafone.com (Postfix) with ESMTPS id 86DAC200A3; Tue, 2 Sep 2014 09:49:27 +0200 (CEST) Received: from AVOEXC03W.internal.vodafone.com (145.230.15.132) by VOEXC03W.internal.vodafone.com (145.230.101.23) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 2 Sep 2014 09:49:27 +0200 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.87]) by AVOEXC03W.internal.vodafone.com ([145.230.15.132]) with mapi id 14.03.0181.006; Tue, 2 Sep 2014 09:49:26 +0200 From: "Haeffner, Walter, Vodafone DE" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: Call for WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPwSKarKFwlbPq2EakRGFWvH7bz5vtgmjA Date: Tue, 2 Sep 2014 07:49:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE10471854C4ED0ABVOEXM20Winterna_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/FEGQ0jSUNnd4QBMIYHNY7z_30mQ Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 07:49:32 -0000 --_000_C8C844F84E550E43865561FAE10471854C4ED0ABVOEXM20Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support adoption - Walter Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jim Guichard (jguicha= r) Gesendet: Dienstag, 26. August 2014 13:41 An: sfc@ietf.org Betreff: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. As always, please note: 1. This is not WG Last Call. The document is not final, and the WG is ex= pected to modify the document's content until there is WG consensus that th= e content is solid. Therefore, please don't oppose adoption just because yo= u want to see changes to its content. 2. If you have objections to adoption of the document, please state your= reasons why, and explain what it would take to address your concerns. 3. If you have issues with the content, by all means raise those issues = and we can begin a dialog about how best to address them. --_000_C8C844F84E550E43865561FAE10471854C4ED0ABVOEXM20Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support adoption - Walter=

 

Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Jim Guichard (jguichar)
Gesendet: Dienstag, 26. August 2014 13:41
An: sfc@ietf.org
Betreff: [sfc] Call for WG adoption of draft-merged-sfc-architecture= -02

 

Greetings WG:

 

This message begins a two w= eek call for WG adoption of draft-merged-sfc-architecture-02 [http://datatr= acker.ietf.org/doc/draft-merged-sfc-architecture/] ending September 9th 2014.

 

Please respond to the SFC m= ailing list with any statements of approval or disapproval.

 

As always, please note:

  1. This is not WG Last Call. The document is not final, and the W= G is expected to modify the document’s content until there is WG cons= ensus that the content is solid. Therefore, please don’t oppose adoption just because you want to see changes to its content.
  2. If you have objections to adoption of the document, please sta= te your reasons why, and explain what it would take to address your concern= s.
  3. If you have issues with the content, by all means raise those = issues and we can begin a dialog about how best to address them.=
--_000_C8C844F84E550E43865561FAE10471854C4ED0ABVOEXM20Winterna_-- From nobody Sun Sep 7 08:12:41 2014 Return-Path: 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 CBDC31A040E for ; Sun, 7 Sep 2014 08:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 vTZZBeJYa7M1 for ; Sun, 7 Sep 2014 08:12:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0065.outbound.protection.outlook.com [65.55.169.65]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485D01A00D2 for ; Sun, 7 Sep 2014 08:12:35 -0700 (PDT) Received: from BLUPR01MB019.prod.exchangelabs.com (10.242.190.146) by BLUPR01MB017.prod.exchangelabs.com (10.242.190.143) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Sun, 7 Sep 2014 15:12:33 +0000 Received: from BLUPR01MB019.prod.exchangelabs.com ([10.242.190.146]) by BLUPR01MB019.prod.exchangelabs.com ([10.242.190.146]) with mapi id 15.00.1019.015; Sun, 7 Sep 2014 15:12:33 +0000 From: Anil Gunturu To: "sfc@ietf.org" Thread-Topic: Typo in section 5.5 of merged arch document Thread-Index: AQHPyq4mIVlTJs0oo0O+yBPYzac7/w== Date: Sun, 7 Sep 2014 15:12:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [98.229.127.217] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009017)(199003)(189002)(46102001)(229853001)(110136001)(85306004)(92726001)(80022001)(19580395003)(107046002)(50986999)(99396002)(106356001)(20776003)(105586002)(79102001)(81542001)(107886001)(101416001)(106116001)(2351001)(15975445006)(86362001)(76482001)(16236675004)(85852003)(74662001)(77982001)(54356999)(2501002)(92566001)(83322001)(83072002)(19617315012)(21056001)(2656002)(4396001)(31966008)(95666004)(36756003)(66066001)(64706001)(74502001)(97736003)(81342001)(90102001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR01MB017; H:BLUPR01MB019.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D031EE1F58EEanilguntururiftiocom_" MIME-Version: 1.0 X-OriginatorOrg: riftio.com Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2QrnbBvXDh5rsi5fPNPfC9QWhhY Subject: [sfc] Typo in section 5.5 of merged arch document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 15:12:39 -0000 --_000_D031EE1F58EEanilguntururiftiocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In section 5.5 of https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/?include_text=3D1, SPF should be SFP to be constant with the terminol= ogy. "In the simplest case, where there is only a single function in the SPF (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SPF exists (the metadata changes but the SPF does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4." -Anil --_000_D031EE1F58EEanilguntururiftiocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0ED85510FFA4C149875CFC0E2D1CB591@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable
In section 5.5 of https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/?include_text=3D1, SPF should be SFP to be constant with the terminology.

"In the simplest case, where there is only a single func=
tion in the
 SPF (the next hop is either the destination address of the flow or
 the appropriate next hop to that destination), one could argue that
 there may be no need for SFC.

 In the cases where the classifier is separate from the single
 function or a function at the terminal address may need sub-prefix or
 per-subscriber metadata, a single SPF exists (the metadata changes
 but the SPF does not), regardless of the number of potential termin=
al
 addresses for the flow.  This is the case of the simple load
 balancer.  See Figure 4.”

-Anil


--_000_D031EE1F58EEanilguntururiftiocom_-- From nobody Sun Sep 7 11:56:30 2014 Return-Path: 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 0D7901A06AB for ; Sun, 7 Sep 2014 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 lq-OFdhB19pa for ; Sun, 7 Sep 2014 11:56:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0092.outbound.protection.outlook.com [65.55.169.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DC61A069E for ; Sun, 7 Sep 2014 11:56:25 -0700 (PDT) Received: from BLUPR01MB019.prod.exchangelabs.com (10.242.190.146) by BLUPR01MB018.prod.exchangelabs.com (10.242.190.144) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Sun, 7 Sep 2014 18:56:23 +0000 Received: from BLUPR01MB019.prod.exchangelabs.com ([10.242.190.146]) by BLUPR01MB019.prod.exchangelabs.com ([10.242.190.146]) with mapi id 15.00.1019.015; Sun, 7 Sep 2014 18:56:23 +0000 From: Anil Gunturu To: "sfc@ietf.org" Thread-Topic: ip-port-locator in draft-penno-sfc-yang-06 Thread-Index: AQHPys1r8JMKptgqGUKXmBopJDliQQ== Date: Sun, 7 Sep 2014 18:56:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.134.71.18] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009017)(199003)(189002)(21056001)(2501002)(81342001)(106356001)(81542001)(74662001)(36756003)(19580395003)(31966008)(87936001)(558084003)(85852003)(4396001)(54356999)(92566001)(97736003)(2656002)(86362001)(50986999)(83072002)(105586002)(76482001)(19617315012)(46102001)(106116001)(16236675004)(107046002)(66066001)(83322001)(95666004)(85306004)(229853001)(110136001)(79102001)(230783001)(2351001)(99396002)(92726001)(74502001)(15975445006)(101416001)(77982001)(20776003)(90102001)(80022001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR01MB018; H:BLUPR01MB019.prod.exchangelabs.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D03222945909anilguntururiftiocom_" MIME-Version: 1.0 X-OriginatorOrg: riftio.com Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/CezybMiO1a8JnaX9os5R24rxO4k Cc: "paulq@cisco.com" , "repenno@cisco.com" Subject: [sfc] ip-port-locator in draft-penno-sfc-yang-06 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 18:56:28 -0000 --_000_D03222945909anilguntururiftiocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the ip-port-locator defined in "Yang Data Model for Service Function Cha= ining" (https://datatracker.ietf.org/doc/draft-penno-sfc-yang/?include_text= =3D1), there is no information for network namespaces. Is it practical to a= ssume that all the SFs will be in the same network context/namespace? -Anil --_000_D03222945909anilguntururiftiocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <38E80D76758D184EB5FA44A55E4630E3@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable

In the ip-port-lo= cator defined in "Yang Data Model for Service Function Chaining" = (https://datatracker.ietf.org/doc/draft-penno-sfc-yang/?include_te= xt=3D1), there is no information for network namespaces. Is it <= font face=3D"Arial">p= ractical to assume that all the SFs will be in the same netw= ork context/namespace?

-Anil
--_000_D03222945909anilguntururiftiocom_-- From nobody Sun Sep 7 16:55:18 2014 Return-Path: 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 B27571A063E for ; Sun, 7 Sep 2014 16:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 XB8JQ9bvtyxh for ; Sun, 7 Sep 2014 16:55:15 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69621A063D for ; Sun, 7 Sep 2014 16:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4032; q=dns/txt; s=iport; t=1410134114; x=1411343714; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bT8vn5NRGJnvqNTDsGhb/pWCsA0BEnXW68TmXCvtK44=; b=mYPHH6Lfn/HLRcmowgSDstZNzHyDhS+MUjpoifiGqPKvqZ0x2BfDKO5M 5So22Zg7Cb6tcIqCp6M0HVs6DBnxVR5ygBFUKsW5XpZ7nUpWgFbbUbwwl xYbeqvcIXkLRijqDJnT26dZEn0OoEHsJ3ZMHlU5VkSpChtmtZvHmsqhdJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FADTvDFStJV2d/2dsb2JhbABZgkcjI1NXBMljAQuHSgGBCxZ4hAQBAQQBAQFiCQsQAgEIBA4tBycLFAMOAgQOBYhCAQy7FQETBI9JBAYBgy+BHQWPK4IVhDCHApUsg2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,484,1406592000"; d="scan'208,217"; a="75782193" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 07 Sep 2014 23:55:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s87NtDvT022532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Sep 2014 23:55:13 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Sun, 7 Sep 2014 18:55:13 -0500 From: "Carlos Pignataro (cpignata)" To: Anil Gunturu Thread-Topic: [sfc] Typo in section 5.5 of merged arch document Thread-Index: AQHPyq4mIVlTJs0oo0O+yBPYzac7/5v2rNYA Date: Sun, 7 Sep 2014 23:55:12 +0000 Message-ID: <9C997479-F40D-46D3-9795-A89810DCCCB8@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.180] Content-Type: multipart/alternative; boundary="_000_9C997479F40D46D39795A89810DCCCB8ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nw9PEXoSIuz0KG7CwR4FhzIWPxI Cc: "sfc@ietf.org" Subject: Re: [sfc] Typo in section 5.5 of merged arch document X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 23:55:16 -0000 --_000_9C997479F40D46D39795A89810DCCCB8ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good catch -- thanks Anil. Carlos. On Sep 7, 2014, at 11:12 AM, Anil Gunturu > wrote: In section 5.5 of https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/?include_text=3D1, SPF should be SFP to be constant with the terminol= ogy. "In the simplest case, where there is only a single function in the SPF (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SPF exists (the metadata changes but the SPF does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4.=94 -Anil _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_9C997479F40D46D39795A89810DCCCB8ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <277AC4F916D1D347A56CEF12BF5D6527@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Good catch -- thanks Anil.

Carlos.

On Sep 7, 2014, at 11:12 AM, Anil Gunturu <anil.gunturu@riftio.com> wrote:

In section 5.5 of https://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/?include_text=3D1, SPF should be SFP to be constant with the terminology.

"In the simplest case, where there is only a single func=
tion in the
 SPF (the next hop is either the destination address of the flow or
 the appropriate next hop to that destination), one could argue that
 there may be no need for SFC.

 In the cases where the classifier is separate from the single
 function or a function at the terminal address may need sub-prefix or
 per-subscriber metadata, a single SPF exists (the metadata changes
 but the SPF does not), regardless of the number of potential termin=
al
 addresses for the flow.  This is the case of the simple load
 balancer.  See Figure 4.=94

-Anil


_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_9C997479F40D46D39795A89810DCCCB8ciscocom_-- From nobody Mon Sep 8 06:06:15 2014 Return-Path: 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 C42FF1A87DE for ; Mon, 8 Sep 2014 06:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 d9W9dk6abrQ7 for ; Mon, 8 Sep 2014 06:06:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252C71A87ED for ; Mon, 8 Sep 2014 06:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1282; q=dns/txt; s=iport; t=1410181571; x=1411391171; h=from:to:cc:subject:date:message-id:mime-version; bh=s+l7nI7o2VKoxR7QDfYOTR28wQ+D3mxDjKASJuRAtaQ=; b=dMpuzk1cI5tTXygn9lCvCN/wWFb+RWNt0fERku4VtkeItJovrERnpNdr Ep5xtW0GXlVJRpxO59N5mWHmWmGZ6k4JFujNeFqeO8Flel7zuQX5CNWXm MVZoQ3Swe40nF2B5ucqdeVngXzPsd6ldZDo16fAB13GzYblRjUU2fjpDw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFANKoDVStJA2M/2dsb2JhbABZgkdGgS7RPIETFniDehAdXBIBCwEOZhcQBA6IR7p/ARePTYRTBZFAizKVLINhgjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,486,1406592000"; d="scan'208,217";a="353407563" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP; 08 Sep 2014 13:06:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s88D6AGi013467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 13:06:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 08:06:10 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPy2WoHqjlPkqWskiGGI+5vqSdEw== Date: Mon, 8 Sep 2014 13:06:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D03321E338D71jguicharciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wKZzTAeBfSmwE4wsyR7a7Ip8_Nk Cc: "Carlos Pignataro \(cpignata\)" , Joel Halpern Direct Subject: [sfc] WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:06:13 -0000 --_000_D03321E338D71jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings: Thank you for your responses on the call for adoption of draft-merged-sfc-a= rchitecture-02. Overall we had very good support for this document. Authors, please post a new version as draft-ietf-sfc-architecture-00 Jim & Thomas --_000_D03321E338D71jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings:

Thank you for your responses on the call for adoption of draft-merged-= sfc-architecture-02. Overall we had very good support for this document.

Authors, please post a new version as draft-ietf-sfc-architecture-00

Jim & Thomas
--_000_D03321E338D71jguicharciscocom_-- From nobody Mon Sep 8 06:58:45 2014 Return-Path: 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 5EEED1A87E7 for ; Mon, 8 Sep 2014 06:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 6k2uxI-mEL3D for ; Mon, 8 Sep 2014 06:58:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3630D1A87D5 for ; Mon, 8 Sep 2014 06:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4488; q=dns/txt; s=iport; t=1410184718; x=1411394318; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MhsMl32T30qcrnKwVuV6p10nfPJ065rUbO7vYV8QONU=; b=hxHgnSIOrzSt+sKKht9BMC1hT34+yvMjXguoOnhypBdawSBqEDoTGVer X7WoKP7PKk/ztwHej2eDOxfh/Oi63cWN3mezYdTFZdpp8T0IGmfHMx2zM 74lbuDzoJTtQNp2Kko0wyFaPGmTIGvNDFJxrnvmnpXH64H6xY6zYBnu82 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAH61DVStJV2Y/2dsb2JhbABZgkcjI4EqBNE8AYERFniEAwEBAQQdXBACAQgEDQECAQIoBzIUAwYIAgQBDQWIQgG6eAEXjzwRB4RMBY8rghWLMpUsg2FsgUiBBwEBAQ X-IronPort-AV: E=Sophos; i="5.04,486,1406592000"; d="scan'208,217"; a="75933037" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 08 Sep 2014 13:58:37 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s88Dwbkp011463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 13:58:37 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 08:58:37 -0500 From: "Carlos Pignataro (cpignata)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG adoption of draft-merged-sfc-architecture-02 Thread-Index: AQHPy2WoHqjlPkqWskiGGI+5vqSdE5v3U/4A Date: Mon, 8 Sep 2014 13:58:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [64.102.156.248] Content-Type: multipart/alternative; boundary="_000_D0332E15670C9cpignataciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/RPOekgW8obrEYMEr10HkULqkuw8 Cc: Joel Halpern Direct Subject: Re: [sfc] WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:58:44 -0000 --_000_D0332E15670C9cpignataciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Thomas, We will post and unmodified version from draft-merged-sfc-architecture-02 (= other than the filename and dates) as draft-ietf-sfc-architecture-00, to th= en fold Adoption comments into draft-ietf-sfc-architecture-01. Thanks, Carlos. From: Jim Guichard > Date: Monday, September 8, 2014 at 9:06 AM To: "sfc@ietf.org" > Cc: Carlos Pignataro >, Joel = Halpern Direct > Subject: WG adoption of draft-merged-sfc-architecture-02 Greetings: Thank you for your responses on the call for adoption of draft-merged-sfc-a= rchitecture-02. Overall we had very good support for this document. Authors, please post a new version as draft-ietf-sfc-architecture-00 Jim & Thomas --_000_D0332E15670C9cpignataciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7EAE86A5F002D944BE81ABBFEAC54E0C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Jim, Thomas,

We will post and unmodified version = from draft-merged-sfc-architecture-02 (other than the filename and dates) a= s draft-ietf-sfc-architecture-00, to then fold Adoption comments into draft-ietf-sfc-architecture-01.
Tha= nks,
Car= los.

From: Jim Guichard <jguichar@cisco.com>
Date: Monday, September 8, 2014 at = 9:06 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Cc: Carlos Pignataro <cpignata@cisco.com>, Joel Halpern Direct= <jmh.direct@joelhalpern.c= om>
Subject: WG adoption of draft-merge= d-sfc-architecture-02

Greetings:

Thank you for your responses on the call for adoption of draft-merged-= sfc-architecture-02. Overall we had very good support for this document.

Authors, please post a new version as draft-ietf-sfc-architecture-00

Jim & Thomas
--_000_D0332E15670C9cpignataciscocom_-- From nobody Mon Sep 8 07:25:23 2014 Return-Path: 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 ADAC11A8845; Mon, 8 Sep 2014 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ORcBRpsTzpiQ; Mon, 8 Sep 2014 07:25:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813E1A8837; Mon, 8 Sep 2014 07:25:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140908142512.11686.78140.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 07:25:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qcKeAXqzSzQxP29wXI203z61ErY Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 14:25:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-00.txt Pages : 26 Date : 2014-09-08 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Sep 8 11:56:39 2014 Return-Path: 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 EC5C11A0339 for ; Mon, 8 Sep 2014 11:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 lFiDMzq-2t8T for ; Mon, 8 Sep 2014 11:56:32 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B87E1A0327 for ; Mon, 8 Sep 2014 11:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=997; q=dns/txt; s=iport; t=1410202592; x=1411412192; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qkR/7fG9aAKft9AdktD3W+QcN0F/kZwyMhd/PlpUuyU=; b=fy1ArXnmQ1Uhh3rVB8pKDXnDD6ZRRpNZ+pS7jARJmorJq4MC+cjFD7H7 uo+zL4+FUhZwYy9lyh95giBoUdFEmHp7xPE5n1RZBIlDGXSVde6cghYfm Voyn362D0u757UhczqcR8boQIxrdLeJU73gfbtJVLCGFegkqsfZrbtpq1 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAPj6DVStJA2B/2dsb2JhbABZgw1TUwQEgnjGeYdMAYEYFniEBAEBBCMVPwERJQIFFgsCAgkDAgECATUGCgYNCAEBBYg5CAWmbJVHAReBLI4ognmBUwWLNYo7hwKBX4VijWuEAUwBgUeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,487,1406592000"; d="scan'208";a="76018622" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP; 08 Sep 2014 18:56:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s88IuV3e007800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Sep 2014 18:56:31 GMT Received: from [10.82.251.127] (10.82.251.127) by xhc-rcd-x10.cisco.com (173.37.183.84) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 8 Sep 2014 13:56:31 -0500 Message-ID: <540DFBE4.6090001@cisco.com> Date: Mon, 8 Sep 2014 11:56:36 -0700 From: Reinaldo Penno Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "sfc@ietf.org" References: <20140908185547.25982.56854.idtracker@ietfa.amsl.com> In-Reply-To: <20140908185547.25982.56854.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140908185547.25982.56854.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.82.251.127] Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cmIsXC_L6_rm6Zf7VXyNda0RymQ Subject: [sfc] Fwd: New Version Notification for draft-penno-sfc-yang-07.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 18:56:36 -0000 A new version of I-D, draft-penno-sfc-yang-07.txt has been successfully submitted by Reinaldo Penno and posted to the IETF repository. Name: draft-penno-sfc-yang Revision: 07 Title: Yang Data Model for Service Function Chaining Document date: 2014-09-08 Group: Individual Submission Pages: 36 URL: http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-07.txt Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-penno-sfc-yang-07 Abstract: This document defines a YANG data model that can be used to configure and manage Service Function Chains. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Sep 9 06:09:28 2014 Return-Path: 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 CC3471A02F5; Tue, 9 Sep 2014 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 n1mE_xN2uIll; Tue, 9 Sep 2014 06:09:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C881A0175; Tue, 9 Sep 2014 06:09:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140909130911.6522.60089.idtracker@ietfa.amsl.com> Date: Tue, 09 Sep 2014 06:09:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/mbri2h8INr4AB3tMjVP_MCVx8EI Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 13:09:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-01.txt Pages : 26 Date : 2014-09-09 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 9 08:07:39 2014 Return-Path: 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 076291A0669 for ; Mon, 8 Sep 2014 16:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, 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 SE74yg9Rs6aS for ; Mon, 8 Sep 2014 16:12:58 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2271D1A0472 for ; Mon, 8 Sep 2014 16:12:47 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by resqmta-ch2-10v.sys.comcast.net with comcast id on1a1o0081ZXKqc01nCmLj; Mon, 08 Sep 2014 23:12:46 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id onCl1o00e2yZEBF3hnClae; Mon, 08 Sep 2014 23:12:46 +0000 From: "ietfdbh" To: , Date: Mon, 8 Sep 2014 19:12:45 -0400 Message-ID: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/LoDFq8qTCj15PQJKihgf6QTrltw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410217966; bh=tzGrB06dK9eipNukk58uP9bgm22TCrsImzGPs0FsqrY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=IEFF1pRpPSJNHK8S34tD+mh2eUCX2kZZKeDhujYu93neWzbfXzgnBeAjuytZ9Yr+D jtr4sfnpGOhc9uZ3NNQOaxr0ItXVx7x8o9WRns+PTrDGjztP8k0O+KzAqHftV3ee5n W5t/pMXYPhB2o2OuW83MbxnEVZTpTlnOmF5Hy7bR+WIrbaMRkfLyOGHrXYPeA/1Mx/ 8RhzaVrMMUqUfaRs8OrhsvK5bz4EbxPuj1lObXgZsJsSnu5I0/or/x+BFMAQNtYUcK TAtttbp21i49BcqLYFZq96ovDPhjjMXVuEOGfRBsYoQCbFKhqRK5LXxXizo0thK8Go rJd2K+fLQwD3A== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/qrHzvljwCQ02I-bCPAp-00UVH8Y X-Mailman-Approved-At: Tue, 09 Sep 2014 08:07:37 -0700 Cc: sfc@ietf.org Subject: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 23:13:03 -0000 Hi, I read draft-ietf-sfc-architecture and have a couple comments. In section 1.3, you use a number of abbreviations, such as SFP and SFC, which have not yet been defined or discussed. These should be spelled out on first use in the document. Or you could reorder the terminology section so it is not forward referencing. (If the order was alphabetical, there would be a case for forward references, but it's not alphabetical either.) I know this is being developed in the routing area, but FIB and RIB are not defined in this document, and there is no reference for the terms. I'm sure you could argue that anybody that doesn't know what a FIB or RIB is shouldn't be reading this document. But it could also be argued that since FIB and RIB are mentioned no place in this document except in these assumptions, that the assumption isn't needed. I think the simplest solution is to point to references for FIB and RIB. The SFC Encapsulation definition is especially difficult, because it talks about things that are not defined in this document, such as "dataplane context". It also references "metadata" but "metadata" is not included in the terminology section. The definition of service functions says "One of multiple Service Functions can be embedded in the same network element." Is that supposed to be an "or"? "Multiple occurrences of the Service Function can exist in the same administrative domain." Can multiple occurrences of the service function exist in the same network device? I'm working with applications that can be configured to provide services differently, and multiple instances run on the same host. "constraints that must be applied" seems incorrect, since the rest of the paragraph talks about exceptions to the must. How about s/that must/to/ ? In 2.2, there is a discussion of state tradeoffs. A parenthesized example is (S->D and D->S); I haven't got a clue what the S and D mean. In section 3, point 2, I don't know what "dynamic realization of SFPs" means. Section 4.2 has a paragraph discussing SF Proxy. I think this would be better under 4.6. What a proxy is does not seem important when describing an SF. In 4.3, "Traffic from SFs eventually returns to the same SFF, which is responsible for putting it back onto the network." I don't understand this sentence. First, I recommend replacing "it" with something more concrete. I'm not sure what the SFF "puts back" on the network. Second, I'm not sure that this agrees with section 1.3, which says an SFF delivers from the network to a SF. Editorial nit: "It should be noted that ..."; well, it's a good thing you noted then, isn't it? Now that you've noted it, you can remove this preamble. "an SFF should be able to interact with metadata" - interact feels wrong here. Does an SFF only need to be able to interpret metadata? To modify metadata? What other types of interaction are expected? 5.5 talks about SPFs; is this supposed to be SFP? Administrateive David Harrington ietfdbh@comcast.net +1-603-828-1401 From nobody Thu Sep 11 15:58:54 2014 Return-Path: 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 13E941A0205 for ; Thu, 11 Sep 2014 15:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 Yoix2Y8wuxwv for ; Thu, 11 Sep 2014 15:58:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C691A0204 for ; Thu, 11 Sep 2014 15:58:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9F830241059; Thu, 11 Sep 2014 15:58:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-41.clppva.east.verizon.net [70.106.135.41]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E74B8241054; Thu, 11 Sep 2014 15:58:50 -0700 (PDT) Message-ID: <54122930.7010703@joelhalpern.com> Date: Thu, 11 Sep 2014 18:58:56 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ietfdbh , cpignata@cisco.com References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> In-Reply-To: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cjKMX3n7L36jFz5bWCR9HmMrb0c Cc: sfc@ietf.org Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 22:58:53 -0000 The reference for FIB that the RFC editor lists is RFC 1322. I doubt that a reference to RFC 1322 in the document would help folks much. And they list RIB as a common abbreviation but without a reference, suggesting that there is no good agreed reference for it. https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt. On 9/8/14, 7:12 PM, ietfdbh wrote: > Hi, > > I read draft-ietf-sfc-architecture and have a couple comments. ... > > I know this is being developed in the routing area, but FIB and RIB are not > defined in this document, and there is no reference for the terms. > I'm sure you could argue that anybody that doesn't know what a FIB or RIB is > shouldn't be reading this document. > But it could also be argued that since FIB and RIB are mentioned no place in > this document except in these assumptions, that the assumption isn't needed. > I think the simplest solution is to point to references for FIB and RIB. ... From nobody Thu Sep 11 16:49:46 2014 Return-Path: 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 4B0CA1A0176 for ; Thu, 11 Sep 2014 16:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Dw1tSS17P8d1 for ; Thu, 11 Sep 2014 16:49:44 -0700 (PDT) Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BB71A0053 for ; Thu, 11 Sep 2014 16:49:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 828A4380234; Thu, 11 Sep 2014 19:49:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id B2F17380167; Thu, 11 Sep 2014 19:49:40 -0400 (EDT) X-Sender-Id: bgreene@senki.org Received: from [10.0.1.14] ([UNAVAILABLE]. [139.193.145.19]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.2.10); Thu, 11 Sep 2014 23:49:43 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_4A3EF81A-7832-432D-9882-9E3D599B7D23"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Barry Greene In-Reply-To: <54122930.7010703@joelhalpern.com> Date: Fri, 12 Sep 2014 06:49:31 +0700 Message-Id: References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> <54122930.7010703@joelhalpern.com> To: Joel Halpern X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ZLI_riXrRR7-sx2yDTuFu5gMft0 Cc: cpignata@cisco.com, ietfdbh , sfc@ietf.org Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:49:46 -0000 --Apple-Mail=_4A3EF81A-7832-432D-9882-9E3D599B7D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There are some good referenced in the BMWG RFCs on FIB and RIB. Check = them out.=20 On Sep 12, 2014, at 5:58 AM, Joel M. Halpern = wrote: > The reference for FIB that the RFC editor lists is RFC 1322. I doubt = that a reference to RFC 1322 in the document would help folks much. And = they list RIB as a common abbreviation but without a reference, = suggesting that there is no good agreed reference for it. > https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt. >=20 > On 9/8/14, 7:12 PM, ietfdbh wrote: >> Hi, >>=20 >> I read draft-ietf-sfc-architecture and have a couple comments. > ... >>=20 >> I know this is being developed in the routing area, but FIB and RIB = are not >> defined in this document, and there is no reference for the terms. >> I'm sure you could argue that anybody that doesn't know what a FIB or = RIB is >> shouldn't be reading this document. >> But it could also be argued that since FIB and RIB are mentioned no = place in >> this document except in these assumptions, that the assumption isn't = needed. >> I think the simplest solution is to point to references for FIB and = RIB. > ... >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_4A3EF81A-7832-432D-9882-9E3D599B7D23 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUEjULAAoJEFVuk3AWv0XzzIEH/20+Iy/XwhXm8OPKC5voKiFz a1066LqkmUeBCETLoyqFE1OAfOti8XMjrWGTva8UT6rmohxJUs6rjGmSC8Jz+30k u4dBWD7mmJiUCM/2MJ3TmBK42MsPv3UumSCHJ7mmsKDV7ubKAyqDthM2XHGwV3Ju yqpfkYQ2soNSkeE/9N6c/R5BOjJICim9Ifb5YNFaRSZzC2hEdf7fzsB9lYWT3JEq HHVfRLzLxdMa5gPVYk2VrnpJEMNOqBD+Yc+BYZCXgHRp2SseH7FlosJ6/MvVvSAC yVwi1tpCN3GNEOqMiBHN+95K7bKHPAO49+Gn59FZ7Y2GkRlLyC0yzlAmFMhK/dk= =bWMO -----END PGP SIGNATURE----- --Apple-Mail=_4A3EF81A-7832-432D-9882-9E3D599B7D23-- From nobody Thu Sep 11 17:08:41 2014 Return-Path: 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 07ADA1A02EE for ; Thu, 11 Sep 2014 17:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 r1Ho5Sg3-GNr for ; Thu, 11 Sep 2014 17:08:36 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AA41A02A6 for ; Thu, 11 Sep 2014 17:08:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1E4AF240763; Thu, 11 Sep 2014 17:08:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-41.clppva.east.verizon.net [70.106.135.41]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FDD22401E2; Thu, 11 Sep 2014 17:08:35 -0700 (PDT) Message-ID: <54123988.806@joelhalpern.com> Date: Thu, 11 Sep 2014 20:08:40 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Greene References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> <54122930.7010703@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ohS0zrO23glm38K6TIrAN1CpzPI Cc: cpignata@cisco.com, ietfdbh , sfc@ietf.org Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 00:08:38 -0000 Thanks Barry. I'll take a look. Can you point me at a starting point to follow? Yours, Joel On 9/11/14, 7:49 PM, Barry Greene wrote: > > There are some good referenced in the BMWG RFCs on FIB and RIB. Check them out. > > > > On Sep 12, 2014, at 5:58 AM, Joel M. Halpern wrote: > >> The reference for FIB that the RFC editor lists is RFC 1322. I doubt that a reference to RFC 1322 in the document would help folks much. And they list RIB as a common abbreviation but without a reference, suggesting that there is no good agreed reference for it. >> https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt. >> >> On 9/8/14, 7:12 PM, ietfdbh wrote: >>> Hi, >>> >>> I read draft-ietf-sfc-architecture and have a couple comments. >> ... >>> >>> I know this is being developed in the routing area, but FIB and RIB are not >>> defined in this document, and there is no reference for the terms. >>> I'm sure you could argue that anybody that doesn't know what a FIB or RIB is >>> shouldn't be reading this document. >>> But it could also be argued that since FIB and RIB are mentioned no place in >>> this document except in these assumptions, that the assumption isn't needed. >>> I think the simplest solution is to point to references for FIB and RIB. >> ... >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Sep 12 06:56:30 2014 Return-Path: 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 ACBCF1A004B for ; Fri, 12 Sep 2014 06:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 NxfYkeNiLjLF for ; Fri, 12 Sep 2014 06:56:26 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC0E1A6EF3 for ; Fri, 12 Sep 2014 06:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2369; q=dns/txt; s=iport; t=1410530186; x=1411739786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H+D4UGoWynzsYkmB7cJtT3KmQk/wfjUs9h5Myfj4GLo=; b=eqF1MDydBDQRGFsgxpbvaM+Ro7yLPo2MMJCPsLaoyzQzR9VnF0m4uOzO ugjNL6Ao7Jnmzij2h6HeeAqws4/WMadQBBr08Uq0M2zWdnWUwhOmj0N7p tJk5sgOHAPb8D008e/QxkVjMriRhFebk4l2lnUuNkygOOyTSn6Cxg1AvP w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADz7ElStJV2Z/2dsb2JhbABfgmojU1cEyGUKh04BgQ4WeIQDAQEBAwEBAQFrCwULAgEIEgYuJwsXDgEBBA4FG4gfCAEMvWgBF48aMweDL4EdBYsDhDSCFoQ3hwSBX5Ngg2FsAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,513,1406592000"; d="scan'208";a="77368842" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP; 12 Sep 2014 13:56:26 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8CDuQqB017888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 13:56:26 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 08:56:25 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] draft-ietf-sfc-architecture Thread-Index: Ac/LoDFq8qTCj15PQJKihgf6QTrltwCna5gAAAHEQIAAAKs3AAAc6M8A Date: Fri, 12 Sep 2014 13:56:25 +0000 Message-ID: <19D1F77C-E2C5-4FDE-A097-4924C9D48C92@cisco.com> References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> <54122930.7010703@joelhalpern.com> <54123988.806@joelhalpern.com> In-Reply-To: <54123988.806@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.156.248] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7449ECAF6B386541B24948A72D8F9EE6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aZMQtk38YaAhBspAyuIJwgaXqtk Cc: Barry Greene , ietfdbh , "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 13:56:28 -0000 For FIB on BMWG's work, the most precise definition is probably in Section = 5.3 of RFC3222 , but that i= n turn points to Appendix B of RFC1812.=20 For RIB on BMWG's RFCs, I only remember and could only find RFC 4098, which= does not really include a "Definition" per se. Net-net, these citations would not add much, I think. We are probably better off generalizing the concept, like: " o No assumption is made on how the information necessary to forward pac= kets and the information necessary to route packets is populated on the inv= olved devices. " Would this be better? Or just assume RIB and FIB are very well known? Thanks, Carlos. On Sep 11, 2014, at 8:08 PM, Joel M. Halpern wrote: > Thanks Barry. I'll take a look. Can you point me at a starting point to= follow? >=20 > Yours, > Joel >=20 > On 9/11/14, 7:49 PM, Barry Greene wrote: >>=20 >> There are some good referenced in the BMWG RFCs on FIB and RIB. Check th= em out. >>=20 >>=20 >>=20 >> On Sep 12, 2014, at 5:58 AM, Joel M. Halpern wrote= : >>=20 >>> The reference for FIB that the RFC editor lists is RFC 1322. I doubt t= hat a reference to RFC 1322 in the document would help folks much. And the= y list RIB as a common abbreviation but without a reference, suggesting tha= t there is no good agreed reference for it. >>> https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt. >>>=20 >>> On 9/8/14, 7:12 PM, ietfdbh wrote: >>>> Hi, >>>>=20 >>>> I read draft-ietf-sfc-architecture and have a couple comments. >>> ... >>>>=20 >>>> I know this is being developed in the routing area, but FIB and RIB ar= e not >>>> defined in this document, and there is no reference for the terms. >>>> I'm sure you could argue that anybody that doesn't know what a FIB or = RIB is >>>> shouldn't be reading this document. >>>> But it could also be argued that since FIB and RIB are mentioned no pl= ace in >>>> this document except in these assumptions, that the assumption isn't n= eeded. >>>> I think the simplest solution is to point to references for FIB and RI= B. >>> ... >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>=20 From nobody Fri Sep 12 08:32:40 2014 Return-Path: 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 AC02A1A0176 for ; Thu, 11 Sep 2014 16:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, 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 ja4nKsBtPhTj for ; Thu, 11 Sep 2014 16:52:10 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29ECB1A0053 for ; Thu, 11 Sep 2014 16:52:10 -0700 (PDT) Received: from omta12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by resqmta-po-06v.sys.comcast.net with comcast id pzhR1o0020x6nqc01zry3q; Thu, 11 Sep 2014 23:51:58 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta12.emeryville.ca.mail.comcast.net with comcast id pzrw1o0042yZEBF8Yzrx8W; Thu, 11 Sep 2014 23:51:57 +0000 From: "ietfdbh" To: "'Joel M. Halpern'" , References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> <54122930.7010703@joelhalpern.com> In-Reply-To: <54122930.7010703@joelhalpern.com> Date: Thu, 11 Sep 2014 19:51:53 -0400 Message-ID: <016b01cfce1b$5dcf0180$196d0480$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH/y36oMrZs5R+x+lmHryaki0KVLgHhiE7tm42TaxA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410479518; bh=ZXyDNGG9ezpqI3gH2Vy0OTvH09TsfkkWmSKdQfPeWYg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=GxkEG0UxQz9a+Deny9R7hNbIWEet+UqAfSRS5yCQzwDnLq/XBPdydmB/nWo0fcry+ KSIHQJJXGCCgA5YqtwGwT5ww+j2l4FJMIEJPuo+56qzwklZMCsFtgf3ynKoOhiqKoS sJz63tPIk1L0axncMb5DDZM1f6Jnh8EDQIv/Nn4C48tkuxsQ0jxAE5wI7SaPkHOcoN W3s+egHST6QSHzYvoytDS4O3BO8TsC15ajcgTWsAaRPV/vWB7JWu52dwDflO7JAw6i dar5+IEQX06e2X9bC4Lk17jiMCsLAqn2X+j6f5CKt/bs2+ZmjewiXFRNpMXw3mUqJ5 KcteyWF9H4JyQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dfusn7zJjf1d34CB37MuHS0OYzE X-Mailman-Approved-At: Fri, 12 Sep 2014 08:32:38 -0700 Cc: sfc@ietf.org Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 23:52:11 -0000 Oh well ... David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, September 11, 2014 6:59 PM > To: ietfdbh; cpignata@cisco.com > Cc: sfc@ietf.org > Subject: Re: [sfc] draft-ietf-sfc-architecture > > The reference for FIB that the RFC editor lists is RFC 1322. I doubt > that a reference to RFC 1322 in the document would help folks much. And > they list RIB as a common abbreviation but without a reference, > suggesting that there is no good agreed reference for it. > https://www.rfc-editor.org/rfc-style-guid/abbrev-expansion.txt. > > On 9/8/14, 7:12 PM, ietfdbh wrote: > > Hi, > > > > I read draft-ietf-sfc-architecture and have a couple comments. > ... > > > > I know this is being developed in the routing area, but FIB and RIB are not > > defined in this document, and there is no reference for the terms. > > I'm sure you could argue that anybody that doesn't know what a FIB or RIB > is > > shouldn't be reading this document. > > But it could also be argued that since FIB and RIB are mentioned no place in > > this document except in these assumptions, that the assumption isn't > needed. > > I think the simplest solution is to point to references for FIB and RIB. > ... From nobody Fri Sep 12 08:32:55 2014 Return-Path: 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 EE6091A6F81 for ; Fri, 12 Sep 2014 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.153 X-Spam-Level: X-Spam-Status: No, score=-18.153 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 pL0r99D7cJqm for ; Fri, 12 Sep 2014 08:32:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB951A6F6D for ; Fri, 12 Sep 2014 08:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5273; q=dns/txt; s=iport; t=1410535972; x=1411745572; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dO+z5G2ZDeF3rQotpXoIZqj/zClLk2kQ+Xp1Egn6laA=; b=hMFZxCey+7RZC7MAaF2vOuvyQOMTSGlx76UHSMTHNUD4LzSuseuTQxDl XCEugbLQe+uTYPs9zJ7VjZ5gqQ+fw3l2uWjtq5FTN2SftrCxjj1SNaIpG Lq1Z/MnHgY9+2S5ObxOVIJzs30ptj+O6mSIxNN8jzrr2c/dnL2l7zgiQD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUIAA0RE1StJA2J/2dsb2JhbABcA4JqI4EqBNA5AgIBgQ8WeIQEAQEDAScTLQsHBQsCAQgSJBAyFw4BAQQOBRuIEwMJCAG3EQiGcgEXjxojEAcRgx6BHQEEjzeCFoYpS4RHlT+DYWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,513,1406592000"; d="scan'208";a="77391671" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP; 12 Sep 2014 15:32:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8CFWpfG007140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Sep 2014 15:32:51 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 12 Sep 2014 10:32:51 -0500 From: "Carlos Pignataro (cpignata)" To: ietfdbh Thread-Topic: draft-ietf-sfc-architecture Thread-Index: Ac/LoDFq8qTCj15PQJKihgf6QTrltwDKIeeA Date: Fri, 12 Sep 2014 15:32:49 +0000 Message-ID: <52D0F77E-521A-4452-B7BF-651AD9F6258B@cisco.com> References: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> In-Reply-To: <00a501cfcbba$666a1ea0$333e5be0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.156.248] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A0B47A5CB910042B5F476B0DA61480B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/r_zurQLHq-c1vugWA3bHgh62lXI Cc: "Joel M. Halpern" , "sfc@ietf.org" Subject: Re: [sfc] draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 15:32:54 -0000 Hi, David, Please see inline. On Sep 8, 2014, at 7:12 PM, ietfdbh wrote: > Hi, >=20 > I read draft-ietf-sfc-architecture and have a couple comments. >=20 > In section 1.3, you use a number of abbreviations, such as SFP and SFC, > which have not yet been defined or discussed. > These should be spelled out on first use in the document. > Or you could reorder the terminology section so it is not forward > referencing. > (If the order was alphabetical, there would be a case for forward > references, but it's not alphabetical either.) >=20 As you noted, all all the terms are defined within the section, and the sec= tion is self-contained. I will reorder the terms so that acronyms used are = always previously defined. > I know this is being developed in the routing area, but FIB and RIB are n= ot > defined in this document, and there is no reference for the terms. > I'm sure you could argue that anybody that doesn't know what a FIB or RIB= is > shouldn't be reading this document. > But it could also be argued that since FIB and RIB are mentioned no place= in > this document except in these assumptions, that the assumption isn't need= ed. > I think the simplest solution is to point to references for FIB and RIB. >=20 Discussed in the forked thread. > The SFC Encapsulation definition is especially difficult, because it talk= s > about things that are not defined in this document, such as "dataplane > context". > It also references "metadata" but "metadata" is not included in the > terminology section. >=20 Metadata is implicitly defined as "the SFC encapsulation carries dataplane = context information, also referred to as metadata." It is further explained below in the document (S3 and S4.9). But yes, I can add a short definition. > The definition of service functions says "One of multiple Service Functio= ns > can be embedded in the same network element." Is that supposed to be an > "or"? >=20 Yes, thanks! > "Multiple occurrences of the Service Function can exist in the same > administrative domain." > Can multiple occurrences of the service function exist in the same networ= k > device? > I'm working with applications that can be configured to provide services > differently, and multiple instances run on the same host. >=20 There's nothing in the text preventing this. > "constraints that must be applied" seems incorrect, since the rest of the > paragraph talks about exceptions to the must.=20 > How about s/that must/to/ ? >=20 I don't see how "constraints that must be applied" is incorrect, or how "to= " would make it correct -- the sentence seems to flow fine considering the = text that follows. > In 2.2, there is a discussion of state tradeoffs. A parenthesized example= is > (S->D and D->S); I haven't got a clue what the S and D mean. >=20 In the context of SFC Symmetry (which is the section in which you find the = example), S =3D=3D Source; D =3D=3D Destination, consistent with Fig 4 and = Fig 5.=20 That said, however, it does not matter much in reality what the letters mea= n. I will clarify this by replacing with "from Source to Destination and from = ...". > In section 3, point 2, I don't know what "dynamic realization of SFPs" > means. >=20 Realizing the SFP dynamically :-) > Section 4.2 has a paragraph discussing SF Proxy. I think this would be > better under 4.6.=20 > What a proxy is does not seem important when describing an SF. >=20 It's important for the SF to define SFC-awareness, and its relation to the = SFC encapsulation. I think the paragraph fits there fine, but to your point= , I will add a forward pointer to S 4.6. > In 4.3, "Traffic from SFs > eventually returns to the same SFF, which is responsible for putting > it back onto the network." I don't understand this sentence.=20 > First, I recommend replacing "it" with something more concrete. I'm not s= ure > what the SFF "puts back" on the network. > Second, I'm not sure that this agrees with section 1.3, which says an SFF > delivers from the network to a SF. >=20 I will s/putting it/injecting traffic/. (if you prefer, I can use "handling= traffic" as well) Overall, this seems consistent with Section 1.3: Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. > Editorial nit: "It should be noted that ..."; well, it's a good thing you > noted then, isn't it? Now that you've noted it, you can remove this > preamble. >=20 Noted. > "an SFF should be able to interact with metadata" - interact feels wrong > here. Does an SFF only need to be able to interpret metadata? To modify > metadata? What other types of interaction are expected? >=20 > 5.5 talks about SPFs; is this supposed to be SFP? >=20 > Administrateive >=20 Ack -- thanks for the review! Carlos. >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >=20 From nobody Tue Sep 16 14:49:38 2014 Return-Path: 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 9FEF41A6F0E for ; Tue, 16 Sep 2014 14:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652, 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 XfgNa5JFrn0x for ; Tue, 16 Sep 2014 14:49:35 -0700 (PDT) Received: from omr-m07.mx.aol.com (omr-m07.mx.aol.com [64.12.143.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 950C11A03BE for ; Tue, 16 Sep 2014 14:49:35 -0700 (PDT) Received: from mtaout-aan02.mx.aol.com (mtaout-aan02.mx.aol.com [172.27.19.78]) by omr-m07.mx.aol.com (Outbound Mail Relay) with ESMTP id 6FB057009438E; Tue, 16 Sep 2014 17:49:34 -0400 (EDT) Received: from mgs-aam01.mail.aol.com (mgs-aam01.mail.aol.com [64.12.250.54]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mtaout-aan02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 39AB73800009B; Tue, 16 Sep 2014 17:49:34 -0400 (EDT) Date: Tue, 16 Sep 2014 17:49:34 -0400 From: "mikebianc@aol.com" To: jguichar@cisco.com, sfc@ietf.org Message-ID: <243854349.5104.1410904174086.JavaMail.tomcat@mgs-aam01.mail.aol.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5103_1340227276.1410904174086" X-Originating-IP: 10.181.180.123, 10.181.180.123 X-Mailer: Alto x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20140625; t=1410904174; bh=lXS19Oa8jBZtqWTR/W/vyMnel9Da9fv1c949avOmA4k=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=tznMmQqCg8s1iseifR1ny4E/2KqkM2YbXOryPgcUKZVR/GOFaI52nI3hgd+DfxNuC TAOGVnLytqjXMFD9i3xIJxnv7+t9nHTpdFVl7RKVQteJufbO/MunomU0sfXp0Yftro VBS/6P9guKgyPV6PNQOWF7emlMmGBkncKh4nobOc= x-aol-sid: 3039ac1b134e5418b06e4aaa X-AOL-IP: 64.12.250.54 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/AucEf-Ma5FxXBT5OeRrYRwnE2Ek Subject: Re: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:49:37 -0000 ------=_Part_5103_1340227276.1410904174086 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable support adoption as well. From: jguichar@cisco.com To: sfc@ietf.org Sent: Tuesday, August 26, 2014 Subject: [sfc] Call for WG adoption of draft-merged-sfc-architecture-02 Greetings WG: This message begins a two week call for WG adoption of draft-merged-sfc-arc= hitecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-architecture= /] ending September 9th 2014. Please respond to the SFC mailing list with any statements of approval or d= isapproval. As always, please note: This is not WG Last Call. The document is not final, and the WG is expected= to modify the document=E2=80=99s content until there is WG consensus that = the content is solid. Therefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.If you have objections to a= doption of the document, please state your reasons why, and explain what it= would take to address your concerns.If you have issues with the content, b= y all means raise those issues and we can begin a dialog about how best to = address them. ------=_Part_5103_1340227276.1410904174086 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
support adoption as= well.





From: jguichar@cisco.com<jguichar@cisco.com= >
To: sfc@ietf.org<sfc@ietf.org>
Sent: Tuesday= , August 26, 2014
Subject: [sfc] Call for WG adoption of draft-me= rged-sfc-architecture-02

Greetings WG:

This message begins a two week call for WG adoption of draft-merged-sf= c-architecture-02 [http://datatracker.ietf.org/doc/draft-merged-sfc-archite= cture/] ending September 9th 2014.

Please respond to the SFC mailing list with any statements of approval= or disapproval.

As always, please note:
  1. This is not WG Last C= all. The document is not final, and the WG is expected to modify the docume= nt=E2=80=99s content until there is WG consensus that the content is solid.= Therefore, please don=E2=80=99t oppose adoption just because you want to see changes to its content.
  2. = If you have objections to= adoption of the document, please state your reasons why, and explain what = it would take to address your concerns.
  3. If you have issues with the conten= t, by all means raise those issues and we can begin a dialog about how best= to address them.
------=_Part_5103_1340227276.1410904174086-- From nobody Wed Sep 17 04:24:50 2014 Return-Path: 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 6A0271A02F2 for ; Wed, 17 Sep 2014 04:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 qFmkkfgJFOaC for ; Wed, 17 Sep 2014 04:24:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CE71A023F for ; Wed, 17 Sep 2014 04:24:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMS00674; Wed, 17 Sep 2014 11:24:45 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 17 Sep 2014 12:24:44 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 17 Sep 2014 19:24:37 +0800 From: "Liushucheng (Will)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP0mY/1t2K1MjscEan3zNGu47pXJwFKsJw Date: Wed, 17 Sep 2014 11:24:37 +0000 Message-ID: References: <20140917105748.19743.47848.idtracker@ietfa.amsl.com> In-Reply-To: <20140917105748.19743.47848.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/7H_Kd_hXb4F02AZi8yE9bBlX8_Q Cc: "draft-liu-sfc-use-cases@tools.ietf.org" Subject: [sfc] FW: New Version Notification for draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 11:24:48 -0000 SGkgYWxsLA0KDQpBY2NvcmRpbmcgdG8gdGhlIG1pbnV0ZXMgb2YgbGFzdCBJRVRGIG1lZXRpbmc6 DQoJVGhvbWFzIE5hcnRlbjogVGhlcmUgd2FzIGEgZmFpciBhbW91bnQgb2Ygc3VwcG9ydCBlYXJs aWVyIHRvIGhhdmUgb25lIGRvY3VtZW50LiBOb3cgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlIGRy YWZ0cy4gSXQgaXMgdXAgdG8gdGhlIFdHIHRvIGRlY2lkZSBob3cgdG8gZ28gZm9yd2FyZC4NCgko Pyk6IERvY3VtZW50IGlzIHZlcnkgY29tcHJlaGVuc2l2ZSBhbmQgdXNlZnVsIGZvciBvcGVyYXRv cnMuDQoJS2VuIEdyYXk6IEFncmVlIHdpdGggVGhvbWFzLiBXaXRoIG11bHRpcGxlIGRvY3VtZW50 cyBpdHMgaGFyZCB0byBmaW5kIHVuaXF1ZSByZXF1aXJlbWVudHMgYWNyb3NzIG1hbnkuIFRoYXQg aXMgd2hhdCBJIHdvdWxkIGxpa2UgdG8gc2VlLg0KCSg/KTogR29vZCBmb3IgV0cgYWRvcHRpb24u DQoJSmltIEd1aWNoYXJkOiBIb3cgbWFueSBoYXZlIHJlYWQgdGhlIGRvY3VtZW50PyBBYm91dCAy MC4NCglUaG9tYXMgTmFydGVuOiBTaG91bGQgd2UgaGF2ZSBzZXBhcmF0ZSBkb2N1bWVudD8gSG93 IG1hbnkgbGlrZSB0byBhZG9wdCB2cyBub3QgYWRvcHQ/IE5vIGNsZWFyIGNvbnNlbnN1cyBpbiB0 aGUgcm9vbSBmb3IgYWRvcHRpb24uIENvbnRpbnVlIHRvIGRpc2N1c3Mgb24tbGlzdC4NCiANCklu IGxhc3QgSUVURiBtZWV0aW5nLCB0aGVyZSB3ZXJlIGFyb3VuZCAyMCBwZXJzb25zIHdobyBzdXBw b3J0ZWQgdG8gYWRvcHQgdGhpcyBkcmFmdC4gQXMgc3VnZ2VzdGVkIGJ5IENoYWlycywgd2UgdXBk YXRlZCBvdXIgZHJhZnQgYW5kIHdpc2ggdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gaGVyZSB0 byBnZXQgbW9yZSBwZW9wbGUgc3VwcG9ydCB1cy4gVGhlIG1haW4gY2hhbmdlcyBhcmU6DQoxLiBD dXQgdGhlIHByb2JsZW1zIGxpc3RlZCBpbiBtb2JpbGUgdXNlIGNhc2UNCjIuIEFkZHJlc3NlZCB0 aGUgY29tbWVudHMgZnJvbSBEYXZlIERvbHNvbiBhYm91dCB0aGUgYmlkaXJlY3Rpb25hbCBsaW5r Lg0KMy4gVXBkYXRlZCB0aGUgcmVmZXJlbmNlLg0KIA0KUGxlYXNlIGxldCB1cyBrbm93IHlvdXIg dGhvdWdodCwgdGhhbmtzIQ0KDQpSZWdhcmRzLA0KV2lsbA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE3LCAyMDE0IDY6 NTggUE0NClRvOiBRaW9uZyBTdW47IEppYWZlbmcgWmh1OyBDaGFuZ2NoZW5nIEh1YW5nOyBOaWNv bGFpIExleW1hbm47IEhvbmd5dSBMaSAoSnVsaW8pOyBMaXVzaHVjaGVuZyAoV2lsbCk7IEZ1IFFp YW87IFFpb25nIFN1bjsgUGVuZyBIZTsgUWlhbyBGdTsgQ2hhbmdjaGVuZyBIdWFuZzsgTW9oYW1l ZCBCb3VjYWRhaXI7IE5pY29sYWkgTGV5bWFubjsgSHVhbmd5b25nIChPbGl2ZXIpOyBNb2hhbWVk IEJvdWNhZGFpcjsgUGVuZyBIZTsgQ2h1b25nIFBoYW07IEppYWZlbmcgWmh1OyBMaXVzaHVjaGVu ZyAoV2lsbCk7IEhvbmd5dSBMaSAoSnVsaW8pOyBDaHVvbmcgUGhhbTsgSHVhbmd5b25nIChPbGl2 ZXIpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxpdS1zZmMt dXNlLWNhc2VzLTA4LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1saXUtc2Zj LXVzZS1jYXNlcy0wOC50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXaWxs KFNodWNoZW5nKSBMaXUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1l OgkJZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMNClJldmlzaW9uOgkwOA0KVGl0bGU6CQlTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIEdlbmVyYWwgVXNlIENhc2VzDQpEb2N1bWVudCBkYXRl OgkyMDE0LTA5LTE3DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxOQ0K VVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWxpdS1zZmMtdXNlLWNhc2VzLTA4LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLw0KSHRtbGl6ZWQ6ICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTA4 DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt bGl1LXNmYy11c2UtY2FzZXMtMDgNCg0KQWJzdHJhY3Q6DQogICBUaGUgZGVsaXZlcnkgb2YgdmFs dWUtYWRkZWQgc2VydmljZXMgcmVsaWVzIG9uIHRoZSBpbnZvY2F0aW9uIG9mDQogICBhZHZhbmNl ZCBTZXJ2aWNlIEZ1bmN0aW9ucyBpbiBhIHNlcXVlbnRpYWwgb3JkZXIuICBUaGlzIG1lY2hhbmlz bSBpcw0KICAgY2FsbGVkIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykuICBUaGUgc2V0 IG9mIGludm9sdmVkIFNlcnZpY2UNCiAgIEZ1bmN0aW9ucyBhbmQgdGhlaXIgb3JkZXIgZGVwZW5k cyBvbiB0aGUgc2VydmljZSBjb250ZXh0IGFuZCBvdGhlcg0KICAgZGVwbG95bWVudC1zcGVjaWZp YyBjb25zaWRlcmF0aW9ucy4NCg0KICAgSGF2aW5nIGEgc2luZ2xlIHVzZSBjYXNlIGRvY3VtZW50 IGVhc2VzIHRoZSBlZmZvcnQgb2YgZGVyaXZpbmcNCiAgIHJlcXVpcmVtZW50cyB0aGF0IGFyZSB0 byBiZSBtZXQgYnkgU0ZDIHNvbHV0aW9uKHMpLiAgTW9yZW92ZXIsIGl0DQogICBhbGxvd3MgdG8g aWRlbnRpZnkgY29tbW9uYWxpdGllcyBiZXR3ZWVuIHRoZSB2YXJpb3VzIHVzZSBjYXNlcyB0aGF0 DQogICBhcmUgb2YgaW50ZXJlc3QuICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIGEgc2V0IG9mIGdl bmVyYWwgdXNlIGNhc2VzDQogICBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Sep 17 05:44:47 2014 Return-Path: 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 138021A0233 for ; Wed, 17 Sep 2014 05:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 fdJDbM26A7sC for ; Wed, 17 Sep 2014 05:44:43 -0700 (PDT) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148711A0202 for ; Wed, 17 Sep 2014 05:44:43 -0700 (PDT) Received: from MacPC2 (206-188-90-150.cpe.distributel.net [206.188.90.150]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id s8HCiYxW008866 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Sep 2014 08:44:34 -0400 From: "Changcheng Huang" To: "'Liushucheng \(Will\)'" , References: <20140917105748.19743.47848.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 17 Sep 2014 08:44:33 -0400 Organization: Carleton University Message-ID: <009101cfd275$2257cde0$670769a0$@carleton.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AQHP0mY/1t2K1MjscEan3zNGu47pXJwFKsJwgAAZvZA= Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/wmXQlqCk8OH8gUpFsqxZJtAogQc Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 12:44:45 -0000 I think the draft has significantly improved. Those who are against = adopting this draft should clearly state why they are against so that = the authors can further improve the draft. Otherwise they should be = considered support as the chairs have been doing for other drafts. Regards, Chang -----Original Message----- From: Liushucheng (Will) [mailto:liushucheng@huawei.com]=20 Sent: Wednesday, September 17, 2014 7:25 AM To: sfc@ietf.org Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: FW: New Version Notification for draft-liu-sfc-use-cases-08.txt Hi all, According to the minutes of last IETF meeting: Thomas Narten: There was a fair amount of support earlier to have one = document. Now there are other use case drafts. It is up to the WG to = decide how to go forward. (?): Document is very comprehensive and useful for operators. Ken Gray: Agree with Thomas. With multiple documents its hard to find = unique requirements across many. That is what I would like to see. (?): Good for WG adoption. Jim Guichard: How many have read the document? About 20. Thomas Narten: Should we have separate document? How many like to adopt = vs not adopt? No clear consensus in the room for adoption. Continue to = discuss on-list. =20 In last IETF meeting, there were around 20 persons who supported to = adopt this draft. As suggested by Chairs, we updated our draft and wish = to continue the discussion here to get more people support us. The main = changes are: 1. Cut the problems listed in mobile use case 2. Addressed the comments from Dave Dolson about the bidirectional link. 3. Updated the reference. =20 Please let us know your thought, thanks! Regards, Will -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, September 17, 2014 6:58 PM To: Qiong Sun; Jiafeng Zhu; Changcheng Huang; Nicolai Leymann; Hongyu Li = (Julio); Liushucheng (Will); Fu Qiao; Qiong Sun; Peng He; Qiao Fu; = Changcheng Huang; Mohamed Boucadair; Nicolai Leymann; Huangyong = (Oliver); Mohamed Boucadair; Peng He; Chuong Pham; Jiafeng Zhu; = Liushucheng (Will); Hongyu Li (Julio); Chuong Pham; Huangyong (Oliver) Subject: New Version Notification for draft-liu-sfc-use-cases-08.txt A new version of I-D, draft-liu-sfc-use-cases-08.txt has been = successfully submitted by Will(Shucheng) Liu and posted to the IETF = repository. Name: draft-liu-sfc-use-cases Revision: 08 Title: Service Function Chaining (SFC) General Use Cases Document date: 2014-09-17 Group: Individual Submission Pages: 19 URL: = http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-08.txt Status: = https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-08 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-08 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context and other deployment-specific considerations. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document presents a set of general use cases of Service Function Chaining (SFC). = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat From nobody Sat Sep 20 06:54:18 2014 Return-Path: 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 B188D1A014A; Sat, 20 Sep 2014 06:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3noAbjvvWgB6; Sat, 20 Sep 2014 06:54:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA621A0102; Sat, 20 Sep 2014 06:54:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140920135413.4995.12352.idtracker@ietfa.amsl.com> Date: Sat, 20 Sep 2014 06:54:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/SBbc20YEs4gcpM7LhK1H_7bgWPU Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Sep 2014 13:54:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-02.txt Pages : 26 Date : 2014-09-20 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Sep 20 23:43:28 2014 Return-Path: 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 316E61A035C for ; Sat, 20 Sep 2014 23:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 XfP20pnqbJPj for ; Sat, 20 Sep 2014 23:43:24 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F6981A035E for ; Sat, 20 Sep 2014 23:43:24 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id hz1so2586650pad.11 for ; Sat, 20 Sep 2014 23:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=IGP/+zAI4TIOAd1ZSV+3fio1SfdKyFu9IlbRdV4AvxQ=; b=YZ54FPbxaI90TxM/8djdjl4ckGtKOVWcwo9/IatASMe8I3y7hZfg7kci7VKRNkQv0W H3sRkyrXClS0kO5Wae1sB8PAUfuiiL9Q+D9ghJk0R3ZCO6f+ru57ZWJ8FiydWEKSlQFr L7Q3XXmq9sKZPj4chbF/LRlD3yeWRLUzHB/MiICRM/63C913wC1hH4juu9NBkN80Csmh 8hE9eQDoD6sgH8KV3RhgRPIRm7jczggJSZieP0hSu6kl9cwPc4PtiO4+cVB6exNfE94G 0YfnYcLOfdmFqojzjbuzktscv/lEaBKdRQ9Xk3BDUUJP10rn92ZNj3OLW8gWxhbAXzdw oXwA== X-Received: by 10.69.18.75 with SMTP id gk11mr14169903pbd.131.1411281803625; Sat, 20 Sep 2014 23:43:23 -0700 (PDT) Received: from xiechf-ctbri-PC ([114.250.163.14]) by mx.google.com with ESMTPSA id qi1sm6060928pac.46.2014.09.20.23.43.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Sep 2014 23:43:23 -0700 (PDT) Date: Sun, 21 Sep 2014 14:43:30 +0800 From: xiechf01 To: huang , "Will Liu (Shucheng)" , sfc References: <20140917105748.19743.47848.idtracker@ietfa.amsl.com>, , <009101cfd275$2257cde0$670769a0$@carleton.ca> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <201409211443241963252@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart077565517141_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/8EFgDrSo-tdUAWjuQfqGbFKh-3Y Cc: draft-liu-sfc-use-cases Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Sep 2014 06:43:26 -0000 This is a multi-part message in MIME format. ------=_001_NextPart077565517141_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkNvbnNpZGVyaW5nIHRoYXQgdXNlIGNhc2UgZG9jdW1lbnQgaXMgZXNzZW50aWFsIGZvciB0 aGUgb3BlcmF0b3JzIHRvIHVuZGVyc3RhbmQgYW5kIGFjY2VwdCBuZXcgdGVjaG5vbG9naWVzLHN1 Y2ggYXMgU0ZDLCBhbmQgdGhpcyBkb2N1bWVudCBoYXMgYmVlbiBpbXByb3ZlZCBiYXNlZCBvbiB0 aGUgY29tbWVudHMgaW4gbGFzdCBTRkMgbWVldGluZywgYW5kIGl0ICBoYXMgY292ZXJkIG1ham9y IGNhc2VzIHRoYXQgb3BlcmF0b3JzIGFyZSBjb25jZXJuZWQsIHNvIEkgdGhpbmsgdGhpcyBjdXJy ZW50IGRvY3VtZW50IGlzIHZlcnkgY29tcHJlaGVuc2l2ZSBhbmQgbWVhbmluZy4gDQoNCkNob25n ZmVuZyBYaWUNCg0KRnJvbTogQ2hhbmdjaGVuZyBIdWFuZw0KRGF0ZTogMjAxNC0wOS0xNyAyMDo0 NA0KVG86ICdMaXVzaHVjaGVuZyBcKFdpbGxcKSc7IHNmY0BpZXRmLm9yZw0KQ0M6IGRyYWZ0LWxp dS1zZmMtdXNlLWNhc2VzDQpTdWJqZWN0OiBSZTogW3NmY10gTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wOC50eHQNCkkgdGhpbmsgdGhlIGRyYWZ0 IGhhcyBzaWduaWZpY2FudGx5IGltcHJvdmVkLiBUaG9zZSB3aG8gYXJlIGFnYWluc3QgYWRvcHRp bmcgdGhpcyBkcmFmdCBzaG91bGQgY2xlYXJseSBzdGF0ZSB3aHkgdGhleSBhcmUgYWdhaW5zdCBz byB0aGF0IHRoZSBhdXRob3JzIGNhbiBmdXJ0aGVyIGltcHJvdmUgdGhlIGRyYWZ0LiBPdGhlcndp c2UgdGhleSBzaG91bGQgYmUgY29uc2lkZXJlZCBzdXBwb3J0IGFzIHRoZSBjaGFpcnMgaGF2ZSBi ZWVuIGRvaW5nIGZvciBvdGhlciBkcmFmdHMuDQoNClJlZ2FyZHMsDQoNCkNoYW5nDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMaXVzaHVjaGVuZyAoV2lsbCkgW21haWx0bzps aXVzaHVjaGVuZ0BodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE3LCAy MDE0IDc6MjUgQU0NClRvOiBzZmNAaWV0Zi5vcmcNCkNjOiBkcmFmdC1saXUtc2ZjLXVzZS1jYXNl c0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMtMDgudHh0DQoNCkhpIGFsbCwNCg0KQWNjb3JkaW5n IHRvIHRoZSBtaW51dGVzIG9mIGxhc3QgSUVURiBtZWV0aW5nOg0KVGhvbWFzIE5hcnRlbjogVGhl cmUgd2FzIGEgZmFpciBhbW91bnQgb2Ygc3VwcG9ydCBlYXJsaWVyIHRvIGhhdmUgb25lIGRvY3Vt ZW50LiBOb3cgdGhlcmUgYXJlIG90aGVyIHVzZSBjYXNlIGRyYWZ0cy4gSXQgaXMgdXAgdG8gdGhl IFdHIHRvIGRlY2lkZSBob3cgdG8gZ28gZm9yd2FyZC4NCig/KTogRG9jdW1lbnQgaXMgdmVyeSBj b21wcmVoZW5zaXZlIGFuZCB1c2VmdWwgZm9yIG9wZXJhdG9ycy4NCktlbiBHcmF5OiBBZ3JlZSB3 aXRoIFRob21hcy4gV2l0aCBtdWx0aXBsZSBkb2N1bWVudHMgaXRzIGhhcmQgdG8gZmluZCB1bmlx dWUgcmVxdWlyZW1lbnRzIGFjcm9zcyBtYW55LiBUaGF0IGlzIHdoYXQgSSB3b3VsZCBsaWtlIHRv IHNlZS4NCig/KTogR29vZCBmb3IgV0cgYWRvcHRpb24uDQpKaW0gR3VpY2hhcmQ6IEhvdyBtYW55 IGhhdmUgcmVhZCB0aGUgZG9jdW1lbnQ/IEFib3V0IDIwLg0KVGhvbWFzIE5hcnRlbjogU2hvdWxk IHdlIGhhdmUgc2VwYXJhdGUgZG9jdW1lbnQ/IEhvdyBtYW55IGxpa2UgdG8gYWRvcHQgdnMgbm90 IGFkb3B0PyBObyBjbGVhciBjb25zZW5zdXMgaW4gdGhlIHJvb20gZm9yIGFkb3B0aW9uLiBDb250 aW51ZSB0byBkaXNjdXNzIG9uLWxpc3QuDQpJbiBsYXN0IElFVEYgbWVldGluZywgdGhlcmUgd2Vy ZSBhcm91bmQgMjAgcGVyc29ucyB3aG8gc3VwcG9ydGVkIHRvIGFkb3B0IHRoaXMgZHJhZnQuIEFz IHN1Z2dlc3RlZCBieSBDaGFpcnMsIHdlIHVwZGF0ZWQgb3VyIGRyYWZ0IGFuZCB3aXNoIHRvIGNv bnRpbnVlIHRoZSBkaXNjdXNzaW9uIGhlcmUgdG8gZ2V0IG1vcmUgcGVvcGxlIHN1cHBvcnQgdXMu IFRoZSBtYWluIGNoYW5nZXMgYXJlOg0KMS4gQ3V0IHRoZSBwcm9ibGVtcyBsaXN0ZWQgaW4gbW9i aWxlIHVzZSBjYXNlDQoyLiBBZGRyZXNzZWQgdGhlIGNvbW1lbnRzIGZyb20gRGF2ZSBEb2xzb24g YWJvdXQgdGhlIGJpZGlyZWN0aW9uYWwgbGluay4NCjMuIFVwZGF0ZWQgdGhlIHJlZmVyZW5jZS4N ClBsZWFzZSBsZXQgdXMga25vdyB5b3VyIHRob3VnaHQsIHRoYW5rcyENCg0KUmVnYXJkcywNCldp bGwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNk YXksIFNlcHRlbWJlciAxNywgMjAxNCA2OjU4IFBNDQpUbzogUWlvbmcgU3VuOyBKaWFmZW5nIFpo dTsgQ2hhbmdjaGVuZyBIdWFuZzsgTmljb2xhaSBMZXltYW5uOyBIb25neXUgTGkgKEp1bGlvKTsg TGl1c2h1Y2hlbmcgKFdpbGwpOyBGdSBRaWFvOyBRaW9uZyBTdW47IFBlbmcgSGU7IFFpYW8gRnU7 IENoYW5nY2hlbmcgSHVhbmc7IE1vaGFtZWQgQm91Y2FkYWlyOyBOaWNvbGFpIExleW1hbm47IEh1 YW5neW9uZyAoT2xpdmVyKTsgTW9oYW1lZCBCb3VjYWRhaXI7IFBlbmcgSGU7IENodW9uZyBQaGFt OyBKaWFmZW5nIFpodTsgTGl1c2h1Y2hlbmcgKFdpbGwpOyBIb25neXUgTGkgKEp1bGlvKTsgQ2h1 b25nIFBoYW07IEh1YW5neW9uZyAoT2xpdmVyKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wOC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMtMDgudHh0IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgV2lsbChTaHVjaGVuZykgTGl1IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMNClJldmlz aW9uOiAwOA0KVGl0bGU6IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgR2VuZXJhbCBV c2UgQ2FzZXMNCkRvY3VtZW50IGRhdGU6IDIwMTQtMDktMTcNCkdyb3VwOiBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAxOQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzLTA4LnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxpdS1zZmMtdXNl LWNhc2VzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWxpdS1zZmMtdXNlLWNhc2VzLTA4DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtbGl1LXNmYy11c2UtY2FzZXMtMDgNCg0KQWJzdHJhY3Q6DQog ICBUaGUgZGVsaXZlcnkgb2YgdmFsdWUtYWRkZWQgc2VydmljZXMgcmVsaWVzIG9uIHRoZSBpbnZv Y2F0aW9uIG9mDQogICBhZHZhbmNlZCBTZXJ2aWNlIEZ1bmN0aW9ucyBpbiBhIHNlcXVlbnRpYWwg b3JkZXIuICBUaGlzIG1lY2hhbmlzbSBpcw0KICAgY2FsbGVkIFNlcnZpY2UgRnVuY3Rpb24gQ2hh aW5pbmcgKFNGQykuICBUaGUgc2V0IG9mIGludm9sdmVkIFNlcnZpY2UNCiAgIEZ1bmN0aW9ucyBh bmQgdGhlaXIgb3JkZXIgZGVwZW5kcyBvbiB0aGUgc2VydmljZSBjb250ZXh0IGFuZCBvdGhlcg0K ICAgZGVwbG95bWVudC1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucy4NCg0KICAgSGF2aW5nIGEgc2lu Z2xlIHVzZSBjYXNlIGRvY3VtZW50IGVhc2VzIHRoZSBlZmZvcnQgb2YgZGVyaXZpbmcNCiAgIHJl cXVpcmVtZW50cyB0aGF0IGFyZSB0byBiZSBtZXQgYnkgU0ZDIHNvbHV0aW9uKHMpLiAgTW9yZW92 ZXIsIGl0DQogICBhbGxvd3MgdG8gaWRlbnRpZnkgY29tbW9uYWxpdGllcyBiZXR3ZWVuIHRoZSB2 YXJpb3VzIHVzZSBjYXNlcyB0aGF0DQogICBhcmUgb2YgaW50ZXJlc3QuICBUaGlzIGRvY3VtZW50 IHByZXNlbnRzIGEgc2V0IG9mIGdlbmVyYWwgdXNlIGNhc2VzDQogICBvZiBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIChTRkMpLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBt YWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmM= ------=_001_NextPart077565517141_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
 
Considering that use case document is essential for the operator= s to=20 understand and accept new technologies,such as SFC, and this document has = been=20 improved based on the comments in last SFC meeting, and it  has cover= d=20 major cases that operators are concerned, so I think this current document= is=20 very comprehensive and meaning.
 
Chongfeng Xie
 
Date: 2014-09-17 20:44
CC: draft-liu-sfc-use-c= ases
Subject: Re: [sfc] New Version Notification for=20 draft-liu-sfc-use-cases-08.txt
I think the draft has significantly improved. Those who are against=20 adopting this draft should clearly state why they are against so that the=20 authors can further improve the draft. Otherwise they should be considered= =20 support as the chairs have been doing for other drafts.
 
Regards,
 
Chang
 
-----Original Message-----
From: Liushucheng (Will) [mailto:liushucheng@huawei.com]
Sent: Wednesday, September 17, 2014 7:25 AM
To: sfc@ietf.org
Cc: draft-liu-sfc-use-cases@tools.ietf.org
Subject: FW: New Version Notification for=20 draft-liu-sfc-use-cases-08.txt
 
Hi all,
 
According to the minutes of last IETF meeting:
Thomas Narten: There was a fair amount of support earlier to have one= =20 document. Now there are other use case drafts. It is up to the WG to decid= e how=20 to go forward.
(?): Document is very comprehensive and useful for operators.
Ken Gray: Agree with Thomas. With multiple documents its hard to find= =20 unique requirements across many. That is what I would like to see.
(?): Good for WG adoption.
Jim Guichard: How many have read the document? About 20.
Thomas Narten: Should we have separate document? How many like to ado= pt vs=20 not adopt? No clear consensus in the room for adoption. Continue to discus= s=20 on-list.
In last IETF meeting, there were around 20 persons who supported to a= dopt=20 this draft. As suggested by Chairs, we updated our draft and wish to conti= nue=20 the discussion here to get more people support us. The main changes are:
1. Cut the problems listed in mobile use case
2. Addressed the comments from Dave Dolson about the bidirectional=20 link.
3. Updated the reference.
Please let us know your thought, thanks!
 
Regards,
Will
 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, September 17, 2014 6:58 PM
To: Qiong Sun; Jiafeng Zhu; Changcheng Huang; Nicolai Leymann; Hongyu= Li=20 (Julio); Liushucheng (Will); Fu Qiao; Qiong Sun; Peng He; Qiao Fu; Changch= eng=20 Huang; Mohamed Boucadair; Nicolai Leymann; Huangyong (Oliver); Mohamed=20 Boucadair; Peng He; Chuong Pham; Jiafeng Zhu; Liushucheng (Will); Hongyu L= i=20 (Julio); Chuong Pham; Huangyong (Oliver)
Subject: New Version Notification for draft-liu-sfc-use-cases-08.txt<= /DIV>
 
 
A new version of I-D, draft-liu-sfc-use-cases-08.txt has been success= fully=20 submitted by Will(Shucheng) Liu and posted to the IETF repository.
 
Name: draft-liu-sfc-use-cases
Revision: 08
Title: Service Function Chaining (SFC) General Use Cases
Document date: 2014-09-17
Group: Individual Submission
Pages: 19
URL:           = ;=20 http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-08.txt
Status:        =20 https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/
Htmlized:      =20 http://tools.ietf.org/html/draft-liu-sfc-use-cases-08
Diff:          =20 http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-08
 
Abstract:
   The delivery of value-added services relies on the invoc= ation=20 of
   advanced Service Functions in a sequential order.  = This=20 mechanism is
   called Service Function Chaining (SFC).  The set of= =20 involved Service
   Functions and their order depends on the service context= and=20 other
   deployment-specific considerations.
 
   Having a single use case document eases the effort of=20 deriving
   requirements that are to be met by SFC solution(s). = ;=20 Moreover, it
   allows to identify commonalities between the various use= cases=20 that
   are of interest.  This document presents a set of g= eneral=20 use cases
   of Service Function Chaining (SFC).
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;       =20
 
 
Please note that it may take a couple of minutes from the time of=20 submission until the htmlized version and diff are available at=20 tools.ietf.org.
 
The IETF Secretariat
 
 
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc
------=_001_NextPart077565517141_=------ From nobody Mon Sep 22 23:29:04 2014 Return-Path: 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 87A0F1A0687 for ; Mon, 22 Sep 2014 23:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 iKU2FZ1Ez0rq for ; Mon, 22 Sep 2014 23:29:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6941A02FC for ; Mon, 22 Sep 2014 23:29:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMX10790; Tue, 23 Sep 2014 06:29:00 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 23 Sep 2014 07:28:59 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 23 Sep 2014 14:28:55 +0800 From: Qin Wu To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-03.txt Thread-Index: AQHP1vaUpwUNEU+DQU+GVZtVczSsZZwOP0gw Date: Tue, 23 Sep 2014 06:28:55 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/5eJKhaOHTkPtkIODM88vHRKCqmY Subject: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 06:29:03 -0000 SGk6DQpIZXJlIGlzIHRoZSB1cGRhdGUgdG8gZHJhZnQtd3ctc2ZjLWNvbnRyb2wtcGxhbmUuDQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFu ZS8NClRoZSBkaWZmIGlzOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt d3ctc2ZjLWNvbnRyb2wtcGxhbmUtMDMNCkkgbGlrZSB0byBzb2xpY2l0IHNvbWUgcmV2aWV3IG9u IHRoaXMgdXBkYXRlLg0KDQpUaGlzIGRyYWZ0IGRlc2NyaWJlcyBTRkMgY29udHJvbCBwbGFuZSBh cmNoaXRlY3R1cmUgYW5kIGRpc2N1c3Nlcw0KaG93IHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu cyBhcmUgc3RydWN0dXJlZCBhbmQgaG93IFNlcnZpY2UNCkZ1bmN0aW9uIENoYWluaW5nIHBhdGgg aXMgcHJvdmlzaW9uZWQgYW5kIHNldHVwLg0KDQpTZXZlcmFsIGNvbnRyb2wgcGxhbmUgY29tcG9u ZW50IGRlcGxveW1lbnRzIGFyZSBleHBsb3JlZCBpbiB0aGUgQXBwZW5kaXguDQoNClJlZ2FyZHMh DQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogSS1ELUFubm91bmNlIFttYWlsdG86 aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnDQq3osvNyrG85DogMjAxNMTqOdTCMjPI1SAxNDoyMQ0KytW8/sjLOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmcNCtb3zOI6IEktRCBBY3Rpb246IGRyYWZ0LXd3LXNmYy1jb250cm9sLXBsYW5lLTAz LnR4dA0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1s aW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAg ICAgICA6IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQ29udHJvbCBQbGFuZSBBY2hp dGVjdHVyZQ0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBIb25neXUgTGkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgUWluIFd1DQogICAgICAgICAgICAgICAgICAgICAgICAgIE1vaGFtZWQg Qm91Y2FkYWlyDQogICAgICAgICAgICAgICAgICAgICAgICAgIENocmlzdGlhbiBKYWNxdWVuZXQN CiAgICAgICAgICAgICAgICAgICAgICAgICAgV2FsdGVyIEhhZWZmbmVyDQoJRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtd3ctc2ZjLWNvbnRyb2wtcGxhbmUtMDMudHh0DQoJUGFnZXMgICAgICAgICAg IDogMTgNCglEYXRlICAgICAgICAgICAgOiAyMDE0LTA5LTIyDQoNCkFic3RyYWN0Og0KICAgVGhp cyBkb2N1bWVudCBkZWZpbmVzIHRoZSBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVyZSB3aGljaCBp bmNsdWRlDQogICBjb250cm9sIHBsYW5lIGNvbXBvbmVudHMgYW5kIGludGVyZmFjZSBiZXR3ZWVu IGNvbnRyb2wgcGxhbmUNCiAgIGNvbXBvbmVudCBhbmQgZGF0YSBwbGFuZSBjb21wb25lbnQuICBU aGlzIGRvY3VtZW50IGZ1cnRoZXIgZGVzY3JpYmVzDQogICBob3cgU2VydmljZSBGdW5jdGlvbnMg Q2hhaW5zIGFyZSBzdHJ1Y3R1cmVkIGFuZCBob3cgU2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5p bmcgcGF0aCBpcyBwcm92aXNpb25lZCBhbmQgc2V0dXAuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS8NCg0KVGhlcmUncyBhbHNvIGEg aHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wMw0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlv dXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wMw0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh bm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIG9yIGZ0cDovL2Z0cC5pZXRm Lm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo= From nobody Tue Sep 23 00:06:09 2014 Return-Path: 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 EC7701A1BAF for ; Tue, 23 Sep 2014 00:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.786, SPF_PASS=-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 bQHHbufTjw3y for ; Tue, 23 Sep 2014 00:06:06 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id 653F91A1BAD for ; Tue, 23 Sep 2014 00:06:04 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.11]) by rmmx-syy-dmz-app12-12012 (RichMail) with SMTP id 2eec54211bdbde3-140c4; Tue, 23 Sep 2014 15:06:04 +0800 (CST) X-RM-TRANSID: 2eec54211bdbde3-140c4 X-RM-SPAM-FLAG: 00000000 Received: from DB2B (unknown[117.136.38.228]) by rmsmtp-syy-appsvr06-12006 (RichMail) with SMTP id 2ee654211bd5534-842c4; Tue, 23 Sep 2014 15:06:04 +0800 (CST) X-RM-TRANSID: 2ee654211bd5534-842c4 From: "gu rong" To: Date: Tue, 23 Sep 2014 15:05:58 +0800 Message-ID: <010b01cfd6fc$d7d559e0$87800da0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/SZjx3v5KLOdiWQx2Vhaxb8gO4/wEleAEwAAAIOuA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/czTXgFlqEjuTb-v5iyrV5Hzgjl8 Subject: [sfc] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-liu-sfc-use-cases-08=2Etxt?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:06:08 -0000 Support! ------------------------------------------ Rong Gu China Mobile Research Institute No.32 Xuanwumen West Street, Xicheng District Beijing, China, 100053 Mobile: +86 13811520541 -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B49=E6=9C=8817=E6=97=A5 = 18:58 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qiong Sun; Jiafeng Zhu; Changcheng Huang; = Nicolai Leymann; Hongyu Li; Shucheng LIU (Will); Fu Qiao; Qiong Sun; = Peng He; Qiao Fu; Changcheng Huang; Mohamed Boucadair; Nicolai Leymann; = Oliver Huang; Mohamed Boucadair; Peng He; Chuong Pham; Jiafeng Zhu; Will = (Shucheng) Liu; Hongyu Li; Chuong Pham; Oliver Huang =E4=B8=BB=E9=A2=98: New Version Notification for = draft-liu-sfc-use-cases-08.txt A new version of I-D, draft-liu-sfc-use-cases-08.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Name: draft-liu-sfc-use-cases Revision: 08 Title: Service Function Chaining (SFC) General Use Cases Document date: 2014-09-17 Group: Individual Submission Pages: 19 URL: = http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-08.txt Status: = https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-08 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-08 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context and other deployment-specific considerations. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document presents a set of general use cases of Service Function Chaining (SFC). = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu Sep 25 00:48:14 2014 Return-Path: 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 3549E1A0298 for ; Thu, 25 Sep 2014 00:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 YFRxZK0RTp-A for ; Thu, 25 Sep 2014 00:48:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228721A0290 for ; Thu, 25 Sep 2014 00:48:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX25131; Thu, 25 Sep 2014 07:48:08 +0000 (GMT) Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Sep 2014 08:48:08 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.14]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Thu, 25 Sep 2014 15:47:56 +0800 From: Jiangyuanlong To: "huang@sce.carleton.ca" , "Liushucheng (Will)" , "sfc@ietf.org" Thread-Topic: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP0nU31h8n1/55XkavKeEvZlUNo5wRhO6g Date: Thu, 25 Sep 2014 07:47:56 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7E9D90@szxema506-mbs.china.huawei.com> References: <20140917105748.19743.47848.idtracker@ietfa.amsl.com> <009101cfd275$2257cde0$670769a0$@carleton.ca> In-Reply-To: <009101cfd275$2257cde0$670769a0$@carleton.ca> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Y-R8NIPLav7yRl2kJHjDgfMNruQ Cc: "draft-liu-sfc-use-cases@tools.ietf.org" Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 07:48:12 -0000 +1 Regards, Yuanlong -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang Sent: Wednesday, September 17, 2014 8:45 PM To: Liushucheng (Will); sfc@ietf.org Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.= txt I think the draft has significantly improved. Those who are against adoptin= g this draft should clearly state why they are against so that the authors = can further improve the draft. Otherwise they should be considered support = as the chairs have been doing for other drafts. Regards, Chang -----Original Message----- From: Liushucheng (Will) [mailto:liushucheng@huawei.com]=20 Sent: Wednesday, September 17, 2014 7:25 AM To: sfc@ietf.org Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: FW: New Version Notification for draft-liu-sfc-use-cases-08.txt Hi all, According to the minutes of last IETF meeting: Thomas Narten: There was a fair amount of support earlier to have one docu= ment. Now there are other use case drafts. It is up to the WG to decide how= to go forward. (?): Document is very comprehensive and useful for operators. Ken Gray: Agree with Thomas. With multiple documents its hard to find uniq= ue requirements across many. That is what I would like to see. (?): Good for WG adoption. Jim Guichard: How many have read the document? About 20. Thomas Narten: Should we have separate document? How many like to adopt vs= not adopt? No clear consensus in the room for adoption. Continue to discus= s on-list. =20 In last IETF meeting, there were around 20 persons who supported to adopt t= his draft. As suggested by Chairs, we updated our draft and wish to continu= e the discussion here to get more people support us. The main changes are: 1. Cut the problems listed in mobile use case 2. Addressed the comments from Dave Dolson about the bidirectional link. 3. Updated the reference. =20 Please let us know your thought, thanks! Regards, Will -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, September 17, 2014 6:58 PM To: Qiong Sun; Jiafeng Zhu; Changcheng Huang; Nicolai Leymann; Hongyu Li (J= ulio); Liushucheng (Will); Fu Qiao; Qiong Sun; Peng He; Qiao Fu; Changcheng= Huang; Mohamed Boucadair; Nicolai Leymann; Huangyong (Oliver); Mohamed Bou= cadair; Peng He; Chuong Pham; Jiafeng Zhu; Liushucheng (Will); Hongyu Li (J= ulio); Chuong Pham; Huangyong (Oliver) Subject: New Version Notification for draft-liu-sfc-use-cases-08.txt A new version of I-D, draft-liu-sfc-use-cases-08.txt has been successfully = submitted by Will(Shucheng) Liu and posted to the IETF repository. Name: draft-liu-sfc-use-cases Revision: 08 Title: Service Function Chaining (SFC) General Use Cases Document date: 2014-09-17 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases= -08.txt Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-08 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-= 08 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context and other deployment-specific considerations. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document presents a set of general use cases of Service Function Chaining (SFC). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Sep 25 10:25:38 2014 Return-Path: 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 775151A8731 for ; Thu, 25 Sep 2014 10:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 DM9_C3wNHrqb for ; Thu, 25 Sep 2014 10:25:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439671A00D2 for ; Thu, 25 Sep 2014 10:25:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJX81135; Thu, 25 Sep 2014 17:25:32 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Sep 2014 18:25:32 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Thu, 25 Sep 2014 10:25:25 -0700 From: Jiafeng Zhu To: "sfc@ietf.org" Thread-Topic: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP0nU31h8n1/55XkavKeEvZlUNo5wRhO6ggACfEKA= Date: Thu, 25 Sep 2014 17:25:25 +0000 Message-ID: <7585D84250391C4F93CA91360F2AF130CBFCE6@SJCEML701-CHM.china.huawei.com> References: <20140917105748.19743.47848.idtracker@ietfa.amsl.com> <009101cfd275$2257cde0$670769a0$@carleton.ca> <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7E9D90@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7E9D90@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.35.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bBg26-pMbAHYh10gz2PNmDz86oM Cc: "draft-liu-sfc-use-cases@tools.ietf.org" Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 17:25:36 -0000 If there is not a particular reason that states this draft can't be adopt b= y this group, let's move forward.=20 +1 Regards, Jiafeng =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang Sent: Wednesday, September 17, 2014 8:45 PM To: Liushucheng (Will); sfc@ietf.org Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: Re: [sfc] New Version Notification for draft-liu-sfc-use-cases-08.= txt I think the draft has significantly improved. Those who are against adoptin= g this draft should clearly state why they are against so that the authors = can further improve the draft. Otherwise they should be considered support = as the chairs have been doing for other drafts. Regards, Chang -----Original Message----- From: Liushucheng (Will) [mailto:liushucheng@huawei.com] Sent: Wednesday, September 17, 2014 7:25 AM To: sfc@ietf.org Cc: draft-liu-sfc-use-cases@tools.ietf.org Subject: FW: New Version Notification for draft-liu-sfc-use-cases-08.txt Hi all, According to the minutes of last IETF meeting: Thomas Narten: There was a fair amount of support earlier to have one docu= ment. Now there are other use case drafts. It is up to the WG to decide how= to go forward. (?): Document is very comprehensive and useful for operators. Ken Gray: Agree with Thomas. With multiple documents its hard to find uniq= ue requirements across many. That is what I would like to see. (?): Good for WG adoption. Jim Guichard: How many have read the document? About 20. Thomas Narten: Should we have separate document? How many like to adopt vs= not adopt? No clear consensus in the room for adoption. Continue to discus= s on-list. =20 In last IETF meeting, there were around 20 persons who supported to adopt t= his draft. As suggested by Chairs, we updated our draft and wish to continu= e the discussion here to get more people support us. The main changes are: 1. Cut the problems listed in mobile use case 2. Addressed the comments fro= m Dave Dolson about the bidirectional link. 3. Updated the reference. =20 Please let us know your thought, thanks! Regards, Will -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, September 17, 2014 6:58 PM To: Qiong Sun; Jiafeng Zhu; Changcheng Huang; Nicolai Leymann; Hongyu Li (J= ulio); Liushucheng (Will); Fu Qiao; Qiong Sun; Peng He; Qiao Fu; Changcheng= Huang; Mohamed Boucadair; Nicolai Leymann; Huangyong (Oliver); Mohamed Bou= cadair; Peng He; Chuong Pham; Jiafeng Zhu; Liushucheng (Will); Hongyu Li (J= ulio); Chuong Pham; Huangyong (Oliver) Subject: New Version Notification for draft-liu-sfc-use-cases-08.txt A new version of I-D, draft-liu-sfc-use-cases-08.txt has been successfully = submitted by Will(Shucheng) Liu and posted to the IETF repository. Name: draft-liu-sfc-use-cases Revision: 08 Title: Service Function Chaining (SFC) General Use Cases Document date: 2014-09-17 Group: Individual Submission Pages: 19 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases= -08.txt Status: https://datatracker.ietf.org/doc/draft-liu-sfc-use-cases/ Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-08 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-liu-sfc-use-cases-= 08 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context and other deployment-specific considerations. Having a single use case document eases the effort of deriving requirements that are to be met by SFC solution(s). Moreover, it allows to identify commonalities between the various use cases that are of interest. This document presents a set of general use cases of Service Function Chaining (SFC). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Sep 25 22:04:22 2014 Return-Path: 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 377DC1A1A0C for ; Thu, 25 Sep 2014 22:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 XnbV3PXWsgTy for ; Thu, 25 Sep 2014 22:04:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0555C1A1A02 for ; Thu, 25 Sep 2014 22:04:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJY15057; Fri, 26 Sep 2014 05:04:16 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Sep 2014 06:04:16 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Fri, 26 Sep 2014 13:04:07 +0800 From: Xuxiaohu To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-xu-sfc-using-mpls-spring-00.txt Thread-Index: AQHP2T4CC80+q51qwUWgk77ioSKUW5wS26rg Date: Fri, 26 Sep 2014 05:04:07 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082BBE08@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/vK9fefHgRjrcLoDqTv37WW3O2WA Subject: [sfc] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 05:04:20 -0000 SGkgYWxsLA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gbGV2ZXJhZ2UgdGhlIE1Q TFMtYmFzZWQgc291cmNlIHJvdXRpbmcgbWVjaGFuaXNtIGFzIGRldmVsb3BlZCBieSB0aGUgU1BS SU5HIFdHIHRvIHJlYWxpemUgdGhlIHNlcnZpY2UgcGF0aCBsYXllciBmdW5jdGlvbmFsaXR5IG9m IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLiBBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUu DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgMTE6NTcgQU0N Cj4gVG86IExpemhlbmJpbjsgTHVpcyBNLiBDb250cmVyYXM7IFh1eGlhb2h1OyBIaW1hbnNodSBD LiBTaGFoOyBYdXhpYW9odTsNCj4gSGltYW5zaHUgU2hhaDsgTHVpcyBNLiBDb250cmVyYXM7IExp emhlbmJpbg0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXh1 LXNmYy11c2luZy1tcGxzLXNwcmluZy0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLTAwLnR4dA0KPiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFhpYW9odSBYdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG IHJlcG9zaXRvcnkuDQo+IA0KPiBOYW1lOgkJZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5n DQo+IFJldmlzaW9uOgkwMA0KPiBUaXRsZToJCVNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgVXNp bmcgTVBMUy1TUFJJTkcNCj4gRG9jdW1lbnQgZGF0ZToJMjAxNC0wOS0yNQ0KPiBHcm91cDoJCUlu ZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczoJCTcNCj4gVVJMOg0KPiBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC14dS1zZmMtdXNpbmctbXBscy1zcHJpbmctMDAu dHh0DQo+IFN0YXR1czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt eHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLw0KPiBIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQteHUtc2ZjLXVzaW5nLW1wbHMtc3ByaW5nLTAwDQo+IA0KPiAN Cj4gQWJzdHJhY3Q6DQo+ICAgIFNvdXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIChT UFJJTkcpIFdHIHNwZWNpZmllcyBhIHNwZWNpYWwNCj4gICAgc291cmNlIHJvdXRpbmcgbWVjaGFu aXNtLiAgU3VjaCBzb3VyY2Ugcm91dGluZyBtZWNoYW5pc20gY2FuIGJlDQo+ICAgIGxldmVyYWdl ZCB0byByZWFsaXplIHRoZSBzZXJ2aWNlIHBhdGggbGF5ZXIgZnVuY3Rpb25hbGl0eSBvZiB0aGUN Cj4gICAgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyAoaS5lLCBzdGVlcmluZyB0cmFmZmljIHRo cm91Z2ggYSBwYXJ0aWN1bGFyDQo+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCkgYnkgZW5jb2Rp bmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBvciB0aGUNCj4gICAgc2VydmljZSBmdW5jdGlv biBjaGFpbiBpbmZvcm1hdGlvbiBhcyB0aGUgZXhwbGljaXQgcGF0aCBpbmZvcm1hdGlvbi4NCj4g ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIGxldmVyYWdlIHRoZSBNUExTLWJhc2Vk IHNvdXJjZSByb3V0aW5nDQo+ICAgIG1lY2hhbmlzbSBhcyBkZXZlbG9wZWQgYnkgdGhlIFNQUklO RyBXRyB0byByZWFsaXplIHRoZSBzZXJ2aWNlIHBhdGgNCj4gICAgbGF5ZXIgZnVuY3Rpb25hbGl0 eSBvZiB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4NCj4gDQo+IA0KPiANCj4gDQo+IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg==