From diego@tid.es Sun Dec 1 10:19:49 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFE11AE01E for ; Sun, 1 Dec 2013 10:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 M4iS2QNTF39H for ; Sun, 1 Dec 2013 10:19:01 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 22BA71AE019 for ; Sun, 1 Dec 2013 10:18:50 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MX500GYK47BA7@tid.hi.inet> for nsc@ietf.org; Sun, 01 Dec 2013 19:18:47 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 23.3C.02810.78D7B925; Sun, 01 Dec 2013 19:18:47 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MX500GYD47BA7@tid.hi.inet> for nsc@ietf.org; Sun, 01 Dec 2013 19:18:47 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.96]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Sun, 01 Dec 2013 19:18:47 +0100 Date: Sun, 01 Dec 2013 18:18:46 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Surendra Kumar (smkumar)" Message-id: Content-id: <67A02E45A5D14B41ADCAE4CE83E8994A@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [nsc] Node or not //RE: Charter text updated Thread-index: AQHO7sHGIY6XJM9E+EC9GoYLacyBew== X-AuditID: 0a5f4e69-b7f9b8e000000afa-5c-529b7d877bd9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1G2vnR1kcHW9rsXxffvZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceDAevaCd24VDadnsjcwtrh2MXJySAiYSMyac5wNwhaTuHBv PZDNxSEksI1R4l7TO3YI5xujxP+rx6GcDYwSXbf3g7WwCKhKbD9ygxXEZgOyHzX/ZgexhQWs JB5OXsYMYnMK6EtsOdPEBLFCQeLPuccsILaIgJHEzNVfwdYxC8xnlGi5MgeogYODV8BS4s7M DJAaZgEziem/boPN4RUQlPgx+R4LSAmzgLrElCm5ECXiEs2tN1kgbEWJaYsaGEFsRgFZiXfz 57NCrLKWuDd9HRuErSexc3cTI8Q5AhJL9pxnhrBFJV4+/gdWLwRUs+7MHvYJjBKzkFwxC8kV sxCumIXkillIrljAyLqKUaw4qSgzPaMkNzEzJ93ASC8jUy8zL7VkEyMk6jJ3MC7fqXKIUYCD UYmHN0N0ZpAQa2JZcWXuIUYJDmYlEV6Lr7OChHhTEiurUovy44tKc1KLDzEycXBKAX25X1vt 41R9kYPq/ktWLHJZtfSea92crdN+XZFmC248mjb542KL6IxS7vRes6eJDu+ycwUn9/3f03RV eYO0prdJU2eTiNfTtrW7zUtzrHZcrHsjqOwwPZ67MFp8+XyNI/4PXJIFFr+8PTN2Tdr8D669 CcbLaot0r3k+nbCI1+mbevcXToPnNUosxRmJhlrMRcWJAOr/qviYAgAA References: Cc: "nsc@ietf.org" , Thomas Nadeau , "Hongyu Li \(Julio\)" , Farrel Adrian Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@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, 01 Dec 2013 18:19:49 -0000 X-List-Received-Date: Sun, 01 Dec 2013 18:19:49 -0000 QWdyZWVkLiBJIHN1cHBvcnQga2VlcGluZyAibm9kZSIuDQoNCkJlIGdvb2RlLA0KDQpPbiAxIERl YyAyMDEzLCBhdCAwNDozMiAsIFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSB3cm90ZToNCg0KPiAr MSwgIm5vZGUiIG1ha2VzIHBlcmZlY3Qgc2Vuc2UuDQo+DQo+IFN1cmVuZHJhLg0KPg0KPiBPbiAx MS8zMC8xMyA2OjE4IEFNLCAiVGhvbWFzIE5hZGVhdSIgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29t PiB3cm90ZToNCj4NCj4+DQo+PiBPbiBOb3YgMzAsIDIwMTM6ODowNyBBTSwgYXQgODowNyBBTSwg QWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4NCj4+IHdyb3RlOg0KPj4NCj4+PiBJ IGRvbid0IGxpa2UgdG8gdXNlICJlbnRpdHkiIGJlY2F1c2UgaXQgaXMgY29tbW9ubHkgc2hvcnRo YW5kIGZvcg0KPj4+ICJOZXR3b3JrDQo+Pj4gRW50aXR5IChORSkiIHdoaWNoIGhhcyBhIGxvbmcg YXNzb2NpYXRpb24gd2l0aCBhIHBoeXNpY2FsIGJveC4NCj4+Pg0KPj4+ICJOb2RlIiAoZm9yIG1l KSBpcyBhIGNvbmNlcHQgb2YgZ3JhcGggdGhlb3J5IGVxdWF0aW5nIHRvICJ2ZXJ0ZXgiIGFuZA0K Pj4+IGlzIGENCj4+PiAicG9pbnQgb24gdGhlIGdyYXBoIi4gVGhhdCwgSSB0aGluaywgbWFucyB0 aGF0IGl0IGlzIHVuaXF1ZWx5DQo+Pj4gYWRkcmVzc2FibGUgYW5kDQo+Pj4gaWRlbnRpZmlhYmxl LCBidXQgbWF5IGJlIGxvZ2ljYWwgb3IgcGh5c2ljYWwgKGluZGVlZCwgd2hlbiB3ZSB3YW50IHRv DQo+Pj4gbWFrZSB0aGUNCj4+PiBkaXN0aW5jdGlvbiB3ZSBzYXkgImxvZ2ljYWwgbm9kZSIgb3Ig InBoeXNpY2FsIG5vZGUiKS4NCj4+DQo+PiAgICAgIEkgYWdyZWUuIEluIGZhY3QsIHdlIHJlZmlu ZWQgdGhhdCBhIGxpdHRsZSBtb3JlIGluIGRyYWZ0LXF1aW5uLXNmYy1hcmNoDQo+PiBieSB1c2lu ZyB0aGlzIGRlZmluaXRpb246DQo+Pg0KPj4gU2VydmljZSBOb2RlIChTTik6ICBQaHlzaWNhbCBv ciB2aXJ0dWFsIGVsZW1lbnQgdGhhdCBob3N0cyBvbmUgb3INCj4+ICAgICBtb3JlIHNlcnZpY2Ug ZnVuY3Rpb25zIGFuZCBoYXMgb25lIG9yIG1vcmUgbmV0d29yayBsb2NhdG9ycw0KPj4gICAgIGFz c29jaWF0ZWQgd2l0aCBpdCBmb3IgcmVhY2hhYmlsaXR5IGFuZCBzZXJ2aWNlIGRlbGl2ZXJ5Lg0K Pj4NCj4+ICAgICAgLS1Ub20NCj4+DQo+Pg0KPj4+DQo+Pj4gSG9uZ3l1LCBJIGFwcHJlY2lhdGUg eW91IGFza2luZyBxdWVzdGlvbnMgdG8gZmluZCBvdXQgd2hhdCBpcyBhbmQgaXMNCj4+PiBub3Qg aW4NCj4+PiBzY29wZSBmb3IgdGhpcyB0ZXh0LiBCdXQgc2luY2Ugd2UgYXJlIGhhdmluZyB0cm91 YmxlIHJlYWNoaW5nDQo+Pj4gY29udmVyZ2VuY2UsIEkNCj4+PiB3b25kZXIgd2hldGhlciB5b3Ug Y291bGQgbWFrZSBhIGNsZWFyIHN0YXRlbWVudCBvZiB3aGF0IGl0IGlzIHRoYXQgeW91DQo+Pj4g d2FudCB0bw0KPj4+IG1ha2Ugc3VyZSBpcyBpbiBzY29wZSBmb3IgdGhlIFdHLiBJZiB5b3UgY2Fu IHNheSAiSSB3YW50IHRoZSBXRyB0byBiZQ0KPj4+IGFibGUgdG8NCj4+PiB3b3JrIG9uLi4uIiB0 aGVuIHdlIGNhbiBwaWNrIGFuIGFwcHJvcHJpYXRlIGFuc3dlcjoNCj4+PiAtIEFoLCBubywgaXQg aXMgb3VyIGludGVudGlvbiB0aGF0IHRoYXQgaXMgb3V0IG9mIHNjb3BlDQo+Pj4gLSBZZXMsIGFu ZCB0aGF0IGlzIGFscmVhZHkgaW4gc2NvcGUNCj4+PiAtIE9oLCB3ZSBzZWUgd2hhdCB5b3UgbWVh biAtIGhlcmUgaXMgYSB0ZXh0IGNoYW5nZS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBBZHJpYW4N Cj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBTdGV3YXJ0 IEJyeWFudCAoc3RicnlhbnQpIFttYWlsdG86c3RicnlhbnRAY2lzY28uY29tXQ0KPj4+PiBTZW50 OiAzMCBOb3ZlbWJlciAyMDEzIDA4OjI3DQo+Pj4+IFRvOiBIb25neXUgTGkgKEp1bGlvKQ0KPj4+ PiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgbnNjQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6IFJl OiBbbnNjXSBOb2RlIG9yIG5vdCAvL1JFOiBDaGFydGVyIHRleHQgdXBkYXRlZA0KPj4+Pg0KPj4+ PiBXb3VsZCBlbnRpdGllcyBiZSBiZXR0ZXIgdGhhbiBub2Rlcz8NCj4+Pj4NCj4+Pj4gUw0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4gT24gMzAgTm92IDIwMTMsIGF0IDA4OjAzLCAiSG9uZ3l1IExp IChKdWxpbykiIDxob25neXUubGlAaHVhd2VpLmNvbT4NCj4+Pj4+IHdyb3RlOg0KPj4+Pj4NCj4+ Pj4+IEhpIGFsbCwNCj4+Pj4+DQo+Pj4+PiBJIGFtIHN0aWxsIHN0cnVnZ2xpbmcgd2l0aCB0aGUg d29yZCAibm9kZSIgaW4gdXBkYXRlZCBjaGFydGVyLg0KPj4+Pj4NCj4+Pj4+ICIgMy4gR2VuZXJp YyBTRkMgRW5jYXBzdWxhdGlvbjogVGhpcyBkb2N1bWVudCB3aWxsIGRlc2NyaWJlIGEgc2luZ2xl DQo+Pj4+PiBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgZm9y IGNvbnZleWluZyB0aGUNCj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGgsIGFuZCBmb3INCj4+Pj4+IGNvbW11bmljYXRpbmcgY29udGV4dCBp bmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQgaW1wbGVtZW50DQo+Pj4+PiBzZXJ2aWNlIGZ1 bmN0aW9ucyBhbmQgc2VydmljZSBmdW5jdGlvbiBjaGFpbnMuIg0KPj4+Pj4NCj4+Pj4+IEkgYW0g bm90IHN1cmUgd2hlcmUgYXJlICJub2RlcyB0aGF0IGltcGxlbWVudCIgaW4gYWJvdmUgdGVzdCBm aXR0aW5nDQo+Pj4+PiBpbnRvDQo+Pj4+IGZvbGxvd2luZyBjYXNlOg0KPj4+Pj4NCj4+Pj4+IFRo ZXJlIGFyZSBzZXZlcmFsIHZpcnR1YWwgU2VydmljZSBGdW5jdGlvbnMgcnVubmluZyBpbiBhIHNh bWUgc2VydmVyLA0KPj4+Pj4gYW5kDQo+Pj4gZWFjaA0KPj4+PiBTZXJ2aWNlIEZ1bmN0aW9uIGlz IHJ1bm5pbmcgaW4gYSBzdGFuZGFsb25lIFZpcnR1YWwgTWFjaGluZS4gVGhlc2UgU0ZzDQo+Pj4+ IGZvcm1zDQo+Pj4gYW4NCj4+Pj4gU0ZDIGluIHRoZSBzZXJ2ZXIuIFRoaXMgaXMgYSB0eXBpY2Fs IE5GViBjYXNlLCB3aGljaCBJIGJlbGlldmUgd2UNCj4+Pj4gYWdyZWVkIHRvDQo+Pj4gc3VwcG9y dA0KPj4+PiBhY2NvcmRpbmcgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24uIFNvLCB3aGVyZSBpcyB0 aGUgbm9kZSBmaXR0aW5nIGludG8/DQo+Pj4+IEVxdWFsDQo+Pj4gdG8gVk1zPw0KPj4+Pj4NCj4+ Pj4+IENoZWVycywNCj4+Pj4+IEhvbmd5dQ0KPj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBuc2MgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4+Pj4+IFNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJl ciAzMCwgMjAxMyAzOjE3IEFNDQo+Pj4+PiBUbzogbnNjQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0 OiBbbnNjXSBDaGFydGVyIHRleHQgdXBkYXRlZA0KPj4+Pj4NCj4+Pj4+IEhpLA0KPj4+Pj4NCj4+ Pj4+IEkndmUgYmVlbiByZWFkaW5nIHRocm91Z2ggdGhlIG1haWxpbmcgbGlzdCBhbmQgaGF2ZSBw b2xpc2hlZCB0aGUNCj4+Pj4+IGNoYXJ0ZXINCj4+PiB0ZXh0IGENCj4+Pj4gbGl0dGxlIGZ1cnRo ZXIuDQo+Pj4+Pg0KPj4+Pj4gSSBwaWNrZWQgdXAgS2V2aW4ncyBzdWdnZXN0aW9ucyBhcyBmb2xs b3dzOg0KPj4+Pj4NCj4+Pj4+IEFkZGVkIHRoZSB3b3JkICJmb3JtYXQiIGRlc2NyaWJpbmcgdGhl IGxheWVyIGluZGVwZW5kZW5jZSBvZiB0aGUNCj4+Pj4gZW5jYXBzdWxhdGlvbiBpbiBwb2ludCAz Lg0KPj4+Pj4NCj4+Pj4+IEluIHBvaW50IDMsIEkgZGlkIG5vdCBkZWxldGUuLi4NCj4+Pj4+ICJU aGF0IGlzLCB0aGUgc2FtZQ0KPj4+Pj4gZW5jYXBzdWxhdGlvbiBtYXkgYmUgdXNlZCBvbiBhIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUNCj4+Pj4+IG5ldHdvcmsgbGF5ZXIg b3IgYXQgYW55IG90aGVyIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3aWxsDQo+ Pj4+PiBhcHBseSBmb3IgdGhlIGNvbnN0cnVjdGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhz IHJlZ2FyZGxlc3Mgb2YNCj4+Pj4+IHRoZSBhY3R1YWwgc2VydmljZS4iDQo+Pj4+PiAuLi5idXQg SSBkaWQgaW5zZXJ0ICJmb3JtYXQiIGluIHRoYXQgdGV4dCBhcyB3ZWxsLg0KPj4+Pj4NCj4+Pj4+ IFN0aWxsIGluIHRoZSBzYW1lIHBvaW50IDMsIEkgdG9vayBKaW0ncyBzL3BhdGggcmVhbGl6ZWQv ZnVuY3Rpb24NCj4+Pj4+IGFwcGxpZWQvDQo+Pj4+Pg0KPj4+Pj4gSSBkaWQgbm90IG1ha2UgYW55 IGNoYW5nZSBhZnRlciBIb25neXUncyBkaXNjdXNzaW9uIG9mICJuZXR3b3JrDQo+Pj4+PiBub2Rl Ii4gSQ0KPj4+IGRvbid0DQo+Pj4+IHRoaW5rIHRoYXQgaXMgYSBzeW5vbnltIGZvciAiTmV0d29y ayBFbGVtZW50IChORSkiLCBidXQgZG9lcyByZXByZXNlbnQNCj4+Pj4gYW4NCj4+Pj4gYWRkcmVz c2FibGUgbm9kZSBvbiB0aGUgZ3JhcGguIEl0ICppcyogYW4gaW50ZXJlc3RpbmcgZGViYXRlIGFi b3V0DQo+Pj4+IHdoZXRoZXIgYQ0KPj4+PiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3Rh bmNlIGNhbiBtb3ZlIGFyb3VuZCwgYnV0IGlmIGl0IGNoYW5nZXMNCj4+Pj4gaWRlbnRpdHkNCj4+ PiBhbmQNCj4+Pj4gYWRkcmVzcyB3aGVuIGl0IGRvZXMgc28gdGhlbiBwZXJoYXBzIGl0IGlzIGhh cmQgdG8ga25vdyB3aGF0IHRvIGNhbGwNCj4+Pj4gaXQuIEJ1dCBJDQo+Pj4gZGlkDQo+Pj4+IHRh a2UgVGhvbWFzJ3MgcHJvcG9zYWwgZm9yIHRoYXQgcGFyYWdyYXBoIGFuZCByZXdvcmsgaXQgdG8g bGVhZCB0by4uDQo+Pj4+Pg0KPj4+Pj4gQW4gU0ZDIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIHNl bGVjdGlvbg0KPj4+Pj4gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgb24g c3BlY2lmaWMgbmV0d29yayBub2RlcyB0bw0KPj4+Pj4gZm9ybQ0KPj4+Pj4gYSBzZXJ2aWNlIGdy YXBoOiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKS4NCj4+Pj4+ DQo+Pj4+PiBUaGlzIGlzIHRoZSB2ZXJzaW9uIHRoYXQgd2lsbCBnbyB0byB0aGUgSUVTRyBvbiBU aHVyc2RheSA1dGguIFlvdSBjYW4NCj4+Pj4+IChvZg0KPj4+Pj4gY291cnNlKSBjb250aW51ZSB0 byBkaXNjdXNzIHRoZSB0ZXh0LCBidXQgaXQgZmVlbHMgbGlrZSB3ZSBhcmUgbm93DQo+Pj4+PiB0 d2Vha2luZw0KPj4+IHRoZQ0KPj4+PiB0d2Vha3MuDQo+Pj4+Pg0KPj4+Pj4gQ2hlZXJzLA0KPj4+ Pj4gQWRyaWFuDQo+Pj4+Pg0KPj4+Pj4gUFMuIElmIHlvdSBjb3VsZCBhbGwgdHJ5IHRvIHJlbWVt YmVyIHRvIGNoYW5nZSB0aGUgc3ViamVjdCBsaW5lIHdoZW4NCj4+Pj4+IHlvdXINCj4+Pj4gY29u dmVyc2F0aW9uIHdhbmRlcnMgb24gdG8gbmV3IHRvcGljcyBpdCB3b3VsZCBiZSBuaWNlLg0KPj4+ Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gbnNjIG1haWxpbmcgbGlz dA0KPj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4gbnNjQGlldGYub3JnDQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pg0KPj4NCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnNj IG1haWxpbmcgbGlzdA0KPiBuc2NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uc2MNCg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDog ICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv IG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0 cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rp c2NsYWltZXIuYXNweA0K From hongyu.li@huawei.com Sun Dec 1 17:39:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6081ADFD5 for ; Sun, 1 Dec 2013 17:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Lx7HwwXcPjmC for ; Sun, 1 Dec 2013 17:39:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B74271ADF60 for ; Sun, 1 Dec 2013 17:39:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYN10971; Mon, 02 Dec 2013 01:39:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 01:38:48 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 01:39:28 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.131]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 09:39:22 +0800 From: "Hongyu Li (Julio)" To: "adrian@olddog.co.uk" Thread-Topic: [nsc] Node or not //RE: Charter text updated Thread-Index: AQHO7aXlJMJ77Rr8z06nGH+RiaCGNpo9OL0AgALphCA= Date: Mon, 2 Dec 2013 01:39:21 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9A326D@SZXEMA509-MBX.china.huawei.com> References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk>, <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> In-Reply-To: <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@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, 02 Dec 2013 01:39:36 -0000 SGkgQWRyaWFuLA0KDQpUaGUgY2FzZSBJIGV4cGVjdCB0aGUgY2hhcnRlciB0byBjb3ZlciBpcyB0 aGUgZXhhbXBsZSBJIG1hZGUgaW4gdGhlIGZpcnN0IGVtYWlsIG9mIHRoaXMgdGhyZWFkLiBOb3cg dGhhdCBub2RlIGNhbiBiZSBpbnRlcnByZXRlZCBhcyBsb2dpY2FsIG9uZXMsIEkgYW0gT0sgd2l0 aCBjdXJyZW50IHRleHQuDQoNClRoYW5rcywNCkhvbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogQWRyaWFuIEZhcnJlbCBbbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWtd IA0KU2VudDogU2F0dXJkYXksIE5vdmVtYmVyIDMwLCAyMDEzIDk6MDcgUE0NClRvOiBIb25neXUg TGkgKEp1bGlvKQ0KQ2M6IG5zY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtuc2NdIE5vZGUgb3Ig bm90IC8vUkU6IENoYXJ0ZXIgdGV4dCB1cGRhdGVkDQoNCkkgZG9uJ3QgbGlrZSB0byB1c2UgImVu dGl0eSIgYmVjYXVzZSBpdCBpcyBjb21tb25seSBzaG9ydGhhbmQgZm9yICJOZXR3b3JrIEVudGl0 eSAoTkUpIiB3aGljaCBoYXMgYSBsb25nIGFzc29jaWF0aW9uIHdpdGggYSBwaHlzaWNhbCBib3gu DQoNCiJOb2RlIiAoZm9yIG1lKSBpcyBhIGNvbmNlcHQgb2YgZ3JhcGggdGhlb3J5IGVxdWF0aW5n IHRvICJ2ZXJ0ZXgiIGFuZCBpcyBhICJwb2ludCBvbiB0aGUgZ3JhcGgiLiBUaGF0LCBJIHRoaW5r LCBtYW5zIHRoYXQgaXQgaXMgdW5pcXVlbHkgYWRkcmVzc2FibGUgYW5kIGlkZW50aWZpYWJsZSwg YnV0IG1heSBiZSBsb2dpY2FsIG9yIHBoeXNpY2FsIChpbmRlZWQsIHdoZW4gd2Ugd2FudCB0byBt YWtlIHRoZSBkaXN0aW5jdGlvbiB3ZSBzYXkgImxvZ2ljYWwgbm9kZSIgb3IgInBoeXNpY2FsIG5v ZGUiKS4NCg0KSG9uZ3l1LCBJIGFwcHJlY2lhdGUgeW91IGFza2luZyBxdWVzdGlvbnMgdG8gZmlu ZCBvdXQgd2hhdCBpcyBhbmQgaXMgbm90IGluIHNjb3BlIGZvciB0aGlzIHRleHQuIEJ1dCBzaW5j ZSB3ZSBhcmUgaGF2aW5nIHRyb3VibGUgcmVhY2hpbmcgY29udmVyZ2VuY2UsIEkgd29uZGVyIHdo ZXRoZXIgeW91IGNvdWxkIG1ha2UgYSBjbGVhciBzdGF0ZW1lbnQgb2Ygd2hhdCBpdCBpcyB0aGF0 IHlvdSB3YW50IHRvIG1ha2Ugc3VyZSBpcyBpbiBzY29wZSBmb3IgdGhlIFdHLiBJZiB5b3UgY2Fu IHNheSAiSSB3YW50IHRoZSBXRyB0byBiZSBhYmxlIHRvIHdvcmsgb24uLi4iIHRoZW4gd2UgY2Fu IHBpY2sgYW4gYXBwcm9wcmlhdGUgYW5zd2VyOg0KLSBBaCwgbm8sIGl0IGlzIG91ciBpbnRlbnRp b24gdGhhdCB0aGF0IGlzIG91dCBvZiBzY29wZQ0KLSBZZXMsIGFuZCB0aGF0IGlzIGFscmVhZHkg aW4gc2NvcGUNCi0gT2gsIHdlIHNlZSB3aGF0IHlvdSBtZWFuIC0gaGVyZSBpcyBhIHRleHQgY2hh bmdlLg0KDQpUaGFua3MsDQpBZHJpYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBTdGV3YXJ0IEJyeWFudCAoc3RicnlhbnQpIFttYWlsdG86c3RicnlhbnRAY2lzY28u Y29tXQ0KPiBTZW50OiAzMCBOb3ZlbWJlciAyMDEzIDA4OjI3DQo+IFRvOiBIb25neXUgTGkgKEp1 bGlvKQ0KPiBDYzogYWRyaWFuQG9sZGRvZy5jby51azsgbnNjQGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbnNjXSBOb2RlIG9yIG5vdCAvL1JFOiBDaGFydGVyIHRleHQgdXBkYXRlZA0KPiANCj4g V291bGQgZW50aXRpZXMgYmUgYmV0dGVyIHRoYW4gbm9kZXM/DQo+IA0KPiBTDQo+IA0KPiANCj4g DQo+ID4gT24gMzAgTm92IDIwMTMsIGF0IDA4OjAzLCAiSG9uZ3l1IExpIChKdWxpbykiIDxob25n eXUubGlAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBJIGFt IHN0aWxsIHN0cnVnZ2xpbmcgd2l0aCB0aGUgd29yZCAibm9kZSIgaW4gdXBkYXRlZCBjaGFydGVy Lg0KPiA+DQo+ID4gIiAzLiBHZW5lcmljIFNGQyBFbmNhcHN1bGF0aW9uOiBUaGlzIGRvY3VtZW50 IHdpbGwgZGVzY3JpYmUgYSBzaW5nbGUNCj4gPiAgIHNlcnZpY2UtbGV2ZWwgZGF0YSBwbGFuZSBl bmNhcHN1bGF0aW9uIGZvcm1hdCBmb3IgY29udmV5aW5nIHRoZQ0KPiA+ICAgc2VydmljZSBmdW5j dGlvbiBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCwgYW5kIGZvcg0KPiA+ICAg Y29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gbm9kZXMgdGhhdCBpbXBs ZW1lbnQNCj4gPiAgIHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu cy4iDQo+ID4NCj4gPiBJIGFtIG5vdCBzdXJlIHdoZXJlIGFyZSAibm9kZXMgdGhhdCBpbXBsZW1l bnQiIGluIGFib3ZlIHRlc3QgZml0dGluZyANCj4gPiBpbnRvDQo+IGZvbGxvd2luZyBjYXNlOg0K PiA+DQo+ID4gVGhlcmUgYXJlIHNldmVyYWwgdmlydHVhbCBTZXJ2aWNlIEZ1bmN0aW9ucyBydW5u aW5nIGluIGEgc2FtZSANCj4gPiBzZXJ2ZXIsIGFuZA0KZWFjaA0KPiBTZXJ2aWNlIEZ1bmN0aW9u IGlzIHJ1bm5pbmcgaW4gYSBzdGFuZGFsb25lIFZpcnR1YWwgTWFjaGluZS4gVGhlc2UgU0ZzIA0K PiBmb3Jtcw0KYW4NCj4gU0ZDIGluIHRoZSBzZXJ2ZXIuIFRoaXMgaXMgYSB0eXBpY2FsIE5GViBj YXNlLCB3aGljaCBJIGJlbGlldmUgd2UgDQo+IGFncmVlZCB0bw0Kc3VwcG9ydA0KPiBhY2NvcmRp bmcgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24uIFNvLCB3aGVyZSBpcyB0aGUgbm9kZSBmaXR0aW5n IGludG8/IA0KPiBFcXVhbA0KdG8gVk1zPw0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+IEhvbmd5dQ0K PiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBuc2MgW21haWx0 bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkcmlhbiBGYXJyZWwNCj4gPiBT ZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMzAsIDIwMTMgMzoxNyBBTQ0KPiA+IFRvOiBuc2NAaWV0 Zi5vcmcNCj4gPiBTdWJqZWN0OiBbbnNjXSBDaGFydGVyIHRleHQgdXBkYXRlZA0KPiA+DQo+ID4g SGksDQo+ID4NCj4gPiBJJ3ZlIGJlZW4gcmVhZGluZyB0aHJvdWdoIHRoZSBtYWlsaW5nIGxpc3Qg YW5kIGhhdmUgcG9saXNoZWQgdGhlIA0KPiA+IGNoYXJ0ZXINCnRleHQgYQ0KPiBsaXR0bGUgZnVy dGhlci4NCj4gPg0KPiA+IEkgcGlja2VkIHVwIEtldmluJ3Mgc3VnZ2VzdGlvbnMgYXMgZm9sbG93 czoNCj4gPg0KPiA+IEFkZGVkIHRoZSB3b3JkICJmb3JtYXQiIGRlc2NyaWJpbmcgdGhlIGxheWVy IGluZGVwZW5kZW5jZSBvZiB0aGUNCj4gZW5jYXBzdWxhdGlvbiBpbiBwb2ludCAzLg0KPiA+DQo+ ID4gSW4gcG9pbnQgMywgSSBkaWQgbm90IGRlbGV0ZS4uLg0KPiA+ICAiVGhhdCBpcywgdGhlIHNh bWUNCj4gPiAgIGVuY2Fwc3VsYXRpb24gbWF5IGJlIHVzZWQgb24gYSBzZXJ2aWNlIGZ1bmN0aW9u IHBhdGggcmVhbGl6ZWQgYXQgdGhlDQo+ID4gICBuZXR3b3JrIGxheWVyIG9yIGF0IGFueSBvdGhl ciBsYXllciwgYW5kIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2lsbA0KPiA+ICAgYXBwbHkgZm9y IHRoZSBjb25zdHJ1Y3Rpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9m DQo+ID4gICB0aGUgYWN0dWFsIHNlcnZpY2UuIg0KPiA+IC4uLmJ1dCBJIGRpZCBpbnNlcnQgImZv cm1hdCIgaW4gdGhhdCB0ZXh0IGFzIHdlbGwuDQo+ID4NCj4gPiBTdGlsbCBpbiB0aGUgc2FtZSBw b2ludCAzLCBJIHRvb2sgSmltJ3Mgcy9wYXRoIHJlYWxpemVkL2Z1bmN0aW9uIA0KPiA+IGFwcGxp ZWQvDQo+ID4NCj4gPiBJIGRpZCBub3QgbWFrZSBhbnkgY2hhbmdlIGFmdGVyIEhvbmd5dSdzIGRp c2N1c3Npb24gb2YgIm5ldHdvcmsgDQo+ID4gbm9kZSIuIEkNCmRvbid0DQo+IHRoaW5rIHRoYXQg aXMgYSBzeW5vbnltIGZvciAiTmV0d29yayBFbGVtZW50IChORSkiLCBidXQgZG9lcyByZXByZXNl bnQgDQo+IGFuIGFkZHJlc3NhYmxlIG5vZGUgb24gdGhlIGdyYXBoLiBJdCAqaXMqIGFuIGludGVy ZXN0aW5nIGRlYmF0ZSBhYm91dCANCj4gd2hldGhlciBhIHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rp b24gaW5zdGFuY2UgY2FuIG1vdmUgYXJvdW5kLCBidXQgaWYgDQo+IGl0IGNoYW5nZXMgaWRlbnRp dHkNCmFuZA0KPiBhZGRyZXNzIHdoZW4gaXQgZG9lcyBzbyB0aGVuIHBlcmhhcHMgaXQgaXMgaGFy ZCB0byBrbm93IHdoYXQgdG8gY2FsbCANCj4gaXQuIEJ1dCBJDQpkaWQNCj4gdGFrZSBUaG9tYXMn cyBwcm9wb3NhbCBmb3IgdGhhdCBwYXJhZ3JhcGggYW5kIHJld29yayBpdCB0byBsZWFkIHRvLi4N Cj4gPg0KPiA+ICAgQW4gU0ZDIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIHNlbGVjdGlvbg0KPiA+ ICAgb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgb24gc3BlY2lmaWMgbmV0 d29yayBub2RlcyB0byBmb3JtDQo+ID4gICBhIHNlcnZpY2UgZ3JhcGg6IHRoaXMgaXMgY2FsbGVk IGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApLg0KPiA+DQo+ID4gVGhpcyBpcyB0aGUgdmVy c2lvbiB0aGF0IHdpbGwgZ28gdG8gdGhlIElFU0cgb24gVGh1cnNkYXkgNXRoLiBZb3UgDQo+ID4g Y2FuIChvZg0KPiA+IGNvdXJzZSkgY29udGludWUgdG8gZGlzY3VzcyB0aGUgdGV4dCwgYnV0IGl0 IGZlZWxzIGxpa2Ugd2UgYXJlIG5vdyANCj4gPiB0d2Vha2luZw0KdGhlDQo+IHR3ZWFrcy4NCj4g Pg0KPiA+IENoZWVycywNCj4gPiBBZHJpYW4NCj4gPg0KPiA+IFBTLiBJZiB5b3UgY291bGQgYWxs IHRyeSB0byByZW1lbWJlciB0byBjaGFuZ2UgdGhlIHN1YmplY3QgbGluZSB3aGVuIA0KPiA+IHlv dXINCj4gY29udmVyc2F0aW9uIHdhbmRlcnMgb24gdG8gbmV3IHRvcGljcyBpdCB3b3VsZCBiZSBu aWNlLg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+ID4gbnNjQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5zYyBtYWlsaW5nIGxpc3QNCj4g PiBuc2NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25zYw0KDQo= From adrian@olddog.co.uk Mon Dec 2 04:21:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C620B1AE45C for ; Mon, 2 Dec 2013 04:21:02 -0800 (PST) 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 fKz2Bqe5feRZ for ; Mon, 2 Dec 2013 04:21:01 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id AD07F1AE45B for ; Mon, 2 Dec 2013 04:21:00 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2CKvWL009608; Mon, 2 Dec 2013 12:20:57 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2CKtXZ009598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Dec 2013 12:20:56 GMT From: "Adrian Farrel" To: Date: Mon, 2 Dec 2013 12:20:54 -0000 Message-ID: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQ== Content-Language: en-gb Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 12:21:03 -0000 Hi, During IESG review Ted and I had a bit of an exchange about the meaning of "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and suggests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity, > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > > Service delivery is currently both a technical and an organizational > challenge that involves significant modification to the network > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of > service functions that are deployed at different points within a > network. > > Today, a common deployment model has service functions inserted on > the data-forwarding path between communicating peers. Going forward, > however, there is a desire to move to a different model, where > service functions, whether physical or virtualized, are not required > to reside on the direct data path and traffic is instead steered > through service functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), and we should not assume that it is immutable. I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian From Ron_Parker@affirmednetworks.com Mon Dec 2 07:03:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029941AE0D1 for ; Mon, 2 Dec 2013 07:03:19 -0800 (PST) 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 IQ4lCpE7q37P for ; Mon, 2 Dec 2013 07:03:17 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1017D1AE078 for ; Mon, 2 Dec 2013 07:03:16 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 07:03:14 -0800 From: Ron Parker To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwg Date: Mon, 2 Dec 2013 15:03:13 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 15:03:19 -0000 Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity, =20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on =20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity, =20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the =20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational =20 > challenge that involves significant modification to the network =20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of =20 > service functions that are deployed at different points within a =20 > network. >=20 > Today, a common deployment model has service functions inserted on =20 > the data-forwarding path between communicating peers. Going forward, =20 > however, there is a desire to move to a different model, where =20 > service functions, whether physical or virtualized, are not required =20 > to reside on the direct data path and traffic is instead steered =20 > through service functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Mon Dec 2 08:34:41 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB8511AC82B for ; Mon, 2 Dec 2013 08:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pk3OgL5gG_nm for ; Mon, 2 Dec 2013 08:34:39 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 373F71AC499 for ; Mon, 2 Dec 2013 08:34:39 -0800 (PST) Received: from mail193-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.22; Mon, 2 Dec 2013 16:34:36 +0000 Received: from mail193-co9 (localhost [127.0.0.1]) by mail193-co9-R.bigfish.com (Postfix) with ESMTP id 88D3042057A; Mon, 2 Dec 2013 16:34:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail193-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(13464003)(51704005)(199002)(189002)(85306002)(19580405001)(77982001)(59766001)(49866001)(56776001)(54316002)(81342001)(47736001)(74706001)(2656002)(19580395003)(4396001)(85852002)(81542001)(33646001)(76576001)(76786001)(87266001)(47976001)(65816001)(50986001)(83322001)(87936001)(80022001)(69226001)(31966008)(46102001)(79102001)(54356001)(83072001)(74366001)(74316001)(63696002)(53806001)(15975445006)(76796001)(51856001)(74662001)(81686001)(76482001)(74876001)(74502001)(81816001)(66066001)(47446002)(80976001)(551934002)(56816005)(90146001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB716; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail193-co9 (localhost.localdomain [127.0.0.1]) by mail193-co9 (MessageSwitch) id 1386002073964340_939; Mon, 2 Dec 2013 16:34:33 +0000 (UTC) Received: from CO9EHSMHS006.bigfish.com (unknown [10.236.132.233]) by mail193-co9.bigfish.com (Postfix) with ESMTP id DD48420003F; Mon, 2 Dec 2013 16:34:33 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS006.bigfish.com (10.236.130.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 2 Dec 2013 16:34:33 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 2 Dec 2013 16:34:32 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 2 Dec 2013 16:34:30 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0820.005; Mon, 2 Dec 2013 16:34:30 +0000 From: Jerome Moisand To: Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFA= Date: Mon, 2 Dec 2013 16:34:30 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 0048BCF4DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 16:34:42 -0000 Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Dec 2 09:52:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B51D1A8032 for ; Mon, 2 Dec 2013 09:52:50 -0800 (PST) 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 9cnQvNLuImmQ for ; Mon, 2 Dec 2013 09:52:48 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2511A802A for ; Mon, 2 Dec 2013 09:52:47 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 09:52:45 -0800 From: Ron Parker To: Jerome Moisand , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYA== Date: Mon, 2 Dec 2013 17:52:44 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 17:52:50 -0000 Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Mon Dec 2 09:58:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557E71A8032 for ; Mon, 2 Dec 2013 09:58:05 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 LC72EdBvYHpi for ; Mon, 2 Dec 2013 09:58:03 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 919521A1DBD for ; Mon, 2 Dec 2013 09:58:02 -0800 (PST) Received: from mail120-db9-R.bigfish.com (10.174.16.241) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Mon, 2 Dec 2013 17:57:59 +0000 Received: from mail120-db9 (localhost [127.0.0.1]) by mail120-db9-R.bigfish.com (Postfix) with ESMTP id 966FC400105; Mon, 2 Dec 2013 17:57:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail120-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(377454003)(76796001)(74876001)(53806001)(551934002)(69226001)(74662001)(54356001)(46102001)(80022001)(31966008)(79102001)(83072001)(51856001)(74316001)(74366001)(76482001)(74502001)(56816005)(90146001)(81816001)(66066001)(80976001)(15975445006)(81686001)(47736001)(49866001)(56776001)(54316002)(81342001)(85306002)(65816001)(81542001)(63696002)(87936001)(77982001)(47976001)(19580405001)(76576001)(33646001)(59766001)(47446002)(83322001)(87266001)(74706001)(19580395003)(50986001)(76786001)(2656002)(4396001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail120-db9 (localhost.localdomain [127.0.0.1]) by mail120-db9 (MessageSwitch) id 1386007078313621_7727; Mon, 2 Dec 2013 17:57:58 +0000 (UTC) Received: from DB9EHSMHS030.bigfish.com (unknown [10.174.16.240]) by mail120-db9.bigfish.com (Postfix) with ESMTP id 468FF1800EA; Mon, 2 Dec 2013 17:57:58 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS030.bigfish.com (10.174.14.40) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 2 Dec 2013 17:57:57 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 2 Dec 2013 17:57:56 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 2 Dec 2013 17:57:54 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0820.005; Mon, 2 Dec 2013 17:57:54 +0000 From: Jerome Moisand To: Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9Q Date: Mon, 2 Dec 2013 17:57:53 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 0048BCF4DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 17:58:05 -0000 Well, the PGW (or a BNG for wireline) is the starting point of the chain. I= t acts as both Service Classifier and Service Policy Enforcement Point (som= etimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function.= Would you agree? (anyhoo, my point was mostly to avoid the middlebox terminology! Even if I = know what you mean!) -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, December 02, 2013 12:53 PM To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Mon Dec 2 10:10:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD63F1AD73F for ; Mon, 2 Dec 2013 10:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 i_3ko99_Xs59 for ; Mon, 2 Dec 2013 10:09:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E50EA1AD8DC for ; Mon, 2 Dec 2013 10:09:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYN93991; Mon, 02 Dec 2013 18:09:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 18:09:11 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 18:09:53 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:09:47 -0800 From: Linda Dunbar To: Jerome Moisand , Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoA= Date: Mon, 2 Dec 2013 18:09:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 18:10:04 -0000 Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service Policy = Enforcement Point.=20 Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions".=20 Linda=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Well, the PGW (or a BNG for wireline) is the starting point of the > chain. It acts as both Service Classifier and Service Policy > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is > squarely a Service Function. Would you agree? >=20 > (anyhoo, my point was mostly to avoid the middlebox terminology! Even > if I know what you mean!) >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Hi, Jerome. >=20 > I agree with your definitions of service vs. service function. >=20 > Regarding functions like PGW, in the upstream direction for user > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment > model. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Issue#1: I think we have to be careful to not use the word 'service' to > speak of a given network function. >=20 > Personally, I always use the word 'service' as something perceived by > the end user/customer. Something that you subscribe to, something that > you benefit from, something that you may be billed for, something that > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many > network functions and related systems, without the end user knowing. >=20 > So a firewall or a spam-filtering proxy is NOT a Service. It's... a > Service Function! Meaning a network function that directly helps in > providing service-related processing and service (profile) > differentiation. It's just a component though, not the entire Service > as perceived by the end user. >=20 > And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), > as this term has a connotation that would seem to exclude some forms of > Service Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', > and yet, they are *the* primary Service Function in today's broadband > networks). >=20 > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use > traffic via a constrained path, and well, the service function does > remain on the data path (granted, the data path changed from a > 'shortest path routed' to a more constrained path, but it's still a > data path!). >=20 > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is actually > fine, if not better (even if the last sentence 'direct data path' > terminology isn't that great either). It also seems to me that we've > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing > paragraph and say: >=20 > << Going forward, however, there is a desire to move to a different > model, where traffic can be steered through service functions (physical > or virtualized), wherever they are deployed.>> >=20 > And then, during the actual work, for sure, we'll need to settle on > clear definitions for 'Service', 'Service Function', etc. >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Adrian, >=20 > I think Ted's text is a very nice summary of what we are trying to > accomplish. >=20 > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly > addressed service functions (i.e., SFC applies to a transparent HTTP > proxy, but not to an explicit HTTP proxy). >=20 > > Network service providers, in addition to delivering IP connectivity, > > frequently provide in-path services such as firewall filtering, load > > balancing and transactional proxies such as spam filters. >=20 > Could become: >=20 > "Network service providers, in addition to delivering IP connectivity, > frequently provide transparent services such as firewall filtering, > load balancing and transactional proxies such as spam filters." >=20 > We may want to strike or replace load balancing as that may not be an > actual transparent service but rather a building block for some actual > transport service -- open to suggestions on this verbage. >=20 >=20 > > Today, a common deployment model has service functions inserted on > > the data-forwarding path between communicating peers. >=20 > Could become: >=20 > "Today, a common deployment model is to insert various mid-boxes on the > data-forwarding path between communicating peers." >=20 >=20 >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text >=20 > Hi, >=20 > During IESG review Ted and I had a bit of an exchange about the meaning > of "a service" and the "layer at which a service chain can be applied". >=20 > Ted was looking for some text to clarify this in the in the charter and > suggests replacing the entire first paragraph with... >=20 > > Network service providers, in addition to delivering IP connectivity, > > frequently provide in-path services such as firewall filtering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with the > > introduction of virtualization, network overlays, and orchestration. > > > > Service delivery is currently both a technical and an organizational > > challenge that involves significant modification to the network > > configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of > > service functions that are deployed at different points within a > > network. > > > > Today, a common deployment model has service functions inserted on > > the data-forwarding path between communicating peers. Going forward, > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. >=20 > This is only a strawman from Ted (and thanks to him for proposing text), > and we should not assume that it is immutable. >=20 > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? >=20 > Opinions please. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Dec 2 10:18:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25B31ADE72 for ; Mon, 2 Dec 2013 10:18:43 -0800 (PST) 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 RwHDCC6We9JO for ; Mon, 2 Dec 2013 10:18:41 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDEE1ADE71 for ; Mon, 2 Dec 2013 10:18:41 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:18:39 -0800 From: Ron Parker To: Jerome Moisand , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAACooFA= Date: Mon, 2 Dec 2013 18:18:38 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 18:18:43 -0000 Jerome, The PGW could be decomposed further for fitting it into an SFC context. T= he call control portion is explicitly addressed and is therefore not subjec= t to SFC controls. The PCEF functions, however, operate in the user plane= and are transparent to the original communications endpoints and therefore= are subject to SFC controls.=20 Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Monday, December 02, 2013 12:58 PM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Well, the PGW (or a BNG for wireline) is the starting point of the chain. I= t acts as both Service Classifier and Service Policy Enforcement Point (som= etimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function.= Would you agree? (anyhoo, my point was mostly to avoid the middlebox terminology! Even if I = know what you mean!) -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, December 02, 2013 12:53 PM To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From robmgl@cisco.com Mon Dec 2 11:08:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E981ADE72 for ; Mon, 2 Dec 2013 11:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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=-0.001, 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 x3bHwvCjPsd8 for ; Mon, 2 Dec 2013 11:08:26 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BB0821ADBCF for ; Mon, 2 Dec 2013 11:08:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9721; q=dns/txt; s=iport; t=1386011304; x=1387220904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GhHUm+pS6QCvaj0Zw6+c9ZOTsepu0KBf7i2ieeI/qm4=; b=Gdnnyjgv6JQ4+x8nrDJgi/IReW40bTVX7NcwaB22z+skQxGgUBT5hf5E CjHlFC/wX+Y1E9YaRtwL19kYsj6RaaLx09tyMdTQuvZsOW12HkN4xRgMn KO2J7DNaiLMQio1TyFz0pCeHMhVNCJO343S2zEX45qhBRArMl3gYF3Vrf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFnanFKtJV2Y/2dsb2JhbABZgwc4U7hngSUWdIIlAQEBAwEBAQE3NAsFBwQCAQgOAwQBAQsCEgkHJwsUCQgBAQQBDQUIh3MGDb92EwSOPxgxBwaDGoETA6ongymBaUE X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208";a="288801670" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 02 Dec 2013 19:08:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB2J8IVP000385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 19:08:18 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 13:08:17 -0600 From: "Roberta Maglione (robmgl)" To: Jerome Moisand , Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAAEY0qA= Date: Mon, 2 Dec 2013 19:08:17 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.8.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 02 Dec 2013 19:08:28 -0000 > Issue#1: I think we have to be careful to not use the word 'service' to s= peak of a given network function. > Personally, I always use the word 'service' as something perceived by the= end user/customer I agree with you on this point and I think this is in-line with the definit= ion of service currently present in draft-quinn-sfc-arch: "Service: An offering provided by an operator that is delivered using one = or more service functions. This may also be referred to as a composite service." >Well, the PGW (or a BNG for wireline) is the starting point of the chain. = It acts as both Service Classifier and Service Policy >Enforcement Point (s= ometimes at L3, sometimes at L4/L7). Hence it is squarely a Service Functio= n. Would you agree? Regarding your comment on BNG in my opinion according to the definitions of= "service function" and "service node" in draft-quinn-sfc-arch the BNG is a= Service Node not a Service Function.=20 Quoting the definitions from draft-quinn-sfc-arch: " Service Function (SF): A network or application based packet treatment, application, compute or storage resource, used singularly or in concert with other service functions within a service chain to enable a service offered by an operator Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery." Any comments? Thanks Roberta -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand Sent: Monday, December 02, 2013 12:58 PM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Well, the PGW (or a BNG for wireline) is the starting point of the chain. I= t acts as both Service Classifier and Service Policy Enforcement Point (som= etimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function.= Would you agree? (anyhoo, my point was mostly to avoid the middlebox terminology! Even if I = know what you mean!) -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, December 02, 2013 12:53 PM To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Mon Dec 2 11:31:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E81AD8F3 for ; Mon, 2 Dec 2013 11:31:40 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 I59wIsUSFWI9 for ; Mon, 2 Dec 2013 11:31:35 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9F41ADEC0 for ; Mon, 2 Dec 2013 11:31:35 -0800 (PST) Received: from mail113-db9-R.bigfish.com (10.174.16.243) by DB9EHSOBE029.bigfish.com (10.174.14.92) with Microsoft SMTP Server id 14.1.225.22; Mon, 2 Dec 2013 19:31:32 +0000 Received: from mail113-db9 (localhost [127.0.0.1]) by mail113-db9-R.bigfish.com (Postfix) with ESMTP id 5F4821403B2; Mon, 2 Dec 2013 19:31:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(z579ehz9371I542I1432Id799hdf9Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail113-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(35774003)(377454003)(76796001)(74876001)(53806001)(551934002)(69226001)(74662001)(54356001)(46102001)(80022001)(31966008)(79102001)(83072001)(51856001)(74316001)(74366001)(76482001)(74502001)(56816005)(90146001)(81816001)(66066001)(80976001)(15975445006)(81686001)(47736001)(49866001)(56776001)(54316002)(81342001)(85306002)(65816001)(81542001)(63696002)(87936001)(77982001)(47976001)(19580405001)(76576001)(33646001)(59766001)(47446002)(83322001)(87266001)(74706001)(19580395003)(50986001)(76786001)(2656002)(4396001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail113-db9 (localhost.localdomain [127.0.0.1]) by mail113-db9 (MessageSwitch) id 138601269170402_20320; Mon, 2 Dec 2013 19:31:31 +0000 (UTC) Received: from DB9EHSMHS009.bigfish.com (unknown [10.174.16.231]) by mail113-db9.bigfish.com (Postfix) with ESMTP id 00EE44C00DC; Mon, 2 Dec 2013 19:31:31 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS009.bigfish.com (10.174.14.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 2 Dec 2013 19:31:29 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Mon, 2 Dec 2013 19:31:29 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.820.5; Mon, 2 Dec 2013 19:31:27 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0820.005; Mon, 2 Dec 2013 19:31:27 +0000 From: Jerome Moisand To: "Roberta Maglione (robmgl)" , Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function Thread-Index: AQHO75UXxZ+bKK8bLU6mQFFpw7n2og== Date: Mon, 2 Dec 2013 19:31:26 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 0048BCF4DA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 02 Dec 2013 19:31:40 -0000 Hi Roberta, Yes, you're right, this is a better way to put it. A BNG includes a Service= Function (or several), but is actually a full Service Node. Same would app= ly to PGW, as Ron pointed out. =3D=3D Sorry Adrian, I am afraid we high jacked a bit the discussion about the fir= st paragraph of the charter though... -----Original Message----- From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com]=20 Sent: Monday, December 02, 2013 2:08 PM To: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text > Issue#1: I think we have to be careful to not use the word 'service' to s= peak of a given network function. > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer I agree with you on this point and I think this is in-line with the definit= ion of service currently present in draft-quinn-sfc-arch: "Service: An offering provided by an operator that is delivered using one = or more service functions. This may also be referred to as a composite service." >Well, the PGW (or a BNG for wireline) is the starting point of the chain. = It acts as both Service Classifier and Service Policy >Enforcement Point (s= ometimes at L3, sometimes at L4/L7). Hence it is squarely a Service Functio= n. Would you agree? Regarding your comment on BNG in my opinion according to the definitions of= "service function" and "service node" in draft-quinn-sfc-arch the BNG is a= Service Node not a Service Function.=20 Quoting the definitions from draft-quinn-sfc-arch: " Service Function (SF): A network or application based packet treatment, application, compute or storage resource, used singularly or in concert with other service functions within a service chain to enable a service offered by an operator Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery." Any comments? Thanks Roberta -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand Sent: Monday, December 02, 2013 12:58 PM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Well, the PGW (or a BNG for wireline) is the starting point of the chain. I= t acts as both Service Classifier and Service Policy Enforcement Point (som= etimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function.= Would you agree? (anyhoo, my point was mostly to avoid the middlebox terminology! Even if I = know what you mean!) -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, December 02, 2013 12:53 PM To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From robmgl@cisco.com Mon Dec 2 12:22:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062B41ADED9 for ; Mon, 2 Dec 2013 12:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 Nmafq1JBFYtY for ; Mon, 2 Dec 2013 12:22:47 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2591ACCFF for ; Mon, 2 Dec 2013 12:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11388; q=dns/txt; s=iport; t=1386015765; x=1387225365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4xs4F/8gfTsybWTqF0Kb9zAmMS751ArutlqXOztUKLI=; b=FTiA3CiUffh3Ya0fFMINEtXARBCIliM76HGTIFXr9ePkihDVCIBwmoTS La9lm9CinANxAUx2VA0orSgRBsKn12TDO2rYk/1oJuNke5E1i1JhbL6+7 L5sSyqO0VsmxewsTqrottbszbY5mKitmCWPQrsIYTX7WPmB+C7BPCQ56+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJ/rnFKtJV2c/2dsb2JhbABZgwc4U7hngSYWdIIlAQEBAwEBAQE3KwkLBQcEAgEIDgMEAQELAhIJBycLFAkIAgQBDQUIh3MGDb96EwSOPxgxBwaDGoETA5Qxjj+HN4MpgWlB X-IronPort-AV: E=Sophos;i="4.93,812,1378857600"; d="scan'208";a="3749453" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 02 Dec 2013 20:22:44 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB2KMhZE026503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 20:22:44 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 14:22:43 -0600 From: "Roberta Maglione (robmgl)" To: Jerome Moisand , "adrian@olddog.co.uk" , "nsc@ietf.org" , Ted Lemon Thread-Topic: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function Thread-Index: AQHO75UcpKRqsuTqQEKL+37tbz83kppBVWeQ Date: Mon, 2 Dec 2013 20:22:43 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D502C89@xmb-rcd-x01.cisco.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.8.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ron Parker Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 02 Dec 2013 20:22:50 -0000 Thanks Jerome. Going back to the discussion about the first paragraph I agree with you wh= en you say that " a firewall or a spam-filtering proxy is NOT a Service. It's... a Service = Function"=20 and this is also in-line with the examples of Service functions listed in d= efinition of SF in the draft-quinn-sfc-arch:=20 "A non-exhaustive list of Service Functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), server load balancers, ..." The current version of the first paragraph as is looks ok to me, but maybe = we should understand better from Ted what is missing/needs to be clarified= in the current text in order to address his comments. Best Regards Roberta -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Monday, December 02, 2013 2:31 PM To: Roberta Maglione (robmgl); Ron Parker; adrian@olddog.co.uk; nsc@ietf.or= g Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text =3D> BNG/PGW and S= ervice Function Hi Roberta, Yes, you're right, this is a better way to put it. A BNG includes a Service= Function (or several), but is actually a full Service Node. Same would app= ly to PGW, as Ron pointed out. =3D=3D Sorry Adrian, I am afraid we high jacked a bit the discussion about the fir= st paragraph of the charter though... -----Original Message----- From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] Sent: Monday, December 02, 2013 2:08 PM To: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text > Issue#1: I think we have to be careful to not use the word 'service' to s= peak of a given network function. > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer I agree with you on this point and I think this is in-line with the definit= ion of service currently present in draft-quinn-sfc-arch: "Service: An offering provided by an operator that is delivered using one = or more service functions. This may also be referred to as a composite service." >Well, the PGW (or a BNG for wireline) is the starting point of the chain. = It acts as both Service Classifier and Service Policy >Enforcement Point (s= ometimes at L3, sometimes at L4/L7). Hence it is squarely a Service Functio= n. Would you agree? Regarding your comment on BNG in my opinion according to the definitions of= "service function" and "service node" in draft-quinn-sfc-arch the BNG is a= Service Node not a Service Function.=20 Quoting the definitions from draft-quinn-sfc-arch: " Service Function (SF): A network or application based packet treatment, application, compute or storage resource, used singularly or in concert with other service functions within a service chain to enable a service offered by an operator Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery." Any comments? Thanks Roberta -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand Sent: Monday, December 02, 2013 12:58 PM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Well, the PGW (or a BNG for wireline) is the starting point of the chain. I= t acts as both Service Classifier and Service Policy Enforcement Point (som= etimes at L3, sometimes at L4/L7). Hence it is squarely a Service Function.= Would you agree? (anyhoo, my point was mostly to avoid the middlebox terminology! Even if I = know what you mean!) -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Monday, December 02, 2013 12:53 PM To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hi, Jerome. I agree with your definitions of service vs. service function. Regarding functions like PGW, in the upstream direction for user traffic, i= t is explicitly addressed (i.e., GTP-U tunneling) and is therefore not in n= eed of any traffic steering. In the downstream direction, the PGW represe= nts itself as a PE router that reaches the subscribers. Most of the inter= est, today, around the mobile use case is for transparent middlebox functio= ns that reside between the PGW and the Internet. The set of service funct= ions is typically called the "Gi LAN", a name that more or less implies the= present day deployment model. Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net] Sent: Monday, December 02, 2013 11:35 AM To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Issue#1: I think we have to be careful to not use the word 'service' to spe= ak of a given network function.=20 Personally, I always use the word 'service' as something perceived by the e= nd user/customer. Something that you subscribe to, something that you benef= it from, something that you may be billed for, something that may require c= ustomer care interactions. This is a 'black box' perspective, the Network S= ervice Provider (or IT department inside an Enterprise) can then implement = such service in many ways, using many network functions and related systems= , without the end user knowing. So a firewall or a spam-filtering proxy is NOT a Service. It's... a Service= Function! Meaning a network function that directly helps in providing serv= ice-related processing and service (profile) differentiation. It's just a c= omponent though, not the entire Service as perceived by the end user. And Ron, I would suggest to avoid speaking of mid-box (or middleboxes), as = this term has a connotation that would seem to exclude some forms of Servic= e Functions (e.g. a BNG or PGW are rarely viewed as 'middlebox', and yet, t= hey are *the* primary Service Function in today's broadband networks).=20 Issue #2: I understand what Ted is trying to say with the 'in-path' aspect,= but fact is service (function) chaining is about steering use traffic via = a constrained path, and well, the service function does remain on the data = path (granted, the data path changed from a 'shortest path routed' to a mor= e constrained path, but it's still a data path!).=20 =3D=3D=3D I don't know, seems to me that the existing first paragraph is actually fin= e, if not better (even if the last sentence 'direct data path' terminology = isn't that great either). It also seems to me that we've been hair-splittin= g for a while now, and maybe we should just move on... I would just suggest= to simplify the last sentence of the existing paragraph and say: << Going forward, however, there is a desire to move to a different model, = where traffic can be steered through service functions (physical or virtual= ized), wherever they are deployed.>> And then, during the actual work, for sure, we'll need to settle on clear d= efinitions for 'Service', 'Service Function', etc. -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Monday, December 02, 2013 10:03 AM To: adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Adrian, I think Ted's text is a very nice summary of what we are trying to accompli= sh. He does use the term "in-path" which could use some elaboration, IMO. I f= eel that SFC applies to transparent mid-boxes and not to explicitly address= ed service functions (i.e., SFC applies to a transparent HTTP proxy, but no= t to an explicit HTTP proxy). > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. =20 Could become: "Network service providers, in addition to delivering IP connectivity, freq= uently provide transparent services such as firewall filtering, load balanc= ing and transactional proxies such as spam filters." We may want to strike or replace load balancing as that may not be an actua= l transparent service but rather a building block for some actual transport= service -- open to suggestions on this verbage. > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Could become: "Today, a common deployment model is to insert various mid-boxes on the dat= a-forwarding path between communicating peers." Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, December 02, 2013 7:21 AM To: nsc@ietf.org Cc: Ted Lemon Subject: [nsc] Ted Lemon's concern with charter text Hi, During IESG review Ted and I had a bit of an exchange about the meaning of = "a service" and the "layer at which a service chain can be applied". Ted was looking for some text to clarify this in the in the charter and sug= gests replacing the entire first paragraph with... > Network service providers, in addition to delivering IP connectivity,=20 > frequently provide in-path services such as firewall filtering, load > balancing and transactional proxies such as spam filters. Delivery > of these types of services is undergoing significant change with the=20 > introduction of virtualization, network overlays, and orchestration. >=20 > Service delivery is currently both a technical and an organizational=20 > challenge that involves significant modification to the network=20 > configuration, impacting the speed at which services can be > deployed and increasing operational costs. Such services are > typically implemented by the ordered combination of a number of=20 > service functions that are deployed at different points within a=20 > network. >=20 > Today, a common deployment model has service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a desire to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through service=20 > functions, wherever they are deployed. This is only a strawman from Ted (and thanks to him for proposing text), an= d we should not assume that it is immutable.=20 I think the way to look at this is: - Is there anything in the new text we disagree with? - Would making this change cause harm? - Could this change be improved still further? Opinions please. Cheers, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ted.Lemon@nominum.com Mon Dec 2 12:35:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E301ADF4B for ; Mon, 2 Dec 2013 12:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 b2wmkRqILzzN for ; Mon, 2 Dec 2013 12:35:21 -0800 (PST) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id EFD471ADF27 for ; Mon, 2 Dec 2013 12:35:20 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUpzvBoNrqNEtyO80e/r8nuN8GEQ8C/ho@postini.com; Mon, 02 Dec 2013 12:35:19 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A37B81B82D7 for ; Mon, 2 Dec 2013 12:35:18 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 820AA190043; Mon, 2 Dec 2013 12:35:18 -0800 (PST) Received: from [192.168.1.3] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 12:35:18 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D502C89@xmb-rcd-x01.cisco.com> Date: Mon, 2 Dec 2013 15:35:14 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502C89@xmb-rcd-x01.cisco.com> To: "Roberta Maglione (robmgl)" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] X-Mailman-Approved-At: Mon, 02 Dec 2013 13:44:04 -0800 Cc: "nsc@ietf.org" , Adrian Farrel , Ron Parker Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 02 Dec 2013 20:35:22 -0000 On Dec 2, 2013, at 3:22 PM, Roberta Maglione (robmgl) = wrote: > The current version of the first paragraph as is looks ok to me, but = maybe we should understand better from Ted what is missing/needs to be = clarified in the current text in order to address his comments. The easiest thing from my side would be for you to put what you think = ought to be there in the text and send me that, and I can tell you = whether it does the job for me. The problem with the original text was = simply that I had no idea what "services" were, and so I couldn't parse = the rest of the charter. Once Adrian explained what that meant, the = whole thing made sense. I'd like it if others reading the charter had = the "makes sense" experience rather than the "no idea what it means" = experience. :) The text that I proposed was simply a proposal for how to restructure = and what to put in to make that happen. I was pretty sure that the = actual terms I used were wrong, so don't feel obliged to retain them. From adrian@olddog.co.uk Mon Dec 2 14:06:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253BB1ADF22 for ; Mon, 2 Dec 2013 14:06:57 -0800 (PST) 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 EX0aqYZeMmrE for ; Mon, 2 Dec 2013 14:06:55 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 76BDB1ADDA0 for ; Mon, 2 Dec 2013 14:06:55 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2M6pse022486; Mon, 2 Dec 2013 22:06:52 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB2M6ou9022466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Dec 2013 22:06:51 GMT From: "Adrian Farrel" To: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502C89@xmb-rcd-x01.cisco.com> In-Reply-To: Date: Mon, 2 Dec 2013 22:06:50 -0000 Message-ID: <0d9601ceefaa$cd87a220$6896e660$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI6Ddjr/xNOBA5IVGGlnkDl+t1YAQGD5WpeApcbTVACBdBpDgJyOktnAiamkGgBekoWvQHDlZT9At9PKWuY5IIJAA== Content-Language: en-gb Cc: 'Ted Lemon' Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 22:06:57 -0000 I think it is clear that Ted is just asking for "a little more background". This should be relatively harmless, but I can bet that there are a few devils (or at least minor daemons) in the detail of that. So, an option here (and, yes, I would also like to avoid splitting hairs for the rest of the year) is to: - merge the current paragraph with Ted's three - update Ted's text as necessary (such as s/service/service function) Anyone want to take a stab, or shall I? Adrian > -----Original Message----- > From: Ted Lemon [mailto:ted.lemon@nominum.com] > Sent: 02 December 2013 20:35 > To: Roberta Maglione (robmgl) > Cc: Jerome Moisand; Adrian Farrel; nsc@ietf.org; Ron Parker > Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and > Service Function > > On Dec 2, 2013, at 3:22 PM, Roberta Maglione (robmgl) > wrote: > > The current version of the first paragraph as is looks ok to me, but maybe we > should understand better from Ted what is missing/needs to be clarified in the > current text in order to address his comments. > > The easiest thing from my side would be for you to put what you think ought to > be there in the text and send me that, and I can tell you whether it does the job > for me. The problem with the original text was simply that I had no idea what > "services" were, and so I couldn't parse the rest of the charter. Once Adrian > explained what that meant, the whole thing made sense. I'd like it if others > reading the charter had the "makes sense" experience rather than the "no idea > what it means" experience. :) > > The text that I proposed was simply a proposal for how to restructure and what > to put in to make that happen. I was pretty sure that the actual terms I used > were wrong, so don't feel obliged to retain them. From jguichar@cisco.com Mon Dec 2 15:00:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D141ADF96 for ; Mon, 2 Dec 2013 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 wNUgMxbtUSB2 for ; Mon, 2 Dec 2013 15:00:45 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id F2BE91ADFA9 for ; Mon, 2 Dec 2013 15:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1386025242; x=1387234842; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RLlhww3beRYjJ+ZZWT48GPHUgpoPHR9tF28ddPC8Sxk=; b=HqTHUb4IBBlVDHp5di5nNqBD/ncoIhCihQJtHeVWPzqptXmWZfd1x9r3 ell29CNsIIzzFjK+HK/YGPzwZ7OlMBKpl2aSVuK9k9jQMIP7bxMrJrmx4 6JWIevzR3wF1TJipXPWSe5O8i0TsvRdD56ygqc0ppALuluUKckwXsYS6y U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAH8QnVKtJXG+/2dsb2JhbABZgwc4U7hngSYWdIIlAQEBBAEBATc0CwwGAQgRBAEBAR4JLgsUCQgCBAENBYgBDcBSEwSOVTMHBoQtA5Qxg2OKXIc3gymCKg X-IronPort-AV: E=Sophos;i="4.93,813,1378857600"; d="scan'208";a="3796022" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-5.cisco.com with ESMTP; 02 Dec 2013 23:00:42 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB2N0gZe001758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 23:00:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 2 Dec 2013 17:00:42 -0600 From: "Jim Guichard (jguichar)" To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function Thread-Index: AQHO77JTN9bp6guKWkGalCXBaF18uA== Date: Mon, 2 Dec 2013 23:00:42 +0000 Message-ID: In-Reply-To: <0d9601ceefaa$cd87a220$6896e660$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.130.20.145] Content-Type: text/plain; charset="us-ascii" Content-ID: <776D418DEAD88E4D8268D028F80DBA5A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Ted Lemon' Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 02 Dec 2013 23:00:47 -0000 Hi Adrian/Ted, Would the following text suffice? Network operators frequently utilize service functions such as firewall filtering, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. Deploying service functions to support service delivery is currently both a technical and an organizational challenge that involves significant modification to the network configuration, impacting the speed at which services can be deployed and increasing operational costs. Such services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network. Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required service functions, wherever they are deployed. On 12/2/13 5:06 PM, "Adrian Farrel" wrote: >I think it is clear that Ted is just asking for "a little more >background". This >should be relatively harmless, but I can bet that there are a few devils >(or at >least minor daemons) in the detail of that. > >So, an option here (and, yes, I would also like to avoid splitting hairs >for the >rest of the year) is to: >- merge the current paragraph with Ted's three >- update Ted's text as necessary (such as s/service/service function) > >Anyone want to take a stab, or shall I? > >Adrian > >> -----Original Message----- >> From: Ted Lemon [mailto:ted.lemon@nominum.com] >> Sent: 02 December 2013 20:35 >> To: Roberta Maglione (robmgl) >> Cc: Jerome Moisand; Adrian Farrel; nsc@ietf.org; Ron Parker >> Subject: Re: [nsc] Ted Lemon's concern with charter text =3D> BNG/PGW an= d >> Service Function >>=20 >> On Dec 2, 2013, at 3:22 PM, Roberta Maglione (robmgl) >> wrote: >> > The current version of the first paragraph as is looks ok to me, but >>maybe >we >> should understand better from Ted what is missing/needs to be >>clarified in >the >> current text in order to address his comments. >>=20 >> The easiest thing from my side would be for you to put what you think >>ought to >> be there in the text and send me that, and I can tell you whether it >>does the >job >> for me. The problem with the original text was simply that I had no >>idea >what >> "services" were, and so I couldn't parse the rest of the charter. Once >Adrian >> explained what that meant, the whole thing made sense. I'd like it if >>others >> reading the charter had the "makes sense" experience rather than the >>"no idea >> what it means" experience. :) >>=20 >> The text that I proposed was simply a proposal for how to restructure >>and what >> to put in to make that happen. I was pretty sure that the actual >>terms I >used >> were wrong, so don't feel obliged to retain them. > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Mon Dec 2 15:47:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085271ADF9A for ; Mon, 2 Dec 2013 15:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 k8s89Vj3Ee11 for ; Mon, 2 Dec 2013 15:47:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA21ADF46 for ; Mon, 2 Dec 2013 15:47:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYO08729; Mon, 02 Dec 2013 23:47:21 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 23:46:34 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 23:47:20 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 15:47:16 -0800 From: Linda Dunbar To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function Thread-Index: AQHO76eq7eCU14hETEupZXy6+uSIXJpB/GYA//+O4rA= Date: Mon, 2 Dec 2013 23:47:15 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C27229@dfweml509-mbx.china.huawei.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502BC9@xmb-rcd-x01.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D502C89@xmb-rcd-x01.cisco.com> <0d9601ceefaa$cd87a220$6896e660$@olddog.co.uk> In-Reply-To: <0d9601ceefaa$cd87a220$6896e660$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'Ted Lemon' Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 02 Dec 2013 23:47:28 -0000 I share the same view as Ted stated: "The problem with the original text wa= s simply that I had no idea what "services" were...".=20 Many service function examples being discussed on the SFC list and in the u= se case drafts are for optimization purpose, like TCP acceleration, Video/W= eb acceleration. Those functions may not even be visible to external entiti= es.=20 The so called "service delivery" in the context of NSC (or SFC) is more abo= ut applying a sequence of service functions to treat packets that match cer= tain criteria.=20 Therefore, I think that the following text is more accurate description: "The mechanisms of applying service functions to "data flows" is undergoing= significant change with the introduction of virtualization, network overla= ys and orchestration. ..." There may be a better name than "data flows", such as plain simple "connec= tivity services" or "traffic among peers".=20 p.s. In the "draft-quinn-nsc-problem-statements", Network Service is define= d as "An externally visible service offered by a network operator; but many= service functions being discussed are not visible to external entities.=20 Linda=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 4:07 PM > To: nsc@ietf.org > Cc: 'Ted Lemon' > Subject: Re: [nsc] Ted Lemon's concern with charter text =3D> BNG/PGW and > Service Function >=20 > I think it is clear that Ted is just asking for "a little more > background". This > should be relatively harmless, but I can bet that there are a few > devils (or at > least minor daemons) in the detail of that. >=20 > So, an option here (and, yes, I would also like to avoid splitting > hairs for the > rest of the year) is to: > - merge the current paragraph with Ted's three > - update Ted's text as necessary (such as s/service/service function) >=20 > Anyone want to take a stab, or shall I? >=20 > Adrian >=20 > > -----Original Message----- > > From: Ted Lemon [mailto:ted.lemon@nominum.com] > > Sent: 02 December 2013 20:35 > > To: Roberta Maglione (robmgl) > > Cc: Jerome Moisand; Adrian Farrel; nsc@ietf.org; Ron Parker > > Subject: Re: [nsc] Ted Lemon's concern with charter text =3D> BNG/PGW > and > > Service Function > > > > On Dec 2, 2013, at 3:22 PM, Roberta Maglione (robmgl) > > > wrote: > > > The current version of the first paragraph as is looks ok to me, > but maybe > we > > should understand better from Ted what is missing/needs to be > clarified in > the > > current text in order to address his comments. > > > > The easiest thing from my side would be for you to put what you think > ought to > > be there in the text and send me that, and I can tell you whether it > does the > job > > for me. The problem with the original text was simply that I had no > idea > what > > "services" were, and so I couldn't parse the rest of the charter. > Once > Adrian > > explained what that meant, the whole thing made sense. I'd like it > if others > > reading the charter had the "makes sense" experience rather than the > "no idea > > what it means" experience. :) > > > > The text that I proposed was simply a proposal for how to restructure > and what > > to put in to make that happen. I was pretty sure that the actual > terms I > used > > were wrong, so don't feel obliged to retain them. >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ted.Lemon@nominum.com Mon Dec 2 16:51:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24271ADFDC for ; Mon, 2 Dec 2013 16:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 OZ2HJcvwV5YG for ; Mon, 2 Dec 2013 16:51:54 -0800 (PST) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBD41ADF92 for ; Mon, 2 Dec 2013 16:51:54 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKUp0rKNml0/Ts6P6YmTO2CYi1ZjBQe9jt@postini.com; Mon, 02 Dec 2013 16:51:52 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F05CE1B82E2 for ; Mon, 2 Dec 2013 16:51:51 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id CD5A0190043; Mon, 2 Dec 2013 16:51:51 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Dec 2013 16:51:51 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: Date: Mon, 2 Dec 2013 19:51:49 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: "nsc@ietf.org" , Adrian Farrel Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@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, 03 Dec 2013 00:51:55 -0000 That looks great to me. But please, pretty please, break that giant = paragraph up into three bite-sized chunks. You could break once at = "Deploying service functions" and a second time at "Today, common". From mls.ietf@gmail.com Tue Dec 3 01:35:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F064B1AE0E5 for ; Tue, 3 Dec 2013 01:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 dnNzvGXyZTlk for ; Tue, 3 Dec 2013 01:35:18 -0800 (PST) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 37A191AE09C for ; Tue, 3 Dec 2013 01:35:18 -0800 (PST) Received: by mail-bk0-f41.google.com with SMTP id v15so5891511bkz.14 for ; Tue, 03 Dec 2013 01:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=+x+p8qabmvsEjV09OizxxasYYJJP4HOoU2JSAytImOM=; b=HXA58TdCQYQ1gP91lfYa0tcQIBuFRLgTrHnrQhk/D0szzDmLX3eCH5Z34xX3hx3C1I BsuYt/ZiScrO3+wjkthTJRYCccOFVqlmw8xe1FU1AyXzyOGpzPnHKUJAvPlf4IVn4hhS 4riV9aquJDYx5VS36tLUwZQwKt6xEK95gbuUK5stocf73oHSGx5FyUOFiRUZ+1ukhjhY w6trDmvy9p2ArgN2MEW0rMu9vyK22LdHbdrIlQ32Z/veZKlueKkTyCMzMz6XQFWWtili EAa3ZohE/86z/bih2N07ah0ObTdvcCFO+P7lkzWrc6p0e6oab0DUn14e+sRSzsS5WQbB DqKQ== X-Received: by 10.204.173.6 with SMTP id n6mr49192996bkz.5.1386063315071; Tue, 03 Dec 2013 01:35:15 -0800 (PST) Received: from [10.1.99.64] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id k9sm50193654bko.16.2013.12.03.01.35.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 01:35:14 -0800 (PST) Message-ID: <529DA5D1.9020202@gmail.com> Date: Tue, 03 Dec 2013 10:35:13 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: nsc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 09:35:20 -0000 Hi all, I have read through draft-quinn-sfc-problem-statement and draft-quinn-sfc-arch and wonder about the slightly different definitions of service function chain in both documents though that they share a similar set of authors. I guess a much better terminology alignment is required. See below for the excerpts from the drafts about the definitions. Anyhow, here is my real point: The definitions of SFC below always read to me as they are describing the services functions and the order of them, but any further information about whether there is a *network* path between the functions is missing in the definition. Also some abstract information about the network path is missing, such as unidirectional, bi-directional, unicast, multicast, etc. Is this intentionally? Is this a hidden assumption that the network overlay(s) is already pre-configured between service nodes? Here are the excerpts for your reference: In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain: A service chain defines the required functions and associated order (service-function1 --> service-function 2) that must be applied to packets and/or frames. A service chain does not specify the network location or specific instance of service functions (e.g. firewall1 vs. firewall2). In draft-quinn-sfc-arch, Section 1.2: Service Function Chain (SFC): A set of service functions that are to be applied to selected traffic in a specific order. The implied order may not be a linear progression as the architecture will allow for nodes that copy to more than one branch. The term service chain is often used as a shorthand version of service function chain. In draft-quinn-sfc-arch, Section 2.1 "service function chaining creates an abstracted view of a service and specifies the set of required service functions as well as the order in which they must be executed. Thanks, Martin From diego@tid.es Tue Dec 3 02:02:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813751AE093 for ; Tue, 3 Dec 2013 02:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 30UQRbcamu5f for ; Tue, 3 Dec 2013 02:02:20 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id B41801AE061 for ; Tue, 3 Dec 2013 02:02:19 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MX8008IR6JRHM@tid.hi.inet> for nsc@ietf.org; Tue, 03 Dec 2013 11:02:15 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 13.92.02810.62CAD925; Tue, 03 Dec 2013 11:02:15 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MX8008II6JQHM@tid.hi.inet> for nsc@ietf.org; Tue, 03 Dec 2013 11:02:14 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.156]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 03 Dec 2013 11:02:14 +0100 Date: Tue, 03 Dec 2013 10:02:14 +0000 From: "Diego R. Lopez" In-reply-to: <529DA5D1.9020202@gmail.com> X-Originating-IP: [10.95.64.115] To: Martin Stiemerling Message-id: <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> Content-id: <61CACDE9B176524C8506BD93A0607164@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-index: AQHO8Ar/rf3uJULcEkqkkV54fuSvI5pCLKKA X-AuditID: 0a5f4e69-b7f9b8e000000afa-fb-529dac26070b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhivcz1FVfMzfI4OhdIYvj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/6W92wFf5Qq/nyby9rA2KHUxcjJISFgIjFtXSMLhC0mceHe erYuRi4OIYFtjBLTr0yAcr4xSjx+fJ8VwpnJKDFtwQJmkBYWAVWJEy+PsILYbED2o+bf7CC2 sECSRF/3bTCbU0BTYtvEuVArFCT+nHsMZosIaEu8/vQZbA6zgLLE8+O/wOK8ApYS23YvYoOI m0m8ensWKi4o8WPyPSCbAyiuLjFlSi5EibhEc+tNFghbUWLaogZGEJtRQFbi3fz5rBCrkiX2 9a1ng7CNJD7emMIKcY6AxJI955khbFGJl4//gcWFBDQkbu09wziBUWIWkitmIbliFsIVs5Bc MQvJFQsYWVcxihUnFWWmZ5TkJmbmpBsY6WVk6mXmpZZsYoREXeYOxuU7VQ4xCnAwKvHwPtw+ J0iINbGsuDL3EKMEB7OSCK/+qrlBQrwpiZVVqUX58UWlOanFhxiZODilGhiN2VdUcT2pTnd9 eaHDfcqNB29u7prUliZmoe508u7HH6s//d3F55y17d3cp3oflsR8apu8X9BN6UVRyB+bDWXP xc9P+2P9T3tK7AO+/jjXf2xrk84eSi1Yo+FS9q+3cfbrTZotfnuEP3fN+VRvsCpH/f/f1s3K 9537X105zPvoi6fKsz2vlboblFiKMxINtZiLihMBHIrerpgCAAA= References: <529DA5D1.9020202@gmail.com> Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 10:02:23 -0000 SGkgTWFydGluLA0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgaXQgaXMgYXMgeW91IHNheTog dGhlcmUgaXMgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiBvZiBhbiBleGlzdGluZyBvdmVybGF5LCBh bmQgb25lIG9mIHRoZSBtb3JlIChpZiBub3QgdGhlIG1vc3QpIGltcG9ydGFudCB0YXNrcyBvZiBT RkMgaXMgcHJlY2lzZWx5IGRlZmluaW5nIGhvdyBtZXRhZGF0YSBpcyB0cmFuc2ZlcnJlZCB1c2lu ZyB0aGUgY29uc3RydWN0cyBwcm92aWRlZCBieSB0aGUgb3ZlcmxheSwgYW5kIGhvdyB0aGVzZSBt ZXRhZGF0YSBjb250cm9sIGZsb3dzIG9uIHRoZSBvdmVybGF5LiBIb3cgdGhlIG92ZXJsYXkgaXMg Y29uZmlndXJlZCBpbiB0ZXJtcyBvZiBuZXR3b3JrIHBhdGhzIHNob3VsZCBiZSBvdXQgb2Ygc2Nv cGUuDQoNCkJlIGdvb2RlLA0KDQpPbiAzIERlYyAyMDEzLCBhdCAxMDozNSAsIE1hcnRpbiBTdGll bWVybGluZyB3cm90ZToNCg0KPiBIaSBhbGwsDQo+DQo+IEkgaGF2ZSByZWFkIHRocm91Z2ggZHJh ZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50IGFuZCBkcmFmdC1xdWlubi1zZmMtYXJjaCBh bmQgd29uZGVyIGFib3V0IHRoZSBzbGlnaHRseSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygc2Vy dmljZSBmdW5jdGlvbiBjaGFpbiBpbiBib3RoIGRvY3VtZW50cyB0aG91Z2ggdGhhdCB0aGV5IHNo YXJlIGEgc2ltaWxhciBzZXQgb2YgYXV0aG9ycy4gSSBndWVzcyBhIG11Y2ggYmV0dGVyIHRlcm1p bm9sb2d5IGFsaWdubWVudCBpcyByZXF1aXJlZC4gU2VlIGJlbG93IGZvciB0aGUgZXhjZXJwdHMg ZnJvbSB0aGUgZHJhZnRzIGFib3V0IHRoZSBkZWZpbml0aW9ucy4NCj4NCj4gQW55aG93LCBoZXJl IGlzIG15IHJlYWwgcG9pbnQ6DQo+DQo+IFRoZSBkZWZpbml0aW9ucyBvZiBTRkMgYmVsb3cgYWx3 YXlzIHJlYWQgdG8gbWUgYXMgdGhleSBhcmUgZGVzY3JpYmluZyB0aGUgc2VydmljZXMgZnVuY3Rp b25zIGFuZCB0aGUgb3JkZXIgb2YgdGhlbSwgYnV0IGFueSBmdXJ0aGVyIGluZm9ybWF0aW9uIGFi b3V0IHdoZXRoZXIgdGhlcmUgaXMgYSAqbmV0d29yayogcGF0aCBiZXR3ZWVuIHRoZSBmdW5jdGlv bnMgaXMgbWlzc2luZyBpbiB0aGUgZGVmaW5pdGlvbi4gQWxzbyBzb21lIGFic3RyYWN0IGluZm9y bWF0aW9uIGFib3V0IHRoZSBuZXR3b3JrIHBhdGggaXMgbWlzc2luZywgc3VjaCBhcyB1bmlkaXJl Y3Rpb25hbCwgYmktZGlyZWN0aW9uYWwsIHVuaWNhc3QsIG11bHRpY2FzdCwgZXRjLg0KPg0KPiBJ cyB0aGlzIGludGVudGlvbmFsbHk/DQo+DQo+IElzIHRoaXMgYSBoaWRkZW4gYXNzdW1wdGlvbiB0 aGF0IHRoZSBuZXR3b3JrIG92ZXJsYXkocykgaXMgYWxyZWFkeSBwcmUtY29uZmlndXJlZCBiZXR3 ZWVuIHNlcnZpY2Ugbm9kZXM/DQo+DQo+DQo+DQo+IEhlcmUgYXJlIHRoZSBleGNlcnB0cyBmb3Ig eW91ciByZWZlcmVuY2U6DQo+DQo+IEluIGRyYWZ0LXF1aW5uLXNmYy1wcm9ibGVtLXN0YXRlbWVu dCwgU2VjdGlvbiAxLjENCj4gICAgIFNlcnZpY2UgQ2hhaW46ICBBIHNlcnZpY2UgY2hhaW4gZGVm aW5lcyB0aGUgcmVxdWlyZWQgZnVuY3Rpb25zIGFuZA0KPiAgICAgIGFzc29jaWF0ZWQgb3JkZXIg KHNlcnZpY2UtZnVuY3Rpb24xIC0tPiBzZXJ2aWNlLWZ1bmN0aW9uIDIpIHRoYXQNCj4gICAgICBt dXN0IGJlIGFwcGxpZWQgdG8gcGFja2V0cyBhbmQvb3IgZnJhbWVzLiAgQSBzZXJ2aWNlIGNoYWlu IGRvZXMNCj4gICAgICBub3Qgc3BlY2lmeSB0aGUgbmV0d29yayBsb2NhdGlvbiBvciBzcGVjaWZp YyBpbnN0YW5jZSBvZiBzZXJ2aWNlDQo+ICAgICAgZnVuY3Rpb25zIChlLmcuIGZpcmV3YWxsMSB2 cy4gZmlyZXdhbGwyKS4NCj4NCj4gSW4gZHJhZnQtcXVpbm4tc2ZjLWFyY2gsIFNlY3Rpb24gMS4y Og0KPiAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQyk6ICBBIHNldCBvZiBzZXJ2aWNlIGZ1 bmN0aW9ucyB0aGF0IGFyZSB0bw0KPiAgIGJlIGFwcGxpZWQgdG8gc2VsZWN0ZWQgdHJhZmZpYyBp biBhIHNwZWNpZmljIG9yZGVyLiAgVGhlIGltcGxpZWQNCj4gICBvcmRlciBtYXkgbm90IGJlIGEg bGluZWFyIHByb2dyZXNzaW9uIGFzIHRoZSBhcmNoaXRlY3R1cmUgd2lsbA0KPiAgIGFsbG93IGZv ciBub2RlcyB0aGF0IGNvcHkgdG8gbW9yZSB0aGFuIG9uZSBicmFuY2guICBUaGUgdGVybQ0KPiAg IHNlcnZpY2UgY2hhaW4gaXMgb2Z0ZW4gdXNlZCBhcyBhIHNob3J0aGFuZCB2ZXJzaW9uIG9mIHNl cnZpY2UNCj4gICBmdW5jdGlvbiBjaGFpbi4NCj4NCj4gSW4gZHJhZnQtcXVpbm4tc2ZjLWFyY2gs IFNlY3Rpb24gMi4xDQo+ICJzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGNyZWF0ZXMgYW4gYWJz dHJhY3RlZCB2aWV3DQo+ICAgb2YgYSBzZXJ2aWNlIGFuZCBzcGVjaWZpZXMgdGhlIHNldCBvZiBy ZXF1aXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcw0KPiAgIHdlbGwgYXMgdGhlIG9yZGVyIGluIHdo aWNoIHRoZXkgbXVzdCBiZSBleGVjdXRlZC4NCj4NCj4NCj4NCj4gVGhhbmtzLA0KPg0KPiAgTWFy dGluDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IG5zYyBtYWlsaW5nIGxpc3QNCj4gbnNjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnNjDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBE b2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0 cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpU ZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVu dsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0 dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZv ciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJh c2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5B Uy9kaXNjbGFpbWVyLmFzcHgNCg== From mls.ietf@gmail.com Tue Dec 3 04:20:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414041AE12B for ; Tue, 3 Dec 2013 04:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 V0tNOPGzfCyj for ; Tue, 3 Dec 2013 04:20:21 -0800 (PST) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C61AE12A for ; Tue, 3 Dec 2013 04:20:20 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id e51so1413395eek.41 for ; Tue, 03 Dec 2013 04:20:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=XZfBZIbrWbQFqlzuTzYhg3ko8nbECGpVS4tTEV6ja5M=; b=jRIYrbdEDvPP5QheVsXplwJ/OJ+e5HV5ssrGIBdrb6zngOLjo7yR81pnq65sL5Wn6P F0TgjvlCoRYWB9MVdvH/bw1o9hQjGDqmk8h2lTSoPxrEck5VWdyK9zUdzTRTWQosu7XZ MwuCN6MLdblbTA5U+61hAfm1fQXpyxnnuink0fQMiRlYz80aokwrpoNcZo3ABBFSvLjN 1xbxmxGJWzuu/uyCM6lLuGL0sbFD/SgALqD+FKsd5+HWslubioqaaHE9opwT6Yqx2xLH XmXVNnHouw0n5hLUieoHfCKHPGw5dPsrIKbSkjN+b8+3jl+cG8KY8gDk75xWO7RirlaI F66w== X-Received: by 10.14.210.200 with SMTP id u48mr2505265eeo.63.1386073217724; Tue, 03 Dec 2013 04:20:17 -0800 (PST) Received: from [10.1.99.64] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id g7sm33241509eet.12.2013.12.03.04.20.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 04:20:16 -0800 (PST) Message-ID: <529DCC7F.9050005@gmail.com> Date: Tue, 03 Dec 2013 13:20:15 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Diego R. Lopez" , "" References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> In-Reply-To: <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 12:20:23 -0000 Hi Diego, all, On 12/03/2013 11:02 AM, Diego R. Lopez wrote: > Hi Martin, > > My understanding is that it is as you say: there is an implicit > assumption of an existing overlay, and one of the more (if not the > most) important tasks of SFC is precisely defining how metadata is > transferred using the constructs provided by the overlay, and how Ok, good to know and it is even better if this is documented in the architecture or wherever appropriate. While I can see the operational reasons for this by today, I consider this as a unnecessary limitation for the future. Is this group only considering this or are there thoughts to go beyond this? > these metadata control flows on the overlay. How the overlay is > configured in terms of network paths should be out of scope. Shouldn't this be mentioned in the charter? Thanks, Martin > > Be goode, > > On 3 Dec 2013, at 10:35 , Martin Stiemerling wrote: > >> Hi all, >> >> I have read through draft-quinn-sfc-problem-statement and >> draft-quinn-sfc-arch and wonder about the slightly different >> definitions of service function chain in both documents though that >> they share a similar set of authors. I guess a much better >> terminology alignment is required. See below for the excerpts from >> the drafts about the definitions. >> >> Anyhow, here is my real point: >> >> The definitions of SFC below always read to me as they are >> describing the services functions and the order of them, but any >> further information about whether there is a *network* path between >> the functions is missing in the definition. Also some abstract >> information about the network path is missing, such as >> unidirectional, bi-directional, unicast, multicast, etc. >> >> Is this intentionally? >> >> Is this a hidden assumption that the network overlay(s) is already >> pre-configured between service nodes? >> >> >> >> Here are the excerpts for your reference: >> >> In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain: A >> service chain defines the required functions and associated order >> (service-function1 --> service-function 2) that must be applied to >> packets and/or frames. A service chain does not specify the >> network location or specific instance of service functions (e.g. >> firewall1 vs. firewall2). >> >> In draft-quinn-sfc-arch, Section 1.2: Service Function Chain (SFC): >> A set of service functions that are to be applied to selected >> traffic in a specific order. The implied order may not be a linear >> progression as the architecture will allow for nodes that copy to >> more than one branch. The term service chain is often used as a >> shorthand version of service function chain. >> >> In draft-quinn-sfc-arch, Section 2.1 "service function chaining >> creates an abstracted view of a service and specifies the set of >> required service functions as well as the order in which they must >> be executed. >> >> >> >> Thanks, >> >> Martin _______________________________________________ nsc mailing >> list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > > > -- "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra política de envío y recepción de correo electrónico > en el enlace situado más abajo. This message is intended exclusively > for its addressee. We only send and receive email on the basis of the > terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx > From diego@tid.es Tue Dec 3 05:27:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4A71ADEB7 for ; Tue, 3 Dec 2013 05:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Phxo2dTZhbVa for ; Tue, 3 Dec 2013 05:27:46 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id E8ABB1AE126 for ; Tue, 3 Dec 2013 05:27:45 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MX800L9AG25X1@tid.hi.inet> for nsc@ietf.org; Tue, 03 Dec 2013 14:27:42 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id F2.F5.03314.E4CDD925; Tue, 03 Dec 2013 14:27:42 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MX800L9JG26X1@tid.hi.inet> for nsc@ietf.org; Tue, 03 Dec 2013 14:27:42 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.156]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Tue, 03 Dec 2013 14:27:41 +0100 Date: Tue, 03 Dec 2013 13:27:41 +0000 From: "Diego R. Lopez" In-reply-to: <529DCC7F.9050005@gmail.com> X-Originating-IP: [10.95.64.115] To: Martin Stiemerling Message-id: <39926BEF-05E4-4D27-A5F3-F0ECB955689B@tid.es> Content-id: <4B8A428053E4B540827DAA560D55D5AE@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-index: AQHO8Ar/rf3uJULcEkqkkV54fuSvI5pCLKKAgAAmj4CAABLYAA== X-AuditID: 0a5f4068-b7fe58e000000cf2-e5-529ddc4e38be X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhinfg0vW7MzfIYHm/psXxffvZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVce/iW8aCGUIVe/awNTDeEexi5OSQEDCRWL9gKhOELSZx4d56 ti5GLg4hgQOMEh0dp1ggnK+MEv29X9khnJmMEscnrWcGaWERUJXo3LiDDcRmA7IfNf9mB7GF BZIk+rpvg9mcApoSHV+eMEOsUJD4c+4xC4gtIqAt8frTZ7A4s4CyxPPjv8DivAKWEmcPnIGK m0lMOfGTESIuKPFj8j2gGg6guLrElCm5ECXiEs2tN1kgbEWJaYsawMoZBWQl3s2fzwqxKlli X996NgjbSeLRo4uMEOcISCzZcx7qNFGJl4//gdULCZRK3GxdyjyBUWIWkitmIbliFsIVs5Bc MQvJFQsYWVcxihUnFWWmZ5TkJmbmpBsY6mVk6mXmpZZsYoTEXMYOxuU7VQ4xCnAwKvHwdmyd EyTEmlhWXJl7iFGCg1lJhNfg7NwgId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYy71rTs6p97qftU 6K+L1oE5lUoHGufEKr+/d1bxa+5899orC5bYqj98+7ZywtawlMZPs3Und2bMPcP5/uoGy5uG D3oL5ky8cUv18JLVZ7a3V/3QZXHkbmG9+f/YuhULflTuyGp4bF/8Jsd0wrrkDFexVRu/s/WK 9OxMz/7yb0anuvu/5db5V7Z8UmIpzkg01GIuKk4EAHSP7B+XAgAA References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <529DCC7F.9050005@gmail.com> Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 13:27:50 -0000 SGkgTWFydGluLA0KDQpPbiAzIERlYyAyMDEzLCBhdCAxMzoyMCAsIE1hcnRpbiBTdGllbWVybGlu ZyB3cm90ZToNCj4+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpdCBpcyBhcyB5b3Ugc2F5OiB0 aGVyZSBpcyBhbiBpbXBsaWNpdA0KPj4gYXNzdW1wdGlvbiBvZiBhbiBleGlzdGluZyBvdmVybGF5 LCBhbmQgb25lIG9mIHRoZSBtb3JlIChpZiBub3QgdGhlDQo+PiBtb3N0KSBpbXBvcnRhbnQgdGFz a3Mgb2YgU0ZDIGlzIHByZWNpc2VseSBkZWZpbmluZyBob3cgbWV0YWRhdGEgaXMNCj4+IHRyYW5z ZmVycmVkIHVzaW5nIHRoZSBjb25zdHJ1Y3RzIHByb3ZpZGVkIGJ5IHRoZSBvdmVybGF5LCBhbmQg aG93DQo+DQo+IE9rLCBnb29kIHRvIGtub3cgYW5kIGl0IGlzIGV2ZW4gYmV0dGVyIGlmIHRoaXMg aXMgZG9jdW1lbnRlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIG9yIHdoZXJldmVyIGFwcHJvcHJpYXRl Lg0KPg0KPiBXaGlsZSBJIGNhbiBzZWUgdGhlIG9wZXJhdGlvbmFsIHJlYXNvbnMgZm9yIHRoaXMg YnkgdG9kYXksIEkgY29uc2lkZXIgdGhpcyBhcyBhIHVubmVjZXNzYXJ5IGxpbWl0YXRpb24gZm9y IHRoZSBmdXR1cmUuIElzIHRoaXMgZ3JvdXAgb25seSBjb25zaWRlcmluZyB0aGlzIG9yIGFyZSB0 aGVyZSB0aG91Z2h0cyB0byBnbyBiZXlvbmQgdGhpcz8NCg0KTXkgdGFrZSBoZXJlIGlzIHRoYXQg dGhlcmUgYXJlIGEgZmV3IG90aGVyIGdyb3VwcyBmb2N1c2VkIG9uIHRoaXMsIGFuZCB0aGF0IHRo ZSBncm91cCBzaG91bGQgc2VlayBmb3IgY29sbGFib3JhdGlvbiB3aXRoIHRoZW0uDQoNCj4+IHRo ZXNlIG1ldGFkYXRhIGNvbnRyb2wgZmxvd3Mgb24gdGhlIG92ZXJsYXkuIEhvdyB0aGUgb3Zlcmxh eSBpcw0KPj4gY29uZmlndXJlZCBpbiB0ZXJtcyBvZiBuZXR3b3JrIHBhdGhzIHNob3VsZCBiZSBv dXQgb2Ygc2NvcGUuDQo+DQo+IFNob3VsZG4ndCB0aGlzIGJlIG1lbnRpb25lZCBpbiB0aGUgY2hh cnRlcj8NCg0KSSB0aGluayBzbywgc3RhdGluZyB0aGUgYWJvdmUgbWVudGlvbmVkIGdyb3VwcyBh cyB0aG9zZSB3aGljaCBTRkMgc2hvdWxkIGJlIGFsaWduZWQgdG8uDQoNCkJlIGdvb2RlLA0KDQot LQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28g Ui4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Bl ei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2Jp bGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNh amUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25z dWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8g ZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2Vu ZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6 DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From bob.briscoe@bt.com Tue Dec 3 06:16:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6C01ADFC2 for ; Tue, 3 Dec 2013 06:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 qfU7427mXrc4 for ; Tue, 3 Dec 2013 06:16:48 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 628941ADFB8 for ; Tue, 3 Dec 2013 06:16:48 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 3 Dec 2013 14:16:44 +0000 Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 3 Dec 2013 14:16:43 +0000 Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 3 Dec 2013 14:16:34 +0000 Received: from BTP075694.jungle.bt.co.uk ([10.111.232.186]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id rB3EGWY2014910; Tue, 3 Dec 2013 14:16:32 GMT Message-ID: <201312031416.rB3EGWY2014910@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 3 Dec 2013 14:13:58 +0000 To: Martin Stiemerling , "Diego R. Lopez" From: Bob Briscoe In-Reply-To: <39926BEF-05E4-4D27-A5F3-F0ECB955689B@tid.es> References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <529DCC7F.9050005@gmail.com> <39926BEF-05E4-4D27-A5F3-F0ECB955689B@tid.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 14:16:51 -0000 Martin, You can forward packets between instances, but=20 you cannot forward packets between logical concepts. The last sentence of the first of these=20 definitions makes it clear that this is a chain=20 of logical concepts that may each be deployed as=20 a collection of instances, NOT a chain of=20 specific instances. The other definitions don't=20 say this, but they contradict it either. There can't be any assumptions about whether a=20 pre-configured overlay is assumed, if a service=20 chain is at least a level of indirection away from any actual routing. However, you're right that uni/bi-directional,=20 uni/multi-cast are as relevant for a chain of=20 concepts as for a chain of real instances. >>>In draft-quinn-sfc-problem-statement, Section 1.1 >>> Service Chain: A service chain defines the required functions and >>> associated order (service-function1 --> service-function 2) that >>> must be applied to packets and/or frames. A service chain does >>> not specify the network location or specific instance of service >>> functions (e.g. firewall1 vs. firewall2). HTH Bob At 13:27 03/12/2013, Diego R. Lopez wrote: >Hi Martin, > >On 3 Dec 2013, at 13:20 , Martin Stiemerling wrote: > >> My understanding is that it is as you say: there is an implicit > >> assumption of an existing overlay, and one of the more (if not the > >> most) important tasks of SFC is precisely defining how metadata is > >> transferred using the constructs provided by the overlay, and how > > > > Ok, good to know and it is even better if=20 > this is documented in the architecture or wherever appropriate. > > > > While I can see the operational reasons for=20 > this by today, I consider this as a unnecessary=20 > limitation for the future. Is this group only=20 > considering this or are there thoughts to go beyond this? > >My take here is that there are a few other=20 >groups focused on this, and that the group=20 >should seek for collaboration with them. > > >> these metadata control flows on the overlay. How the overlay is > >> configured in terms of network paths should be out of scope. > > > > Shouldn't this be mentioned in the charter? > >I think so, stating the above mentioned groups=20 >as those which SFC should be aligned to. > >Be goode, > >-- >"Esta vez no fallaremos, Doctor Infierno" > >Dr Diego R. Lopez >Telefonica I+D >http://people.tid.es/diego.lopez/ > >e-mail: diego@tid.es >Tel: +34 913 129 041 >Mobile: +34 682 051 091 >----------------------------------------- > > >________________________________ > >Este mensaje se dirige exclusivamente a su=20 >destinatario. Puede consultar nuestra pol=C3=ADtica=20 >de env=C3=ADo y recepci=C3=B3n de correo electr=C3=B3nico en el enlace= situado m=C3=A1s abajo. >This message is intended exclusively for its=20 >addressee. We only send and receive email on the basis of the terms set out= at: >http://www.tid.es/ES/PAGINAS/disclaimer.aspx >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc ________________________________________________________________ Bob Briscoe, BT=20 From narten@us.ibm.com Tue Dec 3 06:24:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CAC1ADF0F for ; Tue, 3 Dec 2013 06:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 03Sk56HgJjkv for ; Tue, 3 Dec 2013 06:24:55 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4601AC4C1 for ; Tue, 3 Dec 2013 06:24:55 -0800 (PST) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 3 Dec 2013 07:24:52 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 3 Dec 2013 07:24:50 -0700 Received: from b03cxnp08027.gho.boulder.ibm.com (b03cxnp08027.gho.boulder.ibm.com [9.17.130.19]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id EF21319D8087 for ; Tue, 3 Dec 2013 07:24:28 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08027.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rB3CMgdr36569206 for ; Tue, 3 Dec 2013 13:22:42 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rB3EOXBc004337 for ; Tue, 3 Dec 2013 07:24:33 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-76-142-36.mts.ibm.com [9.76.142.36]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rB3EOVOu004281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 07:24:32 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rB3EOVEL007522; Tue, 3 Dec 2013 09:24:31 -0500 Message-Id: <201312031424.rB3EOVEL007522@cichlid.raleigh.ibm.com> To: Martin Stiemerling In-reply-to: <529DA5D1.9020202@gmail.com> References: <529DA5D1.9020202@gmail.com> Comments: In-reply-to Martin Stiemerling message dated "Tue, 03 Dec 2013 10:35:13 +0100." Date: Tue, 03 Dec 2013 09:24:31 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13120314-0928-0000-0000-0000040378C0 Cc: nsc@ietf.org Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 14:24:57 -0000 Martin, > I have read through draft-quinn-sfc-problem-statement and > draft-quinn-sfc-arch and wonder about the slightly different definitions > of service function chain in both documents though that they share a > similar set of authors. I guess a much better terminology alignment is > required. See below for the excerpts from the drafts about the definitions. > Anyhow, here is my real point: > The definitions of SFC below always read to me as they are describing > the services functions and the order of them, but any further > information about whether there is a *network* path between the > functions is missing in the definition. It is assumed there is a path between service instances (what else would make sense?). To the degree that a service function instance needs to know details about that path (e.g, what type of tunnel - GRE, IP, VXLAN, etc.) that information is assumed to be known to the service function instances. How that information gets to the service function instance is a matter for the control/management protocols. The exact detail on how this is done is not really understood/known/decided yet by the SFC effort, but we expect it to become more clear over the next 6 months. The charter speaks to reevaluating the details of this. Where the service encap comes in is making sure that the data packets include enough information in them so that when data packets arrive at an SF instance, they can be processed correctly *and* can be forwarded to the next SF instance. The encap will have fields that identify a specific SF path for a given data packet that provides the "glue" between the data packet and whatever state information on the SF instance that is needed to process the packet correctly. > Also some abstract information > about the network path is missing, such as unidirectional, > bi-directional, unicast, multicast, etc. This information is a property of the specific SF path and will be known by all the entities that are involved in the service chain. Getting that info to those nodes is the job of the control/management plane. > Is this intentionally? I wouldn't say intentional so much as that the charter can't contain everything. This sort of detail would (IMO) go in the architecture document. > Is this a hidden assumption that the network overlay(s) is already > pre-configured between service nodes? Yes, if you mean pre-configured before data packets for a specific SF path start flowing. But this will almost certainly be configured "dynamically", i.e., when a "composite service" is instantiated. Thomas (with concurrence from Jim) From adrian@olddog.co.uk Tue Dec 3 06:28:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03C1ADFC2; Tue, 3 Dec 2013 06:28:02 -0800 (PST) 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 wcRU_6tj8L6v; Tue, 3 Dec 2013 06:28:01 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id CCDDE1ADBE5; Tue, 3 Dec 2013 06:28:00 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3ERtwc029013; Tue, 3 Dec 2013 14:27:55 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB3ERsl1029001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Dec 2013 14:27:55 GMT From: "Adrian Farrel" To: "'Ted Lemon'" , "'Jim Guichard \(jguichar\)'" References: In-Reply-To: Date: Tue, 3 Dec 2013 14:27:54 -0000 Message-ID: <0e9e01cef033$db63eb40$922bc1c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIlnKU5amiuy3tm9Y9y6iOUlpCAMQGBJ8aqmYkkxWA= Content-Language: en-gb Cc: nsc@ietf.org, iesg@ietf.org Subject: Re: [nsc] Ted Lemon's concern with charter text => BNG/PGW and Service Function X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:28:02 -0000 [Adding IESG into the thread so they can see the changes for the latest revision] Thanks Jim and Ted. I have replaced the first paragraph with Jim's new text and broken it up as Ted requested. > That looks great to me. But please, pretty please, break that giant paragraph up > into three bite-sized chunks. You could break once at "Deploying service > functions" and a second time at "Today, common". Cheers, Adrian From linda.dunbar@huawei.com Tue Dec 3 08:02:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1721A1F6F for ; Tue, 3 Dec 2013 08:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 yl-iOoHGH4dP for ; Tue, 3 Dec 2013 08:02:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09ED41A1F4C for ; Tue, 3 Dec 2013 08:02:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYO88532; Tue, 03 Dec 2013 16:02:48 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 16:01:57 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 16:02:46 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 08:02:40 -0800 From: Linda Dunbar To: "Diego R. Lopez" , Martin Stiemerling Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8Ar/agDTAMpejki63cQaDW6oYJpCw4EA///c5gA= Date: Tue, 3 Dec 2013 16:02:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com> References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> In-Reply-To: <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 03 Dec 2013 16:02:55 -0000 QXJlIHRoZSBvdmVybGF5IGNvbm5lY3Rpb25zIGJldHdlZW4gIlNlcnZpY2UgRnVuY3Rpb25zIiBz aW1pbGFyIHRvIHRvZGF5J3MgdHJhbnNwb3J0IGxheWVyIGJldHdlZW4gImhvc3RzIG9yIGFwcGxp Y2F0aW9ucyI/IA0KDQpUaGVyZSBhcmUgREEsIFNBLCBUQ1Agb3IgVURQIHBvcnRzJmZsYWdzLCBh bmQgb3RoZXIgaGVhZGVyIGZpZWxkcyAodG8gY2FycnkgdGhlIG1ldGFkYXRhKSwgYW5kIHRoZSBw YXlsb2FkIHRvIGNhcnJ5IHRoZSBvcmlnaW5hbCB0cmFmZmljIHRvIGJlIHRyZWF0ZWQgYnkgdGhl ICJzZXJ2aWNlIGZ1bmN0aW9ucyI/IA0KDQpMaW5kYQ0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBuc2MgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERpZWdvIFIuIExvcGV6DQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDAzLCAy MDEzIDQ6MDIgQU0NCj4gVG86IE1hcnRpbiBTdGllbWVybGluZw0KPiBDYzogPG5zY0BpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFtuc2NdIERlZmluaXRpb24gb2YgU2VydmljZSBDaGFpbnMgaW4g ZHJhZnQtcXVpbm4tc2ZjLQ0KPiB7cHJvYmxlbXxhcmNofSBhbmQgaW4gZ2VuZXJhbA0KPiANCj4g SGkgTWFydGluLA0KPiANCj4gTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IGl0IGlzIGFzIHlvdSBz YXk6IHRoZXJlIGlzIGFuIGltcGxpY2l0DQo+IGFzc3VtcHRpb24gb2YgYW4gZXhpc3Rpbmcgb3Zl cmxheSwgYW5kIG9uZSBvZiB0aGUgbW9yZSAoaWYgbm90IHRoZSBtb3N0KQ0KPiBpbXBvcnRhbnQg dGFza3Mgb2YgU0ZDIGlzIHByZWNpc2VseSBkZWZpbmluZyBob3cgbWV0YWRhdGEgaXMNCj4gdHJh bnNmZXJyZWQgdXNpbmcgdGhlIGNvbnN0cnVjdHMgcHJvdmlkZWQgYnkgdGhlIG92ZXJsYXksIGFu ZCBob3cgdGhlc2UNCj4gbWV0YWRhdGEgY29udHJvbCBmbG93cyBvbiB0aGUgb3ZlcmxheS4gSG93 IHRoZSBvdmVybGF5IGlzIGNvbmZpZ3VyZWQgaW4NCj4gdGVybXMgb2YgbmV0d29yayBwYXRocyBz aG91bGQgYmUgb3V0IG9mIHNjb3BlLg0KPiANCj4gQmUgZ29vZGUsDQo+IA0KPiBPbiAzIERlYyAy MDEzLCBhdCAxMDozNSAsIE1hcnRpbiBTdGllbWVybGluZyB3cm90ZToNCj4gDQo+ID4gSGkgYWxs LA0KPiA+DQo+ID4gSSBoYXZlIHJlYWQgdGhyb3VnaCBkcmFmdC1xdWlubi1zZmMtcHJvYmxlbS1z dGF0ZW1lbnQgYW5kIGRyYWZ0LQ0KPiBxdWlubi1zZmMtYXJjaCBhbmQgd29uZGVyIGFib3V0IHRo ZSBzbGlnaHRseSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2YNCj4gc2VydmljZSBmdW5jdGlvbiBj aGFpbiBpbiBib3RoIGRvY3VtZW50cyB0aG91Z2ggdGhhdCB0aGV5IHNoYXJlIGENCj4gc2ltaWxh ciBzZXQgb2YgYXV0aG9ycy4gSSBndWVzcyBhIG11Y2ggYmV0dGVyIHRlcm1pbm9sb2d5IGFsaWdu bWVudCBpcw0KPiByZXF1aXJlZC4gU2VlIGJlbG93IGZvciB0aGUgZXhjZXJwdHMgZnJvbSB0aGUg ZHJhZnRzIGFib3V0IHRoZQ0KPiBkZWZpbml0aW9ucy4NCj4gPg0KPiA+IEFueWhvdywgaGVyZSBp cyBteSByZWFsIHBvaW50Og0KPiA+DQo+ID4gVGhlIGRlZmluaXRpb25zIG9mIFNGQyBiZWxvdyBh bHdheXMgcmVhZCB0byBtZSBhcyB0aGV5IGFyZSBkZXNjcmliaW5nDQo+IHRoZSBzZXJ2aWNlcyBm dW5jdGlvbnMgYW5kIHRoZSBvcmRlciBvZiB0aGVtLCBidXQgYW55IGZ1cnRoZXINCj4gaW5mb3Jt YXRpb24gYWJvdXQgd2hldGhlciB0aGVyZSBpcyBhICpuZXR3b3JrKiBwYXRoIGJldHdlZW4gdGhl DQo+IGZ1bmN0aW9ucyBpcyBtaXNzaW5nIGluIHRoZSBkZWZpbml0aW9uLiBBbHNvIHNvbWUgYWJz dHJhY3QgaW5mb3JtYXRpb24NCj4gYWJvdXQgdGhlIG5ldHdvcmsgcGF0aCBpcyBtaXNzaW5nLCBz dWNoIGFzIHVuaWRpcmVjdGlvbmFsLCBiaS0NCj4gZGlyZWN0aW9uYWwsIHVuaWNhc3QsIG11bHRp Y2FzdCwgZXRjLg0KPiA+DQo+ID4gSXMgdGhpcyBpbnRlbnRpb25hbGx5Pw0KPiA+DQo+ID4gSXMg dGhpcyBhIGhpZGRlbiBhc3N1bXB0aW9uIHRoYXQgdGhlIG5ldHdvcmsgb3ZlcmxheShzKSBpcyBh bHJlYWR5DQo+IHByZS1jb25maWd1cmVkIGJldHdlZW4gc2VydmljZSBub2Rlcz8NCj4gPg0KPiA+ DQo+ID4NCj4gPiBIZXJlIGFyZSB0aGUgZXhjZXJwdHMgZm9yIHlvdXIgcmVmZXJlbmNlOg0KPiA+ DQo+ID4gSW4gZHJhZnQtcXVpbm4tc2ZjLXByb2JsZW0tc3RhdGVtZW50LCBTZWN0aW9uIDEuMQ0K PiA+ICAgICBTZXJ2aWNlIENoYWluOiAgQSBzZXJ2aWNlIGNoYWluIGRlZmluZXMgdGhlIHJlcXVp cmVkIGZ1bmN0aW9ucw0KPiBhbmQNCj4gPiAgICAgIGFzc29jaWF0ZWQgb3JkZXIgKHNlcnZpY2Ut ZnVuY3Rpb24xIC0tPiBzZXJ2aWNlLWZ1bmN0aW9uIDIpIHRoYXQNCj4gPiAgICAgIG11c3QgYmUg YXBwbGllZCB0byBwYWNrZXRzIGFuZC9vciBmcmFtZXMuICBBIHNlcnZpY2UgY2hhaW4gZG9lcw0K PiA+ICAgICAgbm90IHNwZWNpZnkgdGhlIG5ldHdvcmsgbG9jYXRpb24gb3Igc3BlY2lmaWMgaW5z dGFuY2Ugb2Ygc2VydmljZQ0KPiA+ICAgICAgZnVuY3Rpb25zIChlLmcuIGZpcmV3YWxsMSB2cy4g ZmlyZXdhbGwyKS4NCj4gPg0KPiA+IEluIGRyYWZ0LXF1aW5uLXNmYy1hcmNoLCBTZWN0aW9uIDEu MjoNCj4gPiAgIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQyk6ICBBIHNldCBvZiBzZXJ2aWNl IGZ1bmN0aW9ucyB0aGF0IGFyZQ0KPiB0bw0KPiA+ICAgYmUgYXBwbGllZCB0byBzZWxlY3RlZCB0 cmFmZmljIGluIGEgc3BlY2lmaWMgb3JkZXIuICBUaGUgaW1wbGllZA0KPiA+ICAgb3JkZXIgbWF5 IG5vdCBiZSBhIGxpbmVhciBwcm9ncmVzc2lvbiBhcyB0aGUgYXJjaGl0ZWN0dXJlIHdpbGwNCj4g PiAgIGFsbG93IGZvciBub2RlcyB0aGF0IGNvcHkgdG8gbW9yZSB0aGFuIG9uZSBicmFuY2guICBU aGUgdGVybQ0KPiA+ICAgc2VydmljZSBjaGFpbiBpcyBvZnRlbiB1c2VkIGFzIGEgc2hvcnRoYW5k IHZlcnNpb24gb2Ygc2VydmljZQ0KPiA+ICAgZnVuY3Rpb24gY2hhaW4uDQo+ID4NCj4gPiBJbiBk cmFmdC1xdWlubi1zZmMtYXJjaCwgU2VjdGlvbiAyLjENCj4gPiAic2VydmljZSBmdW5jdGlvbiBj aGFpbmluZyBjcmVhdGVzIGFuIGFic3RyYWN0ZWQgdmlldw0KPiA+ICAgb2YgYSBzZXJ2aWNlIGFu ZCBzcGVjaWZpZXMgdGhlIHNldCBvZiByZXF1aXJlZCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcw0KPiA+ ICAgd2VsbCBhcyB0aGUgb3JkZXIgaW4gd2hpY2ggdGhleSBtdXN0IGJlIGV4ZWN1dGVkLg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPg0KPiA+ICBNYXJ0aW4NCj4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5zYyBtYWlsaW5nIGxp c3QNCj4gPiBuc2NAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPiANCj4gDQo+IC0tDQo+ICJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0 b3IgSW5maWVybm8iDQo+IA0KPiBEciBEaWVnbyBSLiBMb3Bleg0KPiBUZWxlZm9uaWNhIEkrRA0K PiBodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCj4gDQo+IGUtbWFpbDogZGllZ29A dGlkLmVzDQo+IFRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQo+IE1vYmlsZTogKzM0IDY4MiAwNTEg MDkxDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IEVzdGUgbWVuc2FqZSBz ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlDQo+IGNvbnN1 bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBl bGVjdHLDs25pY28NCj4gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NCj4gVGhpcyBt ZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5 IHNlbmQNCj4gYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQg b3V0IGF0Og0KPiBodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2Mg bWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0K From linda.dunbar@huawei.com Tue Dec 3 08:22:31 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FA81A1F65 for ; Tue, 3 Dec 2013 08:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 51uQ_HoCadee for ; Tue, 3 Dec 2013 08:22:29 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 602D71A1F62 for ; Tue, 3 Dec 2013 08:22:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ04690; Tue, 03 Dec 2013 16:22:25 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 16:21:35 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 16:22:24 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 08:22:21 -0800 From: Linda Dunbar To: Ron Parker , Kevin J Ma , "Diego R. Lopez" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmCAAM3tAIAAC+iA//+e6/2AAO9wgIAAYteAgAEsV4H/+cMZYA== Date: Tue, 3 Dec 2013 16:22:20 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C28FDD@dfweml509-mbx.china.huawei.com> References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.96] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@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, 03 Dec 2013 16:22:32 -0000 Ron,=20 Thanks for the good description.=20 Just a question, sub-5-tuple operation (like your HTTP2.0 example) won't be= possible if communications are over TLS (Transport Layer Security), correc= t?=20 Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Friday, November 29, 2013 11:15 AM > To: Kevin J Ma; Diego R. Lopez > Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore > Subject: Re: [nsc] Progress toward WG formation >=20 > As Kevin mentioned, he and I had an offline discussion on this topic > and I'd like to summarize for the group what we discussed. >=20 > The issue at hand is whether the SFC architecture will include those > service functions that operate sub-5-tuple, at the transaction level. > Take, for example, HTTP2.0 where an HTTP2.0 aware service > function/classifier may choose to send some transactions on one chain > and others on another. Since these transactions were separated out > from a common five-tuple, in practical terms, all of those transaction- > level chains would need to return back to the original service function > (which perhaps is represented as two distrinct service functions -- > front-half and back half. >=20 > Kevin's basic question is whether the SFC architecture supports this > type of functionality and my view is categorically, yes. In fact 5- > tuple aware and transaction aware decision making is one of the prime > advantages over existing physical or VLAN-based chaining. >=20 > Clearly, there are additional complexities to do this (i.e., what is > the full encapsulation stackup for those packets that represent a > subset of the original 5-tuple?). As a group we would need to decide > what, if any, of that complexity was pushed down into the SFC > capability set or whether that complexity remains solely within the > domain of the affected service functions (i.e., do those service > functions that are chained after the HTTP2.0-aware classifier need to > implicitly know that they are indeed participating in such a scenario?). >=20 > Ron >=20 >=20 > ________________________________________ > From: Kevin J Ma [kevin.ma@azukisystems.com] > Sent: Thursday, November 28, 2013 10:08 AM > To: Diego R. Lopez; Ron Parker > Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore > Subject: RE: [nsc] Progress toward WG formation >=20 > Hi Ron/Diego, >=20 > Certainly there are ways to implement it, but again, my original > question > was simply: is this discussion in or out of scope? And I think the > simple > answer was/is no. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: Diego R. Lopez [mailto:diego@tid.es] > > Sent: Thursday, November 28, 2013 4:15 AM > > To: Ron Parker > > Cc: Kevin J Ma; nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore > > Subject: Re: [nsc] Progress toward WG formation > > > > Indeed. In a typical HTTP application scenario, you have by default > access > > to local and remote IP addresses, TCP port numbers, TLS identity > > parameters, and process environment variables, to name the essential > ones. > > I think it would be reasonable to expect that a SFC module (not to > use the > > accursed "layer": I fully agree with Melinda's previous statement on > the > > layering confusion) would be able to expose some information on its > > metadata. Anyway, that should be a design decision and certainly out > of > > scope for this group. > > > > Be goode, > > > > On 28 Nov 2013, at 03:57 , Ron Parker wrote: > > > > > I don't think there is a strict prohibition on seeing data from > lower > > layers. Even in a traditional user space application implementation > there > > is limited capability to get lower layer information via sockopt and > > recvmsg. > > > > > > Ron > > > > > > > > >> On Nov 27, 2013, at 7:45 PM, "Kevin J Ma" > > > wrote: > > >> > > >> Hi Melinda, > > >> > > >>> Unless someone's written something > > >>> *extremely* funky, as a rule encapsulations/headers/ > > >>> etc. are not available to the services "above" them. > > >> > > >> Indeed. That is precisely the problem. > > >> > > >> If I have a service that runs above that encapsulation layer, > > >> (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.) > > >> how does that service know what chain it's in, and how does > > >> it indicate to the lower encapsulation layer what chain to > > >> send it back out on if reclassification occurs? > > >> > > >> -- Kevin J. Ma > > >> > > >>> -----Original Message----- > > >>> From: Melinda Shore [mailto:melinda.shore@gmail.com] > > >>> Sent: Wednesday, November 27, 2013 7:03 PM > > >>> To: Kevin J Ma > > >>> Cc: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org > > >>> Subject: Re: [nsc] Progress toward WG formation > > >>> > > >>>> On 11/27/13 11:03 AM, Kevin J Ma wrote: > > >>>> My question was partially about whether it would always be the > IP > > >>> datagram, > > >>>> or whether it could be an ethernet frame, or a TCP payload, or > > whether > > >>> it > > >>>> might be just the HTTP entity body. > > >>> > > >>> Where I think you've wandered into the weeds is that you > > >>> appear to believe that the nsc "application" is going to > > >>> receive the entire datagram, from the Ethernet (or > > >>> whatever) frame up. Unless someone's written something > > >>> *extremely* funky, as a rule encapsulations/headers/ > > >>> etc. are not available to the services "above" them. That's > > >>> certainly true for all modern operating systems (TCP > > >>> does not see the Ethernet frame [or the IP datagram], and > > >>> so on). > > >>> > > >>> Melinda > > >> > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > > > > -- > > "Esta vez no fallaremos, Doctor Infierno" > > > > Dr Diego R. Lopez > > Telefonica I+D > > http://people.tid.es/diego.lopez/ > > > > e-mail: diego@tid.es > > Tel: +34 913 129 041 > > Mobile: +34 682 051 091 > > ----------------------------------------- > > > > > > ________________________________ > > > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar > > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en = el > enlace > > situado m=E1s abajo. > > This message is intended exclusively for its addressee. We only send > and > > receive email on the basis of the terms set out at: > > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Tue Dec 3 08:27:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E028F1A1F7C for ; Tue, 3 Dec 2013 08:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 uDmsLTK1BXFA for ; Tue, 3 Dec 2013 08:27:38 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC701A1F62 for ; Tue, 3 Dec 2013 08:27:38 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so21383701pbc.34 for ; Tue, 03 Dec 2013 08:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=toEnrHdfjsMNx8/ukx82yLvvr9F/2Xb3y3NLc/kgss8=; b=kr1AskQyiM9Fr6I486wJpDZK2DU90BHMcMxZTsyVG1Goft9F2imnN9hd+Sslc091Zu KiiCOtTqONyYlG+iDsITtnXw8SP7IC3mwlF3dyrIEpcjd/7qKqM4DIBHzvedjEc6NAJ0 WwoWQbNmYE8qs7oXUMJncm+JeUj2+WO9Gvz0ovQ1MoA0JU45zZi6tRGL/afg0kAH8IiZ JNqqZsBjH+2D8XbKafgyMesr4klPBZAy5BgGSEfpwHUQfq2TePkeYuKvSV5t759pjCCt AtJ93RrrLaO8lx216ks+P6+91l7FOZTZoDtJf/d8vWmSLJ/4wbEzXgKH/5Ik0vP0AVSJ oSxQ== X-Received: by 10.67.3.34 with SMTP id bt2mr76283322pad.3.1386088055772; Tue, 03 Dec 2013 08:27:35 -0800 (PST) Received: from spandex.local (216-67-50-85-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.50.85]) by mx.google.com with ESMTPSA id ae5sm143493329pac.18.2013.12.03.08.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 08:27:34 -0800 (PST) Message-ID: <529E0673.8090706@gmail.com> Date: Tue, 03 Dec 2013 07:27:31 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Linda Dunbar References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> <4A95BA014132FF49AE685FAB4B9F17F645C28FDD@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C28FDD@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Diego R. Lopez" , Ron Parker , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@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, 03 Dec 2013 16:27:41 -0000 On 12/3/13 7:22 AM, Linda Dunbar wrote: > Just a question, sub-5-tuple operation (like your HTTP2.0 example) > won't be possible if communications are over TLS (Transport Layer > Security), correct? There are a lot of reasons to convey that information in the 'signaling' (metadata) and this is prominent among them. The chief counter-argument is NAT, but NAT is generally a hairball issue, particularly in cases where you're describing a third party. To be clear, I haven't been arguing against including 5-tuple or other cross-layer data in the signaling data, but rather than they should be carried explicitly and encapsulated within the nsc message rather than handing the entire frame up the stack. Melinda From walter.haeffner@vodafone.com Tue Dec 3 08:34:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022CF1A802B for ; Tue, 3 Dec 2013 08:34:19 -0800 (PST) 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, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 0G-3ltrHtzqh for ; Tue, 3 Dec 2013 08:34:15 -0800 (PST) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F21A1F5B for ; Tue, 3 Dec 2013 08:34:14 -0800 (PST) Received: from mailint06.vodafone.com (localhost [127.0.0.1]) by mailout06.vodafone.com (Postfix) with ESMTP id 75875140CD3 for ; Tue, 3 Dec 2013 17:34:10 +0100 (CET) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint06.vodafone.com (Postfix) with ESMTPS id 62AFE140D2F; Tue, 3 Dec 2013 17:34:10 +0100 (CET) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.36]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0146.002; Tue, 3 Dec 2013 17:34:09 +0100 From: "Haeffner, Walter, Vodafone DE" To: Linda Dunbar , Jerome Moisand , Ron Parker , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIA== Date: Tue, 3 Dec 2013 16:34:08 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com> Accept-Language: de-DE, en-GB, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 03 Dec 2013 16:34:19 -0000 Hi Linda, I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction.=20 Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW. I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= .=20 Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function.=20 An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation. Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function.=20 Other example: A commercial load balancer may have more functions than just= load balancing. .... =20 What do you think? =20 Regards, Walter -----Urspr=FCngliche Nachricht----- Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar Gesendet: Montag, 2. Dezember 2013 19:10 An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Betreff: Re: [nsc] Ted Lemon's concern with charter text Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point.=20 Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions".=20 Linda=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > chain. It acts as both Service Classifier and Service Policy=20 > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > squarely a Service Function. Would you agree? >=20 > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 > if I know what you mean!) >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Hi, Jerome. >=20 > I agree with your definitions of service vs. service function. >=20 > Regarding functions like PGW, in the upstream direction for user=20 > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment=20 > model. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Issue#1: I think we have to be careful to not use the word 'service'=20 > to speak of a given network function. >=20 > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer. Something that you subscribe to, something that=20 > you benefit from, something that you may be billed for, something that=20 > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many=20 > network functions and related systems, without the end user knowing. >=20 > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > Service Function! Meaning a network function that directly helps in=20 > providing service-related processing and service (profile)=20 > differentiation. It's just a component though, not the entire Service=20 > as perceived by the end user. >=20 > And Ron, I would suggest to avoid speaking of mid-box (or=20 > middleboxes), as this term has a connotation that would seem to=20 > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 > viewed as 'middlebox', and yet, they are *the* primary Service=20 > Function in today's broadband networks). >=20 > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use=20 > traffic via a constrained path, and well, the service function does=20 > remain on the data path (granted, the data path changed from a=20 > 'shortest path routed' to a more constrained path, but it's still a=20 > data path!). >=20 > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is=20 > actually fine, if not better (even if the last sentence 'direct data path= ' > terminology isn't that great either). It also seems to me that we've=20 > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing=20 > paragraph and say: >=20 > << Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through service functions=20 > (physical or virtualized), wherever they are deployed.>> >=20 > And then, during the actual work, for sure, we'll need to settle on=20 > clear definitions for 'Service', 'Service Function', etc. >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Adrian, >=20 > I think Ted's text is a very nice summary of what we are trying to=20 > accomplish. >=20 > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly=20 > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > proxy, but not to an explicit HTTP proxy). >=20 > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall=20 > > filtering, load balancing and transactional proxies such as spam filte= rs. >=20 > Could become: >=20 > "Network service providers, in addition to delivering IP connectivity,=20 > frequently provide transparent services such as firewall filtering,=20 > load balancing and transactional proxies such as spam filters." >=20 > We may want to strike or replace load balancing as that may not be an=20 > actual transparent service but rather a building block for some actual=20 > transport service -- open to suggestions on this verbage. >=20 >=20 > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. >=20 > Could become: >=20 > "Today, a common deployment model is to insert various mid-boxes on=20 > the data-forwarding path between communicating peers." >=20 >=20 >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text >=20 > Hi, >=20 > During IESG review Ted and I had a bit of an exchange about the=20 > meaning of "a service" and the "layer at which a service chain can be app= lied". >=20 > Ted was looking for some text to clarify this in the in the charter=20 > and suggests replacing the entire first paragraph with... >=20 > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall filt= ering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with=20 > > the introduction of virtualization, network overlays, and orchestration= . > > > > Service delivery is currently both a technical and an=20 > > organizational challenge that involves significant modification to=20 > > the network configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of=20 > > service functions that are deployed at different points within a=20 > > network. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. Going forward,=20 > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. >=20 > This is only a strawman from Ted (and thanks to him for proposing=20 > text), and we should not assume that it is immutable. >=20 > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? >=20 > Opinions please. >=20 > Cheers, > Adrian >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From S.Majee@f5.com Tue Dec 3 23:08:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516231AE054 for ; Tue, 3 Dec 2013 23:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 2AIy8z1wVfi3 for ; Tue, 3 Dec 2013 23:08:40 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E588F1AE053 for ; Tue, 3 Dec 2013 23:08:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,822,1378857600"; d="scan'208";a="90933802" X-IPAS-Result: AqIEAPPTnlLAqArr/2dsb2JhbABagz9TuHWBNXSCJQEBAQEDAQEBYgkLDAQCAQgNBAQBAQsCGwcnCxQJCAIEAQ0FCIgGwR4TBI5NMQcGgxqBEwOJCpV2jlCCKg Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 04 Dec 2013 07:08:37 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 23:08:36 -0800 From: Sumandra Majee To: "Haeffner, Walter, Vodafone DE" , "Linda Dunbar" , Jerome Moisand , "Ron Parker" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzM Date: Wed, 4 Dec 2013 07:08:35 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 07:08:44 -0000 Hello Haeffner,=0A= =0A= You are correct that a device like PGW, BNG or Load Balancer may offer mult= iple service. For example commercial load balancer can offer header enrichm= ent, TCP optimization and quite an array of steering functionality. They ca= n and do offer custom policy engines and such. =0A= =0A= Another way of putting this is that a service-node may offer multiple disti= nct services. The local box can select a specific service based on the loca= l policy. In my head I visualizing a service node that has one ingress and= one egress but can offer multiple service inside that local entity. =0A= =0A= I hope that would be possible as per this WG. =0A= =0A= =0A= ________________________________________=0A= From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone DE= [walter.haeffner@vodafone.com]=0A= Sent: Tuesday, December 03, 2013 8:34 AM=0A= To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf= .org=0A= Cc: Ted Lemon=0A= Subject: Re: [nsc] Ted Lemon's concern with charter text=0A= =0A= Hi Linda,=0A= =0A= I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction.=0A= =0A= Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW.=0A= =0A= I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= .=0A= =0A= Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function.=0A= =0A= An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation.=0A= =0A= Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function.=0A= =0A= Other example: A commercial load balancer may have more functions than just= load balancing. ....=0A= =0A= What do you think?=0A= =0A= Regards, Walter=0A= =0A= =0A= -----Urspr=FCngliche Nachricht-----=0A= Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar=0A= Gesendet: Montag, 2. Dezember 2013 19:10=0A= An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org=0A= Cc: Ted Lemon=0A= Betreff: Re: [nsc] Ted Lemon's concern with charter text=0A= =0A= Jerome,=0A= =0A= I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point.=0A= =0A= Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions".=0A= =0A= Linda=0A= =0A= > -----Original Message-----=0A= > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand=0A= > Sent: Monday, December 02, 2013 11:58 AM=0A= > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org=0A= > Cc: Ted Lemon=0A= > Subject: Re: [nsc] Ted Lemon's concern with charter text=0A= >=0A= > Well, the PGW (or a BNG for wireline) is the starting point of the=0A= > chain. It acts as both Service Classifier and Service Policy=0A= > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=0A= > squarely a Service Function. Would you agree?=0A= >=0A= > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=0A= > if I know what you mean!)=0A= >=0A= > -----Original Message-----=0A= > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= > Sent: Monday, December 02, 2013 12:53 PM=0A= > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org=0A= > Cc: Ted Lemon=0A= > Subject: RE: [nsc] Ted Lemon's concern with charter text=0A= >=0A= > Hi, Jerome.=0A= >=0A= > I agree with your definitions of service vs. service function.=0A= >=0A= > Regarding functions like PGW, in the upstream direction for user=0A= > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is=0A= > therefore not in need of any traffic steering. In the downstream=0A= > direction, the PGW represents itself as a PE router that reaches the=0A= > subscribers. Most of the interest, today, around the mobile use case=0A= > is for transparent middlebox functions that reside between the PGW and=0A= > the Internet. The set of service functions is typically called the=0A= > "Gi LAN", a name that more or less implies the present day deployment=0A= > model.=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Jerome Moisand [mailto:jmoisand@juniper.net]=0A= > Sent: Monday, December 02, 2013 11:35 AM=0A= > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org=0A= > Cc: Ted Lemon=0A= > Subject: RE: [nsc] Ted Lemon's concern with charter text=0A= >=0A= > Issue#1: I think we have to be careful to not use the word 'service'=0A= > to speak of a given network function.=0A= >=0A= > Personally, I always use the word 'service' as something perceived by=0A= > the end user/customer. Something that you subscribe to, something that=0A= > you benefit from, something that you may be billed for, something that=0A= > may require customer care interactions. This is a 'black box'=0A= > perspective, the Network Service Provider (or IT department inside an=0A= > Enterprise) can then implement such service in many ways, using many=0A= > network functions and related systems, without the end user knowing.=0A= >=0A= > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=0A= > Service Function! Meaning a network function that directly helps in=0A= > providing service-related processing and service (profile)=0A= > differentiation. It's just a component though, not the entire Service=0A= > as perceived by the end user.=0A= >=0A= > And Ron, I would suggest to avoid speaking of mid-box (or=0A= > middleboxes), as this term has a connotation that would seem to=0A= > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=0A= > viewed as 'middlebox', and yet, they are *the* primary Service=0A= > Function in today's broadband networks).=0A= >=0A= > Issue #2: I understand what Ted is trying to say with the 'in-path'=0A= > aspect, but fact is service (function) chaining is about steering use=0A= > traffic via a constrained path, and well, the service function does=0A= > remain on the data path (granted, the data path changed from a=0A= > 'shortest path routed' to a more constrained path, but it's still a=0A= > data path!).=0A= >=0A= > =3D=3D=3D=0A= > I don't know, seems to me that the existing first paragraph is=0A= > actually fine, if not better (even if the last sentence 'direct data path= '=0A= > terminology isn't that great either). It also seems to me that we've=0A= > been hair-splitting for a while now, and maybe we should just move on...= =0A= > I would just suggest to simplify the last sentence of the existing=0A= > paragraph and say:=0A= >=0A= > << Going forward, however, there is a desire to move to a different=0A= > model, where traffic can be steered through service functions=0A= > (physical or virtualized), wherever they are deployed.>>=0A= >=0A= > And then, during the actual work, for sure, we'll need to settle on=0A= > clear definitions for 'Service', 'Service Function', etc.=0A= >=0A= > -----Original Message-----=0A= > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker=0A= > Sent: Monday, December 02, 2013 10:03 AM=0A= > To: adrian@olddog.co.uk; nsc@ietf.org=0A= > Cc: Ted Lemon=0A= > Subject: Re: [nsc] Ted Lemon's concern with charter text=0A= >=0A= > Adrian,=0A= >=0A= > I think Ted's text is a very nice summary of what we are trying to=0A= > accomplish.=0A= >=0A= > He does use the term "in-path" which could use some elaboration, IMO.=0A= > I feel that SFC applies to transparent mid-boxes and not to explicitly=0A= > addressed service functions (i.e., SFC applies to a transparent HTTP=0A= > proxy, but not to an explicit HTTP proxy).=0A= >=0A= > > Network service providers, in addition to delivering IP=0A= > > connectivity, frequently provide in-path services such as firewall=0A= > > filtering, load balancing and transactional proxies such as spam filte= rs.=0A= >=0A= > Could become:=0A= >=0A= > "Network service providers, in addition to delivering IP connectivity,=0A= > frequently provide transparent services such as firewall filtering,=0A= > load balancing and transactional proxies such as spam filters."=0A= >=0A= > We may want to strike or replace load balancing as that may not be an=0A= > actual transparent service but rather a building block for some actual=0A= > transport service -- open to suggestions on this verbage.=0A= >=0A= >=0A= > > Today, a common deployment model has service functions inserted on=0A= > > the data-forwarding path between communicating peers.=0A= >=0A= > Could become:=0A= >=0A= > "Today, a common deployment model is to insert various mid-boxes on=0A= > the data-forwarding path between communicating peers."=0A= >=0A= >=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel=0A= > Sent: Monday, December 02, 2013 7:21 AM=0A= > To: nsc@ietf.org=0A= > Cc: Ted Lemon=0A= > Subject: [nsc] Ted Lemon's concern with charter text=0A= >=0A= > Hi,=0A= >=0A= > During IESG review Ted and I had a bit of an exchange about the=0A= > meaning of "a service" and the "layer at which a service chain can be app= lied".=0A= >=0A= > Ted was looking for some text to clarify this in the in the charter=0A= > and suggests replacing the entire first paragraph with...=0A= >=0A= > > Network service providers, in addition to delivering IP=0A= > > connectivity, frequently provide in-path services such as firewall filt= ering, load=0A= > > balancing and transactional proxies such as spam filters. Delivery= =0A= > > of these types of services is undergoing significant change with=0A= > > the introduction of virtualization, network overlays, and orchestration= .=0A= > >=0A= > > Service delivery is currently both a technical and an=0A= > > organizational challenge that involves significant modification to=0A= > > the network configuration, impacting the speed at which services can be= =0A= > > deployed and increasing operational costs. Such services are=0A= > > typically implemented by the ordered combination of a number of=0A= > > service functions that are deployed at different points within a=0A= > > network.=0A= > >=0A= > > Today, a common deployment model has service functions inserted on=0A= > > the data-forwarding path between communicating peers. Going forward,=0A= > > however, there is a desire to move to a different model, where=0A= > service=0A= > > functions, whether physical or virtualized, are not required to=0A= > reside=0A= > > on the direct data path and traffic is instead steered through=0A= > service=0A= > > functions, wherever they are deployed.=0A= >=0A= > This is only a strawman from Ted (and thanks to him for proposing=0A= > text), and we should not assume that it is immutable.=0A= >=0A= > I think the way to look at this is:=0A= > - Is there anything in the new text we disagree with?=0A= > - Would making this change cause harm?=0A= > - Could this change be improved still further?=0A= >=0A= > Opinions please.=0A= >=0A= > Cheers,=0A= > Adrian=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From mls.ietf@gmail.com Wed Dec 4 00:58:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67931AE0B9 for ; Wed, 4 Dec 2013 00:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 gDiRG0GIi0xf for ; Wed, 4 Dec 2013 00:58:49 -0800 (PST) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 46CBA1ADFFF for ; Wed, 4 Dec 2013 00:58:49 -0800 (PST) Received: by mail-ea0-f178.google.com with SMTP id d10so10391370eaj.23 for ; Wed, 04 Dec 2013 00:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JC+jIJBU9dhC7RehbYHUXfhduQUYoSrnjLdQ9N53ztg=; b=QiYJhkHh/o7CkndOL/3c60Fe/7nsDy5C57hKeOZoWcFvNLfthpqYYOuphbFeeigBKI SHJaMSEtmksVexOW74soWkDGSrPLhK5r93PAIi+Czp2gtMZNP/SRy0geTpBFBcdkqAnk qSrPZ3rOA92Iv8TdfK7RSdGvCfRQ2+JW5016LsQJ06kONEERx+9rbmb1GE/RnwyFx0Pw pdaWwFq28LHVccVqdSuwTBnMJXM7pXnlpVqqhb62c3mp43k70kUWUrYvteOgwiOJzoJ8 trdIXxiN5+rUPwOJJtpA5rVVRM3enRfa0jRGd1xEKt5RpOP1/1mX6XwlOGoCxHMiEaNm iiQw== X-Received: by 10.15.27.132 with SMTP id p4mr64194eeu.113.1386147525969; Wed, 04 Dec 2013 00:58:45 -0800 (PST) Received: from [10.1.1.190] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id l4sm55968765een.13.2013.12.04.00.58.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 00:58:45 -0800 (PST) Message-ID: <529EEEC3.2030708@gmail.com> Date: Wed, 04 Dec 2013 09:58:43 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Bob Briscoe , "Diego R. Lopez" References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <529DCC7F.9050005@gmail.com> <39926BEF-05E4-4D27-A5F3-F0ECB955689B@tid.es> <201312031416.rB3EGWY2014910@bagheera.jungle.bt.co.uk> In-Reply-To: <201312031416.rB3EGWY2014910@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 08:58:51 -0000 Bob, On 12/03/2013 03:13 PM, Bob Briscoe wrote: > Martin, > > You can forward packets between instances, but you cannot forward > packets between logical concepts. Indeed and that's clear to me just from the beginning. > > The last sentence of the first of these definitions makes it clear that > this is a chain of logical concepts that may each be deployed as a > collection of instances, NOT a chain of specific instances. The other > definitions don't say this, but they contradict it either. Right it is all about abstractions but abstractions need to be complete in themselves. And the incomplete definitions do not make the overall understanding better. > > There can't be any assumptions about whether a pre-configured overlay is > assumed, if a service chain is at least a level of indirection away from > any actual routing. Right, but I got the impression when reading the drafts that the pre-configuration is implicitly assumed. My point is just that the actual solution/protocol should not rely on the assumption that the overlay is just there. It should should allow for it, but not exclude it. > > However, you're right that uni/bi-directional, uni/multi-cast are as > relevant for a chain of concepts as for a chain of real instances. Jep and hopefully to be added to the definition anytime soon. > >>>> In draft-quinn-sfc-problem-statement, Section 1.1 >>>> Service Chain: A service chain defines the required functions and >>>> associated order (service-function1 --> service-function 2) that >>>> must be applied to packets and/or frames. A service chain does >>>> not specify the network location or specific instance of service >>>> functions (e.g. firewall1 vs. firewall2). > > HTH It did -- thanks! Martin > > > Bob > > > At 13:27 03/12/2013, Diego R. Lopez wrote: >> Hi Martin, >> >> On 3 Dec 2013, at 13:20 , Martin Stiemerling wrote: >> >> My understanding is that it is as you say: there is an implicit >> >> assumption of an existing overlay, and one of the more (if not the >> >> most) important tasks of SFC is precisely defining how metadata is >> >> transferred using the constructs provided by the overlay, and how >> > >> > Ok, good to know and it is even better if this is documented in the >> architecture or wherever appropriate. >> > >> > While I can see the operational reasons for this by today, I >> consider this as a unnecessary limitation for the future. Is this >> group only considering this or are there thoughts to go beyond this? >> >> My take here is that there are a few other groups focused on this, and >> that the group should seek for collaboration with them. >> >> >> these metadata control flows on the overlay. How the overlay is >> >> configured in terms of network paths should be out of scope. >> > >> > Shouldn't this be mentioned in the charter? >> >> I think so, stating the above mentioned groups as those which SFC >> should be aligned to. >> >> Be goode, >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede >> consultar nuestra política de envío y recepción de correo >> electrónico en el enlace situado más abajo. >> This message is intended exclusively for its addressee. We only send >> and receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > ________________________________________________________________ > Bob Briscoe, BT From mls.ietf@gmail.com Wed Dec 4 01:23:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CD91AE227 for ; Wed, 4 Dec 2013 01:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 YqwxkAjPmQNw for ; Wed, 4 Dec 2013 01:23:53 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id EB8481AE229 for ; Wed, 4 Dec 2013 01:23:32 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id 6so6601817bkj.10 for ; Wed, 04 Dec 2013 01:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tuF4f67Rzqm3WrjhriIu0nu+yVY70hK2Jfh9TU8cqiw=; b=q8dC9Sq5i5b0jFLPsvPJp+GQJt0myqVO4t7kQP2PTFLMsGPm25sOXl5+C+Js3EhUPo 0FDaUK43cUHx4RgedNWGckIrrjigYo8+CNuQxXPIadANNd858nBEv3GNAy4yff1dk89y p7S6jYBl7ghrOEbmtsu/pmybwuOp+oynj34wj9THtl1KJucKbxMDpcpZhUCshBJJgjCB RQz1vrBJVYLE2dKgO8L7jHhOh1xhQ8tticSPwg1cqfuufildo+9VYrSTb50OWl0LM9wf LD9rJDek1P2jv5rpaamIUyV1+CgxMsaQWGQ9IJBVsUE56/NURuZklcydegYQSQR3NTzf 803A== X-Received: by 10.204.122.137 with SMTP id l9mr7741673bkr.23.1386149009489; Wed, 04 Dec 2013 01:23:29 -0800 (PST) Received: from [10.1.1.190] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id lr9sm24483356bkb.2.2013.12.04.01.23.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:23:28 -0800 (PST) Message-ID: <529EF48F.7080902@gmail.com> Date: Wed, 04 Dec 2013 10:23:27 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Thomas Narten References: <529DA5D1.9020202@gmail.com> <201312031424.rB3EOVEL007522@cichlid.raleigh.ibm.com> In-Reply-To: <201312031424.rB3EOVEL007522@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nsc@ietf.org Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 09:23:55 -0000 Thomas, On 12/03/2013 03:24 PM, Thomas Narten wrote: > Martin, > >> I have read through draft-quinn-sfc-problem-statement and >> draft-quinn-sfc-arch and wonder about the slightly different definitions >> of service function chain in both documents though that they share a >> similar set of authors. I guess a much better terminology alignment is >> required. See below for the excerpts from the drafts about the definitions. > >> Anyhow, here is my real point: > >> The definitions of SFC below always read to me as they are describing >> the services functions and the order of them, but any further >> information about whether there is a *network* path between the >> functions is missing in the definition. > > It is assumed there is a path between service instances (what else > would make sense?). To the degree that a service function instance > needs to know details about that path (e.g, what type of tunnel - GRE, > IP, VXLAN, etc.) that information is assumed to be known to the > service function instances. How that information gets to the service I am with you on the 'need anyway to have a path between the instance'. However, as said in my response to Bob's email, I am fine if SFC is working SFC where the path is pre-configured ahead of time of any SFC configuration but SFC should also support the case where the path is configured on demand just before the SFC is instantiated. > function instance is a matter for the control/management > protocols. The exact detail on how this is done is not really Ok, that's covered by the charter in item no. 4. > understood/known/decided yet by the SFC effort, but we expect it to > become more clear over the next 6 months. The charter speaks to > reevaluating the details of this. With respect to the reevaluation, are you referring to this sentence out of the charter: "The working group will examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to the components of the service function chaining architecture". I'm not sure that this reads like reevaluate to me, but it is good to know. > > Where the service encap comes in is making sure that the data packets > include enough information in them so that when data packets arrive at > an SF instance, they can be processed correctly *and* can be forwarded > to the next SF instance. The encap will have fields that identify a > specific SF path for a given data packet that provides the "glue" > between the data packet and whatever state information on the SF > instance that is needed to process the packet correctly. +1 > >> Also some abstract information >> about the network path is missing, such as unidirectional, >> bi-directional, unicast, multicast, etc. > > This information is a property of the specific SF path and will be > known by all the entities that are involved in the service > chain. Getting that info to those nodes is the job of the > control/management plane. I would say that those properties are already part of the abstract definition, i.e., the definition of the service chain. The actual instantiation has to take care how to implement multicast, but the fact that a link in the SFC requires a certain network property is part of the abstraction. > >> Is this intentionally? > > I wouldn't say intentional so much as that the charter can't contain > everything. This sort of detail would (IMO) go in the architecture document. Agreed for the charter, I am just worried about the documents, but that can be worked out. > >> Is this a hidden assumption that the network overlay(s) is already >> pre-configured between service nodes? > > Yes, if you mean pre-configured before data packets for a specific SF > path start flowing. But this will almost certainly be configured > "dynamically", i.e., when a "composite service" is instantiated. Ok, looks we are on the same page. Thank you, Martin From mls.ietf@gmail.com Wed Dec 4 01:29:04 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5571AE227 for ; Wed, 4 Dec 2013 01:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_55=0.6, 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 Z8kW2LyvgQcZ for ; Wed, 4 Dec 2013 01:29:03 -0800 (PST) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8DE1AE216 for ; Wed, 4 Dec 2013 01:29:03 -0800 (PST) Received: by mail-bk0-f51.google.com with SMTP id 6so6385621bkj.24 for ; Wed, 04 Dec 2013 01:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PnC53tknpagJ+IX4d84oSm/QB6/EMKZLjQ429zI/p1g=; b=cFxrHGOA6Ng3IeninQb1cRKjTMdyUi4am4d9CynIvwhr2WgRVxBO4/0dOEhz2h4XxN IFsgUMjbABszwhYGYlzdeHrC+IFGEf7fOLHhSkEpkh8hSX5LPOFVFlSKQJjIbj6l4Dto SerO+GiSLeJftamrVfRZd+X5AWuaq6YTiGIrDHRh38j4T7QdDWjYhmbhqqtISwQgV3c7 hCfMmZI/XW4G61poRODdKDvEhoSreibkxHzgG9VGkTc0kt2xY9ldRY6tOySebZIM+p9Q NZm5ZHpzjQpPnD6LUDlyjj6VEJNyGMvxgLglNe1XAVvapYRkVscNP2qP21Xl2XnBjmLr N0tw== X-Received: by 10.205.104.4 with SMTP id dk4mr99521bkc.108.1386149339792; Wed, 04 Dec 2013 01:28:59 -0800 (PST) Received: from [10.1.1.190] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id o5sm28788286bkz.4.2013.12.04.01.28.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:28:58 -0800 (PST) Message-ID: <529EF5D9.5040509@gmail.com> Date: Wed, 04 Dec 2013 10:28:57 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Linda Dunbar , "Diego R. Lopez" References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 09:29:04 -0000 On 12/03/2013 05:02 PM, Linda Dunbar wrote: > Are the overlay connections between "Service Functions" similar to > today's transport layer between "hosts or applications"? > > There are DA, SA, TCP or UDP ports&flags, and other header fields (to > carry the metadata), and the payload to carry the original traffic to > be treated by the "service functions"? I can see, for instance, UDP as one way of interconnecting functions, but I don't see that reusing the transport protocol headers for carrying meta-data is the right thing. Martin > > Linda > > > >> -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] >> On Behalf Of Diego R. Lopez Sent: Tuesday, December 03, 2013 4:02 >> AM To: Martin Stiemerling Cc: Subject: Re: [nsc] >> Definition of Service Chains in draft-quinn-sfc- {problem|arch} and >> in general >> >> Hi Martin, >> >> My understanding is that it is as you say: there is an implicit >> assumption of an existing overlay, and one of the more (if not the >> most) important tasks of SFC is precisely defining how metadata is >> transferred using the constructs provided by the overlay, and how >> these metadata control flows on the overlay. How the overlay is >> configured in terms of network paths should be out of scope. >> >> Be goode, >> >> On 3 Dec 2013, at 10:35 , Martin Stiemerling wrote: >> >>> Hi all, >>> >>> I have read through draft-quinn-sfc-problem-statement and draft- >> quinn-sfc-arch and wonder about the slightly different definitions >> of service function chain in both documents though that they share >> a similar set of authors. I guess a much better terminology >> alignment is required. See below for the excerpts from the drafts >> about the definitions. >>> >>> Anyhow, here is my real point: >>> >>> The definitions of SFC below always read to me as they are >>> describing >> the services functions and the order of them, but any further >> information about whether there is a *network* path between the >> functions is missing in the definition. Also some abstract >> information about the network path is missing, such as >> unidirectional, bi- directional, unicast, multicast, etc. >>> >>> Is this intentionally? >>> >>> Is this a hidden assumption that the network overlay(s) is >>> already >> pre-configured between service nodes? >>> >>> >>> >>> Here are the excerpts for your reference: >>> >>> In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain: >>> A service chain defines the required functions >> and >>> associated order (service-function1 --> service-function 2) that >>> must be applied to packets and/or frames. A service chain does >>> not specify the network location or specific instance of service >>> functions (e.g. firewall1 vs. firewall2). >>> >>> In draft-quinn-sfc-arch, Section 1.2: Service Function Chain >>> (SFC): A set of service functions that are >> to >>> be applied to selected traffic in a specific order. The implied >>> order may not be a linear progression as the architecture will >>> allow for nodes that copy to more than one branch. The term >>> service chain is often used as a shorthand version of service >>> function chain. >>> >>> In draft-quinn-sfc-arch, Section 2.1 "service function chaining >>> creates an abstracted view of a service and specifies the set of >>> required service functions as well as the order in which they >>> must be executed. >>> >>> >>> >>> Thanks, >>> >>> Martin _______________________________________________ nsc >>> mailing list nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> >> -- "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 >> 091 ----------------------------------------- >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede >> consultar nuestra política de envío y recepción de correo >> electrónico en el enlace situado más abajo. This message is >> intended exclusively for its addressee. We only send and receive >> email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From hongyu.li@huawei.com Wed Dec 4 01:41:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A2A1AE09A for ; Wed, 4 Dec 2013 01:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 Nqu3ZqUpkHYT for ; Wed, 4 Dec 2013 01:41:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4FA1ADFCC for ; Wed, 4 Dec 2013 01:41:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYP55261; Wed, 04 Dec 2013 09:41:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 09:40:53 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 09:41:39 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.131]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 17:41:35 +0800 From: "Hongyu Li (Julio)" To: Martin Stiemerling , Thomas Narten Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8NKUm98JJxjcPkq+Johjhk7PQZpDxwgw Date: Wed, 4 Dec 2013 09:41:35 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9A3FE1@SZXEMA509-MBX.china.huawei.com> References: <529DA5D1.9020202@gmail.com> <201312031424.rB3EOVEL007522@cichlid.raleigh.ibm.com> <529EF48F.7080902@gmail.com> In-Reply-To: <529EF48F.7080902@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 09:41:51 -0000 Rm9yIHRoZSBwYXJ0ICJwYXRoIGJldHdlZW4gaW5zdGFuY2UiLCBteSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgU0ZDIGlzIHRyeWluZyB0byBkZWZpbmUgYW4gb3ZlcmxheSB3aGVyZSBwYXRoIG9yIHJl YWNoYWJpbGl0eSBvZiBpbnN0YW5jZSBzaG91bGQgYmUgcHJvdmlkZWQgYnkgdW5kZXJsYXkgbGF5 ZXIuIEluIG90aGVyIHdvcmRzLCBpbnN0YW5jZXMgb2YgU2VydmljZSBGdW5jdGlvbnMgYmV0d2Vl biBob3BzIG9uIGEgQ2hhaW4gc2hvdWxkIGJlIHJlYWNoYWJsZSBvbiB0aGUgdW5kZXJsYXkgbmV0 d29yayBvZiBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4uDQoNCkhvbmd5dQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNYXJ0aW4gU3RpZW1lcmxpbmcNClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1i ZXIgMDQsIDIwMTMgNToyMyBQTQ0KVG86IFRob21hcyBOYXJ0ZW4NCkNjOiBuc2NAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbbnNjXSBEZWZpbml0aW9uIG9mIFNlcnZpY2UgQ2hhaW5zIGluIGRyYWZ0 LXF1aW5uLXNmYy17cHJvYmxlbXxhcmNofSBhbmQgaW4gZ2VuZXJhbA0KDQpUaG9tYXMsDQoNCg0K T24gMTIvMDMvMjAxMyAwMzoyNCBQTSwgVGhvbWFzIE5hcnRlbiB3cm90ZToNCj4gTWFydGluLA0K Pg0KPj4gSSBoYXZlIHJlYWQgdGhyb3VnaCBkcmFmdC1xdWlubi1zZmMtcHJvYmxlbS1zdGF0ZW1l bnQgYW5kIA0KPj4gZHJhZnQtcXVpbm4tc2ZjLWFyY2ggYW5kIHdvbmRlciBhYm91dCB0aGUgc2xp Z2h0bHkgZGlmZmVyZW50IA0KPj4gZGVmaW5pdGlvbnMgb2Ygc2VydmljZSBmdW5jdGlvbiBjaGFp biBpbiBib3RoIGRvY3VtZW50cyB0aG91Z2ggdGhhdCANCj4+IHRoZXkgc2hhcmUgYSBzaW1pbGFy IHNldCBvZiBhdXRob3JzLiBJIGd1ZXNzIGEgbXVjaCBiZXR0ZXIgDQo+PiB0ZXJtaW5vbG9neSBh bGlnbm1lbnQgaXMgcmVxdWlyZWQuIFNlZSBiZWxvdyBmb3IgdGhlIGV4Y2VycHRzIGZyb20gdGhl IGRyYWZ0cyBhYm91dCB0aGUgZGVmaW5pdGlvbnMuDQo+DQo+PiBBbnlob3csIGhlcmUgaXMgbXkg cmVhbCBwb2ludDoNCj4NCj4+IFRoZSBkZWZpbml0aW9ucyBvZiBTRkMgYmVsb3cgYWx3YXlzIHJl YWQgdG8gbWUgYXMgdGhleSBhcmUgZGVzY3JpYmluZyANCj4+IHRoZSBzZXJ2aWNlcyBmdW5jdGlv bnMgYW5kIHRoZSBvcmRlciBvZiB0aGVtLCBidXQgYW55IGZ1cnRoZXIgDQo+PiBpbmZvcm1hdGlv biBhYm91dCB3aGV0aGVyIHRoZXJlIGlzIGEgKm5ldHdvcmsqIHBhdGggYmV0d2VlbiB0aGUgDQo+ PiBmdW5jdGlvbnMgaXMgbWlzc2luZyBpbiB0aGUgZGVmaW5pdGlvbi4NCj4NCj4gSXQgaXMgYXNz dW1lZCB0aGVyZSBpcyBhIHBhdGggYmV0d2VlbiBzZXJ2aWNlIGluc3RhbmNlcyAod2hhdCBlbHNl IA0KPiB3b3VsZCBtYWtlIHNlbnNlPykuIFRvIHRoZSBkZWdyZWUgdGhhdCBhIHNlcnZpY2UgZnVu Y3Rpb24gaW5zdGFuY2UgDQo+IG5lZWRzIHRvIGtub3cgZGV0YWlscyBhYm91dCB0aGF0IHBhdGgg KGUuZywgd2hhdCB0eXBlIG9mIHR1bm5lbCAtIEdSRSwgDQo+IElQLCBWWExBTiwgZXRjLikgdGhh dCBpbmZvcm1hdGlvbiBpcyBhc3N1bWVkIHRvIGJlIGtub3duIHRvIHRoZSANCj4gc2VydmljZSBm dW5jdGlvbiBpbnN0YW5jZXMuIEhvdyB0aGF0IGluZm9ybWF0aW9uIGdldHMgdG8gdGhlIHNlcnZp Y2UNCg0KSSBhbSB3aXRoIHlvdSBvbiB0aGUgJ25lZWQgYW55d2F5IHRvIGhhdmUgYSBwYXRoIGJl dHdlZW4gdGhlIGluc3RhbmNlJy4gDQpIb3dldmVyLCBhcyBzYWlkIGluIG15IHJlc3BvbnNlIHRv IEJvYidzIGVtYWlsLCBJIGFtIGZpbmUgaWYgU0ZDIGlzIHdvcmtpbmcgU0ZDIHdoZXJlIHRoZSBw YXRoIGlzIHByZS1jb25maWd1cmVkIGFoZWFkIG9mIHRpbWUgb2YgYW55IFNGQyBjb25maWd1cmF0 aW9uIGJ1dCBTRkMgc2hvdWxkIGFsc28gc3VwcG9ydCB0aGUgY2FzZSB3aGVyZSB0aGUgcGF0aCBp cyBjb25maWd1cmVkIG9uIGRlbWFuZCBqdXN0IGJlZm9yZSB0aGUgU0ZDIGlzIGluc3RhbnRpYXRl ZC4NCg0KPiBmdW5jdGlvbiBpbnN0YW5jZSBpcyBhIG1hdHRlciBmb3IgdGhlIGNvbnRyb2wvbWFu YWdlbWVudCBwcm90b2NvbHMuIA0KPiBUaGUgZXhhY3QgZGV0YWlsIG9uIGhvdyB0aGlzIGlzIGRv bmUgaXMgbm90IHJlYWxseQ0KDQpPaywgdGhhdCdzIGNvdmVyZWQgYnkgdGhlIGNoYXJ0ZXIgaW4g aXRlbSBuby4gNC4NCg0KPiB1bmRlcnN0b29kL2tub3duL2RlY2lkZWQgeWV0IGJ5IHRoZSBTRkMg ZWZmb3J0LCBidXQgd2UgZXhwZWN0IGl0IHRvIA0KPiBiZWNvbWUgbW9yZSBjbGVhciBvdmVyIHRo ZSBuZXh0IDYgbW9udGhzLiBUaGUgY2hhcnRlciBzcGVha3MgdG8gDQo+IHJlZXZhbHVhdGluZyB0 aGUgZGV0YWlscyBvZiB0aGlzLg0KDQpXaXRoIHJlc3BlY3QgdG8gdGhlIHJlZXZhbHVhdGlvbiwg YXJlIHlvdSByZWZlcnJpbmcgdG8gdGhpcyBzZW50ZW5jZSBvdXQgb2YgdGhlIGNoYXJ0ZXI6DQoi VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBleGFtaW5lIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8g YmUgZ2F0aGVyZWQgZnJvbSB0aGUgbmV0d29yayBhbmQgc2VydmljZSBmdW5jdGlvbnMgaW4gc3Vw cG9ydCBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGFuZCBob3cgdGhhdCBpbmZvcm1hdGlv biBtYXkgYmUgbWFkZSBhdmFpbGFibGUgdG8gdGhlIGNvbXBvbmVudHMgb2YgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW5pbmcgYXJjaGl0ZWN0dXJlIi4NCg0KSSdtIG5vdCBzdXJlIHRoYXQgdGhp cyByZWFkcyBsaWtlIHJlZXZhbHVhdGUgdG8gbWUsIGJ1dCBpdCBpcyBnb29kIHRvIGtub3cuDQoN Cj4NCj4gV2hlcmUgdGhlIHNlcnZpY2UgZW5jYXAgY29tZXMgaW4gaXMgbWFraW5nIHN1cmUgdGhh dCB0aGUgZGF0YSBwYWNrZXRzIA0KPiBpbmNsdWRlIGVub3VnaCBpbmZvcm1hdGlvbiBpbiB0aGVt IHNvIHRoYXQgd2hlbiBkYXRhIHBhY2tldHMgYXJyaXZlIGF0IA0KPiBhbiBTRiBpbnN0YW5jZSwg dGhleSBjYW4gYmUgcHJvY2Vzc2VkIGNvcnJlY3RseSAqYW5kKiBjYW4gYmUgZm9yd2FyZGVkIA0K PiB0byB0aGUgbmV4dCBTRiBpbnN0YW5jZS4gVGhlIGVuY2FwIHdpbGwgaGF2ZSBmaWVsZHMgdGhh dCBpZGVudGlmeSBhIA0KPiBzcGVjaWZpYyBTRiBwYXRoIGZvciBhIGdpdmVuIGRhdGEgcGFja2V0 IHRoYXQgcHJvdmlkZXMgdGhlICJnbHVlIg0KPiBiZXR3ZWVuIHRoZSBkYXRhIHBhY2tldCBhbmQg d2hhdGV2ZXIgc3RhdGUgaW5mb3JtYXRpb24gb24gdGhlIFNGIA0KPiBpbnN0YW5jZSB0aGF0IGlz IG5lZWRlZCB0byBwcm9jZXNzIHRoZSBwYWNrZXQgY29ycmVjdGx5Lg0KDQorMQ0KDQo+DQo+PiBB bHNvIHNvbWUgYWJzdHJhY3QgaW5mb3JtYXRpb24NCj4+IGFib3V0IHRoZSBuZXR3b3JrIHBhdGgg aXMgbWlzc2luZywgc3VjaCBhcyB1bmlkaXJlY3Rpb25hbCwgDQo+PiBiaS1kaXJlY3Rpb25hbCwg dW5pY2FzdCwgbXVsdGljYXN0LCBldGMuDQo+DQo+IFRoaXMgaW5mb3JtYXRpb24gaXMgYSBwcm9w ZXJ0eSBvZiB0aGUgc3BlY2lmaWMgU0YgcGF0aCBhbmQgd2lsbCBiZSANCj4ga25vd24gYnkgYWxs IHRoZSBlbnRpdGllcyB0aGF0IGFyZSBpbnZvbHZlZCBpbiB0aGUgc2VydmljZSBjaGFpbi4gDQo+ IEdldHRpbmcgdGhhdCBpbmZvIHRvIHRob3NlIG5vZGVzIGlzIHRoZSBqb2Igb2YgdGhlIGNvbnRy b2wvbWFuYWdlbWVudCANCj4gcGxhbmUuDQoNCkkgd291bGQgc2F5IHRoYXQgdGhvc2UgcHJvcGVy dGllcyBhcmUgYWxyZWFkeSBwYXJ0IG9mIHRoZSBhYnN0cmFjdCBkZWZpbml0aW9uLCBpLmUuLCB0 aGUgZGVmaW5pdGlvbiBvZiB0aGUgc2VydmljZSBjaGFpbi4NClRoZSBhY3R1YWwgaW5zdGFudGlh dGlvbiBoYXMgdG8gdGFrZSBjYXJlIGhvdyB0byBpbXBsZW1lbnQgbXVsdGljYXN0LCBidXQgdGhl IGZhY3QgdGhhdCBhIGxpbmsgaW4gdGhlIFNGQyByZXF1aXJlcyBhIGNlcnRhaW4gbmV0d29yayBw cm9wZXJ0eSBpcyBwYXJ0IG9mIHRoZSBhYnN0cmFjdGlvbi4NCg0KPg0KPj4gSXMgdGhpcyBpbnRl bnRpb25hbGx5Pw0KPg0KPiBJIHdvdWxkbid0IHNheSBpbnRlbnRpb25hbCBzbyBtdWNoIGFzIHRo YXQgdGhlIGNoYXJ0ZXIgY2FuJ3QgY29udGFpbiANCj4gZXZlcnl0aGluZy4gVGhpcyBzb3J0IG9m IGRldGFpbCB3b3VsZCAoSU1PKSBnbyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KDQpB Z3JlZWQgZm9yIHRoZSBjaGFydGVyLCBJIGFtIGp1c3Qgd29ycmllZCBhYm91dCB0aGUgZG9jdW1l bnRzLCBidXQgdGhhdCBjYW4gYmUgd29ya2VkIG91dC4NCg0KPg0KPj4gSXMgdGhpcyBhIGhpZGRl biBhc3N1bXB0aW9uIHRoYXQgdGhlIG5ldHdvcmsgb3ZlcmxheShzKSBpcyBhbHJlYWR5IA0KPj4g cHJlLWNvbmZpZ3VyZWQgYmV0d2VlbiBzZXJ2aWNlIG5vZGVzPw0KPg0KPiBZZXMsIGlmIHlvdSBt ZWFuIHByZS1jb25maWd1cmVkIGJlZm9yZSBkYXRhIHBhY2tldHMgZm9yIGEgc3BlY2lmaWMgU0Yg DQo+IHBhdGggc3RhcnQgZmxvd2luZy4gQnV0IHRoaXMgd2lsbCBhbG1vc3QgY2VydGFpbmx5IGJl IGNvbmZpZ3VyZWQgDQo+ICJkeW5hbWljYWxseSIsIGkuZS4sIHdoZW4gYSAiY29tcG9zaXRlIHNl cnZpY2UiIGlzIGluc3RhbnRpYXRlZC4NCg0KT2ssIGxvb2tzIHdlIGFyZSBvbiB0aGUgc2FtZSBw YWdlLg0KDQpUaGFuayB5b3UsDQoNCiAgIE1hcnRpbg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K From jguichar@cisco.com Wed Dec 4 04:33:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9871AE250 for ; Wed, 4 Dec 2013 04:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.902 X-Spam-Level: X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_55=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 G7B3Sa2zazvW for ; Wed, 4 Dec 2013 04:33:49 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 414661AE24B for ; Wed, 4 Dec 2013 04:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5032; q=dns/txt; s=iport; t=1386160423; x=1387370023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1WuTyUx3g4upNzeiCOJU+YE7VEfQyIZikeqSx9F4guY=; b=GcWxRizGhZp8ZhCYwK/OkMs1Sl5+bjFDmO8BypuCA+Ke3arcjJVnT2EV /FD9pYTOzkgeyUslOYsogi32+od8LJEArehKmQHRlbJWddjGlCNWq/+Dm 4rdVwDZ1lI0XtHVXE5E1V9nZ5oD7YJG77bxmUjtr6V1bphA3L3QTMGk+o c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FAMgfn1KtJXG9/2dsb2JhbABagwc4uTyBIxZ0giUBAQEDAQEBASRHCwUHBAIBCA4DAQMBAQEnByEGCxQDBggCBAoEBYdwAwkGDboUDYcTF4xtgS8RAR0zBwaDGoETA4kKiyeBeIFrgTCJLIF+hTmBa4E+gXE X-IronPort-AV: E=Sophos;i="4.93,824,1378857600"; d="scan'208";a="4231585" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 04 Dec 2013 12:33:43 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB4CXfcV013929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 12:33:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 06:33:41 -0600 From: "Jim Guichard (jguichar)" To: Martin Stiemerling Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8Ar+GH7Bk4FwSkmNSidAdHzrUZpCofoAgABks4CAASRVgP//zwlM Date: Wed, 4 Dec 2013 12:33:41 +0000 Message-ID: <47F1E2F4-6BC3-4F35-AF38-9445D9D26FFC@cisco.com> References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com>, <529EF5D9.5040509@gmail.com> In-Reply-To: <529EF5D9.5040509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Diego R. Lopez" , Linda Dunbar Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 12:33:51 -0000 Hi Martin, Sent from my iPhone > On Dec 4, 2013, at 3:29 AM, "Martin Stiemerling" wro= te: >=20 >> On 12/03/2013 05:02 PM, Linda Dunbar wrote: >> Are the overlay connections between "Service Functions" similar to >> today's transport layer between "hosts or applications"? >>=20 >> There are DA, SA, TCP or UDP ports&flags, and other header fields (to >> carry the metadata), and the payload to carry the original traffic to >> be treated by the "service functions"? >=20 > I can see, for instance, UDP as one way of interconnecting functions, but= I don't see that reusing the transport protocol headers for carrying meta-= data is the right thing. >=20 > Martin Jim> exactly and that is absolutely not the intent of the SFC work. >=20 >>=20 >> Linda >>=20 >>=20 >>=20 >>> -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] >>> On Behalf Of Diego R. Lopez Sent: Tuesday, December 03, 2013 4:02 >>> AM To: Martin Stiemerling Cc: Subject: Re: [nsc] >>> Definition of Service Chains in draft-quinn-sfc- {problem|arch} and >>> in general >>>=20 >>> Hi Martin, >>>=20 >>> My understanding is that it is as you say: there is an implicit >>> assumption of an existing overlay, and one of the more (if not the >>> most) important tasks of SFC is precisely defining how metadata is >>> transferred using the constructs provided by the overlay, and how >>> these metadata control flows on the overlay. How the overlay is >>> configured in terms of network paths should be out of scope. >>>=20 >>> Be goode, >>>=20 >>>> On 3 Dec 2013, at 10:35 , Martin Stiemerling wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I have read through draft-quinn-sfc-problem-statement and draft- >>> quinn-sfc-arch and wonder about the slightly different definitions >>> of service function chain in both documents though that they share >>> a similar set of authors. I guess a much better terminology >>> alignment is required. See below for the excerpts from the drafts >>> about the definitions. >>>>=20 >>>> Anyhow, here is my real point: >>>>=20 >>>> The definitions of SFC below always read to me as they are >>>> describing >>> the services functions and the order of them, but any further >>> information about whether there is a *network* path between the >>> functions is missing in the definition. Also some abstract >>> information about the network path is missing, such as >>> unidirectional, bi- directional, unicast, multicast, etc. >>>>=20 >>>> Is this intentionally? >>>>=20 >>>> Is this a hidden assumption that the network overlay(s) is >>>> already >>> pre-configured between service nodes? >>>>=20 >>>>=20 >>>>=20 >>>> Here are the excerpts for your reference: >>>>=20 >>>> In draft-quinn-sfc-problem-statement, Section 1.1 Service Chain: >>>> A service chain defines the required functions >>> and >>>> associated order (service-function1 --> service-function 2) that >>>> must be applied to packets and/or frames. A service chain does >>>> not specify the network location or specific instance of service >>>> functions (e.g. firewall1 vs. firewall2). >>>>=20 >>>> In draft-quinn-sfc-arch, Section 1.2: Service Function Chain >>>> (SFC): A set of service functions that are >>> to >>>> be applied to selected traffic in a specific order. The implied >>>> order may not be a linear progression as the architecture will >>>> allow for nodes that copy to more than one branch. The term >>>> service chain is often used as a shorthand version of service >>>> function chain. >>>>=20 >>>> In draft-quinn-sfc-arch, Section 2.1 "service function chaining >>>> creates an abstracted view of a service and specifies the set of >>>> required service functions as well as the order in which they >>>> must be executed. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Martin _______________________________________________ nsc >>>> mailing list nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>> -- "Esta vez no fallaremos, Doctor Infierno" >>>=20 >>> Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ >>>=20 >>> e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 >>> 091 ----------------------------------------- >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>> consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo >>> electr=F3nico en el enlace situado m=E1s abajo. This message is >>> intended exclusively for its addressee. We only send and receive >>> email on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Dec 4 05:00:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB411AE12D for ; Wed, 4 Dec 2013 05:00:28 -0800 (PST) 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 JvmZF5e1gNls for ; Wed, 4 Dec 2013 05:00:25 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 95BD61AE108 for ; Wed, 4 Dec 2013 05:00:25 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 05:00:22 -0800 From: Ron Parker To: "Hongyu Li (Julio)" Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8NKR81mSO9zz/UWqksmsMPSeJJpEToGA//+xbqs= Date: Wed, 4 Dec 2013 13:00:21 +0000 Message-ID: References: <529DA5D1.9020202@gmail.com> <201312031424.rB3EOVEL007522@cichlid.raleigh.ibm.com> <529EF48F.7080902@gmail.com>, <6EB34CB5D82C4645B826C56144826EA97E9A3FE1@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E9A3FE1@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , Martin Stiemerling , "nsc@ietf.org" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 13:00:28 -0000 If the service function locators are IP addresses , then the "underlay" mus= t support the transport of IP -- this can be an IP routed network, a MAC s= witched network, an SDN network, or some combination. =20 Ron > On Dec 4, 2013, at 4:41 AM, "Hongyu Li (Julio)" wr= ote: >=20 > For the part "path between instance", my understanding is that SFC is try= ing to define an overlay where path or reachability of instance should be p= rovided by underlay layer. In other words, instances of Service Functions b= etween hops on a Chain should be reachable on the underlay network of a Ser= vice Function Chain. >=20 > Hongyu >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Martin Stiemerling > Sent: Wednesday, December 04, 2013 5:23 PM > To: Thomas Narten > Cc: nsc@ietf.org > Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{probl= em|arch} and in general >=20 > Thomas, >=20 >=20 >> On 12/03/2013 03:24 PM, Thomas Narten wrote: >> Martin, >>=20 >>> I have read through draft-quinn-sfc-problem-statement and=20 >>> draft-quinn-sfc-arch and wonder about the slightly different=20 >>> definitions of service function chain in both documents though that=20 >>> they share a similar set of authors. I guess a much better=20 >>> terminology alignment is required. See below for the excerpts from the = drafts about the definitions. >>=20 >>> Anyhow, here is my real point: >>=20 >>> The definitions of SFC below always read to me as they are describing=20 >>> the services functions and the order of them, but any further=20 >>> information about whether there is a *network* path between the=20 >>> functions is missing in the definition. >>=20 >> It is assumed there is a path between service instances (what else=20 >> would make sense?). To the degree that a service function instance=20 >> needs to know details about that path (e.g, what type of tunnel - GRE,=20 >> IP, VXLAN, etc.) that information is assumed to be known to the=20 >> service function instances. How that information gets to the service >=20 > I am with you on the 'need anyway to have a path between the instance'.=20 > However, as said in my response to Bob's email, I am fine if SFC is worki= ng SFC where the path is pre-configured ahead of time of any SFC configurat= ion but SFC should also support the case where the path is configured on de= mand just before the SFC is instantiated. >=20 >> function instance is a matter for the control/management protocols.=20 >> The exact detail on how this is done is not really >=20 > Ok, that's covered by the charter in item no. 4. >=20 >> understood/known/decided yet by the SFC effort, but we expect it to=20 >> become more clear over the next 6 months. The charter speaks to=20 >> reevaluating the details of this. >=20 > With respect to the reevaluation, are you referring to this sentence out = of the charter: > "The working group will examine what information needs to be gathered fro= m the network and service functions in support of service function chaining= and how that information may be made available to the components of the se= rvice function chaining architecture". >=20 > I'm not sure that this reads like reevaluate to me, but it is good to kno= w. >=20 >>=20 >> Where the service encap comes in is making sure that the data packets=20 >> include enough information in them so that when data packets arrive at=20 >> an SF instance, they can be processed correctly *and* can be forwarded=20 >> to the next SF instance. The encap will have fields that identify a=20 >> specific SF path for a given data packet that provides the "glue" >> between the data packet and whatever state information on the SF=20 >> instance that is needed to process the packet correctly. >=20 > +1 >=20 >>=20 >>> Also some abstract information >>> about the network path is missing, such as unidirectional,=20 >>> bi-directional, unicast, multicast, etc. >>=20 >> This information is a property of the specific SF path and will be=20 >> known by all the entities that are involved in the service chain.=20 >> Getting that info to those nodes is the job of the control/management=20 >> plane. >=20 > I would say that those properties are already part of the abstract defini= tion, i.e., the definition of the service chain. > The actual instantiation has to take care how to implement multicast, but= the fact that a link in the SFC requires a certain network property is par= t of the abstraction. >=20 >>=20 >>> Is this intentionally? >>=20 >> I wouldn't say intentional so much as that the charter can't contain=20 >> everything. This sort of detail would (IMO) go in the architecture docum= ent. >=20 > Agreed for the charter, I am just worried about the documents, but that c= an be worked out. >=20 >>=20 >>> Is this a hidden assumption that the network overlay(s) is already=20 >>> pre-configured between service nodes? >>=20 >> Yes, if you mean pre-configured before data packets for a specific SF=20 >> path start flowing. But this will almost certainly be configured=20 >> "dynamically", i.e., when a "composite service" is instantiated. >=20 > Ok, looks we are on the same page. >=20 > Thank you, >=20 > Martin >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Dec 4 05:51:25 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3340A1AE227 for ; Wed, 4 Dec 2013 05:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 QztYAApqt-pw for ; Wed, 4 Dec 2013 05:51:23 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 070831AE131 for ; Wed, 4 Dec 2013 05:51:23 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 05:51:19 -0800 From: Ron Parker To: Sumandra Majee , "Haeffner, Walter, Vodafone DE" , Linda Dunbar , Jerome Moisand , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1A= Date: Wed, 4 Dec 2013 13:51:18 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 13:51:25 -0000 Sumandra, Your use case should absolutely be supported. Many service functions may= be co-located in the same compute complex (without getting too precise on = the meaning of that term). And in such a case, each may use distinct or s= hared network locators (i.e., distinct or shared IP addresses). Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Wednesday, December 04, 2013 2:09 AM To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hello Haeffner, You are correct that a device like PGW, BNG or Load Balancer may offer mult= iple service. For example commercial load balancer can offer header enrichm= ent, TCP optimization and quite an array of steering functionality. They ca= n and do offer custom policy engines and such.=20 Another way of putting this is that a service-node may offer multiple disti= nct services. The local box can select a specific service based on the loca= l policy. In my head I visualizing a service node that has one ingress and= one egress but can offer multiple service inside that local entity.=20 I hope that would be possible as per this WG. =20 ________________________________________ From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone DE= [walter.haeffner@vodafone.com] Sent: Tuesday, December 03, 2013 8:34 AM To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf= .org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Hi Linda, I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction. Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW. I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= . Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function. An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation. Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function. Other example: A commercial load balancer may have more functions than just= load balancing. .... What do you think? Regards, Walter -----Urspr=FCngliche Nachricht----- Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar Gesendet: Montag, 2. Dezember 2013 19:10 An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Betreff: Re: [nsc] Ted Lemon's concern with charter text Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point. Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions". Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > chain. It acts as both Service Classifier and Service Policy=20 > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > squarely a Service Function. Would you agree? > > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 > if I know what you mean!) > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Hi, Jerome. > > I agree with your definitions of service vs. service function. > > Regarding functions like PGW, in the upstream direction for user=20 > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment=20 > model. > > Ron > > > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Issue#1: I think we have to be careful to not use the word 'service' > to speak of a given network function. > > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer. Something that you subscribe to, something that=20 > you benefit from, something that you may be billed for, something that=20 > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many=20 > network functions and related systems, without the end user knowing. > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > Service Function! Meaning a network function that directly helps in=20 > providing service-related processing and service (profile)=20 > differentiation. It's just a component though, not the entire Service=20 > as perceived by the end user. > > And Ron, I would suggest to avoid speaking of mid-box (or=20 > middleboxes), as this term has a connotation that would seem to=20 > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 > viewed as 'middlebox', and yet, they are *the* primary Service=20 > Function in today's broadband networks). > > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use=20 > traffic via a constrained path, and well, the service function does=20 > remain on the data path (granted, the data path changed from a=20 > 'shortest path routed' to a more constrained path, but it's still a=20 > data path!). > > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is=20 > actually fine, if not better (even if the last sentence 'direct data path= ' > terminology isn't that great either). It also seems to me that we've=20 > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing=20 > paragraph and say: > > << Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through service functions=20 > (physical or virtualized), wherever they are deployed.>> > > And then, during the actual work, for sure, we'll need to settle on=20 > clear definitions for 'Service', 'Service Function', etc. > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Adrian, > > I think Ted's text is a very nice summary of what we are trying to=20 > accomplish. > > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly=20 > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > proxy, but not to an explicit HTTP proxy). > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall=20 > > filtering, load balancing and transactional proxies such as spam filte= rs. > > Could become: > > "Network service providers, in addition to delivering IP connectivity,=20 > frequently provide transparent services such as firewall filtering,=20 > load balancing and transactional proxies such as spam filters." > > We may want to strike or replace load balancing as that may not be an=20 > actual transparent service but rather a building block for some actual=20 > transport service -- open to suggestions on this verbage. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. > > Could become: > > "Today, a common deployment model is to insert various mid-boxes on=20 > the data-forwarding path between communicating peers." > > > > Ron > > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text > > Hi, > > During IESG review Ted and I had a bit of an exchange about the=20 > meaning of "a service" and the "layer at which a service chain can be app= lied". > > Ted was looking for some text to clarify this in the in the charter=20 > and suggests replacing the entire first paragraph with... > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall filt= ering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with=20 > > the introduction of virtualization, network overlays, and orchestration= . > > > > Service delivery is currently both a technical and an=20 > > organizational challenge that involves significant modification to=20 > > the network configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of=20 > > service functions that are deployed at different points within a=20 > > network. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. Going forward,=20 > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. > > This is only a strawman from Ted (and thanks to him for proposing=20 > text), and we should not assume that it is immutable. > > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? > > Opinions please. > > Cheers, > Adrian > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmoisand@juniper.net Wed Dec 4 07:33:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21161AE2A8 for ; Wed, 4 Dec 2013 07:33:46 -0800 (PST) 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, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, 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 CgaKLrc7j2Tg for ; Wed, 4 Dec 2013 07:33:41 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 429F11AE2A6 for ; Wed, 4 Dec 2013 07:33:41 -0800 (PST) Received: from mail210-co9-R.bigfish.com (10.236.132.229) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 15:33:37 +0000 Received: from mail210-co9 (localhost [127.0.0.1]) by mail210-co9-R.bigfish.com (Postfix) with ESMTP id 0262F940A42; Wed, 4 Dec 2013 15:33:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic89bh542I1dbaI1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail210-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(13464003)(51704005)(377454003)(74876001)(74662001)(76796001)(551934002)(69226001)(74316001)(46102001)(51856001)(31966008)(54356001)(79102001)(53806001)(74366001)(83072001)(76482001)(74502001)(90146001)(56816005)(81816001)(66066001)(15975445006)(80976001)(81686001)(47736001)(49866001)(56776001)(54316002)(81342001)(85306002)(65816001)(81542001)(47976001)(63696002)(47446002)(77982001)(87936001)(80022001)(87266001)(33646001)(59766001)(76576001)(19580405001)(74706001)(19580395003)(50986001)(76786001)(2656002)(83322001)(4396001)(85852002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB715; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail210-co9 (localhost.localdomain [127.0.0.1]) by mail210-co9 (MessageSwitch) id 1386171215978587_20262; Wed, 4 Dec 2013 15:33:35 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.249]) by mail210-co9.bigfish.com (Postfix) with ESMTP id E9892300052; Wed, 4 Dec 2013 15:33:35 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 15:33:33 +0000 Received: from CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 15:33:31 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB715.namprd05.prod.outlook.com (10.141.228.150) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 15:33:29 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 15:33:29 +0000 From: Jerome Moisand To: Ron Parker , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , Linda Dunbar , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkA== Date: Wed, 4 Dec 2013 15:33:29 +0000 Message-ID: <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 15:33:47 -0000 Back to the original thread... ;-) The new wording sounds fine to me. I would just reiterate my suggestion abo= ut avoiding the 'direct data path' terminology. Service chaining is about m= odifying the data path, it's not about avoiding it. I understand what 'dire= ct' is supposed to mean, but this may be rather confusing to other readers. Current text: << Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required servic= e functions, wherever they are deployed.>> Proposed change: << Today, common deployment models have service functions inserted on the r= egular data-forwarding path between communicating peers. Going forward, how= ever, there is a desire to move to a different model, where traffic can be = steered through required service functions (physical or virtualized), where= ver they are deployed.>> Tx Jerome -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Wednesday, December 04, 2013 8:51 AM To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moi= sand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Sumandra, Your use case should absolutely be supported. Many service functions may= be co-located in the same compute complex (without getting too precise on = the meaning of that term). And in such a case, each may use distinct or s= hared network locators (i.e., distinct or shared IP addresses). Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com] Sent: Wednesday, December 04, 2013 2:09 AM To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hello Haeffner, You are correct that a device like PGW, BNG or Load Balancer may offer mult= iple service. For example commercial load balancer can offer header enrichm= ent, TCP optimization and quite an array of steering functionality. They ca= n and do offer custom policy engines and such.=20 Another way of putting this is that a service-node may offer multiple disti= nct services. The local box can select a specific service based on the loca= l policy. In my head I visualizing a service node that has one ingress and= one egress but can offer multiple service inside that local entity.=20 I hope that would be possible as per this WG. =20 ________________________________________ From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone DE= [walter.haeffner@vodafone.com] Sent: Tuesday, December 03, 2013 8:34 AM To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf= .org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Hi Linda, I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction. Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW. I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= . Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function. An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation. Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function. Other example: A commercial load balancer may have more functions than just= load balancing. .... What do you think? Regards, Walter -----Urspr=FCngliche Nachricht----- Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar Gesendet: Montag, 2. Dezember 2013 19:10 An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Betreff: Re: [nsc] Ted Lemon's concern with charter text Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point. Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions". Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > chain. It acts as both Service Classifier and Service Policy=20 > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > squarely a Service Function. Would you agree? > > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 > if I know what you mean!) > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Hi, Jerome. > > I agree with your definitions of service vs. service function. > > Regarding functions like PGW, in the upstream direction for user=20 > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment=20 > model. > > Ron > > > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Issue#1: I think we have to be careful to not use the word 'service' > to speak of a given network function. > > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer. Something that you subscribe to, something that=20 > you benefit from, something that you may be billed for, something that=20 > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many=20 > network functions and related systems, without the end user knowing. > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > Service Function! Meaning a network function that directly helps in=20 > providing service-related processing and service (profile)=20 > differentiation. It's just a component though, not the entire Service=20 > as perceived by the end user. > > And Ron, I would suggest to avoid speaking of mid-box (or=20 > middleboxes), as this term has a connotation that would seem to=20 > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 > viewed as 'middlebox', and yet, they are *the* primary Service=20 > Function in today's broadband networks). > > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use=20 > traffic via a constrained path, and well, the service function does=20 > remain on the data path (granted, the data path changed from a=20 > 'shortest path routed' to a more constrained path, but it's still a=20 > data path!). > > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is=20 > actually fine, if not better (even if the last sentence 'direct data path= ' > terminology isn't that great either). It also seems to me that we've=20 > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing=20 > paragraph and say: > > << Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through service functions=20 > (physical or virtualized), wherever they are deployed.>> > > And then, during the actual work, for sure, we'll need to settle on=20 > clear definitions for 'Service', 'Service Function', etc. > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Adrian, > > I think Ted's text is a very nice summary of what we are trying to=20 > accomplish. > > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly=20 > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > proxy, but not to an explicit HTTP proxy). > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall=20 > > filtering, load balancing and transactional proxies such as spam filte= rs. > > Could become: > > "Network service providers, in addition to delivering IP connectivity,=20 > frequently provide transparent services such as firewall filtering,=20 > load balancing and transactional proxies such as spam filters." > > We may want to strike or replace load balancing as that may not be an=20 > actual transparent service but rather a building block for some actual=20 > transport service -- open to suggestions on this verbage. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. > > Could become: > > "Today, a common deployment model is to insert various mid-boxes on=20 > the data-forwarding path between communicating peers." > > > > Ron > > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text > > Hi, > > During IESG review Ted and I had a bit of an exchange about the=20 > meaning of "a service" and the "layer at which a service chain can be app= lied". > > Ted was looking for some text to clarify this in the in the charter=20 > and suggests replacing the entire first paragraph with... > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall filt= ering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with=20 > > the introduction of virtualization, network overlays, and orchestration= . > > > > Service delivery is currently both a technical and an=20 > > organizational challenge that involves significant modification to=20 > > the network configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of=20 > > service functions that are deployed at different points within a=20 > > network. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. Going forward,=20 > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. > > This is only a strawman from Ted (and thanks to him for proposing=20 > text), and we should not assume that it is immutable. > > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? > > Opinions please. > > Cheers, > Adrian > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Dec 4 08:05:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425121AE2E6 for ; Wed, 4 Dec 2013 08:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 pt1d1uIq5Rtw for ; Wed, 4 Dec 2013 08:05:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3F1AE2E3 for ; Wed, 4 Dec 2013 08:05:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYP91783; Wed, 04 Dec 2013 16:05:12 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 16:04:16 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 16:05:08 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:05:04 -0800 From: Linda Dunbar To: Martin Stiemerling , "Diego R. Lopez" Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8Ar/agDTAMpejki63cQaDW6oYJpCw4EA///c5gCAAawigP//5E2A Date: Wed, 4 Dec 2013 16:05:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2A242@dfweml509-mbx.china.huawei.com> References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com> <529EF5D9.5040509@gmail.com> In-Reply-To: <529EF5D9.5040509@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 16:05:19 -0000 TWFydGluLCANCg0KUXVlc3Rpb25zIGluc2VydGVkIGJlbG93Og0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IA0KPiBJIGNhbiBzZWUsIGZvciBpbnN0YW5jZSwgVURQIGFzIG9uZSB3 YXkgb2YgaW50ZXJjb25uZWN0aW5nIGZ1bmN0aW9ucywNCg0KW0xpbmRhXSBXZSBoYXZlIGJlZW4g dXNpbmcgVURQIChWeExBTikgdG8gaW50ZXJjb25uZWN0IHNlcnZpY2UgZnVuY3Rpb25zIGluIG91 ciBHaUxBTiBlbnZpcm9ubWVudC4NCg0KSXMgdGhlcmUgYW55IHJlYXNvbiB0aGF0IFRDUCBjYW4n dCBiZSB1c2VkIG9yIG5vdCBhcHByb3ByaWF0ZSBmb3IgaW50ZXJjb25uZWN0aW5nIHNlcnZpY2Ug ZnVuY3Rpb25zPw0KDQoNCj4gYnV0IEkgZG9uJ3Qgc2VlIHRoYXQgcmV1c2luZyB0aGUgdHJhbnNw b3J0IHByb3RvY29sIGhlYWRlcnMgZm9yDQo+IGNhcnJ5aW5nDQo+IG1ldGEtZGF0YSBpcyB0aGUg cmlnaHQgdGhpbmcuDQoNCltMaW5kYV0gRnVsbHkgQWdyZWUgd2l0aCB3aGF0IHlvdSBzdGF0ZWQg aGVyZS4gSG93ZXZlciwganVzdCBvdXQgb2YgY3VyaW9zaXR5LCB3aGF0IGhhcm0gaXQgY2FuIGNh dXNlIGJ5IHVzaW5nIHNvbWUgdW4tZGVmaW5lZCBVRFAgb3IgVENQIHBvcnQgbnVtYmVyIHRvIGNh cnJ5IHNvbWUgdmFsdWVzIGJldHdlZW4gIlNlcnZpY2UgRnVuY3Rpb25zIiBpZiB0aG9zZSBzZXJ2 aWNlIGZ1bmN0aW9ucyBhZ3JlZSB1cG9uIHRoZSBtZWFuaW5nIG9mIHRoZSB2YWx1ZT8gDQoNCkxp bmRhDQoNCg0K From Ron_Parker@affirmednetworks.com Wed Dec 4 08:13:09 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36C01AE2D4 for ; Wed, 4 Dec 2013 08:13:09 -0800 (PST) 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 Z1ILYlRiyAYe for ; Wed, 4 Dec 2013 08:13:07 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC531AE155 for ; Wed, 4 Dec 2013 08:13:07 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:13:04 -0800 From: Ron Parker To: Linda Dunbar , Martin Stiemerling , "Diego R. Lopez" Thread-Topic: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general Thread-Index: AQHO8Ar/Cb57FU6Q+UCf5yPF9aB4LppCw4EAgABks4CAASRVgIAAbquA//97f3A= Date: Wed, 4 Dec 2013 16:13:03 +0000 Message-ID: References: <529DA5D1.9020202@gmail.com> <45010FA2-8FC2-4A91-9414-AED044FFEDA3@tid.es> <4A95BA014132FF49AE685FAB4B9F17F645C28D1A@dfweml509-mbx.china.huawei.com> <529EF5D9.5040509@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F645C2A242@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C2A242@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem|arch} and in general X-BeenThere: nsc@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, 04 Dec 2013 16:13:09 -0000 Linda, That type of ad-hoc usage of existing protocols (i.e., let's assign some se= mantic meaning to the value of the source UDP port) is what makes multi-ven= dor interoperability as problematic as it is. The charter is quite explic= it that a common service header be used to convey any information necessary= to make the service function chain operational. Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, December 04, 2013 11:05 AM To: Martin Stiemerling; Diego R. Lopez Cc: Subject: Re: [nsc] Definition of Service Chains in draft-quinn-sfc-{problem= |arch} and in general Martin,=20 Questions inserted below: > -----Original Message----- >=20 > I can see, for instance, UDP as one way of interconnecting functions, [Linda] We have been using UDP (VxLAN) to interconnect service functions in= our GiLAN environment. Is there any reason that TCP can't be used or not appropriate for interconn= ecting service functions? > but I don't see that reusing the transport protocol headers for=20 > carrying meta-data is the right thing. [Linda] Fully Agree with what you stated here. However, just out of curiosi= ty, what harm it can cause by using some un-defined UDP or TCP port number = to carry some values between "Service Functions" if those service functions= agree upon the meaning of the value?=20 Linda _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Dec 4 08:17:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6D71AE197 for ; Wed, 4 Dec 2013 08:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 hxqDmK0OiUK6 for ; Wed, 4 Dec 2013 08:17:15 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0391AE155 for ; Wed, 4 Dec 2013 08:17:15 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:17:12 -0800 From: Ron Parker To: Jerome Moisand , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , Linda Dunbar , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZg Date: Wed, 4 Dec 2013 16:17:10 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 16:17:20 -0000 Jerome, I like your edits, but I'm iffy on "regular data path". I'll offer a furt= her refinement of your text: << Today, common deployment models have service functions inserted transpar= ently on the data-forwarding path between communicating peers. Going forwa= rd, however, there is a desire to move to a different model, where traffic = can be steered through required service functions (physical or virtualized)= , wherever they are deployed.>> Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Wednesday, December 04, 2013 10:33 AM To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Back to the original thread... ;-) The new wording sounds fine to me. I would just reiterate my suggestion abo= ut avoiding the 'direct data path' terminology. Service chaining is about m= odifying the data path, it's not about avoiding it. I understand what 'dire= ct' is supposed to mean, but this may be rather confusing to other readers. Current text: << Today, common deployment models have service functions inserted on the d= ata-forwarding path between communicating peers. Going forward, however, th= ere is a need to move to a different model, where service functions, whethe= r physical or virtualized, are not required to reside on the direct data pa= th and traffic is instead steered through required service functions, where= ver they are deployed.>> Proposed change: << Today, common deployment models have service functions inserted on the r= egular data-forwarding path between communicating peers. Going forward, how= ever, there is a desire to move to a different model, where traffic can be = steered through required service functions (physical or virtualized), where= ver they are deployed.>> Tx Jerome -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, December 04, 2013 8:51 AM To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moi= sand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Sumandra, Your use case should absolutely be supported. Many service functions may= be co-located in the same compute complex (without getting too precise on = the meaning of that term). And in such a case, each may use distinct or s= hared network locators (i.e., distinct or shared IP addresses). Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com] Sent: Wednesday, December 04, 2013 2:09 AM To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hello Haeffner, You are correct that a device like PGW, BNG or Load Balancer may offer mult= iple service. For example commercial load balancer can offer header enrichm= ent, TCP optimization and quite an array of steering functionality. They ca= n and do offer custom policy engines and such.=20 Another way of putting this is that a service-node may offer multiple disti= nct services. The local box can select a specific service based on the loca= l policy. In my head I visualizing a service node that has one ingress and= one egress but can offer multiple service inside that local entity.=20 I hope that would be possible as per this WG. =20 ________________________________________ From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone DE= [walter.haeffner@vodafone.com] Sent: Tuesday, December 03, 2013 8:34 AM To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf= .org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Hi Linda, I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction. Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW. I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= . Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function. An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation. Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function. Other example: A commercial load balancer may have more functions than just= load balancing. .... What do you think? Regards, Walter -----Urspr=FCngliche Nachricht----- Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar Gesendet: Montag, 2. Dezember 2013 19:10 An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Betreff: Re: [nsc] Ted Lemon's concern with charter text Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point. Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions". Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > chain. It acts as both Service Classifier and Service Policy=20 > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > squarely a Service Function. Would you agree? > > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 > if I know what you mean!) > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Hi, Jerome. > > I agree with your definitions of service vs. service function. > > Regarding functions like PGW, in the upstream direction for user=20 > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment=20 > model. > > Ron > > > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Issue#1: I think we have to be careful to not use the word 'service' > to speak of a given network function. > > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer. Something that you subscribe to, something that=20 > you benefit from, something that you may be billed for, something that=20 > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many=20 > network functions and related systems, without the end user knowing. > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > Service Function! Meaning a network function that directly helps in=20 > providing service-related processing and service (profile)=20 > differentiation. It's just a component though, not the entire Service=20 > as perceived by the end user. > > And Ron, I would suggest to avoid speaking of mid-box (or=20 > middleboxes), as this term has a connotation that would seem to=20 > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 > viewed as 'middlebox', and yet, they are *the* primary Service=20 > Function in today's broadband networks). > > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use=20 > traffic via a constrained path, and well, the service function does=20 > remain on the data path (granted, the data path changed from a=20 > 'shortest path routed' to a more constrained path, but it's still a=20 > data path!). > > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is=20 > actually fine, if not better (even if the last sentence 'direct data path= ' > terminology isn't that great either). It also seems to me that we've=20 > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing=20 > paragraph and say: > > << Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through service functions=20 > (physical or virtualized), wherever they are deployed.>> > > And then, during the actual work, for sure, we'll need to settle on=20 > clear definitions for 'Service', 'Service Function', etc. > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Adrian, > > I think Ted's text is a very nice summary of what we are trying to=20 > accomplish. > > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly=20 > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > proxy, but not to an explicit HTTP proxy). > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall=20 > > filtering, load balancing and transactional proxies such as spam filte= rs. > > Could become: > > "Network service providers, in addition to delivering IP connectivity,=20 > frequently provide transparent services such as firewall filtering,=20 > load balancing and transactional proxies such as spam filters." > > We may want to strike or replace load balancing as that may not be an=20 > actual transparent service but rather a building block for some actual=20 > transport service -- open to suggestions on this verbage. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. > > Could become: > > "Today, a common deployment model is to insert various mid-boxes on=20 > the data-forwarding path between communicating peers." > > > > Ron > > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text > > Hi, > > During IESG review Ted and I had a bit of an exchange about the=20 > meaning of "a service" and the "layer at which a service chain can be app= lied". > > Ted was looking for some text to clarify this in the in the charter=20 > and suggests replacing the entire first paragraph with... > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall filt= ering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with=20 > > the introduction of virtualization, network overlays, and orchestration= . > > > > Service delivery is currently both a technical and an=20 > > organizational challenge that involves significant modification to=20 > > the network configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of=20 > > service functions that are deployed at different points within a=20 > > network. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. Going forward,=20 > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. > > This is only a strawman from Ted (and thanks to him for proposing=20 > text), and we should not assume that it is immutable. > > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? > > Opinions please. > > Cheers, > Adrian > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Dec 4 08:30:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5741AE2B7 for ; Wed, 4 Dec 2013 08:30:48 -0800 (PST) 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, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 UjtSQZi29Lv2 for ; Wed, 4 Dec 2013 08:30:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 582981AE078 for ; Wed, 4 Dec 2013 08:30:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYP93667; Wed, 04 Dec 2013 16:30:39 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 16:29:45 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 16:30:38 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 08:30:34 -0800 From: Linda Dunbar To: Ron Parker , Jerome Moisand , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAACG40A= Date: Wed, 4 Dec 2013 16:30:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2A2EA@dfweml509-mbx.china.huawei.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 16:30:48 -0000 Ron's refined wording is very accurate description. Really like it.=20 Linda > -----Original Message----- >=20 > << Today, common deployment models have service functions inserted > transparently on the data-forwarding path between communicating peers. > Going forward, however, there is a desire to move to a different model, > where traffic can be steered through required service functions > (physical or virtualized), wherever they are deployed.>> >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Wednesday, December 04, 2013 10:33 AM > To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda > Dunbar; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Back to the original thread... ;-) >=20 > The new wording sounds fine to me. I would just reiterate my suggestion > about avoiding the 'direct data path' terminology. Service chaining is > about modifying the data path, it's not about avoiding it. I understand > what 'direct' is supposed to mean, but this may be rather confusing to > other readers. >=20 > Current text: > << Today, common deployment models have service functions inserted on > the data-forwarding path between communicating peers. Going forward, > however, there is a need to move to a different model, where service > functions, whether physical or virtualized, are not required to reside > on the direct data path and traffic is instead steered through required > service functions, wherever they are deployed.>> >=20 > Proposed change: >=20 > << Today, common deployment models have service functions inserted on > the regular data-forwarding path between communicating peers. Going > forward, however, there is a desire to move to a different model, where > traffic can be steered through required service functions (physical or > virtualized), wherever they are deployed.>> >=20 > Tx > Jerome >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Wednesday, December 04, 2013 8:51 AM > To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome > Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Sumandra, >=20 > Your use case should absolutely be supported. Many service functions > may be co-located in the same compute complex (without getting too > precise on the meaning of that term). And in such a case, each may > use distinct or shared network locators (i.e., distinct or shared IP > addresses). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, December 04, 2013 2:09 AM > To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron > Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Hello Haeffner, >=20 > You are correct that a device like PGW, BNG or Load Balancer may offer > multiple service. For example commercial load balancer can offer header > enrichment, TCP optimization and quite an array of steering > functionality. They can and do offer custom policy engines and such. >=20 > Another way of putting this is that a service-node may offer multiple > distinct services. The local box can select a specific service based on > the local policy. In my head I visualizing a service node that has one > ingress and one egress but can offer multiple service inside that local > entity. >=20 > I hope that would be possible as per this WG. >=20 >=20 > ________________________________________ > From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, > Vodafone DE [walter.haeffner@vodafone.com] > Sent: Tuesday, December 03, 2013 8:34 AM > To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; > nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Hi Linda, >=20 > I support your statement. Suggest we carefully distinguish between an > abstract function, mean a well-defined unique elementary functionality > and a physical device like a BNG or PGW or even a switch, router or x86 > middleware box. Reading Ron's arguments, I assume Ron probably thinks > in the same direction. >=20 > Originally e.g. a BNG is the service creation point for a DSL service > (PPP, DHCP). A BNG as you said will also classify or inspect traffic > and forward it according certain rules given e.g. by a AAA > (up/downstream). Similar arguments for a PGW. >=20 > I could insert a service card into a BNG box and run e.g. CG-NAT on it. > Means CG-NAT would be in the BNG box but it is another elementary > functionality which also could be realized outside the BNG box on > another platform just dedicated for CG-NAT and located deep in the > service function chain platform. I could plug service cards into > routers and run some service functions. >=20 > Some vendors offer proprietary systems which include more than one > unique functionality. I could buy a "performance enhancement proxy" > (whatever it means) which includes in e.g. TCP optimization, header > enrichment and video optimization. This is typically a big installation > over some racks but it can still be seen as one system or performance > enhancement function. >=20 > An instantiation of an abstract unique elementary function (node) in a > service function chain (directed graph) may even consist of a load > balancer and a certain number of instances of the elementary service > function, physical or virtualized. See also Ron's argumentation. >=20 > Means one really should distinguish between an abstract elementary > functionality which I would associate with a node (for short service > function) in an abstract service chain (directed graph) and a physical > box which may include more than just one instantiation of an elementary > function. >=20 > Other example: A commercial load balancer may have more functions than > just load balancing. .... >=20 > What do you think? >=20 > Regards, Walter >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar > Gesendet: Montag, 2. Dezember 2013 19:10 > An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Betreff: Re: [nsc] Ted Lemon's concern with charter text >=20 > Jerome, >=20 > I agree with you that the PGW (or a BNG for wireline) is the starting > point of the chain. (most likely) It acts as both Service Classifier > and Service Policy Enforcement Point. >=20 > Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic > to other service functions", but I don't think PGW/BNG themselves > should be called "service functions". >=20 > Linda >=20 > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > > Sent: Monday, December 02, 2013 11:58 AM > > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: Re: [nsc] Ted Lemon's concern with charter text > > > > Well, the PGW (or a BNG for wireline) is the starting point of the > > chain. It acts as both Service Classifier and Service Policy > > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is > > squarely a Service Function. Would you agree? > > > > (anyhoo, my point was mostly to avoid the middlebox terminology! Even > > if I know what you mean!) > > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Monday, December 02, 2013 12:53 PM > > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: RE: [nsc] Ted Lemon's concern with charter text > > > > Hi, Jerome. > > > > I agree with your definitions of service vs. service function. > > > > Regarding functions like PGW, in the upstream direction for user > > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > > therefore not in need of any traffic steering. In the downstream > > direction, the PGW represents itself as a PE router that reaches the > > subscribers. Most of the interest, today, around the mobile use > case > > is for transparent middlebox functions that reside between the PGW > and > > the Internet. The set of service functions is typically called the > > "Gi LAN", a name that more or less implies the present day deployment > > model. > > > > Ron > > > > > > -----Original Message----- > > From: Jerome Moisand [mailto:jmoisand@juniper.net] > > Sent: Monday, December 02, 2013 11:35 AM > > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: RE: [nsc] Ted Lemon's concern with charter text > > > > Issue#1: I think we have to be careful to not use the word 'service' > > to speak of a given network function. > > > > Personally, I always use the word 'service' as something perceived by > > the end user/customer. Something that you subscribe to, something > that > > you benefit from, something that you may be billed for, something > that > > may require customer care interactions. This is a 'black box' > > perspective, the Network Service Provider (or IT department inside an > > Enterprise) can then implement such service in many ways, using many > > network functions and related systems, without the end user knowing. > > > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a > > Service Function! Meaning a network function that directly helps in > > providing service-related processing and service (profile) > > differentiation. It's just a component though, not the entire Service > > as perceived by the end user. > > > > And Ron, I would suggest to avoid speaking of mid-box (or > > middleboxes), as this term has a connotation that would seem to > > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely > > viewed as 'middlebox', and yet, they are *the* primary Service > > Function in today's broadband networks). > > > > Issue #2: I understand what Ted is trying to say with the 'in-path' > > aspect, but fact is service (function) chaining is about steering use > > traffic via a constrained path, and well, the service function does > > remain on the data path (granted, the data path changed from a > > 'shortest path routed' to a more constrained path, but it's still a > > data path!). > > > > =3D=3D=3D > > I don't know, seems to me that the existing first paragraph is > > actually fine, if not better (even if the last sentence 'direct data > path' > > terminology isn't that great either). It also seems to me that we've > > been hair-splitting for a while now, and maybe we should just move > on... > > I would just suggest to simplify the last sentence of the existing > > paragraph and say: > > > > << Going forward, however, there is a desire to move to a different > > model, where traffic can be steered through service functions > > (physical or virtualized), wherever they are deployed.>> > > > > And then, during the actual work, for sure, we'll need to settle on > > clear definitions for 'Service', 'Service Function', etc. > > > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > > Sent: Monday, December 02, 2013 10:03 AM > > To: adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: Re: [nsc] Ted Lemon's concern with charter text > > > > Adrian, > > > > I think Ted's text is a very nice summary of what we are trying to > > accomplish. > > > > He does use the term "in-path" which could use some elaboration, IMO. > > I feel that SFC applies to transparent mid-boxes and not to > explicitly > > addressed service functions (i.e., SFC applies to a transparent HTTP > > proxy, but not to an explicit HTTP proxy). > > > > > Network service providers, in addition to delivering IP > > > connectivity, frequently provide in-path services such as firewall > > > filtering, load balancing and transactional proxies such as spam > filters. > > > > Could become: > > > > "Network service providers, in addition to delivering IP connectivity, > > frequently provide transparent services such as firewall filtering, > > load balancing and transactional proxies such as spam filters." > > > > We may want to strike or replace load balancing as that may not be an > > actual transparent service but rather a building block for some > actual > > transport service -- open to suggestions on this verbage. > > > > > > > Today, a common deployment model has service functions inserted on > > > the data-forwarding path between communicating peers. > > > > Could become: > > > > "Today, a common deployment model is to insert various mid-boxes on > > the data-forwarding path between communicating peers." > > > > > > > > Ron > > > > > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Monday, December 02, 2013 7:21 AM > > To: nsc@ietf.org > > Cc: Ted Lemon > > Subject: [nsc] Ted Lemon's concern with charter text > > > > Hi, > > > > During IESG review Ted and I had a bit of an exchange about the > > meaning of "a service" and the "layer at which a service chain can be > applied". > > > > Ted was looking for some text to clarify this in the in the charter > > and suggests replacing the entire first paragraph with... > > > > > Network service providers, in addition to delivering IP > > > connectivity, frequently provide in-path services such as firewall > filtering, load > > > balancing and transactional proxies such as spam filters. > Delivery > > > of these types of services is undergoing significant change with > > > the introduction of virtualization, network overlays, and > orchestration. > > > > > > Service delivery is currently both a technical and an > > > organizational challenge that involves significant modification to > > > the network configuration, impacting the speed at which services > can be > > > deployed and increasing operational costs. Such services are > > > typically implemented by the ordered combination of a number of > > > service functions that are deployed at different points within a > > > network. > > > > > > Today, a common deployment model has service functions inserted on > > > the data-forwarding path between communicating peers. Going forward, > > > however, there is a desire to move to a different model, where > > service > > > functions, whether physical or virtualized, are not required to > > reside > > > on the direct data path and traffic is instead steered through > > service > > > functions, wherever they are deployed. > > > > This is only a strawman from Ted (and thanks to him for proposing > > text), and we should not assume that it is immutable. > > > > I think the way to look at this is: > > - Is there anything in the new text we disagree with? > > - Would making this change cause harm? > > - Could this change be improved still further? > > > > Opinions please. > > > > Cheers, > > Adrian > > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > > > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 From jmoisand@juniper.net Wed Dec 4 08:40:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84C401AE2E4 for ; Wed, 4 Dec 2013 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001, 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 gGS97VkrjmIZ for ; Wed, 4 Dec 2013 08:40:42 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id D02841AE2CC for ; Wed, 4 Dec 2013 08:40:39 -0800 (PST) Received: from mail172-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE023.bigfish.com (10.174.4.86) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 16:40:36 +0000 Received: from mail172-db8 (localhost [127.0.0.1]) by mail172-db8-R.bigfish.com (Postfix) with ESMTP id 4D982A80A01; Wed, 4 Dec 2013 16:40:36 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371Ic89bh542I1dbaI1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h9a9j1155h) Received-SPF: pass (mail172-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(199002)(189002)(51704005)(377454003)(47446002)(551934002)(15975445006)(76796001)(69226001)(51856001)(83072001)(79102001)(46102001)(54356001)(53806001)(74316001)(74366001)(74662001)(76482001)(19580395003)(56816005)(85852002)(90146001)(66066001)(81816001)(81686001)(47736001)(49866001)(56776001)(54316002)(81342001)(85306002)(65816001)(59766001)(19580405001)(2656002)(80976001)(50986001)(33646001)(80022001)(76786001)(31966008)(74876001)(87266001)(87936001)(76576001)(47976001)(83322001)(74706001)(74502001)(63696002)(77982001)(81542001)(4396001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB714; H:CO2PR05MB716.namprd05.prod.outlook.com; CLIP:66.129.241.17; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail172-db8 (localhost.localdomain [127.0.0.1]) by mail172-db8 (MessageSwitch) id 1386175234478590_28378; Wed, 4 Dec 2013 16:40:34 +0000 (UTC) Received: from DB8EHSMHS026.bigfish.com (unknown [10.174.8.253]) by mail172-db8.bigfish.com (Postfix) with ESMTP id 64F6F10004C; Wed, 4 Dec 2013 16:40:34 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS026.bigfish.com (10.174.4.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 16:40:29 +0000 Received: from CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 16:40:27 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com (10.141.228.152) by CO2PR05MB714.namprd05.prod.outlook.com (10.141.228.148) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 4 Dec 2013 16:40:23 +0000 Received: from CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) by CO2PR05MB716.namprd05.prod.outlook.com ([10.141.228.152]) with mapi id 15.00.0820.005; Wed, 4 Dec 2013 16:40:23 +0000 From: Jerome Moisand To: Linda Dunbar , Ron Parker , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAACG40AAAFUZgA== Date: Wed, 4 Dec 2013 16:40:23 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> <4A95BA014132FF49AE685FAB4B9F17F645C2A2EA@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C2A2EA@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.17] x-forefront-prvs: 0050CEFE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 04 Dec 2013 16:40:45 -0000 Yes, I was struggling with the same point, Ron. Your rewording is perfect. = Hopefully, Ted and Adrian and Jim will like it too! ;-) -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=20 Sent: Wednesday, December 04, 2013 11:31 AM To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter, Vodafone = DE; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Ron's refined wording is very accurate description. Really like it.=20 Linda > -----Original Message----- >=20 > << Today, common deployment models have service functions inserted=20 > transparently on the data-forwarding path between communicating peers. > Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through required service functions=20 > (physical or virtualized), wherever they are deployed.>> >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Wednesday, December 04, 2013 10:33 AM > To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda=20 > Dunbar; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Back to the original thread... ;-) >=20 > The new wording sounds fine to me. I would just reiterate my=20 > suggestion about avoiding the 'direct data path' terminology. Service=20 > chaining is about modifying the data path, it's not about avoiding it.=20 > I understand what 'direct' is supposed to mean, but this may be rather=20 > confusing to other readers. >=20 > Current text: > << Today, common deployment models have service functions inserted on=20 > the data-forwarding path between communicating peers. Going forward,=20 > however, there is a need to move to a different model, where service=20 > functions, whether physical or virtualized, are not required to reside=20 > on the direct data path and traffic is instead steered through=20 > required service functions, wherever they are deployed.>> >=20 > Proposed change: >=20 > << Today, common deployment models have service functions inserted on=20 > the regular data-forwarding path between communicating peers. Going=20 > forward, however, there is a desire to move to a different model,=20 > where traffic can be steered through required service functions=20 > (physical or virtualized), wherever they are deployed.>> >=20 > Tx > Jerome >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Wednesday, December 04, 2013 8:51 AM > To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar;=20 > Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Sumandra, >=20 > Your use case should absolutely be supported. Many service functions > may be co-located in the same compute complex (without getting too > precise on the meaning of that term). And in such a case, each may > use distinct or shared network locators (i.e., distinct or shared IP=20 > addresses). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, December 04, 2013 2:09 AM > To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron=20 > Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Hello Haeffner, >=20 > You are correct that a device like PGW, BNG or Load Balancer may offer=20 > multiple service. For example commercial load balancer can offer=20 > header enrichment, TCP optimization and quite an array of steering=20 > functionality. They can and do offer custom policy engines and such. >=20 > Another way of putting this is that a service-node may offer multiple=20 > distinct services. The local box can select a specific service based=20 > on the local policy. In my head I visualizing a service node that has=20 > one ingress and one egress but can offer multiple service inside that=20 > local entity. >=20 > I hope that would be possible as per this WG. >=20 >=20 > ________________________________________ > From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter,=20 > Vodafone DE [walter.haeffner@vodafone.com] > Sent: Tuesday, December 03, 2013 8:34 AM > To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk;=20 > nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Hi Linda, >=20 > I support your statement. Suggest we carefully distinguish between an=20 > abstract function, mean a well-defined unique elementary functionality=20 > and a physical device like a BNG or PGW or even a switch, router or=20 > x86 middleware box. Reading Ron's arguments, I assume Ron probably=20 > thinks in the same direction. >=20 > Originally e.g. a BNG is the service creation point for a DSL service=20 > (PPP, DHCP). A BNG as you said will also classify or inspect traffic=20 > and forward it according certain rules given e.g. by a AAA=20 > (up/downstream). Similar arguments for a PGW. >=20 > I could insert a service card into a BNG box and run e.g. CG-NAT on it. > Means CG-NAT would be in the BNG box but it is another elementary=20 > functionality which also could be realized outside the BNG box on=20 > another platform just dedicated for CG-NAT and located deep in the=20 > service function chain platform. I could plug service cards into=20 > routers and run some service functions. >=20 > Some vendors offer proprietary systems which include more than one=20 > unique functionality. I could buy a "performance enhancement proxy" > (whatever it means) which includes in e.g. TCP optimization, header=20 > enrichment and video optimization. This is typically a big=20 > installation over some racks but it can still be seen as one system or=20 > performance enhancement function. >=20 > An instantiation of an abstract unique elementary function (node) in a=20 > service function chain (directed graph) may even consist of a load=20 > balancer and a certain number of instances of the elementary service=20 > function, physical or virtualized. See also Ron's argumentation. >=20 > Means one really should distinguish between an abstract elementary=20 > functionality which I would associate with a node (for short service > function) in an abstract service chain (directed graph) and a=20 > physical box which may include more than just one instantiation of an=20 > elementary function. >=20 > Other example: A commercial load balancer may have more functions than=20 > just load balancing. .... >=20 > What do you think? >=20 > Regards, Walter >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar > Gesendet: Montag, 2. Dezember 2013 19:10 > An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Betreff: Re: [nsc] Ted Lemon's concern with charter text >=20 > Jerome, >=20 > I agree with you that the PGW (or a BNG for wireline) is the starting=20 > point of the chain. (most likely) It acts as both Service Classifier=20 > and Service Policy Enforcement Point. >=20 > Do you call PGW or BNG a "service function"? PGW/BNG can steer=20 > traffic to other service functions", but I don't think PGW/BNG=20 > themselves should be called "service functions". >=20 > Linda >=20 > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > > Sent: Monday, December 02, 2013 11:58 AM > > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: Re: [nsc] Ted Lemon's concern with charter text > > > > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > > chain. It acts as both Service Classifier and Service Policy=20 > > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > > squarely a Service Function. Would you agree? > > > > (anyhoo, my point was mostly to avoid the middlebox terminology!=20 > > Even if I know what you mean!) > > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Monday, December 02, 2013 12:53 PM > > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: RE: [nsc] Ted Lemon's concern with charter text > > > > Hi, Jerome. > > > > I agree with your definitions of service vs. service function. > > > > Regarding functions like PGW, in the upstream direction for user=20 > > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > > therefore not in need of any traffic steering. In the downstream > > direction, the PGW represents itself as a PE router that reaches the > > subscribers. Most of the interest, today, around the mobile use > case > > is for transparent middlebox functions that reside between the PGW > and > > the Internet. The set of service functions is typically called the > > "Gi LAN", a name that more or less implies the present day=20 > > deployment model. > > > > Ron > > > > > > -----Original Message----- > > From: Jerome Moisand [mailto:jmoisand@juniper.net] > > Sent: Monday, December 02, 2013 11:35 AM > > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: RE: [nsc] Ted Lemon's concern with charter text > > > > Issue#1: I think we have to be careful to not use the word 'service' > > to speak of a given network function. > > > > Personally, I always use the word 'service' as something perceived=20 > > by the end user/customer. Something that you subscribe to, something > that > > you benefit from, something that you may be billed for, something > that > > may require customer care interactions. This is a 'black box' > > perspective, the Network Service Provider (or IT department inside=20 > > an > > Enterprise) can then implement such service in many ways, using many=20 > > network functions and related systems, without the end user knowing. > > > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > > Service Function! Meaning a network function that directly helps in=20 > > providing service-related processing and service (profile)=20 > > differentiation. It's just a component though, not the entire=20 > > Service as perceived by the end user. > > > > And Ron, I would suggest to avoid speaking of mid-box (or=20 > > middleboxes), as this term has a connotation that would seem to=20 > > exclude some forms of Service Functions (e.g. a BNG or PGW are=20 > > rarely viewed as 'middlebox', and yet, they are *the* primary=20 > > Service Function in today's broadband networks). > > > > Issue #2: I understand what Ted is trying to say with the 'in-path' > > aspect, but fact is service (function) chaining is about steering=20 > > use traffic via a constrained path, and well, the service function=20 > > does remain on the data path (granted, the data path changed from a=20 > > 'shortest path routed' to a more constrained path, but it's still a=20 > > data path!). > > > > =3D=3D=3D > > I don't know, seems to me that the existing first paragraph is=20 > > actually fine, if not better (even if the last sentence 'direct data > path' > > terminology isn't that great either). It also seems to me that we've=20 > > been hair-splitting for a while now, and maybe we should just move > on... > > I would just suggest to simplify the last sentence of the existing=20 > > paragraph and say: > > > > << Going forward, however, there is a desire to move to a different=20 > > model, where traffic can be steered through service functions=20 > > (physical or virtualized), wherever they are deployed.>> > > > > And then, during the actual work, for sure, we'll need to settle on=20 > > clear definitions for 'Service', 'Service Function', etc. > > > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > > Sent: Monday, December 02, 2013 10:03 AM > > To: adrian@olddog.co.uk; nsc@ietf.org > > Cc: Ted Lemon > > Subject: Re: [nsc] Ted Lemon's concern with charter text > > > > Adrian, > > > > I think Ted's text is a very nice summary of what we are trying to=20 > > accomplish. > > > > He does use the term "in-path" which could use some elaboration, IMO. > > I feel that SFC applies to transparent mid-boxes and not to > explicitly > > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > > proxy, but not to an explicit HTTP proxy). > > > > > Network service providers, in addition to delivering IP=20 > > > connectivity, frequently provide in-path services such as firewall=20 > > > filtering, load balancing and transactional proxies such as spam > filters. > > > > Could become: > > > > "Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide transparent services such as=20 > > firewall filtering, load balancing and transactional proxies such as sp= am filters." > > > > We may want to strike or replace load balancing as that may not be=20 > > an actual transparent service but rather a building block for some > actual > > transport service -- open to suggestions on this verbage. > > > > > > > Today, a common deployment model has service functions inserted=20 > > > on the data-forwarding path between communicating peers. > > > > Could become: > > > > "Today, a common deployment model is to insert various mid-boxes on=20 > > the data-forwarding path between communicating peers." > > > > > > > > Ron > > > > > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Monday, December 02, 2013 7:21 AM > > To: nsc@ietf.org > > Cc: Ted Lemon > > Subject: [nsc] Ted Lemon's concern with charter text > > > > Hi, > > > > During IESG review Ted and I had a bit of an exchange about the=20 > > meaning of "a service" and the "layer at which a service chain can=20 > > be > applied". > > > > Ted was looking for some text to clarify this in the in the charter=20 > > and suggests replacing the entire first paragraph with... > > > > > Network service providers, in addition to delivering IP=20 > > > connectivity, frequently provide in-path services such as firewall > filtering, load > > > balancing and transactional proxies such as spam filters. > Delivery > > > of these types of services is undergoing significant change with=20 > > > the introduction of virtualization, network overlays, and > orchestration. > > > > > > Service delivery is currently both a technical and an=20 > > > organizational challenge that involves significant modification to=20 > > > the network configuration, impacting the speed at which services > can be > > > deployed and increasing operational costs. Such services are > > > typically implemented by the ordered combination of a number of=20 > > > service functions that are deployed at different points within a=20 > > > network. > > > > > > Today, a common deployment model has service functions inserted=20 > > > on the data-forwarding path between communicating peers. Going=20 > > > forward, however, there is a desire to move to a different model,=20 > > > where > > service > > > functions, whether physical or virtualized, are not required to > > reside > > > on the direct data path and traffic is instead steered through > > service > > > functions, wherever they are deployed. > > > > This is only a strawman from Ted (and thanks to him for proposing=20 > > text), and we should not assume that it is immutable. > > > > I think the way to look at this is: > > - Is there anything in the new text we disagree with? > > - Would making this change cause harm? > > - Could this change be improved still further? > > > > Opinions please. > > > > Cheers, > > Adrian > > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > > > > > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 From smkumar@cisco.com Wed Dec 4 21:57:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5BE1AE085 for ; Wed, 4 Dec 2013 21:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.202 X-Spam-Level: X-Spam-Status: No, score=-7.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LOAN=2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 AE-8QMXjrU0s for ; Wed, 4 Dec 2013 21:57:02 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6621AE03F for ; Wed, 4 Dec 2013 21:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17314; q=dns/txt; s=iport; t=1386223019; x=1387432619; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XguGOxZ/xWiH9BI1/Ljqf3/H8FL6H+Du0DxH+OK7UMI=; b=JHsokUP78Y8OktBceojpvSW6sourkMfQGdk4+G8H0wB9hikZv8Niv4p8 eWHRAX0fbmVKBZcEfwkfu4ChzhOvVbDXKdRiZ4dRTgZt3uZ2AvFrz4kly vMzlHsAMcOEiNtEs60wwGHTkL+FRRmB8X8lWdfCURYRBXqxvVFf3DTdAo A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHcUoFKtJV2Y/2dsb2JhbABZgwc4U7hrgRkWdIIlAQEBAwEBAQFiCQsMBgEIDgMEAQENGy4LFAkIAgQBDQWHfAYNwSgTBI5+BwaELQOJCo8KkhODKYIq X-IronPort-AV: E=Sophos;i="4.93,831,1378857600"; d="scan'208";a="4464566" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 05 Dec 2013 05:56:55 +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 rB55utUl020888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 05:56:55 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 23:56:55 -0600 From: "Surendra Kumar (smkumar)" To: Jerome Moisand , Linda Dunbar , Ron Parker , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAACG40AAAFUZgAAXrPqA Date: Thu, 5 Dec 2013 05:56:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.120.27] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <57986B439C9B0740A9ADDA7C630D4743@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 05:57:05 -0000 I liked the original text better. "need"/"desire" could not care less. Surendra. On 12/4/13 8:40 AM, "Jerome Moisand" wrote: >Yes, I was struggling with the same point, Ron. Your rewording is >perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-) > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Wednesday, December 04, 2013 11:31 AM >To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter, >Vodafone DE; adrian@olddog.co.uk; nsc@ietf.org >Cc: Ted Lemon >Subject: RE: [nsc] Ted Lemon's concern with charter text > > >Ron's refined wording is very accurate description. Really like it. > >Linda >> -----Original Message----- >>=20 >> << Today, common deployment models have service functions inserted >> transparently on the data-forwarding path between communicating peers. >> Going forward, however, there is a desire to move to a different >> model, where traffic can be steered through required service functions >> (physical or virtualized), wherever they are deployed.>> >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Wednesday, December 04, 2013 10:33 AM >> To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda >> Dunbar; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Back to the original thread... ;-) >>=20 >> The new wording sounds fine to me. I would just reiterate my >> suggestion about avoiding the 'direct data path' terminology. Service >> chaining is about modifying the data path, it's not about avoiding it. >> I understand what 'direct' is supposed to mean, but this may be rather >> confusing to other readers. >>=20 >> Current text: >> << Today, common deployment models have service functions inserted on >> the data-forwarding path between communicating peers. Going forward, >> however, there is a need to move to a different model, where service >> functions, whether physical or virtualized, are not required to reside >> on the direct data path and traffic is instead steered through >> required service functions, wherever they are deployed.>> >>=20 >> Proposed change: >>=20 >> << Today, common deployment models have service functions inserted on >> the regular data-forwarding path between communicating peers. Going >> forward, however, there is a desire to move to a different model, >> where traffic can be steered through required service functions >> (physical or virtualized), wherever they are deployed.>> >>=20 >> Tx >> Jerome >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Wednesday, December 04, 2013 8:51 AM >> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; >> Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Sumandra, >>=20 >> Your use case should absolutely be supported. Many service functions >> may be co-located in the same compute complex (without getting too >> precise on the meaning of that term). And in such a case, each may >> use distinct or shared network locators (i.e., distinct or shared IP >> addresses). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, December 04, 2013 2:09 AM >> To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron >> Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Hello Haeffner, >>=20 >> You are correct that a device like PGW, BNG or Load Balancer may offer >> multiple service. For example commercial load balancer can offer >> header enrichment, TCP optimization and quite an array of steering >> functionality. They can and do offer custom policy engines and such. >>=20 >> Another way of putting this is that a service-node may offer multiple >> distinct services. The local box can select a specific service based >> on the local policy. In my head I visualizing a service node that has >> one ingress and one egress but can offer multiple service inside that >> local entity. >>=20 >> I hope that would be possible as per this WG. >>=20 >>=20 >> ________________________________________ >> From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, >> Vodafone DE [walter.haeffner@vodafone.com] >> Sent: Tuesday, December 03, 2013 8:34 AM >> To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; >> nsc@ietf.org >> Cc: Ted Lemon >> Subject: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Hi Linda, >>=20 >> I support your statement. Suggest we carefully distinguish between an >> abstract function, mean a well-defined unique elementary functionality >> and a physical device like a BNG or PGW or even a switch, router or >> x86 middleware box. Reading Ron's arguments, I assume Ron probably >> thinks in the same direction. >>=20 >> Originally e.g. a BNG is the service creation point for a DSL service >> (PPP, DHCP). A BNG as you said will also classify or inspect traffic >> and forward it according certain rules given e.g. by a AAA >> (up/downstream). Similar arguments for a PGW. >>=20 >> I could insert a service card into a BNG box and run e.g. CG-NAT on it. >> Means CG-NAT would be in the BNG box but it is another elementary >> functionality which also could be realized outside the BNG box on >> another platform just dedicated for CG-NAT and located deep in the >> service function chain platform. I could plug service cards into >> routers and run some service functions. >>=20 >> Some vendors offer proprietary systems which include more than one >> unique functionality. I could buy a "performance enhancement proxy" >> (whatever it means) which includes in e.g. TCP optimization, header >> enrichment and video optimization. This is typically a big >> installation over some racks but it can still be seen as one system or >> performance enhancement function. >>=20 >> An instantiation of an abstract unique elementary function (node) in a >> service function chain (directed graph) may even consist of a load >> balancer and a certain number of instances of the elementary service >> function, physical or virtualized. See also Ron's argumentation. >>=20 >> Means one really should distinguish between an abstract elementary >> functionality which I would associate with a node (for short service >> function) in an abstract service chain (directed graph) and a >> physical box which may include more than just one instantiation of an >> elementary function. >>=20 >> Other example: A commercial load balancer may have more functions than >> just load balancing. .... >>=20 >> What do you think? >>=20 >> Regards, Walter >>=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar >> Gesendet: Montag, 2. Dezember 2013 19:10 >> An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Betreff: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Jerome, >>=20 >> I agree with you that the PGW (or a BNG for wireline) is the starting >> point of the chain. (most likely) It acts as both Service Classifier >> and Service Policy Enforcement Point. >>=20 >> Do you call PGW or BNG a "service function"? PGW/BNG can steer >> traffic to other service functions", but I don't think PGW/BNG >> themselves should be called "service functions". >>=20 >> Linda >>=20 >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand >> > Sent: Monday, December 02, 2013 11:58 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Well, the PGW (or a BNG for wireline) is the starting point of the >> > chain. It acts as both Service Classifier and Service Policy >> > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is >> > squarely a Service Function. Would you agree? >> > >> > (anyhoo, my point was mostly to avoid the middlebox terminology! >> > Even if I know what you mean!) >> > >> > -----Original Message----- >> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > Sent: Monday, December 02, 2013 12:53 PM >> > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, Jerome. >> > >> > I agree with your definitions of service vs. service function. >> > >> > Regarding functions like PGW, in the upstream direction for user >> > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is >> > therefore not in need of any traffic steering. In the downstream >> > direction, the PGW represents itself as a PE router that reaches the >> > subscribers. Most of the interest, today, around the mobile use >> case >> > is for transparent middlebox functions that reside between the PGW >> and >> > the Internet. The set of service functions is typically called the >> > "Gi LAN", a name that more or less implies the present day >> > deployment model. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: Jerome Moisand [mailto:jmoisand@juniper.net] >> > Sent: Monday, December 02, 2013 11:35 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Issue#1: I think we have to be careful to not use the word 'service' >> > to speak of a given network function. >> > >> > Personally, I always use the word 'service' as something perceived >> > by the end user/customer. Something that you subscribe to, something >> that >> > you benefit from, something that you may be billed for, something >> that >> > may require customer care interactions. This is a 'black box' >> > perspective, the Network Service Provider (or IT department inside >> > an >> > Enterprise) can then implement such service in many ways, using many >> > network functions and related systems, without the end user knowing. >> > >> > So a firewall or a spam-filtering proxy is NOT a Service. It's... a >> > Service Function! Meaning a network function that directly helps in >> > providing service-related processing and service (profile) >> > differentiation. It's just a component though, not the entire >> > Service as perceived by the end user. >> > >> > And Ron, I would suggest to avoid speaking of mid-box (or >> > middleboxes), as this term has a connotation that would seem to >> > exclude some forms of Service Functions (e.g. a BNG or PGW are >> > rarely viewed as 'middlebox', and yet, they are *the* primary >> > Service Function in today's broadband networks). >> > >> > Issue #2: I understand what Ted is trying to say with the 'in-path' >> > aspect, but fact is service (function) chaining is about steering >> > use traffic via a constrained path, and well, the service function >> > does remain on the data path (granted, the data path changed from a >> > 'shortest path routed' to a more constrained path, but it's still a >> > data path!). >> > >> > =3D=3D=3D >> > I don't know, seems to me that the existing first paragraph is >> > actually fine, if not better (even if the last sentence 'direct data >> path' >> > terminology isn't that great either). It also seems to me that we've >> > been hair-splitting for a while now, and maybe we should just move >> on... >> > I would just suggest to simplify the last sentence of the existing >> > paragraph and say: >> > >> > << Going forward, however, there is a desire to move to a different >> > model, where traffic can be steered through service functions >> > (physical or virtualized), wherever they are deployed.>> >> > >> > And then, during the actual work, for sure, we'll need to settle on >> > clear definitions for 'Service', 'Service Function', etc. >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker >> > Sent: Monday, December 02, 2013 10:03 AM >> > To: adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Adrian, >> > >> > I think Ted's text is a very nice summary of what we are trying to >> > accomplish. >> > >> > He does use the term "in-path" which could use some elaboration, IMO. >> > I feel that SFC applies to transparent mid-boxes and not to >> explicitly >> > addressed service functions (i.e., SFC applies to a transparent HTTP >> > proxy, but not to an explicit HTTP proxy). >> > >> > > Network service providers, in addition to delivering IP >> > > connectivity, frequently provide in-path services such as firewall >> > > filtering, load balancing and transactional proxies such as spam >> filters. >> > >> > Could become: >> > >> > "Network service providers, in addition to delivering IP >> > connectivity, frequently provide transparent services such as >> > firewall filtering, load balancing and transactional proxies such as >>spam filters." >> > >> > We may want to strike or replace load balancing as that may not be >> > an actual transparent service but rather a building block for some >> actual >> > transport service -- open to suggestions on this verbage. >> > >> > >> > > Today, a common deployment model has service functions inserted >> > > on the data-forwarding path between communicating peers. >> > >> > Could become: >> > >> > "Today, a common deployment model is to insert various mid-boxes on >> > the data-forwarding path between communicating peers." >> > >> > >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >> > Sent: Monday, December 02, 2013 7:21 AM >> > To: nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, >> > >> > During IESG review Ted and I had a bit of an exchange about the >> > meaning of "a service" and the "layer at which a service chain can >> > be >> applied". >> > >> > Ted was looking for some text to clarify this in the in the charter >> > and suggests replacing the entire first paragraph with... >> > >> > > Network service providers, in addition to delivering IP >> > > connectivity, frequently provide in-path services such as firewall >> filtering, load >> > > balancing and transactional proxies such as spam filters. >> Delivery >> > > of these types of services is undergoing significant change with >> > > the introduction of virtualization, network overlays, and >> orchestration. >> > > >> > > Service delivery is currently both a technical and an >> > > organizational challenge that involves significant modification to >> > > the network configuration, impacting the speed at which services >> can be >> > > deployed and increasing operational costs. Such services are >> > > typically implemented by the ordered combination of a number of >> > > service functions that are deployed at different points within a >> > > network. >> > > >> > > Today, a common deployment model has service functions inserted >> > > on the data-forwarding path between communicating peers. Going >> > > forward, however, there is a desire to move to a different model, >> > > where >> > service >> > > functions, whether physical or virtualized, are not required to >> > reside >> > > on the direct data path and traffic is instead steered through >> > service >> > > functions, wherever they are deployed. >> > >> > This is only a strawman from Ted (and thanks to him for proposing >> > text), and we should not assume that it is immutable. >> > >> > I think the way to look at this is: >> > - Is there anything in the new text we disagree with? >> > - Would making this change cause harm? >> > - Could this change be improved still further? >> > >> > Opinions please. >> > >> > Cheers, >> > Adrian >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >>=20 > > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jiangyuanlong@huawei.com Wed Dec 4 23:01:41 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FED1A1F58 for ; Wed, 4 Dec 2013 23:01:41 -0800 (PST) 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, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 f1Xu0Uj4mrGK for ; Wed, 4 Dec 2013 23:01:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 522961A1F02 for ; Wed, 4 Dec 2013 23:01:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBA59076; Thu, 05 Dec 2013 07:01:31 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 07:00:40 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Dec 2013 07:01:29 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.204]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 15:01:17 +0800 From: Jiangyuanlong To: Ron Parker , Jerome Moisand , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , Linda Dunbar , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAB6NJ+A= Date: Thu, 5 Dec 2013 07:01:17 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6CB754@szxema506-mbs.china.huawei.com> References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 07:01:41 -0000 Hi Ron and colleagues, I wonder how can a service function be physical or virtualized, maybe impli= citly you mean the node they are implemented on. To be consistent with othe= r terminologies in the proposed charter such as "service function instances= " and "network nodes", and call out network function "virtualization" as a = new trend, I would like to propose the following text: << Today, common deployment models have service functions implemented on ph= ysical nodes which are located on the regular data-forwarding path between = communicating peers. Going forward, however, there is a desire to move to a= different model, where service functions can be implemented on either phys= ical or virtualized network nodes, and traffic can be steered through requi= red service functions wherever they are deployed.>> Regards, Yuanlong -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, December 05, 2013 12:17 AM To: Jerome Moisand; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Du= nbar; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Jerome, I like your edits, but I'm iffy on "regular data path". I'll offer a furt= her refinement of your text: << Today, common deployment models have service functions inserted transpar= ently on the data-forwarding path between communicating peers. Going forwa= rd, however, there is a desire to move to a different model, where traffic = can be steered through required service functions (physical or virtualized)= , wherever they are deployed.>> Ron -----Original Message----- From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 Sent: Wednesday, December 04, 2013 10:33 AM To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Back to the original thread... ;-) The new wording sounds fine to me. I would just reiterate my suggestion abo= ut avoiding the 'direct data path' terminology. Service chaining is about m= odifying the data path, it's not about avoiding it. I understand what 'dire= ct' is supposed to mean, but this may be rather confusing to other readers. Current text: << Today, common deployment models have service functions inserted on the d= ata-forwarding path between communicating peers. Going forward, however, th= ere is a need to move to a different model, where service functions, whethe= r physical or virtualized, are not required to reside on the direct data pa= th and traffic is instead steered through required service functions, where= ver they are deployed.>> Proposed change: << Today, common deployment models have service functions inserted on the r= egular data-forwarding path between communicating peers. Going forward, how= ever, there is a desire to move to a different model, where traffic can be = steered through required service functions (physical or virtualized), where= ver they are deployed.>> Tx Jerome -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, December 04, 2013 8:51 AM To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moi= sand; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Sumandra, Your use case should absolutely be supported. Many service functions may= be co-located in the same compute complex (without getting too precise on = the meaning of that term). And in such a case, each may use distinct or s= hared network locators (i.e., distinct or shared IP addresses). Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com] Sent: Wednesday, December 04, 2013 2:09 AM To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Parker= ; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: RE: [nsc] Ted Lemon's concern with charter text Hello Haeffner, You are correct that a device like PGW, BNG or Load Balancer may offer mult= iple service. For example commercial load balancer can offer header enrichm= ent, TCP optimization and quite an array of steering functionality. They ca= n and do offer custom policy engines and such.=20 Another way of putting this is that a service-node may offer multiple disti= nct services. The local box can select a specific service based on the loca= l policy. In my head I visualizing a service node that has one ingress and= one egress but can offer multiple service inside that local entity.=20 I hope that would be possible as per this WG. =20 ________________________________________ From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone DE= [walter.haeffner@vodafone.com] Sent: Tuesday, December 03, 2013 8:34 AM To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf= .org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text Hi Linda, I support your statement. Suggest we carefully distinguish between an abst= ract function, mean a well-defined unique elementary functionality and a ph= ysical device like a BNG or PGW or even a switch, router or x86 middleware = box. Reading Ron's arguments, I assume Ron probably thinks in the same dire= ction. Originally e.g. a BNG is the service creation point for a DSL service (PPP,= DHCP). A BNG as you said will also classify or inspect traffic and forward= it according certain rules given e.g. by a AAA (up/downstream). Similar a= rguments for a PGW. I could insert a service card into a BNG box and run e.g. CG-NAT on it. Mea= ns CG-NAT would be in the BNG box but it is another elementary functionalit= y which also could be realized outside the BNG box on another platform just= dedicated for CG-NAT and located deep in the service function chain platfo= rm. I could plug service cards into routers and run some service functions= . Some vendors offer proprietary systems which include more than one unique f= unctionality. I could buy a "performance enhancement proxy" (whatever it me= ans) which includes in e.g. TCP optimization, header enrichment and video o= ptimization. This is typically a big installation over some racks but it ca= n still be seen as one system or performance enhancement function. An instantiation of an abstract unique elementary function (node) in a serv= ice function chain (directed graph) may even consist of a load balancer and= a certain number of instances of the elementary service function, physical= or virtualized. See also Ron's argumentation. Means one really should distinguish between an abstract elementary function= ality which I would associate with a node (for short service function) in = an abstract service chain (directed graph) and a physical box which may inc= lude more than just one instantiation of an elementary function. Other example: A commercial load balancer may have more functions than just= load balancing. .... What do you think? Regards, Walter -----Urspr=FCngliche Nachricht----- Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar Gesendet: Montag, 2. Dezember 2013 19:10 An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Betreff: Re: [nsc] Ted Lemon's concern with charter text Jerome, I agree with you that the PGW (or a BNG for wireline) is the starting point= of the chain. (most likely) It acts as both Service Classifier and Service= Policy Enforcement Point. Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic to = other service functions", but I don't think PGW/BNG themselves should be ca= lled "service functions". Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand > Sent: Monday, December 02, 2013 11:58 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Well, the PGW (or a BNG for wireline) is the starting point of the=20 > chain. It acts as both Service Classifier and Service Policy=20 > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 > squarely a Service Function. Would you agree? > > (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 > if I know what you mean!) > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, December 02, 2013 12:53 PM > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Hi, Jerome. > > I agree with your definitions of service vs. service function. > > Regarding functions like PGW, in the upstream direction for user=20 > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is > therefore not in need of any traffic steering. In the downstream > direction, the PGW represents itself as a PE router that reaches the > subscribers. Most of the interest, today, around the mobile use case > is for transparent middlebox functions that reside between the PGW and > the Internet. The set of service functions is typically called the > "Gi LAN", a name that more or less implies the present day deployment=20 > model. > > Ron > > > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net] > Sent: Monday, December 02, 2013 11:35 AM > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text > > Issue#1: I think we have to be careful to not use the word 'service' > to speak of a given network function. > > Personally, I always use the word 'service' as something perceived by=20 > the end user/customer. Something that you subscribe to, something that=20 > you benefit from, something that you may be billed for, something that=20 > may require customer care interactions. This is a 'black box' > perspective, the Network Service Provider (or IT department inside an > Enterprise) can then implement such service in many ways, using many=20 > network functions and related systems, without the end user knowing. > > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 > Service Function! Meaning a network function that directly helps in=20 > providing service-related processing and service (profile)=20 > differentiation. It's just a component though, not the entire Service=20 > as perceived by the end user. > > And Ron, I would suggest to avoid speaking of mid-box (or=20 > middleboxes), as this term has a connotation that would seem to=20 > exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 > viewed as 'middlebox', and yet, they are *the* primary Service=20 > Function in today's broadband networks). > > Issue #2: I understand what Ted is trying to say with the 'in-path' > aspect, but fact is service (function) chaining is about steering use=20 > traffic via a constrained path, and well, the service function does=20 > remain on the data path (granted, the data path changed from a=20 > 'shortest path routed' to a more constrained path, but it's still a=20 > data path!). > > =3D=3D=3D > I don't know, seems to me that the existing first paragraph is=20 > actually fine, if not better (even if the last sentence 'direct data path= ' > terminology isn't that great either). It also seems to me that we've=20 > been hair-splitting for a while now, and maybe we should just move on... > I would just suggest to simplify the last sentence of the existing=20 > paragraph and say: > > << Going forward, however, there is a desire to move to a different=20 > model, where traffic can be steered through service functions=20 > (physical or virtualized), wherever they are deployed.>> > > And then, during the actual work, for sure, we'll need to settle on=20 > clear definitions for 'Service', 'Service Function', etc. > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Monday, December 02, 2013 10:03 AM > To: adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text > > Adrian, > > I think Ted's text is a very nice summary of what we are trying to=20 > accomplish. > > He does use the term "in-path" which could use some elaboration, IMO. > I feel that SFC applies to transparent mid-boxes and not to explicitly=20 > addressed service functions (i.e., SFC applies to a transparent HTTP=20 > proxy, but not to an explicit HTTP proxy). > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall=20 > > filtering, load balancing and transactional proxies such as spam filte= rs. > > Could become: > > "Network service providers, in addition to delivering IP connectivity,=20 > frequently provide transparent services such as firewall filtering,=20 > load balancing and transactional proxies such as spam filters." > > We may want to strike or replace load balancing as that may not be an=20 > actual transparent service but rather a building block for some actual=20 > transport service -- open to suggestions on this verbage. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. > > Could become: > > "Today, a common deployment model is to insert various mid-boxes on=20 > the data-forwarding path between communicating peers." > > > > Ron > > > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, December 02, 2013 7:21 AM > To: nsc@ietf.org > Cc: Ted Lemon > Subject: [nsc] Ted Lemon's concern with charter text > > Hi, > > During IESG review Ted and I had a bit of an exchange about the=20 > meaning of "a service" and the "layer at which a service chain can be app= lied". > > Ted was looking for some text to clarify this in the in the charter=20 > and suggests replacing the entire first paragraph with... > > > Network service providers, in addition to delivering IP=20 > > connectivity, frequently provide in-path services such as firewall filt= ering, load > > balancing and transactional proxies such as spam filters. Delivery > > of these types of services is undergoing significant change with=20 > > the introduction of virtualization, network overlays, and orchestration= . > > > > Service delivery is currently both a technical and an=20 > > organizational challenge that involves significant modification to=20 > > the network configuration, impacting the speed at which services can be > > deployed and increasing operational costs. Such services are > > typically implemented by the ordered combination of a number of=20 > > service functions that are deployed at different points within a=20 > > network. > > > > Today, a common deployment model has service functions inserted on=20 > > the data-forwarding path between communicating peers. Going forward,=20 > > however, there is a desire to move to a different model, where > service > > functions, whether physical or virtualized, are not required to > reside > > on the direct data path and traffic is instead steered through > service > > functions, wherever they are deployed. > > This is only a strawman from Ted (and thanks to him for proposing=20 > text), and we should not assume that it is immutable. > > I think the way to look at this is: > - Is there anything in the new text we disagree with? > - Would making this change cause harm? > - Could this change be improved still further? > > Opinions please. > > Cheers, > Adrian > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Dec 5 04:37:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDC21ADF8D for ; Thu, 5 Dec 2013 04:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 wvqFxrqPw3Ee for ; Thu, 5 Dec 2013 04:37:23 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id A918A1ADF7B for ; Thu, 5 Dec 2013 04:37:23 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 04:37:20 -0800 From: Ron Parker To: Jiangyuanlong Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAB6NJ+AADCj29w== Date: Thu, 5 Dec 2013 12:37:19 +0000 Message-ID: References: <0c2701ceef58$f3725540$da56ffc0$@olddog.co.uk> <4A95BA014132FF49AE685FAB4B9F17F645C266B5@dfweml509-mbx.china.huawei.com>, <0BF7E0211CA62B42AE3FD4020E41609884963066@SEAEMBX01.olympus.F5Net.com> <8c035fce5e564bb9a34b5fcc8b95b3c3@CO2PR05MB716.namprd05.prod.outlook.com> , <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6CB754@szxema506-mbs.china.huawei.com> In-Reply-To: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6CB754@szxema506-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Sumandra Majee , Linda Dunbar , "Haeffner, Walter, Vodafone DE" , Ted Lemon , "adrian@olddog.co.uk" Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 12:37:27 -0000 Yuanlong, I don't have a problem pointing out that most deployments today are on non-= virtualized service functions. But we should be careful with the wording -= - even virtualized service functions reside on physical compute nodes. =20 Ron > On Dec 5, 2013, at 2:01 AM, "Jiangyuanlong" wr= ote: >=20 > Hi Ron and colleagues, >=20 > I wonder how can a service function be physical or virtualized, maybe imp= licitly you mean the node they are implemented on. To be consistent with ot= her terminologies in the proposed charter such as "service function instanc= es" and "network nodes", and call out network function "virtualization" as = a new trend, I would like to propose the following text: >=20 > << Today, common deployment models have service functions implemented on = physical nodes which are located on the regular data-forwarding path betwee= n communicating peers. Going forward, however, there is a desire to move to= a different model, where service functions can be implemented on either ph= ysical or virtualized network nodes, and traffic can be steered through req= uired service functions wherever they are deployed.>> >=20 > Regards, > Yuanlong >=20 >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Thursday, December 05, 2013 12:17 AM > To: Jerome Moisand; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda = Dunbar; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Jerome, >=20 > I like your edits, but I'm iffy on "regular data path". I'll offer a fu= rther refinement of your text: >=20 > << Today, common deployment models have service functions inserted transp= arently on the data-forwarding path between communicating peers. Going for= ward, however, there is a desire to move to a different model, where traffi= c can be steered through required service functions (physical or virtualize= d), wherever they are deployed.>> >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jerome Moisand [mailto:jmoisand@juniper.net]=20 > Sent: Wednesday, December 04, 2013 10:33 AM > To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunb= ar; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Back to the original thread... ;-) >=20 > The new wording sounds fine to me. I would just reiterate my suggestion a= bout avoiding the 'direct data path' terminology. Service chaining is about= modifying the data path, it's not about avoiding it. I understand what 'di= rect' is supposed to mean, but this may be rather confusing to other reader= s. >=20 > Current text: > << Today, common deployment models have service functions inserted on the= data-forwarding path between communicating peers. Going forward, however, = there is a need to move to a different model, where service functions, whet= her physical or virtualized, are not required to reside on the direct data = path and traffic is instead steered through required service functions, whe= rever they are deployed.>> >=20 > Proposed change: >=20 > << Today, common deployment models have service functions inserted on the= regular data-forwarding path between communicating peers. Going forward, h= owever, there is a desire to move to a different model, where traffic can b= e steered through required service functions (physical or virtualized), whe= rever they are deployed.>> >=20 > Tx > Jerome >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Wednesday, December 04, 2013 8:51 AM > To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome M= oisand; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Sumandra, >=20 > Your use case should absolutely be supported. Many service functions m= ay be co-located in the same compute complex (without getting too precise o= n the meaning of that term). And in such a case, each may use distinct or= shared network locators (i.e., distinct or shared IP addresses). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Wednesday, December 04, 2013 2:09 AM > To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron Park= er; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Subject: RE: [nsc] Ted Lemon's concern with charter text >=20 > Hello Haeffner, >=20 > You are correct that a device like PGW, BNG or Load Balancer may offer mu= ltiple service. For example commercial load balancer can offer header enric= hment, TCP optimization and quite an array of steering functionality. They = can and do offer custom policy engines and such.=20 >=20 > Another way of putting this is that a service-node may offer multiple dis= tinct services. The local box can select a specific service based on the lo= cal policy. In my head I visualizing a service node that has one ingress a= nd one egress but can offer multiple service inside that local entity.=20 >=20 > I hope that would be possible as per this WG. =20 >=20 >=20 > ________________________________________ > From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, Vodafone = DE [walter.haeffner@vodafone.com] > Sent: Tuesday, December 03, 2013 8:34 AM > To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ie= tf.org > Cc: Ted Lemon > Subject: Re: [nsc] Ted Lemon's concern with charter text >=20 > Hi Linda, >=20 > I support your statement. Suggest we carefully distinguish between an ab= stract function, mean a well-defined unique elementary functionality and a = physical device like a BNG or PGW or even a switch, router or x86 middlewar= e box. Reading Ron's arguments, I assume Ron probably thinks in the same di= rection. >=20 > Originally e.g. a BNG is the service creation point for a DSL service (PP= P, DHCP). A BNG as you said will also classify or inspect traffic and forwa= rd it according certain rules given e.g. by a AAA (up/downstream). Similar= arguments for a PGW. >=20 > I could insert a service card into a BNG box and run e.g. CG-NAT on it. M= eans CG-NAT would be in the BNG box but it is another elementary functional= ity which also could be realized outside the BNG box on another platform ju= st dedicated for CG-NAT and located deep in the service function chain plat= form. I could plug service cards into routers and run some service functio= ns. >=20 > Some vendors offer proprietary systems which include more than one unique= functionality. I could buy a "performance enhancement proxy" (whatever it = means) which includes in e.g. TCP optimization, header enrichment and video= optimization. This is typically a big installation over some racks but it = can still be seen as one system or performance enhancement function. >=20 > An instantiation of an abstract unique elementary function (node) in a se= rvice function chain (directed graph) may even consist of a load balancer a= nd a certain number of instances of the elementary service function, physic= al or virtualized. See also Ron's argumentation. >=20 > Means one really should distinguish between an abstract elementary functi= onality which I would associate with a node (for short service function) i= n an abstract service chain (directed graph) and a physical box which may i= nclude more than just one instantiation of an elementary function. >=20 > Other example: A commercial load balancer may have more functions than ju= st load balancing. .... >=20 > What do you think? >=20 > Regards, Walter >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar > Gesendet: Montag, 2. Dezember 2013 19:10 > An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org > Cc: Ted Lemon > Betreff: Re: [nsc] Ted Lemon's concern with charter text >=20 > Jerome, >=20 > I agree with you that the PGW (or a BNG for wireline) is the starting poi= nt of the chain. (most likely) It acts as both Service Classifier and Servi= ce Policy Enforcement Point. >=20 > Do you call PGW or BNG a "service function"? PGW/BNG can steer traffic t= o other service functions", but I don't think PGW/BNG themselves should be = called "service functions". >=20 > Linda >=20 >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand >> Sent: Monday, December 02, 2013 11:58 AM >> To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Well, the PGW (or a BNG for wireline) is the starting point of the=20 >> chain. It acts as both Service Classifier and Service Policy=20 >> Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is=20 >> squarely a Service Function. Would you agree? >>=20 >> (anyhoo, my point was mostly to avoid the middlebox terminology! Even=20 >> if I know what you mean!) >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, December 02, 2013 12:53 PM >> To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Hi, Jerome. >>=20 >> I agree with your definitions of service vs. service function. >>=20 >> Regarding functions like PGW, in the upstream direction for user=20 >> traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is >> therefore not in need of any traffic steering. In the downstream >> direction, the PGW represents itself as a PE router that reaches the >> subscribers. Most of the interest, today, around the mobile use case >> is for transparent middlebox functions that reside between the PGW and >> the Internet. The set of service functions is typically called the >> "Gi LAN", a name that more or less implies the present day deployment=20 >> model. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Monday, December 02, 2013 11:35 AM >> To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Issue#1: I think we have to be careful to not use the word 'service' >> to speak of a given network function. >>=20 >> Personally, I always use the word 'service' as something perceived by=20 >> the end user/customer. Something that you subscribe to, something that=20 >> you benefit from, something that you may be billed for, something that=20 >> may require customer care interactions. This is a 'black box' >> perspective, the Network Service Provider (or IT department inside an >> Enterprise) can then implement such service in many ways, using many=20 >> network functions and related systems, without the end user knowing. >>=20 >> So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 >> Service Function! Meaning a network function that directly helps in=20 >> providing service-related processing and service (profile)=20 >> differentiation. It's just a component though, not the entire Service=20 >> as perceived by the end user. >>=20 >> And Ron, I would suggest to avoid speaking of mid-box (or=20 >> middleboxes), as this term has a connotation that would seem to=20 >> exclude some forms of Service Functions (e.g. a BNG or PGW are rarely=20 >> viewed as 'middlebox', and yet, they are *the* primary Service=20 >> Function in today's broadband networks). >>=20 >> Issue #2: I understand what Ted is trying to say with the 'in-path' >> aspect, but fact is service (function) chaining is about steering use=20 >> traffic via a constrained path, and well, the service function does=20 >> remain on the data path (granted, the data path changed from a=20 >> 'shortest path routed' to a more constrained path, but it's still a=20 >> data path!). >>=20 >> =3D=3D=3D >> I don't know, seems to me that the existing first paragraph is=20 >> actually fine, if not better (even if the last sentence 'direct data pat= h' >> terminology isn't that great either). It also seems to me that we've=20 >> been hair-splitting for a while now, and maybe we should just move on... >> I would just suggest to simplify the last sentence of the existing=20 >> paragraph and say: >>=20 >> << Going forward, however, there is a desire to move to a different=20 >> model, where traffic can be steered through service functions=20 >> (physical or virtualized), wherever they are deployed.>> >>=20 >> And then, during the actual work, for sure, we'll need to settle on=20 >> clear definitions for 'Service', 'Service Function', etc. >>=20 >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker >> Sent: Monday, December 02, 2013 10:03 AM >> To: adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Adrian, >>=20 >> I think Ted's text is a very nice summary of what we are trying to=20 >> accomplish. >>=20 >> He does use the term "in-path" which could use some elaboration, IMO. >> I feel that SFC applies to transparent mid-boxes and not to explicitly=20 >> addressed service functions (i.e., SFC applies to a transparent HTTP=20 >> proxy, but not to an explicit HTTP proxy). >>=20 >>> Network service providers, in addition to delivering IP=20 >>> connectivity, frequently provide in-path services such as firewall=20 >>> filtering, load balancing and transactional proxies such as spam filte= rs. >>=20 >> Could become: >>=20 >> "Network service providers, in addition to delivering IP connectivity,=20 >> frequently provide transparent services such as firewall filtering,=20 >> load balancing and transactional proxies such as spam filters." >>=20 >> We may want to strike or replace load balancing as that may not be an=20 >> actual transparent service but rather a building block for some actual=20 >> transport service -- open to suggestions on this verbage. >>=20 >>=20 >>> Today, a common deployment model has service functions inserted on=20 >>> the data-forwarding path between communicating peers. >>=20 >> Could become: >>=20 >> "Today, a common deployment model is to insert various mid-boxes on=20 >> the data-forwarding path between communicating peers." >>=20 >>=20 >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Monday, December 02, 2013 7:21 AM >> To: nsc@ietf.org >> Cc: Ted Lemon >> Subject: [nsc] Ted Lemon's concern with charter text >>=20 >> Hi, >>=20 >> During IESG review Ted and I had a bit of an exchange about the=20 >> meaning of "a service" and the "layer at which a service chain can be ap= plied". >>=20 >> Ted was looking for some text to clarify this in the in the charter=20 >> and suggests replacing the entire first paragraph with... >>=20 >>> Network service providers, in addition to delivering IP=20 >>> connectivity, frequently provide in-path services such as firewall filt= ering, load >>> balancing and transactional proxies such as spam filters. Delivery >>> of these types of services is undergoing significant change with=20 >>> the introduction of virtualization, network overlays, and orchestration= . >>>=20 >>> Service delivery is currently both a technical and an=20 >>> organizational challenge that involves significant modification to=20 >>> the network configuration, impacting the speed at which services can be >>> deployed and increasing operational costs. Such services are >>> typically implemented by the ordered combination of a number of=20 >>> service functions that are deployed at different points within a=20 >>> network. >>>=20 >>> Today, a common deployment model has service functions inserted on=20 >>> the data-forwarding path between communicating peers. Going forward,=20 >>> however, there is a desire to move to a different model, where >> service >>> functions, whether physical or virtualized, are not required to >> reside >>> on the direct data path and traffic is instead steered through >> service >>> functions, wherever they are deployed. >>=20 >> This is only a strawman from Ted (and thanks to him for proposing=20 >> text), and we should not assume that it is immutable. >>=20 >> I think the way to look at this is: >> - Is there anything in the new text we disagree with? >> - Would making this change cause harm? >> - Could this change be improved still further? >>=20 >> Opinions please. >>=20 >> Cheers, >> Adrian >>=20 >>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Dec 5 08:50:56 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18211AE0FB for ; Thu, 5 Dec 2013 08:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.202 X-Spam-Level: X-Spam-Status: No, score=-12.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 mtkM2RIwNFKm for ; Thu, 5 Dec 2013 08:50:53 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 25B9C1AE0C8 for ; Thu, 5 Dec 2013 08:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17757; q=dns/txt; s=iport; t=1386262250; x=1387471850; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mrrMqyhdLLNtz+R109iTfHH9HlGpVap9cjxJBuWNOG4=; b=J5Oc8uXtJs/Bl+Qr2tjC4F/eTnact7gU9g3qI5i1E+C72Wf/qgQ8yz+h 2fdrjLnOydUouPPjZ1pHFUqm5CJhs/q+CTjJxY+lk8avYlZxTG3f5UBSB Ot+tCvIlpnSZ69u1idZBTkHadLHkFTvH277a03dzZldwMD4OcoJ2Mi9dR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAA+uoFKtJXHA/2dsb2JhbABZgwc4U7htgRwWdIIlAQEBAwEBAQFiCQsMBgEIDgMEAQENGy4LFAkIAgQBDQWHfAYNwVkTBI8ABwaELQOYFJITgymCKg X-IronPort-AV: E=Sophos;i="4.93,834,1378857600"; d="scan'208";a="289695673" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2013 16:50:48 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB5GomiO003179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 16:50:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 10:50:48 -0600 From: "Jim Guichard (jguichar)" To: Jerome Moisand , Linda Dunbar , Ron Parker , Sumandra Majee , "Haeffner, Walter, Vodafone DE" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAACG40AAAFUZgAA0zC0A Date: Thu, 5 Dec 2013 16:50:47 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.183] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 16:50:56 -0000 I'm afraid that I do not like the use of the word "transparent" in the revised text as this will require even more explanation in the charter. What do we mean by "transparent"; transparent to the end-user? Transparent to the TCP session? Transparent to =8A? You get my point. I would suggest that removal of "transparent" from the text should be sufficient as the existing text is only meant to say that service functions sit on the forwarding path today and in future we want to relax that requirement through steering. On 12/4/13 11:40 AM, "Jerome Moisand" wrote: >Yes, I was struggling with the same point, Ron. Your rewording is >perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-) > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Wednesday, December 04, 2013 11:31 AM >To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter, >Vodafone DE; adrian@olddog.co.uk; nsc@ietf.org >Cc: Ted Lemon >Subject: RE: [nsc] Ted Lemon's concern with charter text > > >Ron's refined wording is very accurate description. Really like it. > >Linda >> -----Original Message----- >>=20 >> << Today, common deployment models have service functions inserted >> transparently on the data-forwarding path between communicating peers. >> Going forward, however, there is a desire to move to a different >> model, where traffic can be steered through required service functions >> (physical or virtualized), wherever they are deployed.>> >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Wednesday, December 04, 2013 10:33 AM >> To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda >> Dunbar; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Back to the original thread... ;-) >>=20 >> The new wording sounds fine to me. I would just reiterate my >> suggestion about avoiding the 'direct data path' terminology. Service >> chaining is about modifying the data path, it's not about avoiding it. >> I understand what 'direct' is supposed to mean, but this may be rather >> confusing to other readers. >>=20 >> Current text: >> << Today, common deployment models have service functions inserted on >> the data-forwarding path between communicating peers. Going forward, >> however, there is a need to move to a different model, where service >> functions, whether physical or virtualized, are not required to reside >> on the direct data path and traffic is instead steered through >> required service functions, wherever they are deployed.>> >>=20 >> Proposed change: >>=20 >> << Today, common deployment models have service functions inserted on >> the regular data-forwarding path between communicating peers. Going >> forward, however, there is a desire to move to a different model, >> where traffic can be steered through required service functions >> (physical or virtualized), wherever they are deployed.>> >>=20 >> Tx >> Jerome >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Wednesday, December 04, 2013 8:51 AM >> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; >> Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Sumandra, >>=20 >> Your use case should absolutely be supported. Many service functions >> may be co-located in the same compute complex (without getting too >> precise on the meaning of that term). And in such a case, each may >> use distinct or shared network locators (i.e., distinct or shared IP >> addresses). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, December 04, 2013 2:09 AM >> To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron >> Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Hello Haeffner, >>=20 >> You are correct that a device like PGW, BNG or Load Balancer may offer >> multiple service. For example commercial load balancer can offer >> header enrichment, TCP optimization and quite an array of steering >> functionality. They can and do offer custom policy engines and such. >>=20 >> Another way of putting this is that a service-node may offer multiple >> distinct services. The local box can select a specific service based >> on the local policy. In my head I visualizing a service node that has >> one ingress and one egress but can offer multiple service inside that >> local entity. >>=20 >> I hope that would be possible as per this WG. >>=20 >>=20 >> ________________________________________ >> From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, >> Vodafone DE [walter.haeffner@vodafone.com] >> Sent: Tuesday, December 03, 2013 8:34 AM >> To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; >> nsc@ietf.org >> Cc: Ted Lemon >> Subject: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Hi Linda, >>=20 >> I support your statement. Suggest we carefully distinguish between an >> abstract function, mean a well-defined unique elementary functionality >> and a physical device like a BNG or PGW or even a switch, router or >> x86 middleware box. Reading Ron's arguments, I assume Ron probably >> thinks in the same direction. >>=20 >> Originally e.g. a BNG is the service creation point for a DSL service >> (PPP, DHCP). A BNG as you said will also classify or inspect traffic >> and forward it according certain rules given e.g. by a AAA >> (up/downstream). Similar arguments for a PGW. >>=20 >> I could insert a service card into a BNG box and run e.g. CG-NAT on it. >> Means CG-NAT would be in the BNG box but it is another elementary >> functionality which also could be realized outside the BNG box on >> another platform just dedicated for CG-NAT and located deep in the >> service function chain platform. I could plug service cards into >> routers and run some service functions. >>=20 >> Some vendors offer proprietary systems which include more than one >> unique functionality. I could buy a "performance enhancement proxy" >> (whatever it means) which includes in e.g. TCP optimization, header >> enrichment and video optimization. This is typically a big >> installation over some racks but it can still be seen as one system or >> performance enhancement function. >>=20 >> An instantiation of an abstract unique elementary function (node) in a >> service function chain (directed graph) may even consist of a load >> balancer and a certain number of instances of the elementary service >> function, physical or virtualized. See also Ron's argumentation. >>=20 >> Means one really should distinguish between an abstract elementary >> functionality which I would associate with a node (for short service >> function) in an abstract service chain (directed graph) and a >> physical box which may include more than just one instantiation of an >> elementary function. >>=20 >> Other example: A commercial load balancer may have more functions than >> just load balancing. .... >>=20 >> What do you think? >>=20 >> Regards, Walter >>=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar >> Gesendet: Montag, 2. Dezember 2013 19:10 >> An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Betreff: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Jerome, >>=20 >> I agree with you that the PGW (or a BNG for wireline) is the starting >> point of the chain. (most likely) It acts as both Service Classifier >> and Service Policy Enforcement Point. >>=20 >> Do you call PGW or BNG a "service function"? PGW/BNG can steer >> traffic to other service functions", but I don't think PGW/BNG >> themselves should be called "service functions". >>=20 >> Linda >>=20 >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand >> > Sent: Monday, December 02, 2013 11:58 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Well, the PGW (or a BNG for wireline) is the starting point of the >> > chain. It acts as both Service Classifier and Service Policy >> > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it is >> > squarely a Service Function. Would you agree? >> > >> > (anyhoo, my point was mostly to avoid the middlebox terminology! >> > Even if I know what you mean!) >> > >> > -----Original Message----- >> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > Sent: Monday, December 02, 2013 12:53 PM >> > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, Jerome. >> > >> > I agree with your definitions of service vs. service function. >> > >> > Regarding functions like PGW, in the upstream direction for user >> > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is >> > therefore not in need of any traffic steering. In the downstream >> > direction, the PGW represents itself as a PE router that reaches the >> > subscribers. Most of the interest, today, around the mobile use >> case >> > is for transparent middlebox functions that reside between the PGW >> and >> > the Internet. The set of service functions is typically called the >> > "Gi LAN", a name that more or less implies the present day >> > deployment model. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: Jerome Moisand [mailto:jmoisand@juniper.net] >> > Sent: Monday, December 02, 2013 11:35 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Issue#1: I think we have to be careful to not use the word 'service' >> > to speak of a given network function. >> > >> > Personally, I always use the word 'service' as something perceived >> > by the end user/customer. Something that you subscribe to, something >> that >> > you benefit from, something that you may be billed for, something >> that >> > may require customer care interactions. This is a 'black box' >> > perspective, the Network Service Provider (or IT department inside >> > an >> > Enterprise) can then implement such service in many ways, using many >> > network functions and related systems, without the end user knowing. >> > >> > So a firewall or a spam-filtering proxy is NOT a Service. It's... a >> > Service Function! Meaning a network function that directly helps in >> > providing service-related processing and service (profile) >> > differentiation. It's just a component though, not the entire >> > Service as perceived by the end user. >> > >> > And Ron, I would suggest to avoid speaking of mid-box (or >> > middleboxes), as this term has a connotation that would seem to >> > exclude some forms of Service Functions (e.g. a BNG or PGW are >> > rarely viewed as 'middlebox', and yet, they are *the* primary >> > Service Function in today's broadband networks). >> > >> > Issue #2: I understand what Ted is trying to say with the 'in-path' >> > aspect, but fact is service (function) chaining is about steering >> > use traffic via a constrained path, and well, the service function >> > does remain on the data path (granted, the data path changed from a >> > 'shortest path routed' to a more constrained path, but it's still a >> > data path!). >> > >> > =3D=3D=3D >> > I don't know, seems to me that the existing first paragraph is >> > actually fine, if not better (even if the last sentence 'direct data >> path' >> > terminology isn't that great either). It also seems to me that we've >> > been hair-splitting for a while now, and maybe we should just move >> on... >> > I would just suggest to simplify the last sentence of the existing >> > paragraph and say: >> > >> > << Going forward, however, there is a desire to move to a different >> > model, where traffic can be steered through service functions >> > (physical or virtualized), wherever they are deployed.>> >> > >> > And then, during the actual work, for sure, we'll need to settle on >> > clear definitions for 'Service', 'Service Function', etc. >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker >> > Sent: Monday, December 02, 2013 10:03 AM >> > To: adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Adrian, >> > >> > I think Ted's text is a very nice summary of what we are trying to >> > accomplish. >> > >> > He does use the term "in-path" which could use some elaboration, IMO. >> > I feel that SFC applies to transparent mid-boxes and not to >> explicitly >> > addressed service functions (i.e., SFC applies to a transparent HTTP >> > proxy, but not to an explicit HTTP proxy). >> > >> > > Network service providers, in addition to delivering IP >> > > connectivity, frequently provide in-path services such as firewall >> > > filtering, load balancing and transactional proxies such as spam >> filters. >> > >> > Could become: >> > >> > "Network service providers, in addition to delivering IP >> > connectivity, frequently provide transparent services such as >> > firewall filtering, load balancing and transactional proxies such as >>spam filters." >> > >> > We may want to strike or replace load balancing as that may not be >> > an actual transparent service but rather a building block for some >> actual >> > transport service -- open to suggestions on this verbage. >> > >> > >> > > Today, a common deployment model has service functions inserted >> > > on the data-forwarding path between communicating peers. >> > >> > Could become: >> > >> > "Today, a common deployment model is to insert various mid-boxes on >> > the data-forwarding path between communicating peers." >> > >> > >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >> > Sent: Monday, December 02, 2013 7:21 AM >> > To: nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, >> > >> > During IESG review Ted and I had a bit of an exchange about the >> > meaning of "a service" and the "layer at which a service chain can >> > be >> applied". >> > >> > Ted was looking for some text to clarify this in the in the charter >> > and suggests replacing the entire first paragraph with... >> > >> > > Network service providers, in addition to delivering IP >> > > connectivity, frequently provide in-path services such as firewall >> filtering, load >> > > balancing and transactional proxies such as spam filters. >> Delivery >> > > of these types of services is undergoing significant change with >> > > the introduction of virtualization, network overlays, and >> orchestration. >> > > >> > > Service delivery is currently both a technical and an >> > > organizational challenge that involves significant modification to >> > > the network configuration, impacting the speed at which services >> can be >> > > deployed and increasing operational costs. Such services are >> > > typically implemented by the ordered combination of a number of >> > > service functions that are deployed at different points within a >> > > network. >> > > >> > > Today, a common deployment model has service functions inserted >> > > on the data-forwarding path between communicating peers. Going >> > > forward, however, there is a desire to move to a different model, >> > > where >> > service >> > > functions, whether physical or virtualized, are not required to >> > reside >> > > on the direct data path and traffic is instead steered through >> > service >> > > functions, wherever they are deployed. >> > >> > This is only a strawman from Ted (and thanks to him for proposing >> > text), and we should not assume that it is immutable. >> > >> > I think the way to look at this is: >> > - Is there anything in the new text we disagree with? >> > - Would making this change cause harm? >> > - Could this change be improved still further? >> > >> > Opinions please. >> > >> > Cheers, >> > Adrian >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >>=20 > > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Dec 5 08:52:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B451B1AE09C for ; Thu, 5 Dec 2013 08:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001] 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 GxbJEIb-ByXf for ; Thu, 5 Dec 2013 08:51:57 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 52D7F1AE0A7 for ; Thu, 5 Dec 2013 08:51:57 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Thu, 5 Dec 2013 08:51:54 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , Jerome Moisand , Linda Dunbar , "Sumandra Majee" , "Haeffner, Walter, Vodafone DE" , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Ted Lemon's concern with charter text Thread-Index: Ac7vWKMGVaRZS67tTS2whFbZFiFUfQAFYRwgAAItRFAAAv5SYAABLS9QAABnMoAALI8iIAAgdwzMAA6US1AAA1tgkAABuXZgAACG40AAAFUZgAA0zC0AAAIRb3A= Date: Thu, 5 Dec 2013 16:51:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 16:52:00 -0000 No objections from me. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, December 05, 2013 11:51 AM To: Jerome Moisand; Linda Dunbar; Ron Parker; Sumandra Majee; Haeffner, Wal= ter, Vodafone DE; adrian@olddog.co.uk; nsc@ietf.org Cc: Ted Lemon Subject: Re: [nsc] Ted Lemon's concern with charter text I'm afraid that I do not like the use of the word "transparent" in the revi= sed text as this will require even more explanation in the charter. What do we mean by "transparent"; transparent to the end-user? Transparent = to the TCP session? Transparent to =A9? You get my point. I would suggest t= hat removal of "transparent" from the text should be sufficient as the exis= ting text is only meant to say that service functions sit on the forwarding= path today and in future we want to relax that requirement through steerin= g. On 12/4/13 11:40 AM, "Jerome Moisand" wrote: >Yes, I was struggling with the same point, Ron. Your rewording is=20 >perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-) > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Wednesday, December 04, 2013 11:31 AM >To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter,=20 >Vodafone DE; adrian@olddog.co.uk; nsc@ietf.org >Cc: Ted Lemon >Subject: RE: [nsc] Ted Lemon's concern with charter text > > >Ron's refined wording is very accurate description. Really like it. > >Linda >> -----Original Message----- >>=20 >> << Today, common deployment models have service functions inserted=20 >> transparently on the data-forwarding path between communicating peers. >> Going forward, however, there is a desire to move to a different=20 >> model, where traffic can be steered through required service=20 >> functions (physical or virtualized), wherever they are deployed.>> >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jerome Moisand [mailto:jmoisand@juniper.net] >> Sent: Wednesday, December 04, 2013 10:33 AM >> To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda=20 >> Dunbar; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Back to the original thread... ;-) >>=20 >> The new wording sounds fine to me. I would just reiterate my=20 >> suggestion about avoiding the 'direct data path' terminology. Service=20 >> chaining is about modifying the data path, it's not about avoiding it. >> I understand what 'direct' is supposed to mean, but this may be=20 >> rather confusing to other readers. >>=20 >> Current text: >> << Today, common deployment models have service functions inserted on=20 >> the data-forwarding path between communicating peers. Going forward,=20 >> however, there is a need to move to a different model, where service=20 >> functions, whether physical or virtualized, are not required to=20 >> reside on the direct data path and traffic is instead steered through=20 >> required service functions, wherever they are deployed.>> >>=20 >> Proposed change: >>=20 >> << Today, common deployment models have service functions inserted on=20 >> the regular data-forwarding path between communicating peers. Going=20 >> forward, however, there is a desire to move to a different model,=20 >> where traffic can be steered through required service functions=20 >> (physical or virtualized), wherever they are deployed.>> >>=20 >> Tx >> Jerome >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Wednesday, December 04, 2013 8:51 AM >> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar;=20 >> Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Sumandra, >>=20 >> Your use case should absolutely be supported. Many service functions >> may be co-located in the same compute complex (without getting too >> precise on the meaning of that term). And in such a case, each may >> use distinct or shared network locators (i.e., distinct or shared IP=20 >> addresses). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Wednesday, December 04, 2013 2:09 AM >> To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron=20 >> Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >> Hello Haeffner, >>=20 >> You are correct that a device like PGW, BNG or Load Balancer may=20 >> offer multiple service. For example commercial load balancer can=20 >> offer header enrichment, TCP optimization and quite an array of=20 >> steering functionality. They can and do offer custom policy engines and = such. >>=20 >> Another way of putting this is that a service-node may offer multiple=20 >> distinct services. The local box can select a specific service based=20 >> on the local policy. In my head I visualizing a service node that=20 >> has one ingress and one egress but can offer multiple service inside=20 >> that local entity. >>=20 >> I hope that would be possible as per this WG. >>=20 >>=20 >> ________________________________________ >> From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter,=20 >> Vodafone DE [walter.haeffner@vodafone.com] >> Sent: Tuesday, December 03, 2013 8:34 AM >> To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk;=20 >> nsc@ietf.org >> Cc: Ted Lemon >> Subject: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Hi Linda, >>=20 >> I support your statement. Suggest we carefully distinguish between=20 >> an abstract function, mean a well-defined unique elementary=20 >> functionality and a physical device like a BNG or PGW or even a=20 >> switch, router or >> x86 middleware box. Reading Ron's arguments, I assume Ron probably=20 >> thinks in the same direction. >>=20 >> Originally e.g. a BNG is the service creation point for a DSL service=20 >> (PPP, DHCP). A BNG as you said will also classify or inspect traffic=20 >> and forward it according certain rules given e.g. by a AAA=20 >> (up/downstream). Similar arguments for a PGW. >>=20 >> I could insert a service card into a BNG box and run e.g. CG-NAT on it. >> Means CG-NAT would be in the BNG box but it is another elementary=20 >> functionality which also could be realized outside the BNG box on=20 >> another platform just dedicated for CG-NAT and located deep in the=20 >> service function chain platform. I could plug service cards into=20 >> routers and run some service functions. >>=20 >> Some vendors offer proprietary systems which include more than one=20 >> unique functionality. I could buy a "performance enhancement proxy" >> (whatever it means) which includes in e.g. TCP optimization, header=20 >> enrichment and video optimization. This is typically a big=20 >> installation over some racks but it can still be seen as one system=20 >> or performance enhancement function. >>=20 >> An instantiation of an abstract unique elementary function (node) in=20 >> a service function chain (directed graph) may even consist of a load=20 >> balancer and a certain number of instances of the elementary service=20 >> function, physical or virtualized. See also Ron's argumentation. >>=20 >> Means one really should distinguish between an abstract elementary=20 >> functionality which I would associate with a node (for short service >> function) in an abstract service chain (directed graph) and a=20 >> physical box which may include more than just one instantiation of an=20 >> elementary function. >>=20 >> Other example: A commercial load balancer may have more functions=20 >> than just load balancing. .... >>=20 >> What do you think? >>=20 >> Regards, Walter >>=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar >> Gesendet: Montag, 2. Dezember 2013 19:10 >> An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Betreff: Re: [nsc] Ted Lemon's concern with charter text >>=20 >> Jerome, >>=20 >> I agree with you that the PGW (or a BNG for wireline) is the starting=20 >> point of the chain. (most likely) It acts as both Service Classifier=20 >> and Service Policy Enforcement Point. >>=20 >> Do you call PGW or BNG a "service function"? PGW/BNG can steer=20 >> traffic to other service functions", but I don't think PGW/BNG=20 >> themselves should be called "service functions". >>=20 >> Linda >>=20 >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand >> > Sent: Monday, December 02, 2013 11:58 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Well, the PGW (or a BNG for wireline) is the starting point of the=20 >> > chain. It acts as both Service Classifier and Service Policy=20 >> > Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it=20 >> > is squarely a Service Function. Would you agree? >> > >> > (anyhoo, my point was mostly to avoid the middlebox terminology! >> > Even if I know what you mean!) >> > >> > -----Original Message----- >> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > Sent: Monday, December 02, 2013 12:53 PM >> > To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, Jerome. >> > >> > I agree with your definitions of service vs. service function. >> > >> > Regarding functions like PGW, in the upstream direction for user=20 >> > traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is >> > therefore not in need of any traffic steering. In the downstream >> > direction, the PGW represents itself as a PE router that reaches the >> > subscribers. Most of the interest, today, around the mobile use >> case >> > is for transparent middlebox functions that reside between the PGW >> and >> > the Internet. The set of service functions is typically called the >> > "Gi LAN", a name that more or less implies the present day=20 >> > deployment model. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: Jerome Moisand [mailto:jmoisand@juniper.net] >> > Sent: Monday, December 02, 2013 11:35 AM >> > To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: RE: [nsc] Ted Lemon's concern with charter text >> > >> > Issue#1: I think we have to be careful to not use the word 'service' >> > to speak of a given network function. >> > >> > Personally, I always use the word 'service' as something perceived=20 >> > by the end user/customer. Something that you subscribe to,=20 >> > something >> that >> > you benefit from, something that you may be billed for, something >> that >> > may require customer care interactions. This is a 'black box' >> > perspective, the Network Service Provider (or IT department inside=20 >> > an >> > Enterprise) can then implement such service in many ways, using=20 >> > many network functions and related systems, without the end user knowi= ng. >> > >> > So a firewall or a spam-filtering proxy is NOT a Service. It's... a=20 >> > Service Function! Meaning a network function that directly helps in=20 >> > providing service-related processing and service (profile)=20 >> > differentiation. It's just a component though, not the entire=20 >> > Service as perceived by the end user. >> > >> > And Ron, I would suggest to avoid speaking of mid-box (or=20 >> > middleboxes), as this term has a connotation that would seem to=20 >> > exclude some forms of Service Functions (e.g. a BNG or PGW are=20 >> > rarely viewed as 'middlebox', and yet, they are *the* primary=20 >> > Service Function in today's broadband networks). >> > >> > Issue #2: I understand what Ted is trying to say with the 'in-path' >> > aspect, but fact is service (function) chaining is about steering=20 >> > use traffic via a constrained path, and well, the service function=20 >> > does remain on the data path (granted, the data path changed from a=20 >> > 'shortest path routed' to a more constrained path, but it's still a=20 >> > data path!). >> > >> > =3D=3D=3D >> > I don't know, seems to me that the existing first paragraph is=20 >> > actually fine, if not better (even if the last sentence 'direct=20 >> > data >> path' >> > terminology isn't that great either). It also seems to me that=20 >> > we've been hair-splitting for a while now, and maybe we should just=20 >> > move >> on... >> > I would just suggest to simplify the last sentence of the existing=20 >> > paragraph and say: >> > >> > << Going forward, however, there is a desire to move to a different=20 >> > model, where traffic can be steered through service functions=20 >> > (physical or virtualized), wherever they are deployed.>> >> > >> > And then, during the actual work, for sure, we'll need to settle on=20 >> > clear definitions for 'Service', 'Service Function', etc. >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker >> > Sent: Monday, December 02, 2013 10:03 AM >> > To: adrian@olddog.co.uk; nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: Re: [nsc] Ted Lemon's concern with charter text >> > >> > Adrian, >> > >> > I think Ted's text is a very nice summary of what we are trying to=20 >> > accomplish. >> > >> > He does use the term "in-path" which could use some elaboration, IMO. >> > I feel that SFC applies to transparent mid-boxes and not to >> explicitly >> > addressed service functions (i.e., SFC applies to a transparent=20 >> > HTTP proxy, but not to an explicit HTTP proxy). >> > >> > > Network service providers, in addition to delivering IP=20 >> > > connectivity, frequently provide in-path services such as=20 >> > > firewall filtering, load balancing and transactional proxies=20 >> > > such as spam >> filters. >> > >> > Could become: >> > >> > "Network service providers, in addition to delivering IP=20 >> > connectivity, frequently provide transparent services such as=20 >> > firewall filtering, load balancing and transactional proxies such=20 >> > as >>spam filters." >> > >> > We may want to strike or replace load balancing as that may not be=20 >> > an actual transparent service but rather a building block for some >> actual >> > transport service -- open to suggestions on this verbage. >> > >> > >> > > Today, a common deployment model has service functions inserted=20 >> > > on the data-forwarding path between communicating peers. >> > >> > Could become: >> > >> > "Today, a common deployment model is to insert various mid-boxes on=20 >> > the data-forwarding path between communicating peers." >> > >> > >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >> > Sent: Monday, December 02, 2013 7:21 AM >> > To: nsc@ietf.org >> > Cc: Ted Lemon >> > Subject: [nsc] Ted Lemon's concern with charter text >> > >> > Hi, >> > >> > During IESG review Ted and I had a bit of an exchange about the=20 >> > meaning of "a service" and the "layer at which a service chain can=20 >> > be >> applied". >> > >> > Ted was looking for some text to clarify this in the in the charter=20 >> > and suggests replacing the entire first paragraph with... >> > >> > > Network service providers, in addition to delivering IP=20 >> > > connectivity, frequently provide in-path services such as=20 >> > > firewall >> filtering, load >> > > balancing and transactional proxies such as spam filters. >> Delivery >> > > of these types of services is undergoing significant change with=20 >> > > the introduction of virtualization, network overlays, and >> orchestration. >> > > >> > > Service delivery is currently both a technical and an=20 >> > > organizational challenge that involves significant modification=20 >> > > to the network configuration, impacting the speed at which=20 >> > > services >> can be >> > > deployed and increasing operational costs. Such services are >> > > typically implemented by the ordered combination of a number of=20 >> > > service functions that are deployed at different points within a=20 >> > > network. >> > > >> > > Today, a common deployment model has service functions inserted=20 >> > > on the data-forwarding path between communicating peers. Going=20 >> > > forward, however, there is a desire to move to a different model,=20 >> > > where >> > service >> > > functions, whether physical or virtualized, are not required to >> > reside >> > > on the direct data path and traffic is instead steered through >> > service >> > > functions, wherever they are deployed. >> > >> > This is only a strawman from Ted (and thanks to him for proposing=20 >> > text), and we should not assume that it is immutable. >> > >> > I think the way to look at this is: >> > - Is there anything in the new text we disagree with? >> > - Would making this change cause harm? >> > - Could this change be improved still further? >> > >> > Opinions please. >> > >> > Cheers, >> > Adrian >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >>=20 > > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From tnadeau@lucidvision.com Thu Dec 5 11:04:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329A71AE154 for ; Thu, 5 Dec 2013 11:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_LOAN=2.3, RP_MATCHES_RCVD=-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 ADUr3EcdGkOS for ; Thu, 5 Dec 2013 11:04:20 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 37B3A1AE148 for ; Thu, 5 Dec 2013 11:04:20 -0800 (PST) Received: from [192.168.1.104] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 793FF26615C5; Thu, 5 Dec 2013 14:04:16 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_2EF92558-4515-4437-8617-4B6E4D3CAB22"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 5 Dec 2013 14:04:15 -0500 Message-Id: <9CA2B2FB-3818-454E-B912-2030CD071CD1@lucidvision.com> References: To: Guichard Jim X-Mailer: Apple Mail (2.1822) Cc: "nsc@ietf.org" , Sumandra Majee , Linda Dunbar , "Haeffner, Walter, Vodafone DE" , Ted Lemon , Ron Parker , Farrel Adrian Subject: Re: [nsc] Ted Lemon's concern with charter text X-BeenThere: nsc@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, 05 Dec 2013 19:04:23 -0000 --Apple-Mail=_2EF92558-4515-4437-8617-4B6E4D3CAB22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yea, I agree. This is a slippery slope akin to where we = originally went off the road in PWE3 when we debated "reproduces the = wire" or something like that. What we ended up with was "faithfully = approximates" or something. That relaxation of the = terminology/requirements went a long way in pragmatism of solutions.=20 --Tom > I'm afraid that I do not like the use of the word "transparent" in the > revised text as this will require even more explanation in the = charter. > What do we mean by "transparent"; transparent to the end-user? = Transparent > to the TCP session? Transparent to =8A? You get my point. I would = suggest > that removal of "transparent" from the text should be sufficient as = the > existing text is only meant to say that service functions sit on the > forwarding path today and in future we want to relax that requirement > through steering. >=20 > On 12/4/13 11:40 AM, "Jerome Moisand" wrote: >=20 >> Yes, I was struggling with the same point, Ron. Your rewording is >> perfect. Hopefully, Ted and Adrian and Jim will like it too! ;-) >>=20 >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Wednesday, December 04, 2013 11:31 AM >> To: Ron Parker; Jerome Moisand; Sumandra Majee; Haeffner, Walter, >> Vodafone DE; adrian@olddog.co.uk; nsc@ietf.org >> Cc: Ted Lemon >> Subject: RE: [nsc] Ted Lemon's concern with charter text >>=20 >>=20 >> Ron's refined wording is very accurate description. Really like it. >>=20 >> Linda >>> -----Original Message----- >>>=20 >>> << Today, common deployment models have service functions inserted >>> transparently on the data-forwarding path between communicating = peers. >>> Going forward, however, there is a desire to move to a different >>> model, where traffic can be steered through required service = functions >>> (physical or virtualized), wherever they are deployed.>> >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Jerome Moisand [mailto:jmoisand@juniper.net] >>> Sent: Wednesday, December 04, 2013 10:33 AM >>> To: Ron Parker; Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda >>> Dunbar; adrian@olddog.co.uk; nsc@ietf.org >>> Cc: Ted Lemon >>> Subject: RE: [nsc] Ted Lemon's concern with charter text >>>=20 >>> Back to the original thread... ;-) >>>=20 >>> The new wording sounds fine to me. I would just reiterate my >>> suggestion about avoiding the 'direct data path' terminology. = Service >>> chaining is about modifying the data path, it's not about avoiding = it. >>> I understand what 'direct' is supposed to mean, but this may be = rather >>> confusing to other readers. >>>=20 >>> Current text: >>> << Today, common deployment models have service functions inserted = on >>> the data-forwarding path between communicating peers. Going forward, >>> however, there is a need to move to a different model, where service >>> functions, whether physical or virtualized, are not required to = reside >>> on the direct data path and traffic is instead steered through >>> required service functions, wherever they are deployed.>> >>>=20 >>> Proposed change: >>>=20 >>> << Today, common deployment models have service functions inserted = on >>> the regular data-forwarding path between communicating peers. Going >>> forward, however, there is a desire to move to a different model, >>> where traffic can be steered through required service functions >>> (physical or virtualized), wherever they are deployed.>> >>>=20 >>> Tx >>> Jerome >>>=20 >>> -----Original Message----- >>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> Sent: Wednesday, December 04, 2013 8:51 AM >>> To: Sumandra Majee; Haeffner, Walter, Vodafone DE; Linda Dunbar; >>> Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >>> Cc: Ted Lemon >>> Subject: RE: [nsc] Ted Lemon's concern with charter text >>>=20 >>> Sumandra, >>>=20 >>> Your use case should absolutely be supported. Many service = functions >>> may be co-located in the same compute complex (without getting too >>> precise on the meaning of that term). And in such a case, each may >>> use distinct or shared network locators (i.e., distinct or shared IP >>> addresses). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> Sent: Wednesday, December 04, 2013 2:09 AM >>> To: Haeffner, Walter, Vodafone DE; Linda Dunbar; Jerome Moisand; Ron >>> Parker; adrian@olddog.co.uk; nsc@ietf.org >>> Cc: Ted Lemon >>> Subject: RE: [nsc] Ted Lemon's concern with charter text >>>=20 >>> Hello Haeffner, >>>=20 >>> You are correct that a device like PGW, BNG or Load Balancer may = offer >>> multiple service. For example commercial load balancer can offer >>> header enrichment, TCP optimization and quite an array of steering >>> functionality. They can and do offer custom policy engines and such. >>>=20 >>> Another way of putting this is that a service-node may offer = multiple >>> distinct services. The local box can select a specific service based >>> on the local policy. In my head I visualizing a service node that = has >>> one ingress and one egress but can offer multiple service inside = that >>> local entity. >>>=20 >>> I hope that would be possible as per this WG. >>>=20 >>>=20 >>> ________________________________________ >>> From: nsc [nsc-bounces@ietf.org] on behalf of Haeffner, Walter, >>> Vodafone DE [walter.haeffner@vodafone.com] >>> Sent: Tuesday, December 03, 2013 8:34 AM >>> To: Linda Dunbar; Jerome Moisand; Ron Parker; adrian@olddog.co.uk; >>> nsc@ietf.org >>> Cc: Ted Lemon >>> Subject: Re: [nsc] Ted Lemon's concern with charter text >>>=20 >>> Hi Linda, >>>=20 >>> I support your statement. Suggest we carefully distinguish between = an >>> abstract function, mean a well-defined unique elementary = functionality >>> and a physical device like a BNG or PGW or even a switch, router or >>> x86 middleware box. Reading Ron's arguments, I assume Ron probably >>> thinks in the same direction. >>>=20 >>> Originally e.g. a BNG is the service creation point for a DSL = service >>> (PPP, DHCP). A BNG as you said will also classify or inspect traffic >>> and forward it according certain rules given e.g. by a AAA >>> (up/downstream). Similar arguments for a PGW. >>>=20 >>> I could insert a service card into a BNG box and run e.g. CG-NAT on = it. >>> Means CG-NAT would be in the BNG box but it is another elementary >>> functionality which also could be realized outside the BNG box on >>> another platform just dedicated for CG-NAT and located deep in the >>> service function chain platform. I could plug service cards into >>> routers and run some service functions. >>>=20 >>> Some vendors offer proprietary systems which include more than one >>> unique functionality. I could buy a "performance enhancement proxy" >>> (whatever it means) which includes in e.g. TCP optimization, header >>> enrichment and video optimization. This is typically a big >>> installation over some racks but it can still be seen as one system = or >>> performance enhancement function. >>>=20 >>> An instantiation of an abstract unique elementary function (node) in = a >>> service function chain (directed graph) may even consist of a load >>> balancer and a certain number of instances of the elementary service >>> function, physical or virtualized. See also Ron's argumentation. >>>=20 >>> Means one really should distinguish between an abstract elementary >>> functionality which I would associate with a node (for short service >>> function) in an abstract service chain (directed graph) and a >>> physical box which may include more than just one instantiation of = an >>> elementary function. >>>=20 >>> Other example: A commercial load balancer may have more functions = than >>> just load balancing. .... >>>=20 >>> What do you think? >>>=20 >>> Regards, Walter >>>=20 >>>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: nsc [mailto:nsc-bounces@ietf.org] Im Auftrag von Linda Dunbar >>> Gesendet: Montag, 2. Dezember 2013 19:10 >>> An: Jerome Moisand; Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >>> Cc: Ted Lemon >>> Betreff: Re: [nsc] Ted Lemon's concern with charter text >>>=20 >>> Jerome, >>>=20 >>> I agree with you that the PGW (or a BNG for wireline) is the = starting >>> point of the chain. (most likely) It acts as both Service Classifier >>> and Service Policy Enforcement Point. >>>=20 >>> Do you call PGW or BNG a "service function"? PGW/BNG can steer >>> traffic to other service functions", but I don't think PGW/BNG >>> themselves should be called "service functions". >>>=20 >>> Linda >>>=20 >>>> -----Original Message----- >>>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand >>>> Sent: Monday, December 02, 2013 11:58 AM >>>> To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >>>> Cc: Ted Lemon >>>> Subject: Re: [nsc] Ted Lemon's concern with charter text >>>>=20 >>>> Well, the PGW (or a BNG for wireline) is the starting point of the >>>> chain. It acts as both Service Classifier and Service Policy >>>> Enforcement Point (sometimes at L3, sometimes at L4/L7). Hence it = is >>>> squarely a Service Function. Would you agree? >>>>=20 >>>> (anyhoo, my point was mostly to avoid the middlebox terminology! >>>> Even if I know what you mean!) >>>>=20 >>>> -----Original Message----- >>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>> Sent: Monday, December 02, 2013 12:53 PM >>>> To: Jerome Moisand; adrian@olddog.co.uk; nsc@ietf.org >>>> Cc: Ted Lemon >>>> Subject: RE: [nsc] Ted Lemon's concern with charter text >>>>=20 >>>> Hi, Jerome. >>>>=20 >>>> I agree with your definitions of service vs. service function. >>>>=20 >>>> Regarding functions like PGW, in the upstream direction for user >>>> traffic, it is explicitly addressed (i.e., GTP-U tunneling) and is >>>> therefore not in need of any traffic steering. In the downstream >>>> direction, the PGW represents itself as a PE router that reaches = the >>>> subscribers. Most of the interest, today, around the mobile use >>> case >>>> is for transparent middlebox functions that reside between the PGW >>> and >>>> the Internet. The set of service functions is typically called = the >>>> "Gi LAN", a name that more or less implies the present day >>>> deployment model. >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Jerome Moisand [mailto:jmoisand@juniper.net] >>>> Sent: Monday, December 02, 2013 11:35 AM >>>> To: Ron Parker; adrian@olddog.co.uk; nsc@ietf.org >>>> Cc: Ted Lemon >>>> Subject: RE: [nsc] Ted Lemon's concern with charter text >>>>=20 >>>> Issue#1: I think we have to be careful to not use the word = 'service' >>>> to speak of a given network function. >>>>=20 >>>> Personally, I always use the word 'service' as something perceived >>>> by the end user/customer. Something that you subscribe to, = something >>> that >>>> you benefit from, something that you may be billed for, something >>> that >>>> may require customer care interactions. This is a 'black box' >>>> perspective, the Network Service Provider (or IT department inside >>>> an >>>> Enterprise) can then implement such service in many ways, using = many >>>> network functions and related systems, without the end user = knowing. >>>>=20 >>>> So a firewall or a spam-filtering proxy is NOT a Service. It's... a >>>> Service Function! Meaning a network function that directly helps in >>>> providing service-related processing and service (profile) >>>> differentiation. It's just a component though, not the entire >>>> Service as perceived by the end user. >>>>=20 >>>> And Ron, I would suggest to avoid speaking of mid-box (or >>>> middleboxes), as this term has a connotation that would seem to >>>> exclude some forms of Service Functions (e.g. a BNG or PGW are >>>> rarely viewed as 'middlebox', and yet, they are *the* primary >>>> Service Function in today's broadband networks). >>>>=20 >>>> Issue #2: I understand what Ted is trying to say with the 'in-path' >>>> aspect, but fact is service (function) chaining is about steering >>>> use traffic via a constrained path, and well, the service function >>>> does remain on the data path (granted, the data path changed from a >>>> 'shortest path routed' to a more constrained path, but it's still a >>>> data path!). >>>>=20 >>>> =3D=3D=3D >>>> I don't know, seems to me that the existing first paragraph is >>>> actually fine, if not better (even if the last sentence 'direct = data >>> path' >>>> terminology isn't that great either). It also seems to me that = we've >>>> been hair-splitting for a while now, and maybe we should just move >>> on... >>>> I would just suggest to simplify the last sentence of the existing >>>> paragraph and say: >>>>=20 >>>> << Going forward, however, there is a desire to move to a different >>>> model, where traffic can be steered through service functions >>>> (physical or virtualized), wherever they are deployed.>> >>>>=20 >>>> And then, during the actual work, for sure, we'll need to settle on >>>> clear definitions for 'Service', 'Service Function', etc. >>>>=20 >>>> -----Original Message----- >>>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker >>>> Sent: Monday, December 02, 2013 10:03 AM >>>> To: adrian@olddog.co.uk; nsc@ietf.org >>>> Cc: Ted Lemon >>>> Subject: Re: [nsc] Ted Lemon's concern with charter text >>>>=20 >>>> Adrian, >>>>=20 >>>> I think Ted's text is a very nice summary of what we are trying to >>>> accomplish. >>>>=20 >>>> He does use the term "in-path" which could use some elaboration, = IMO. >>>> I feel that SFC applies to transparent mid-boxes and not to >>> explicitly >>>> addressed service functions (i.e., SFC applies to a transparent = HTTP >>>> proxy, but not to an explicit HTTP proxy). >>>>=20 >>>>> Network service providers, in addition to delivering IP >>>>> connectivity, frequently provide in-path services such as firewall >>>>> filtering, load balancing and transactional proxies such as spam >>> filters. >>>>=20 >>>> Could become: >>>>=20 >>>> "Network service providers, in addition to delivering IP >>>> connectivity, frequently provide transparent services such as >>>> firewall filtering, load balancing and transactional proxies such = as >>> spam filters." >>>>=20 >>>> We may want to strike or replace load balancing as that may not be >>>> an actual transparent service but rather a building block for some >>> actual >>>> transport service -- open to suggestions on this verbage. >>>>=20 >>>>=20 >>>>> Today, a common deployment model has service functions inserted >>>>> on the data-forwarding path between communicating peers. >>>>=20 >>>> Could become: >>>>=20 >>>> "Today, a common deployment model is to insert various mid-boxes on >>>> the data-forwarding path between communicating peers." >>>>=20 >>>>=20 >>>>=20 >>>> Ron >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >>>> Sent: Monday, December 02, 2013 7:21 AM >>>> To: nsc@ietf.org >>>> Cc: Ted Lemon >>>> Subject: [nsc] Ted Lemon's concern with charter text >>>>=20 >>>> Hi, >>>>=20 >>>> During IESG review Ted and I had a bit of an exchange about the >>>> meaning of "a service" and the "layer at which a service chain can >>>> be >>> applied". >>>>=20 >>>> Ted was looking for some text to clarify this in the in the charter >>>> and suggests replacing the entire first paragraph with... >>>>=20 >>>>> Network service providers, in addition to delivering IP >>>>> connectivity, frequently provide in-path services such as firewall >>> filtering, load >>>>> balancing and transactional proxies such as spam filters. >>> Delivery >>>>> of these types of services is undergoing significant change with >>>>> the introduction of virtualization, network overlays, and >>> orchestration. >>>>>=20 >>>>> Service delivery is currently both a technical and an >>>>> organizational challenge that involves significant modification to >>>>> the network configuration, impacting the speed at which services >>> can be >>>>> deployed and increasing operational costs. Such services are >>>>> typically implemented by the ordered combination of a number of >>>>> service functions that are deployed at different points within a >>>>> network. >>>>>=20 >>>>> Today, a common deployment model has service functions inserted >>>>> on the data-forwarding path between communicating peers. Going >>>>> forward, however, there is a desire to move to a different model, >>>>> where >>>> service >>>>> functions, whether physical or virtualized, are not required to >>>> reside >>>>> on the direct data path and traffic is instead steered through >>>> service >>>>> functions, wherever they are deployed. >>>>=20 >>>> This is only a strawman from Ted (and thanks to him for proposing >>>> text), and we should not assume that it is immutable. >>>>=20 >>>> I think the way to look at this is: >>>> - Is there anything in the new text we disagree with? >>>> - Would making this change cause harm? >>>> - Could this change be improved still further? >>>>=20 >>>> Opinions please. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_2EF92558-4515-4437-8617-4B6E4D3CAB22 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 iQIcBAEBCgAGBQJSoM4vAAoJEPcO+I7eiUJZEWkP/3xx0j5//7V/sIeVYIXAIMax d98VR8tvlth+bxJ1bx1DCvI2t7oiWvDxD/aNdIgHZzPwcxg5hG2bD6AgGjIul7Yk ZpUtF611i3KrjaEmI6piQ97p8pDPG4zs1gb1w8lZ+kX8wR5AYihsolCXYfaoq7r8 q8m8wOUuRiZ1SaqTCnJFOxQzeHRMVqsEVsCvolTH5bIH8XS2zLY5xNpNpJmhmcBu 3R3Q2xEpC2oBEKyac5SvSEsx0QA0eKusgYyF7yNC8wdWoIbPTfc1iKDVQvi5/qep RE55XWH+0qdt1R+GWQ3IJS9v41AZWVidK8X6bGgEsV4vDfg6T9Rk2WaalTRp3ben Zva1/0RmbTieapbVumwZmrYKuDrXGhMhYDT7dBWqLmPd3/xIMAp3rpYkLTgdxNqa tnjjLASJnts309e23gwPSBsqwBFNDFtsouKu0eAHkcmqAwN2jq8OBqUMlsGdtJvJ KQpi+BUMyStZW0ZBBB4u830bhjl3m+hLR7E3paQmKoNVxHN/ygn35y2d9nz3XaHt 7YE/cbRMR2CQ2LAYmwDSEq9HU8TH1TuC99F3qqDtdT5Yqc9xxEwqqQcDB3A8JgNv 2MesXLLXLcUiUWELBuyNhyeoFq6KZNLp1R7FuWegaigtg1EkO0OyTCFhzvffa47t ++GJvPVGZOcLXOWltmr8 =f/la -----END PGP SIGNATURE----- --Apple-Mail=_2EF92558-4515-4437-8617-4B6E4D3CAB22-- From zehn.cao@gmail.com Thu Dec 5 19:00:59 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D621AE22B for ; Thu, 5 Dec 2013 19:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 qmKRPv5npU-L for ; Thu, 5 Dec 2013 19:00:57 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9721AE228 for ; Thu, 5 Dec 2013 19:00:56 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so85724wgh.29 for ; Thu, 05 Dec 2013 19:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JYEbIccGO/Ko7WVhhsitRP3GOB+039CdCAe1ER8t/VM=; b=wSQhPMeRSh8OYV1bmRnrMyr6lKJekkq5lnJKuhORyUc98CW+rt36FZCxLcodic8RqJ JlfdE0LWxvWgT05Gr5lJgr4nHa10mJU+GmAqhl//sCqd9aZ3HHxWvl8aYLu8S/RtaEKm reUbNEw4kBr+57DI0CYaF8p0rKheiZMkTSCfG7AUoMCeS3xSV823swbiy3IpQUpkDo04 zmZzxAmUFEDdEfzKZzVUxcLnA8vHkjN/lQz9lqa2cZ6uTpD3bCSmkaUALOCnLeQuQz9U ZuidBaXolNHIdY3om/jzD913+6Fz7rJFzDH7fPTNSuGuYTIoCbETSVKwnHPiV/+Rh3KH 2puQ== MIME-Version: 1.0 X-Received: by 10.194.9.100 with SMTP id y4mr883991wja.22.1386298852542; Thu, 05 Dec 2013 19:00:52 -0800 (PST) Received: by 10.216.206.73 with HTTP; Thu, 5 Dec 2013 19:00:52 -0800 (PST) In-Reply-To: References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 6 Dec 2013 11:00:52 +0800 Message-ID: From: "Cao,Zhen" To: sarikaya@ieee.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "nsc@ietf.org" , Ian Smith , "Jim Guichard \(jguichar\)" , "Liushucheng \(Will\)" , Ron Parker , Mohamed Boucadair Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@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, 06 Dec 2013 03:01:00 -0000 per subscriber actually equal to per-flow based service chain. In order to identify the subscriber or their group, it will need to identify the flow. For this perspective, it is included. Regards, zhen On Thu, Nov 21, 2013 at 12:09 AM, Behcet Sarikaya wrote: > Hi Med, > > I think that the parental control service is an example. Another example = is > the traffic offloader service that we defined in draft-xue-aps-service > chaining-usecase-00.txt. > > Regards, > > Behcet > > > On Fri, Nov 15, 2013 at 3:08 AM, wrote: >> >> Hi Behcet, >> >> >> >> Which requirements document are you referring to? This one >> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00? >> >> >> >> We should make a distinction between classification rules and the set of >> SFCs themselves. Classification rules may be subscriber-inferred while I= =92m >> still not convinced the set of SFCs should be built on a per-subscriber >> basis. >> >> >> >> Cheers, >> >> Med >> >> >> >> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de >> Behcet Sarikaya >> Envoy=E9 : mercredi 16 octobre 2013 00:11 >> =C0 : Ian Smith >> Cc : nsc@ietf.org; Jim Guichard (jguichar); Liushucheng (Will); Ron Park= er >> Objet : Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> >> >> Folks, I checked and found out that in the requirements draft >> per-subscriber service issue is pretty clearly stated. >> >> My suggestion is to remove the paragraph that starts with SFC are not >> per-subscriber. It is confusing. >> >> Regards, >> >> Behcet >> >> >> >> On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith wrote: >> >> I'll see what I can do. >> >> ________________________________ >> >> From: Jim Guichard (jguichar) [jguichar@cisco.com] >> >> Sent: Tuesday, October 15, 2013 5:14 PM >> To: Ian Smith >> Cc: Ron Parker; ; nsc@ietf.org; Liushucheng (Will) >> >> >> Subject: Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> >> >> Use cases from real operators would be a start. >> >> Sent from my iPhone >> >> >> On Oct 15, 2013, at 5:11 PM, "Ian Smith" wrote: >> >> what do you need to make this reality driven? >> >> ________________________________ >> >> From: Jim Guichard (jguichar) [jguichar@cisco.com] >> Sent: Tuesday, October 15, 2013 5:02 PM >> To: Ron Parker >> Cc: ; nsc@ietf.org; Liushucheng (Will); Ian Smith >> Subject: Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> Sure but we should deal in reality driven by use cases and I have yet to >> see anyone suggest they will build an individual service chain for every >> client. In fact the complete opposite seems true. >> >> Sent from my iPhone >> >> >> On Oct 15, 2013, at 4:52 PM, "Ron Parker" >> wrote: >> >> Agree that is the typical usage of policy. And, the degenerate case is >> that the world is comprised of subscriber groups that have exactly 1 >> subscriber. Probably not practical, but why prevent it? >> >> >> >> Ron >> >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ji= m >> Guichard (jguichar) >> Sent: Tuesday, October 15, 2013 4:48 PM >> To: >> Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith >> Subject: Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> >> >> No, to me this is most certainly a per-subscriber-group. >> >> Sent from my iPhone >> >> >> On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" >> wrote: >> >> I was talking about something like parental control. >> >> Do you qualify such an SFC as each mobile client getting its own SFC? >> >> I think it is more like per-subscriber-group. It could be per subscriber >> as well but I can not think of an example at this moment. >> >> >> >> On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) >> wrote: >> >> Hi Ian, >> >> If by subscriber you mean per-tenant or per-subscriber-group then I will >> agree that SFC's will be built for these but that's a far cry from >> per-subscriber which implies to me an individual broadband or mobile cli= ent. >> >> Sent from my iPhone >> >> >> On Oct 15, 2013, at 1:51 PM, "Ian Smith" wrote: >> >> I don't think that is a foregone conclusion. >> >> When you combine what is being done in IaaS environments for muti-tenant >> dynamic datacenters with what you can do with policy defined networking = and >> IPv6, for an access provider to provision per-subscriber VAS LANs and >> default gateways takes away a lot of the big problems caused by aggregat= ion >> that you're trying to solve with service chains. More to the point, you >> don't need to disaggregate anything when you know that all the traffic >> belongs to a single customer, and that the default gateway of each node = is >> the next hop in the service chain. Solving the problem for 1 >> subscriber@1Gbps is trivial; what makes what we're talking about in this >> list hard is that you are trying to solve it for 10 million subscribers >> @100Gbps but in truth the only technology-based reason you do that is >> because of administrative challenges that the cloud world is solving (an= d >> may have solved before anything is produced in a WG) and that are square= ly >> in the domain of things already proven to be better done by computers th= an >> people. >> >> I tend to argue that per-subscriber provisioning of the access path >> triggered by identity-based authentication is the obvious and natural >> evolution of the technology being fielded today. >> >> >> >> ________________________________ >> >> From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim >> Guichard (jguichar) [jguichar@cisco.com] >> Sent: Tuesday, October 15, 2013 1:34 PM >> To: sarikaya@ieee.org; Liushucheng (Will) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> It seems very unlikely that one would opt for a solution whereby a >> separate SFC is required per-subscriber; clearly millions of SFC's is no= t >> desirable no matter how you cut it. IMHO, the support of services that >> require per-subscriber policy are more likely to be realized using somet= hing >> like the solution described in draft-quinn-sfc-nsh. >> >> >> >> From: Behcet Sarikaya >> Reply-To: "sarikaya@ieee.org" >> Date: Tuesday, October 15, 2013 11:44 AM >> To: "Liushucheng (Will)" >> Cc: "nsc@ietf.org" >> Subject: Re: [nsc] FW: New Version Notification for >> draft-liu-sfc-use-cases-00.txt >> >> >> >> Hi Shucheng, >> >> In the use cases draft, you say that >> >> SFC are not per-subscriber. In other words, this document assumes >> per-subscriber SFCs are not instantiated in the network. >> Deployments cases that would require per-subscriber SFCs are out >> of scope. >> >> However you have at least three parental control use cases. How would it >> be possible to have parental control not being per-subscriber? >> >> Regards, >> >> Behcet >> >> >> >> On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) >> wrote: >> >> Folks, >> >> We've uploaded the updated and renamed use case draft. Looking forward t= o >> your comments. >> >> Regards, >> Shucheng LIU (Will) >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, October 10, 2013 3:42 PM >> To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); >> Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao >> Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt >> >> >> A new version of I-D, draft-liu-sfc-use-cases-00.txt >> has been successfully submitted by Will(Shucheng) Liu and posted to the >> IETF repository. >> >> Filename: draft-liu-sfc-use-cases >> Revision: 00 >> Title: Service Function Chaining Use Cases >> Creation date: 2013-10-10 >> Group: Individual Submission >> Number of pages: 14 >> URL: >> http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt >> Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases >> Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 >> >> >> 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. >> >> This document presents a set of use cases of Service Function >> Chaining (SFC). >> >> >> >> >> 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 >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> >> >> >> > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From adrian@olddog.co.uk Mon Dec 9 14:05:34 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDF51AE5D1 for ; Mon, 9 Dec 2013 14:05:34 -0800 (PST) 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 gp46_sWiz1hw for ; Mon, 9 Dec 2013 14:05:33 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E65381AE522 for ; Mon, 9 Dec 2013 14:05:32 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB9M5Qcw021958 for ; Mon, 9 Dec 2013 22:05:26 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB9M5PHp021948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 9 Dec 2013 22:05:26 GMT From: "Adrian Farrel" To: Date: Mon, 9 Dec 2013 22:05:26 -0000 Message-ID: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQarg== Content-Language: en-gb Subject: [nsc] Still tweaking the charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:05:34 -0000 Hi, The IESG discussed the draft charter and proposed a few changes. You can see the latest version at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I'm in the process of verifying with them that these changes address their concerns. Your review *is* welcome, but please try to look at this to determine whether you can live with the changes. Obviously something that is a big deal should have a light shone on it, but let's beware of wordsmithing it to death - the IESG is more than capable of doing that without your help! Cheers, Adrian From haibin.song@huawei.com Tue Dec 10 00:02:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DF31AE039 for ; Tue, 10 Dec 2013 00:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 klV3RkbkLSUG for ; Tue, 10 Dec 2013 00:02:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6D29B1ADEB4 for ; Tue, 10 Dec 2013 00:02:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYV20809; Tue, 10 Dec 2013 08:01:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 08:01:52 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 10 Dec 2013 08:01:57 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 10 Dec 2013 16:01:53 +0800 From: "Songhaibin (A)" To: "nsc@ietf.org" Thread-Topic: nfvcon mailing list Thread-Index: Ac71fFS+Dg0i1JAuRHaWd+oM7VvfWg== Date: Tue, 10 Dec 2013 08:01:52 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nsc] nfvcon mailing list X-BeenThere: nsc@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, 10 Dec 2013 08:02:06 -0000 Dear folks, For those who are interested, the following is a mailing list to discuss NF= V configuration and modeling. https://www.ietf.org/mailman/listinfo/nfvcon Best Regards! -Haibin From paulq@cisco.com Tue Dec 10 11:04:16 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0BB1ADFAA for ; Tue, 10 Dec 2013 11:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, 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 UB_0hibh5ugq for ; Tue, 10 Dec 2013 11:04:15 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id D51091AE142 for ; Tue, 10 Dec 2013 11:04:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1386702249; x=1387911849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NPKTZylvlPRuKp0ZYU0KlnpdIIPE74CEasU0SQY9Ij4=; b=hs3z8ZPspR/4Qoe7GN8oUISkMqrINwa7zw69akRSH10SdwUjn+SY6sn9 5qs729VGYAejVMtfxcRGLTxZX5FnEGFiwyXVdHc7+VqpIRK5Beb5SJbhZ y+jq7jYfkHwI00n71CCiD4ItK37vCzNZ/GfX/m1LXOmpo+hhSxcYimV/4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAFRlp1KtJXHA/2dsb2JhbABZgwc4U6ckkXqBHxZ0giUBAQEDAQEBATc0CwULAgEINhAnCyUBAQQOBYd8Bg3BFhMEji4kMweDIYETBJgUkhODKYFpQQ X-IronPort-AV: E=Sophos;i="4.93,866,1378857600"; d="scan'208";a="5763059" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 10 Dec 2013 19:04:07 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBAJ47Jn002697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 19:04:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.172]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 10 Dec 2013 13:04:07 -0600 From: "Paul Quinn (paulq)" To: "" Thread-Topic: [nsc] Still tweaking the charter Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQargA4jc8A Date: Tue, 10 Dec 2013 19:04:06 +0000 Message-ID: <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> References: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> In-Reply-To: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <34153CC1AB0E23489A6B18F428783F3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@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, 10 Dec 2013 19:04:16 -0000 Hi Adrian, I do have one concern re: the suggested charter update. =20 In the encap section, it states: "...indicates the sequence of service func= tions that make up the Service Function Chain through an identifier or by a= n explicit list". This suggests implementation (i.e. ID vs. list) which se= ems too specific and inappropriate for the charter. Furthermore, I think i= t's too early in the process to limit the path selection mechanism. I suggest simply stating: "...indicates the sequence of service functions t= hat make up the Service Function Chain". That ensure that SFC selection is= addressed, yet stays away from the "how" in the charter. Thanks, and happy holidays! Paul On Dec 9, 2013, at 5:05 PM, Adrian Farrel wrote: > Hi, >=20 > The IESG discussed the draft charter and proposed a few changes. > You can see the latest version at > https://datatracker.ietf.org/doc/charter-ietf-sfc/ >=20 > I'm in the process of verifying with them that these changes address thei= r > concerns. >=20 > Your review *is* welcome, but please try to look at this to determine whe= ther > you can live with the changes. Obviously something that is a big deal sho= uld > have a light shone on it, but let's beware of wordsmithing it to death - = the > IESG is more than capable of doing that without your help! >=20 > Cheers, > Adrian >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Tue Dec 10 15:17:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01FC1A1F79 for ; Tue, 10 Dec 2013 15:17:36 -0800 (PST) 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 Wg3WUP8Y23oh for ; Tue, 10 Dec 2013 15:17:35 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id B4D861ACCDE for ; Tue, 10 Dec 2013 15:17:34 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBANHOq9027520; Tue, 10 Dec 2013 23:17:24 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBANHMX3027511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Dec 2013 23:17:23 GMT From: "Adrian Farrel" To: "'Paul Quinn \(paulq\)'" References: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> In-Reply-To: <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> Date: Tue, 10 Dec 2013 23:17:22 -0000 Message-ID: <06b901cef5fd$fb924040$f2b6c0c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKTxm1zp87SzP+czKVnsYSUpOnMigLr7Gk7mK0OpeA= Content-Language: en-gb Cc: nsc@ietf.org, "'Jim Guichard \(jguichar\)'" , 'Thomas Narten' Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:17:37 -0000 Yes Paul, I agree completely. However, we ran into "indicates the sequence" being interpreted as precisely one of "through an identifier" or "by an explicit list". So we had ADs saying "but why have you excluded the other". Maybe we could add "...or by any other means." Adrian > -----Original Message----- > From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > Sent: 10 December 2013 19:04 > To: > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten > Subject: Re: [nsc] Still tweaking the charter > > Hi Adrian, > > I do have one concern re: the suggested charter update. > > In the encap section, it states: "...indicates the sequence of service functions that > make up the Service Function Chain through an identifier or by an explicit list". > This suggests implementation (i.e. ID vs. list) which seems too specific and > inappropriate for the charter. Furthermore, I think it's too early in the process to > limit the path selection mechanism. > > I suggest simply stating: "...indicates the sequence of service functions that make > up the Service Function Chain". That ensure that SFC selection is addressed, yet > stays away from the "how" in the charter. > > Thanks, and happy holidays! > Paul > > > On Dec 9, 2013, at 5:05 PM, Adrian Farrel wrote: > > > Hi, > > > > The IESG discussed the draft charter and proposed a few changes. > > You can see the latest version at > > https://datatracker.ietf.org/doc/charter-ietf-sfc/ > > > > I'm in the process of verifying with them that these changes address their > > concerns. > > > > Your review *is* welcome, but please try to look at this to determine whether > > you can live with the changes. Obviously something that is a big deal should > > have a light shone on it, but let's beware of wordsmithing it to death - the > > IESG is more than capable of doing that without your help! > > > > Cheers, > > Adrian > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Dec 11 07:57:34 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C691ADF9B for ; Wed, 11 Dec 2013 07:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 J5nmslc7xohr for ; Wed, 11 Dec 2013 07:57:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F051B1ADF90 for ; Wed, 11 Dec 2013 07:57:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBG75708; Wed, 11 Dec 2013 15:57:25 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 15:57:06 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 15:57:07 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 07:57:02 -0800 From: Linda Dunbar To: "Paul Quinn (paulq)" , "" Thread-Topic: [nsc] Still tweaking the charter Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQargA4jc8AAB8nKnA= Date: Wed, 11 Dec 2013 15:57:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C2F234@dfweml509-mbx.china.huawei.com> References: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> In-Reply-To: <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.197] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Thomas Narten Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@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, 11 Dec 2013 15:57:34 -0000 Agree with Paul's suggestion.=20 Linda > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) > Sent: Tuesday, December 10, 2013 1:04 PM > To: > Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten > Subject: Re: [nsc] Still tweaking the charter >=20 > Hi Adrian, >=20 > I do have one concern re: the suggested charter update. >=20 > In the encap section, it states: "...indicates the sequence of service > functions that make up the Service Function Chain through an identifier > or by an explicit list". This suggests implementation (i.e. ID vs. > list) which seems too specific and inappropriate for the charter. > Furthermore, I think it's too early in the process to limit the path > selection mechanism. >=20 > I suggest simply stating: "...indicates the sequence of service > functions that make up the Service Function Chain". That ensure that > SFC selection is addressed, yet stays away from the "how" in the > charter. >=20 > Thanks, and happy holidays! > Paul >=20 >=20 > On Dec 9, 2013, at 5:05 PM, Adrian Farrel wrote: >=20 > > Hi, > > > > The IESG discussed the draft charter and proposed a few changes. > > You can see the latest version at > > https://datatracker.ietf.org/doc/charter-ietf-sfc/ > > > > I'm in the process of verifying with them that these changes address > their > > concerns. > > > > Your review *is* welcome, but please try to look at this to determine > whether > > you can live with the changes. Obviously something that is a big deal > should > > have a light shone on it, but let's beware of wordsmithing it to > death - the > > IESG is more than capable of doing that without your help! > > > > Cheers, > > Adrian > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From paulq@cisco.com Wed Dec 11 09:05:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1260B1AE166 for ; Wed, 11 Dec 2013 09:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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=-0.001, 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 cZGfNeT-eMtS for ; Wed, 11 Dec 2013 09:05:24 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 403881AE156 for ; Wed, 11 Dec 2013 09:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2782; q=dns/txt; s=iport; t=1386781519; x=1387991119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mxih8Wt8dbKK/d34gGC3yOnNrH2T28vpk+704+LORTQ=; b=ceZckzEunILO+3uioh3MWePYGRrx+l2FgN3eVY8ij5lRb36v87Mrcvfa pvQD/1kZ6rewwBYW5y0n/l74cFLa/hyuv2XwgRK64B+Coji34ENrsmED3 Yp/17YMMOliY7qWIEX3ZQ06alf7tHu9DTAFbwwn4CRalgCVBxUTlHdU/8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAPKaqFKtJXG+/2dsb2JhbABZgwc4U6cZkgCBHRZ0giUBAQEDAQEBATctBwsFBwQCAQgRBAEBAR4JBycLFAkIAQEEDgWHfAYNwh4TBI4xJDMHBoMbgRMEmBSSE4MpgWlB X-IronPort-AV: E=Sophos;i="4.93,872,1378857600"; d="scan'208";a="290970629" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 11 Dec 2013 17:05:18 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBBH5IFB015775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 17:05:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.19]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 11:05:18 -0600 From: "Paul Quinn (paulq)" To: "" Thread-Topic: [nsc] Still tweaking the charter Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQargA4jc8AAAjYYQAAJUqUAA== Date: Wed, 11 Dec 2013 17:05:17 +0000 Message-ID: <7528273C-EECF-444A-BEFD-62EE8110073C@cisco.com> References: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> <06b901cef5fd$fb924040$f2b6c0c0$@olddog.co.uk> In-Reply-To: <06b901cef5fd$fb924040$f2b6c0c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <9FDE1FA234973E42BAA8FE7DEE792D0A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Jim Guichard \(jguichar\)" , Thomas Narten Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@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, 11 Dec 2013 17:05:26 -0000 Adrian, If we simply state "...indicates the sequence of service functions that mak= e up the Service Function Chain" we should cover all cases. I don't under= stand the confusion: there's no implication of identifier vs. explicit list= . If they feel that indicates implies an ID, then perhaps: "denotes/conveys/c= arries the sequence of service functions that make up the Service Function = Chain"? Thanks Paul On Dec 10, 2013, at 6:17 PM, Adrian Farrel wrote: > Yes Paul, I agree completely. >=20 > However, we ran into "indicates the sequence" being interpreted as precis= ely one > of "through an identifier" or "by an explicit list". So we had ADs saying= "but > why have you excluded the other". >=20 > Maybe we could add "...or by any other means." >=20 > Adrian >=20 >> -----Original Message----- >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >> Sent: 10 December 2013 19:04 >> To: >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten >> Subject: Re: [nsc] Still tweaking the charter >>=20 >> Hi Adrian, >>=20 >> I do have one concern re: the suggested charter update. >>=20 >> In the encap section, it states: "...indicates the sequence of service > functions that >> make up the Service Function Chain through an identifier or by an explic= it > list". >> This suggests implementation (i.e. ID vs. list) which seems too specific= and >> inappropriate for the charter. Furthermore, I think it's too early in t= he > process to >> limit the path selection mechanism. >>=20 >> I suggest simply stating: "...indicates the sequence of service function= s that > make >> up the Service Function Chain". That ensure that SFC selection is addre= ssed, > yet >> stays away from the "how" in the charter. >>=20 >> Thanks, and happy holidays! >> Paul >>=20 >>=20 >> On Dec 9, 2013, at 5:05 PM, Adrian Farrel wrote: >>=20 >>> Hi, >>>=20 >>> The IESG discussed the draft charter and proposed a few changes. >>> You can see the latest version at >>> https://datatracker.ietf.org/doc/charter-ietf-sfc/ >>>=20 >>> I'm in the process of verifying with them that these changes address th= eir >>> concerns. >>>=20 >>> Your review *is* welcome, but please try to look at this to determine > whether >>> you can live with the changes. Obviously something that is a big deal s= hould >>> have a light shone on it, but let's beware of wordsmithing it to death = - the >>> IESG is more than capable of doing that without your help! >>>=20 >>> Cheers, >>> Adrian >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 From mn1921@att.com Wed Dec 11 10:08:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676E21ADFD3 for ; Wed, 11 Dec 2013 10:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 t0zMh1ObINft for ; Wed, 11 Dec 2013 10:08:17 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4CED41ADF58 for ; Wed, 11 Dec 2013 10:08:17 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id c0aa8a25.2ae26b057940.1895337.00-2495.5300411.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 11 Dec 2013 18:08:12 +0000 (UTC) X-MXL-Hash: 52a8aa0c732dbce3-891c48dccedab96998721021069f51488dafedba Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 00aa8a25.0.1895215.00-2333.5300079.nbfkord-smmo06.seg.att.com (envelope-from ); Wed, 11 Dec 2013 18:08:01 +0000 (UTC) X-MXL-Hash: 52a8aa014f632ed6-406c1c93d77090071abf64e2cc255a2f72eba766 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBBI7w4Z012857; Wed, 11 Dec 2013 13:07:59 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rBBI7qE1012789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 13:07:56 -0500 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (MISOUT7MSGHUB9F.itservices.sbc.com [144.151.223.71]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 11 Dec 2013 18:07:42 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 13:07:42 -0500 From: "NAPIERALA, MARIA H" To: "Paul Quinn (paulq)" , "" Thread-Topic: [nsc] Still tweaking the charter Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQargA4jc8AAAjYYQAAJUqUAAAKdp5Q Date: Wed, 11 Dec 2013 18:07:41 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012F93AF@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <040501cef52a$c46136e0$4d23a4a0$@olddog.co.uk> <858C4A3F-E269-4459-A85F-D6A3E34DF608@cisco.com> <06b901cef5fd$fb924040$f2b6c0c0$@olddog.co.uk> <7528273C-EECF-444A-BEFD-62EE8110073C@cisco.com> In-Reply-To: <7528273C-EECF-444A-BEFD-62EE8110073C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=KeZlR3kD c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=aabdN8GTbV8A:10 a=ofMgfj31e3cA:10 a=-s3I2kwCOWQA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=W7mWKOA_F0kA:10 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8] X-AnalysisOut: [ a=AUd_NHdVAAAA:8 a=oct0XHTX6__KJCeqOEQA:9 a=CjuIK1q_8ugA:] X-AnalysisOut: [10 a=lZB815dzVvQA:10 a=jqlaW5bC1iAA:10 a=JfD0Fch1gWkA:10 a] X-AnalysisOut: [=JfW0fFOfWJTltqKb:21 a=U1NfFVmoQ7hrikNA:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] Cc: "" , "Jim Guichard \(jguichar\)" , Thomas Narten Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@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, 11 Dec 2013 18:08:19 -0000 We have also discussed in the past that this field should be made optional = for cases where only metadata is of interest. Maria=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) > Sent: Wednesday, December 11, 2013 12:05 PM > To: > Cc: ; Jim Guichard (jguichar); Thomas Narten > Subject: Re: [nsc] Still tweaking the charter >=20 > Adrian, >=20 > If we simply state "...indicates the sequence of service functions that > make up the Service Function Chain" we should cover all cases. I > don't understand the confusion: there's no implication of identifier > vs. explicit list. >=20 > If they feel that indicates implies an ID, then perhaps: > "denotes/conveys/carries the sequence of service functions that make up > the Service Function Chain"? >=20 > Thanks > Paul >=20 >=20 > On Dec 10, 2013, at 6:17 PM, Adrian Farrel wrote: >=20 > > Yes Paul, I agree completely. > > > > However, we ran into "indicates the sequence" being interpreted as > precisely one > > of "through an identifier" or "by an explicit list". So we had ADs > saying "but > > why have you excluded the other". > > > > Maybe we could add "...or by any other means." > > > > Adrian > > > >> -----Original Message----- > >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] > >> Sent: 10 December 2013 19:04 > >> To: > >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten > >> Subject: Re: [nsc] Still tweaking the charter > >> > >> Hi Adrian, > >> > >> I do have one concern re: the suggested charter update. > >> > >> In the encap section, it states: "...indicates the sequence of > service > > functions that > >> make up the Service Function Chain through an identifier or by an > explicit > > list". > >> This suggests implementation (i.e. ID vs. list) which seems too > specific and > >> inappropriate for the charter. Furthermore, I think it's too early > in the > > process to > >> limit the path selection mechanism. > >> > >> I suggest simply stating: "...indicates the sequence of service > functions that > > make > >> up the Service Function Chain". That ensure that SFC selection is > addressed, > > yet > >> stays away from the "how" in the charter. > >> > >> Thanks, and happy holidays! > >> Paul > >> > >> > >> On Dec 9, 2013, at 5:05 PM, Adrian Farrel > wrote: > >> > >>> Hi, > >>> > >>> The IESG discussed the draft charter and proposed a few changes. > >>> You can see the latest version at > >>> https://datatracker.ietf.org/doc/charter-ietf-sfc/ > >>> > >>> I'm in the process of verifying with them that these changes > address their > >>> concerns. > >>> > >>> Your review *is* welcome, but please try to look at this to > determine > > whether > >>> you can live with the changes. Obviously something that is a big > deal should > >>> have a light shone on it, but let's beware of wordsmithing it to > death - the > >>> IESG is more than capable of doing that without your help! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> _______________________________________________ > >>> nsc mailing list > >>> nsc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/nsc > > >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Wed Dec 11 11:32:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2B1AE15B for ; Wed, 11 Dec 2013 11:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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=-0.001, 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 bemD2lCPx_Me for ; Wed, 11 Dec 2013 11:31:58 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DC2921ADFB8 for ; Wed, 11 Dec 2013 11:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3855; q=dns/txt; s=iport; t=1386790312; x=1387999912; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wi+gNSOiqWJf5zmMCfhkrDZZCKvrz78GFAOfMqeilnI=; b=FPlgG88510qgeawMsYDYSGj8o4dqG5McspcuEeyZpa1BkahALwt6Dytz A4al/43CZQUOBrq1JgEhXx9lEXJz34UIc+I8ow3qDoWY0M0Sn3p01J6KY w86eCJQv/S9s6kJYic1UcnSHO4aTD1h1v5YcbpZL04E08Yi0u2e5FuSuv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAP28qFKtJXHB/2dsb2JhbABZgwc4U7kZgR0WdIIlAQEBBAEBATctBwsMBgEIEQQBAQEeCS4LFAkIAQEEAQ0FiAINwioTBI4xVwcGhC4EmBSSE4MpgWlB X-IronPort-AV: E=Sophos;i="4.93,873,1378857600"; d="scan'208";a="290883113" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 11 Dec 2013 19:31:41 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBBJVfqu023140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 19:31:41 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 13:31:40 -0600 From: "Surendra Kumar (smkumar)" To: "NAPIERALA, MARIA H" , "Paul Quinn (paulq)" , "" Thread-Topic: [nsc] Still tweaking the charter Thread-Index: Ac71KqxtVEqaeZRBTReeNJrDCpQargA4jc8AAAjYYQAAJUqUAAAKdp5Q//9PHoA= Date: Wed, 11 Dec 2013 19:31:40 +0000 Message-ID: In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012F93AF@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.147.8] Content-Type: text/plain; charset="us-ascii" Content-ID: <49F091EAB723514DAA1B2750BDF881BD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "Jim Guichard \(jguichar\)" , Thomas Narten Subject: Re: [nsc] Still tweaking the charter X-BeenThere: nsc@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, 11 Dec 2013 19:32:00 -0000 We agreed to defer the discussion until later, IIRC. Surendra. On 12/11/13 10:07 AM, "NAPIERALA, MARIA H" wrote: >We have also discussed in the past that this field should be made >optional for cases where only metadata is of interest. > >Maria=20 > >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) >> Sent: Wednesday, December 11, 2013 12:05 PM >> To: >> Cc: ; Jim Guichard (jguichar); Thomas Narten >> Subject: Re: [nsc] Still tweaking the charter >>=20 >> Adrian, >>=20 >> If we simply state "...indicates the sequence of service functions that >> make up the Service Function Chain" we should cover all cases. I >> don't understand the confusion: there's no implication of identifier >> vs. explicit list. >>=20 >> If they feel that indicates implies an ID, then perhaps: >> "denotes/conveys/carries the sequence of service functions that make up >> the Service Function Chain"? >>=20 >> Thanks >> Paul >>=20 >>=20 >> On Dec 10, 2013, at 6:17 PM, Adrian Farrel wrote: >>=20 >> > Yes Paul, I agree completely. >> > >> > However, we ran into "indicates the sequence" being interpreted as >> precisely one >> > of "through an identifier" or "by an explicit list". So we had ADs >> saying "but >> > why have you excluded the other". >> > >> > Maybe we could add "...or by any other means." >> > >> > Adrian >> > >> >> -----Original Message----- >> >> From: Paul Quinn (paulq) [mailto:paulq@cisco.com] >> >> Sent: 10 December 2013 19:04 >> >> To: >> >> Cc: nsc@ietf.org; Jim Guichard (jguichar); Thomas Narten >> >> Subject: Re: [nsc] Still tweaking the charter >> >> >> >> Hi Adrian, >> >> >> >> I do have one concern re: the suggested charter update. >> >> >> >> In the encap section, it states: "...indicates the sequence of >> service >> > functions that >> >> make up the Service Function Chain through an identifier or by an >> explicit >> > list". >> >> This suggests implementation (i.e. ID vs. list) which seems too >> specific and >> >> inappropriate for the charter. Furthermore, I think it's too early >> in the >> > process to >> >> limit the path selection mechanism. >> >> >> >> I suggest simply stating: "...indicates the sequence of service >> functions that >> > make >> >> up the Service Function Chain". That ensure that SFC selection is >> addressed, >> > yet >> >> stays away from the "how" in the charter. >> >> >> >> Thanks, and happy holidays! >> >> Paul >> >> >> >> >> >> On Dec 9, 2013, at 5:05 PM, Adrian Farrel >> wrote: >> >> >> >>> Hi, >> >>> >> >>> The IESG discussed the draft charter and proposed a few changes. >> >>> You can see the latest version at >> >>> https://datatracker.ietf.org/doc/charter-ietf-sfc/ >> >>> >> >>> I'm in the process of verifying with them that these changes >> address their >> >>> concerns. >> >>> >> >>> Your review *is* welcome, but please try to look at this to >> determine >> > whether >> >>> you can live with the changes. Obviously something that is a big >> deal should >> >>> have a light shone on it, but let's beware of wordsmithing it to >> death - the >> >>> IESG is more than capable of doing that without your help! >> >>> >> >>> Cheers, >> >>> Adrian >> >>> >> >>> _______________________________________________ >> >>> nsc mailing list >> >>> nsc@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/nsc >> > >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From iesg-secretary@ietf.org Wed Dec 11 16:04:33 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 951F01AE21E; Wed, 11 Dec 2013 16:04:33 -0800 (PST) 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 EGLsH4WqO2UY; Wed, 11 Dec 2013 16:04:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 624931AE1FE; Wed, 11 Dec 2013 16:04:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131212000431.24760.14652.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 16:04:31 -0800 X-Mailman-Approved-At: Thu, 12 Dec 2013 01:50:16 -0800 Cc: sfc WG Subject: [nsc] WG Review: Service Function Chaining (sfc) X-BeenThere: nsc@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: Thu, 12 Dec 2013 00:04:33 -0000 A new IETF working group has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-19. Service Function Chaining (sfc) ------------------------------------------------ Current Status: Proposed WG Chairs: Jim Guichard Thomas Narten Assigned Area Director: Adrian Farrel Mailing list Address: nsc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nsc Archive: http://www.ietf.org/mail-archive/web/nsc/ Charter: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. Deploying service functions to support service delivery is currently both a technical and an organizational challenge that involves significant modification to the network configuration, impacting the speed at which services can be deployed and increasing operational costs. Such services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network. Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required service functions, wherever they are deployed. For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.). The SFC working group will document a new approach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. The WG will examine existing identifier schemes, if there is a need for such identifiers in the context of the Generic SFC encapsulation, before defining any new identifier scheme. The working group will examine what information needs to be gathered from the network and service functions in support of Service Function Chaining and how that information may be made available to the components of the Service Function Chaining architecture. The SFC WG will closely consider and address the management and security implications when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC architectural building blocks and their relationships including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format that: - indicates the sequence of service functions that make up the Service Function Chain - specifies the Service Function Path, - communicates context information between nodes that implement service functions and Service Function Chains. It is intended that the encapsulation format be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the same encapsulation format will apply for the construction of Service Function Paths regardless of the actual service. The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found. 4. Control Plane Mechanisms: A document will be developed to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be carried out in the working group responsible for the protocol being modified in coordination with this working group, but may be done in this working group under a revised charter after agreement with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC components related to the support of Service Function Chaining will certainly be needed, but first needs to be better understood and scoped. Milestones: Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Jan 2015 - Submit to IESG Informational document defining the architecture for SFC Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation From iesg-secretary@ietf.org Fri Dec 20 09:12:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194A71AD603; Fri, 20 Dec 2013 09:12:40 -0800 (PST) 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 EwSCzJ8gIS2U; Fri, 20 Dec 2013 09:12:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FB51AD669; Fri, 20 Dec 2013 09:12:36 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131220171236.12658.36731.idtracker@ietfa.amsl.com> Date: Fri, 20 Dec 2013 09:12:36 -0800 Cc: sfc WG Subject: [nsc] WG Action: Formed Service Function Chaining (sfc) X-BeenThere: nsc@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: Fri, 20 Dec 2013 17:12:40 -0000 A new IETF working group has been formed in the Routing Area. For additional information please contact the Area Directors or the WG Chairs. Service Function Chaining (sfc) ------------------------------------------------ Current Status: Proposed WG Chairs: Jim Guichard Thomas Narten Assigned Area Director: Adrian Farrel Mailing list Address: nsc@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nsc Archive: http://www.ietf.org/mail-archive/web/nsc/ Charter: Network operators frequently utilize service functions such as packet filtering at firewalls, load-balancing and transactional proxies (for example spam filters) in the delivery of services to end users. Delivery of these types of services is undergoing significant change with the introduction of virtualization, network overlays, and orchestration. Deploying service functions to support service delivery is currently both a technical and an organizational challenge that involves significant modification to the network configuration, impacting the speed at which services can be deployed and increasing operational costs. Such services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within a network. Today, common deployment models have service functions inserted on the data-forwarding path between communicating peers. Going forward, however, there is a need to move to a different model, where service functions, whether physical or virtualized, are not required to reside on the direct data path and traffic is instead steered through required service functions, wherever they are deployed. For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (network layer, transport layer, application layer, etc.). The SFC working group will document a new approach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or protocol extensions to convey the Service Function Chain and Service Function Path information to nodes that are involved in the implementation of service functions and Service Function Chains, as well as mechanisms for steering traffic through service functions. The WG will examine existing identifier schemes, if there is a need for such identifiers in the context of the Generic SFC encapsulation, before defining any new identifier scheme. The working group will examine what information needs to be gathered from the network and service functions in support of Service Function Chaining and how that information may be made available to the components of the Service Function Chaining architecture. The SFC WG will closely consider and address the management and security implications when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the problem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC architectural building blocks and their relationships including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping in mind that architectural decisions made for the intra-domain case may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format that: - indicates the sequence of service functions that make up the Service Function Chain - specifies the Service Function Path, - communicates context information between nodes that implement service functions and Service Function Chains. It is intended that the encapsulation format be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the same encapsulation format will apply for the construction of Service Function Paths regardless of the actual service. The working group will consider using an existing encapsulation (with extensions as appropriate) if a suitable candidate is found. 4. Control Plane Mechanisms: A document will be developed to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be carried out in the working group responsible for the protocol being modified in coordination with this working group, but may be done in this working group under a revised charter after agreement with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC components related to the support of Service Function Chaining will certainly be needed, but first needs to be better understood and scoped. Milestones: Apr 2014 - Submit to IESG Information document defining the SFC problem statement and core use cases Apr 2014 - Consult with OPS area on possible SFC charter modifications for management and configuration of SFC components related to the support of Service Function Chaining Jan 2015 - Submit to IESG Informational document defining the architecture for SFC Jan 2015 - Informational document defining the control plane requirements for conveying information between control or management elements and SFC implementation points Aug 2015 - Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation From adrian@olddog.co.uk Tue Dec 24 10:09:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03B1AE049 for ; Tue, 24 Dec 2013 10:09:14 -0800 (PST) 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 sC9QZmD0dfao for ; Tue, 24 Dec 2013 10:09:12 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5A1ADFF7 for ; Tue, 24 Dec 2013 10:09:11 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBOI97hn022976 for ; Tue, 24 Dec 2013 18:09:07 GMT Received: from 950129200 (AGrenoble-651-1-569-5.w90-52.abo.wanadoo.fr [90.52.233.5]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBOI3WRg021975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Dec 2013 18:08:44 GMT From: "Adrian Farrel" To: Date: Tue, 24 Dec 2013 18:03:40 -0000 Message-ID: <024901cf00d3$33bd7ef0$9b387cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7/UBP/z8hA0XuDQIiGMoXU0EpheQ== Content-Language: en-gb Subject: [nsc] Time to get to work! X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 18:09:14 -0000 All systems go. Please work according to your charter under the guidance of your chairs. For the enquiring mind... We will migrate the list to sfc@... when the Secretariat gets back after the New Year break. >From my experience, this is pretty painless. Adrian > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of The IESG > Sent: 20 December 2013 17:13 > To: IETF-Announce > Cc: sfc WG > Subject: [nsc] WG Action: Formed Service Function Chaining (sfc) > > A new IETF working group has been formed in the Routing Area. For > additional information please contact the Area Directors or the WG > Chairs. > > Service Function Chaining (sfc) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Jim Guichard > Thomas Narten > > Assigned Area Director: > Adrian Farrel > > Mailing list > Address: nsc@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/nsc > Archive: http://www.ietf.org/mail-archive/web/nsc/ > > Charter: > > Network operators frequently utilize service functions such as packet > filtering at firewalls, load-balancing and transactional proxies (for > example spam filters) in the delivery of services to end users. Delivery > of these types of services is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > > Deploying service functions to support service delivery is currently both > a technical and an organizational challenge that involves significant > modification to the network configuration, impacting the speed at which > services can be deployed and increasing operational costs. Such > services are typically implemented by the ordered combination of a > number of service functions that are deployed at different points within > a network. > > Today, common deployment models have service functions inserted on > the data-forwarding path between communicating peers. Going forward, > however, there is a need to move to a different model, where service > functions, whether physical or virtualized, are not required to reside on > the direct data path and traffic is instead steered through required > service functions, wherever they are deployed. > > For a given service, the abstracted view of the required service > functions and the order in which they are to be applied is called a > Service Function Chain (SFC). An SFC is instantiated through selection > of specific service function instances on specific network nodes to form > a service graph: this is called a Service Function Path (SFP). The > service functions may be applied at any layer within the network > protocol stack (network layer, transport layer, application layer, etc.). > > > The SFC working group will document a new approach to service delivery > and operation. It will produce an architecture for service function > chaining that includes the necessary protocols or protocol extensions to > convey the Service Function Chain and Service Function Path information > to nodes that are involved in the implementation of service functions > and Service Function Chains, as well as mechanisms for steering traffic > through service functions. The WG will examine existing identifier > schemes, > if there is a need for such identifiers in the context of the Generic SFC > encapsulation, before defining any new identifier scheme. > > The working group will examine what information needs to be gathered > from the network and service functions in support of Service Function > Chaining and how that information may be made available to the > components of the Service Function Chaining architecture. The SFC > WG will closely consider and address the management and security > implications when documenting these deliverables. > > Specifically, the SFC WG is chartered to deliver the following: > > 1. Problem Statement: This document will provide a summary of the > problem space to be addressed by the SFC working group including > example high-level use cases. Additionally, the working group will > normalize nomenclature and definitions for service function chaining. > > 2. Architecture: This document will provide a description of the SFC > architectural building blocks and their relationships including > interconnection, placement of SFC specific capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. The initial scope is > restricted to a single administrative domain, keeping in mind that > architectural decisions made for the intra-domain case may have > implications for the inter-domain case. > > 3. Generic SFC Encapsulation: This document will describe a single > service-level data plane encapsulation format that: > - indicates the sequence of service functions that make up the > Service Function Chain > - specifies the Service Function Path, > - communicates context information between nodes that implement > service functions and Service Function Chains. > It is intended that the encapsulation format be agnostic to the > layer at which it is applied and the service that is being > constructed. That is, the same encapsulation may be used on a > service function chain applied at the network layer or at any other > layer, and the same encapsulation format will apply for the > construction of Service Function Paths regardless of the actual > service. The working group will consider using an existing > encapsulation (with extensions as appropriate) if a suitable > candidate is found. > > 4. Control Plane Mechanisms: A document will be developed to describe > requirements for conveying information between control or management > elements and SFC implementation points. All protocol extension work > resulting from these requirements should be carried out in the > working group responsible for the protocol being modified in > coordination with this working group, but may be done in this working > group under a revised charter after agreement with all the relevant > WG chairs and responsible ADs. > > 5. Manageability: Work on the management and configuration of SFC > components related to the support of Service Function Chaining will > certainly be needed, but first needs to be better understood and > scoped. > > Milestones: > Apr 2014 - Submit to IESG Information document defining the SFC problem > statement and core use cases > Apr 2014 - Consult with OPS area on possible SFC charter modifications > for management and configuration of SFC components related to the support > of Service Function Chaining > Jan 2015 - Submit to IESG Informational document defining the > architecture for SFC > Jan 2015 - Informational document defining the control plane > requirements for conveying information between control or management > elements and SFC implementation points > Aug 2015 - Submit to IESG Standards Track document specifying the > generic service function chaining header encapsulation > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc