From nobody Wed Aug 20 18:19:52 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083EC1A0B0C; Wed, 20 Aug 2014 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRirUpF6DyW0; Wed, 20 Aug 2014 13:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F3F1A0661; Wed, 20 Aug 2014 13:47:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820204726.19506.59152.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 13:47:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/supa/aWYuJK9GBQQWbZqqP0GWP2VQRcI X-Mailman-Approved-At: Wed, 20 Aug 2014 18:19:48 -0700 Cc: marc.blanchet@viagenie.ca, cathy.zhou@huawei.com, liushucheng@huawei.com, supa@ietf.org Subject: [Supa] New Non-WG Mailing List: SUPA (Shared Unified Policy Automation) X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 20:47:28 -0000 A new IETF non-working group email list has been created. List address: supa@ietf.org Archive: http://www.ietf.org/mail-archive/web/supa/ To subscribe: https://www.ietf.org/mailman/listinfo/supa Purpose: This list is to discuss the problem statement and use cases, how to map network service graphs into specific network management and controlling policies, and protocol specifications e.g. models to support the supa. For additional information, please contact the list administrators. From nobody Thu Aug 21 18:16:32 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71171A0AD0 for ; Thu, 21 Aug 2014 18:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HS5UsjF6qjO for ; Thu, 21 Aug 2014 18:15:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC061A06AB for ; Thu, 21 Aug 2014 18:15:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIM64825; Fri, 22 Aug 2014 01:15:19 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Aug 2014 02:15:18 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 22 Aug 2014 09:15:16 +0800 From: "Liushucheng (Will)" To: "supa@ietf.org" Thread-Topic: A summary of previous discussion Thread-Index: Ac+9pocFLab0mnkjSLGGFS4haWQ9OA== Date: Fri, 22 Aug 2014 01:15:15 +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.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF66694SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/_40KIMsEDQXW6zYvVW6yg4hogsc X-Mailman-Approved-At: Thu, 21 Aug 2014 18:16:28 -0700 Subject: [Supa] A summary of previous discussion X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 01:15:23 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF66694SZXEMA509MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This work has been discussed with more than a hundred of emails in openv6 m= ailing list in last couple of months. To get a quick glance of these emails= please click: http://editor.rozanak.com/msg/aponf_summary.htm Regards, Will --_000_C9B5F12337F6F841B35C404CF0554ACB5FF66694SZXEMA509MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

This work has been discussed with more than a hun= dred of emails in openv6 mailing list in last couple of months. To get a qu= ick glance of these emails please click:

http://editor.rozanak.com/msg/aponf_summary.htm

 

Regards,

Will

 

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF66694SZXEMA509MBSchi_-- From nobody Fri Aug 22 00:03:05 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11BD1A00F6; Fri, 22 Aug 2014 00:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.958 X-Spam-Level: X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_103=0.327, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 UrXX3P0UvCv2; Fri, 22 Aug 2014 00:01:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0921F1A00EC; Fri, 22 Aug 2014 00:01:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIM85946; Fri, 22 Aug 2014 07:01:47 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Aug 2014 08:01:46 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.196]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 22 Aug 2014 15:01:36 +0800 From: "Liushucheng (Will)" To: Tina TSOU , Ying Cheng Thread-Topic: [Openv6] regarding name of our activity and mailing list name Thread-Index: AQHPu5iQQixsQJFYZ0GB0qlplu5DQ5vcMe2Q Date: Fri, 22 Aug 2014 07:01:34 +0000 Message-ID: References: , <001401cfa7ea$03922910$0ab67b30$@tsinghua.edu.cn>, <34FC9348-2BE1-44AE-828E-C26DBF4A7603@huawei.com>, , <201407311511083630083@chinaunicom.cn>, <000001cfac9b$df207b70$9d617250$@unizar.es>, <492274AF-4404-4E44-BEE1-044B271E18DD@huawei.com>, <201408181742181824567@chinaunicom.cn> <201408181742479153148@chinaunicom.cn> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: multipart/alternative; boundary="_000_C9B5F12337F6F841B35C404CF0554ACB5FF667F8SZXEMA509MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/supa/K48P0mW6gyQCLDXlaezPoxrbAlA X-Mailman-Approved-At: Fri, 22 Aug 2014 00:03:03 -0700 Cc: "openv6@ietf.org" , "kireeti@juniper.net" , 'Jose Saldana' , 'Jun Bi' , "karagian@cs.utwente.nl" , "spencerdawkins.ietf@gmail.com" , "supa@ietf.org" , "andrew.qu@mediatek.com" Subject: Re: [Supa] [Openv6] regarding name of our activity and mailing list name X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 07:01:59 -0000 --_000_C9B5F12337F6F841B35C404CF0554ACB5FF667F8SZXEMA509MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBUaW5hLCBZaW5nIGV0IGFsLA0KDQpUaGUgbWFpbGluZyBsaXN0IHN1cGFAaWV0Zi5vcmc8 bWFpbHRvOnN1cGFAaWV0Zi5vcmc+IHdhcyBqdXN0IGNyZWF0ZWQuIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3VwYQ0KDQpXZaGvdmUgYXNrZWQgdGhlIHNlY3JldGFyeSB0 byBhZGQgYWxsIG9wZW52NiBzdWJzY3JpYmVycyB0aGVyZS4gSG93ZXZlciwgaXQgc2VlbXMgdGhh dCB0aGVyZSBhcmUgb25seSBhcm91bmQgMTAgc3VjY2Vzc2Z1bGx5IG1vdmVkIHRoZXJlIGR1ZSB0 byB0aGUgc3lzdGVtIHByb2JsZW0uICBXZSBhcmUgdHJ5aW5nIHRvIG1hbnVhbGx5IGZpeCB0aGlz LiBZb3UgbWF5IGFsc28gc3Vic2NyaWJlIHdpdGggdGhlIGxpbmsgaW4gdGhpcyBlbWFpbC4gVGhl biwgd2UgY2FuIGNvbnRpbnVlIG91ciBkaXNjdXNzaW9uIHRoZXJlLg0KDQpSZWdhcmRzLA0KV2ls bA0KDQpGcm9tOiBPcGVudjYgW21haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFRpbmEgVFNPVQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDE5LCAyMDE0IDY6MDEgUE0N ClRvOiBZaW5nIENoZW5nDQpDYzogb3BlbnY2QGlldGYub3JnOyBraXJlZXRpQGp1bmlwZXIubmV0 OyAnSm9zZSBTYWxkYW5hJzsgJ0p1biBCaSc7IGthcmFnaWFuQGNzLnV0d2VudGUubmw7IHNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tOyBhbmRyZXcucXVAbWVkaWF0ZWsuY29tDQpTdWJqZWN0 OiBSZTogW09wZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBtYWlsaW5n IGxpc3QgbmFtZQ0KDQpEZWFyIFlpbmcgZXQgYWwsDQoNClRoYW5rIHlvdSBmb3IgYXNraW5nLg0K DQpBcyBmYXIgYXMgSSBrbm93LCB0aGUgbWFpbCBhZG1pbmlzdHJhdG9ycyBhcmUgd29ya2luZyB3 aXRoIFNwZW5jZXIgYW5kIElFVEYgc2VjcmV0YXJ5IHRvIGNyZWF0ZSBzdXBhQGlldGYub3JnPG1h aWx0bzpzdXBhQGlldGYub3JnPiwgYXV0byBzdWJzY3JpYmUgZXZlcnlvbmUgaW4gb3BlbnY2QGll dGYub3JnPG1haWx0bzpvcGVudjZAaWV0Zi5vcmc+IHRvIHRoZSBuZXcgbGlzdCwgYW5kIGFsc28g Y29weSB0aGUgbWFpbCBhcmNoaWV2ZXMgdG8gdGhlcmUuIFBscyBzdGF5IHR1bmVkLg0KDQpSZWdh cmRpbmcgdGhlIHByb3RvY29sIHNwZWNzLCBJoa9tIGF3YXJlIHRoYXQgcGVvcGxlIGxpa2UgR2Vv cmdpb3MsIEx1aXMsIFdpbGwsIEp1biwgS2lyZWV0aSwgQW5kcmV3LCBKdWVyZ2VuLCBKRiBldCBh bCBhcmUgZGlzY3Vzc2luZyBvZmZsaW5lIGFib3V0IHRoZSBOZXR3b3JrIE1vZGVsIGZvciBhIHBy b2dyYW1tYWJsZSBpbnRlcmZhY2UgdG8gdmlydHVhbCBsaW5rczoNCkRlc2NyaWJlIHRoZSBuZXR3 b3JrIGNvbmZpZ3VyYXRpb24uDQpEZXNjcmliZSB0aGUgbGF5ZXIgMC03IG5ldHdvcmsgdG9wb2xv Z3ksIGluY2x1ZGluZyB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gaW50cmEtbGF5ZXIgYW5kIGlu dGVyLWxheWVyIGNvbm5lY3Rpb25zLg0KDQpJdCB3b3VsZCBiZSBnb29kIGlmIHRoZXkgY291bGQg YnJpbmcgc29tZSBkaXNjdXNzaW9uIHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIGJyb2FkZXIgYXVk aWVuY2UuDQoNCg0KVGhhbmsgeW91LA0KVGluYQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7Iy6O6IFlpbmcgQ2hlbmcNCreiy83Ksbzko7ogMjAxNC0wOC0xOCAxNzo0Mjox OA0KytW8/sjLo7ogSnVuIEJpOyAnVGluYSBUU09VJzsgJ0pvc2UgU2FsZGFuYSc7ICdzcGVuY2Vy IGRhd2tpbnMnDQqzrcvNo7oga2lyZWV0aUBqdW5pcGVyLm5ldDxtYWlsdG86a2lyZWV0aUBqdW5p cGVyLm5ldD47IGFuZHJldy5xdUBtZWRpYXRlay5jb208bWFpbHRvOmFuZHJldy5xdUBtZWRpYXRl ay5jb20+OyBvcGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9wZW52NkBpZXRmLm9yZz47ICdMaXVzaHVj aGVuZyAoV2lsbCknOyBrYXJhZ2lhbkBjcy51dHdlbnRlLm5sPG1haWx0bzprYXJhZ2lhbkBjcy51 dHdlbnRlLm5sPg0K1vfM4qO6IFJlOiBSRTogW09wZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3Vy IGFjdGl2aXR5IGFuZCBtYWlsaW5nIGxpc3QgbmFtZQ0KDQpEZWFyIGFsbCwNCg0KSSBhbSBub3Qg c3VyZSB3aGV0aGVyIEkgaGF2ZSBjYXB0dXJlZCBhbGwgdGhlIHBvaW50cy4NCg0KU2hhbGwgd2Ug c3Vic2NyaWJlIHRoZSBuZXcgZW1haWwgcmVmbGVjdG9yIHN1cGFAaWV0Zi5vcmc8bWFpbHRvOnN1 cGFAaWV0Zi5vcmc+PyAgQWRkaXRpb25hbGx5LCB3aGF0IGFyZSB0aGUgcG9zc2libGUgcHJvdG9j b2wgc3BlY2lmaWNhdGlvbnMgZm9yIFNVUEE/DQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzLA0K WWluZw0KDQoNCg0KMjAxNC0wOC0xOA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CllpbmcgQ0hFTkcgILPM06gNCkNoaW5hIFVuaWNvbSBOZXR3b3JrIFRlY2hub2xvZ3kgUmVzZWFy Y2ggSW5zdGl0dXRlINbQufrBqs2ozfjC57y8yvXR0L6/1LoNClRlbDogKzg2LTEwLTY4Nzk5OTk5 LTc3MDINCk1vYmlsZTogKzg2LTE4NjAxMTAyOTcxDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kt6K8/sjLo7ogSnVuIEJpDQq3osvNyrG85KO6IDIwMTQtMDgtMDQgIDE1OjU3OjEw DQrK1bz+yMujuiAnVGluYSBUU09VJzsgJ0pvc2UgU2FsZGFuYSc7ICdzcGVuY2VyIGRhd2tpbnMn DQqzrcvNo7ogWWluZyBDaGVuZyjBqs2ovK/NxcGqzajN+MLnvLzK9dHQvr/Uuik7IGtpcmVldGlA anVuaXBlci5uZXQ8bWFpbHRvOmtpcmVldGlAanVuaXBlci5uZXQ+OyBhbmRyZXcucXVAbWVkaWF0 ZWsuY29tPG1haWx0bzphbmRyZXcucXVAbWVkaWF0ZWsuY29tPjsgb3BlbnY2QGlldGYub3JnPG1h aWx0bzpvcGVudjZAaWV0Zi5vcmc+OyAnTGl1c2h1Y2hlbmcgKFdpbGwpJzsga2FyYWdpYW5AY3Mu dXR3ZW50ZS5ubDxtYWlsdG86a2FyYWdpYW5AY3MudXR3ZW50ZS5ubD4NCtb3zOKjuiBSRTogW09w ZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBtYWlsaW5nIGxpc3QgbmFt ZQ0KR29vZC4NCg0KVGhhbmtzLA0KSnVuDQoNCkZyb206IG9wZW52Ni1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvcGVudjYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRpbmEgVFNPVQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgNCwg MjAxNCAyOjQyIFBNDQpUbzogSm9zZSBTYWxkYW5hOyBzcGVuY2VyIGRhd2tpbnMNCkNjOiBZaW5n IENoZW5nOyBraXJlZXRpQGp1bmlwZXIubmV0PG1haWx0bzpraXJlZXRpQGp1bmlwZXIubmV0Pjsg YW5kcmV3LnF1QG1lZGlhdGVrLmNvbTxtYWlsdG86YW5kcmV3LnF1QG1lZGlhdGVrLmNvbT47IG9w ZW52NkBpZXRmLm9yZzxtYWlsdG86b3BlbnY2QGlldGYub3JnPjsgTGl1c2h1Y2hlbmcgKFdpbGwp OyBqdW5iaUB0c2luZ2h1YS5lZHUuY248bWFpbHRvOmp1bmJpQHRzaW5naHVhLmVkdS5jbj47IGth cmFnaWFuQGNzLnV0d2VudGUubmw8bWFpbHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmw+DQpTdWJq ZWN0OiBSZTogW09wZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBtYWls aW5nIGxpc3QgbmFtZQ0KDQpEZWFyIGFsbCwNCg0KSXQgc2VlbXMgdGhhdCB0aGUgY29uc2Vuc3Vz IGlzIHRvIGNoYW5nZSBvcGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9wZW52NkBpZXRmLm9yZz4gdG8g c3VwYUBpZXRmLm9yZzxtYWlsdG86c3VwYUBpZXRmLm9yZz4uDQoNCg0KRGVhciBTcGVuY2VyLA0K DQpXb3VsZCB5b3UgaGVscCB0byBnZXQgaXQgZG9uZT8NCg0KDQpUaGFuayB5b3UsDQpUaW5hDQoN Ck9uIEp1bCAzMSwgMjAxNCwgYXQgNDo0NiBQTSwgIkpvc2UgU2FsZGFuYSIgPGpzYWxkYW5hQHVu aXphci5lczxtYWlsdG86anNhbGRhbmFAdW5pemFyLmVzPj4gd3JvdGU6DQorMQ0KDQpKb3NlDQoN CkRlOiBPcGVudjYgW21haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZ10gRW4gbm9tYnJlIGRl IFlpbmcgQ2hlbmcNCkVudmlhZG8gZWw6IGp1ZXZlcywgMzEgZGUganVsaW8gZGUgMjAxNCA5OjEx DQpQYXJhOiBMaXVzaHVjaGVuZyAoV2lsbCk7IGthcmFnaWFuQGNzLnV0d2VudGUubmw8bWFpbHRv OmthcmFnaWFuQGNzLnV0d2VudGUubmw+OyBUaW5hIFRTT1U7IGp1bmJpQHRzaW5naHVhLmVkdS5j bjxtYWlsdG86anVuYmlAdHNpbmdodWEuZWR1LmNuPg0KQ0M6IGFuZHJldy5xdUBtZWRpYXRlay5j b208bWFpbHRvOmFuZHJldy5xdUBtZWRpYXRlay5jb20+OyBraXJlZXRpQGp1bmlwZXIubmV0PG1h aWx0bzpraXJlZXRpQGp1bmlwZXIubmV0Pjsgb3BlbnY2QGlldGYub3JnPG1haWx0bzpvcGVudjZA aWV0Zi5vcmc+DQpBc3VudG86IFJlOiBbT3BlbnY2XSByZWdhcmRpbmcgbmFtZSBvZiBvdXIgYWN0 aXZpdHkgYW5kIG1haWxpbmcgbGlzdCBuYW1lDQoNCkRlYXIgYWxsLA0KDQpUaGFua3MgZm9yIFRp bmEncyBzdWdnZXN0aW9uLg0KDQpGcm9tIG15IHBlcnNvbmFsIG9waW5pb24sIFNVUEEgY2FuIGJl dHRlciByZWZsZWN0IG91ciBhY3R1YWwgd29yay4NCg0KQlIsDQpZaW5nDQoNCg0KDQoNCjIwMTQt MDctMzENCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpZaW5nIENIRU5HICCzzNOo DQpDaGluYSBVbmljb20gTmV0d29yayBUZWNobm9sb2d5IFJlc2VhcmNoIEluc3RpdHV0ZSDW0Ln6 warNqM34wue8vMr10dC+v9S6DQpUZWw6ICs4Ni0xMC02ODc5OTk5OS03NzAyDQpNb2JpbGU6ICs4 Ni0xODYwMTEwMjk3MQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7Iy6O6 IExpdXNodWNoZW5nIChXaWxsKQ0Kt6LLzcqxvOSjuiAyMDE0LTA3LTI5ICAxNDoxODowMQ0KytW8 /sjLo7oga2FyYWdpYW5AY3MudXR3ZW50ZS5ubDxtYWlsdG86a2FyYWdpYW5AY3MudXR3ZW50ZS5u bD47IFRpbmEgVFNPVTsganVuYmlAdHNpbmdodWEuZWR1LmNuPG1haWx0bzpqdW5iaUB0c2luZ2h1 YS5lZHUuY24+DQqzrcvNo7ogYW5kcmV3LnF1QG1lZGlhdGVrLmNvbTxtYWlsdG86YW5kcmV3LnF1 QG1lZGlhdGVrLmNvbT47IGtpcmVldGlAanVuaXBlci5uZXQ8bWFpbHRvOmtpcmVldGlAanVuaXBl ci5uZXQ+OyBvcGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9wZW52NkBpZXRmLm9yZz4NCtb3zOKjuiBS ZTogW09wZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBtYWlsaW5nIGxp c3QgbmFtZQ0KKzEsIHRoZSBzaG9ydGVyLCB0aGUgZWFzaWVyIHRvIHJlbWVtYmVyLg0KDQpSZWdh cmRzLA0KV2lsbCAoU2h1Y2hlbmcgTElVKQ0KDQpGcm9tOiBPcGVudjYgW21haWx0bzpvcGVudjYt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGthcmFnaWFuQGNzLnV0d2VudGUubmw8bWFp bHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmw+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0 IDI6MDEgQU0NClRvOiBUaW5hIFRTT1U7IGp1bmJpQHRzaW5naHVhLmVkdS5jbjxtYWlsdG86anVu YmlAdHNpbmdodWEuZWR1LmNuPg0KQ2M6IGFuZHJldy5xdUBtZWRpYXRlay5jb208bWFpbHRvOmFu ZHJldy5xdUBtZWRpYXRlay5jb20+OyBraXJlZXRpQGp1bmlwZXIubmV0PG1haWx0bzpraXJlZXRp QGp1bmlwZXIubmV0Pjsgb3BlbnY2QGlldGYub3JnPG1haWx0bzpvcGVudjZAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW09wZW52Nl0gcmVnYXJkaW5nIG5hbWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBt YWlsaW5nIGxpc3QgbmFtZQ0KDQoNCkRlYWUgVGluYSwgRGVhciBhbGwsDQoNCg0KDQpUaGFuayB5 b3UgdmVyeSBtdWNoIQ0KDQpJIHdvdWxkIHBlcmVmZXIgdGhlIG5hbWUgU1VQQSwgc2luY2UgaXQg aXMgcmVwcmVzZW50aW5nIG91ciBhY3Rpdml0eSBtb3JlIGFjY3VyYXRlbHkgdGhhbiB3aGF0IHRo ZSBuYW1lIFBBTkFNQSBpcyByZXByZXNlbnRpbmcuDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCkdl b3JnaW9zDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpW YW46IFRpbmEgVFNPVSBbVGluYS5Uc291LlpvdXRpbmdAaHVhd2VpLmNvbTxtYWlsdG86VGluYS5U c291LlpvdXRpbmdAaHVhd2VpLmNvbT5dDQpWZXJ6b25kZW46IG1hYW5kYWcgMjgganVsaSAyMDE0 IDU6MzcNCkFhbjogSnVuIEJpDQpDQzogS2FyYWdpYW5uaXMsIEcuIChFV0kpOyBvcGVudjZAaWV0 Zi5vcmc8bWFpbHRvOm9wZW52NkBpZXRmLm9yZz47IGFuZHJldy5xdUBtZWRpYXRlay5jb208bWFp bHRvOmFuZHJldy5xdUBtZWRpYXRlay5jb20+OyBraXJlZXRpQGp1bmlwZXIubmV0PG1haWx0bzpr aXJlZXRpQGp1bmlwZXIubmV0Pg0KT25kZXJ3ZXJwOiBSZTogW09wZW52Nl0gcmVnYXJkaW5nIG5h bWUgb2Ygb3VyIGFjdGl2aXR5IGFuZCBtYWlsaW5nIGxpc3QgbmFtZQ0KRGVhciBKdW4sIEdlb3Jn aW9zIGV0IGFsLA0KDQpIb3cgYWJvdXQNCg0KU1VQQToNClNoYXJlZCBVbmlmaWVkIFBvbGljeSBB dXRvbWF0aW9uDQoNCm9yDQoNClBBTkFNQToNClBvbGljZXMgZm9yIEFwcGxpY2F0aW9uLWJhc2Vk IE5ldHdvcmsgQWRtaW5pc3RyYXRpb24gJiBNYW5hZ2VtZW50IEF1dG9tYXRpb24NCg0KPw0KDQoN ClRoYW5rIHlvdSwNClRpbmENCg0KT24gSnVsIDI1LCAyMDE0LCBhdCA1OjIzIFBNLCAiSnVuIEJp IiA8anVuYmlAdHNpbmdodWEuZWR1LmNuPG1haWx0bzpqdW5iaUB0c2luZ2h1YS5lZHUuY24+PiB3 cm90ZToNClRoZW4gbGV0J3MgcHJvcG9zZSBhIG5ldyBuYW1lIG9mIHRoZSBXRy4NCg0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcGVudjYtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86b3BlbnY2LWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b3BlbnY2LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZg0Ka2FyYWdpYW5AY3MudXR3ZW50ZS5ubDxtYWlsdG86a2FyYWdp YW5AY3MudXR3ZW50ZS5ubD4NClNlbnQ6IEZyaWRheSwgSnVseSAyNSwgMjAxNCA0OjAxIEFNDQpU bzoganVuYmlAdHNpbmdodWEuZWR1LmNuPG1haWx0bzpqdW5iaUB0c2luZ2h1YS5lZHUuY24+OyBv cGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9wZW52NkBpZXRmLm9yZz4NClN1YmplY3Q6IFtPcGVudjZd IHJlZ2FyZGluZyBuYW1lIG9mIG91ciBhY3Rpdml0eSBhbmQgbWFpbGluZyBsaXN0IG5hbWUNCg0K SGkgSmluLCBIaSBhbGwsDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgc3VnZ2VzdGlv biENClRoZXJlIGFyZSB0d28gcG9zc2libGUgcGF0aHMgdGhhdCB3ZSBjb3VsZCBmb2xsb3c6DQoN CjEpIEtlZXAgdGhlIG5hbWUgQVBPTkYgYW5kIGNyZWF0ZSBhIG5ldyBtYWlsaW5nIGxpc3Qgd2l0 aCBuYW1lOg0KYXBvbmZAaWV0Zi5vcmc8bWFpbHRvOmFwb25mQGlldGYub3JnPg0KRHJhd2JhY2s6 IHRoZSBuYW1lIGNvbnRhaW5zIHRoZSB3b3JkcyAiTmV0d29yayBGdW5jdGlvbnMiIHdoaWNoIG1p Z2h0IGJlDQptaXNsZWlkaW5nDQoNCjIpIENyZWF0ZSBhIG5ldyBuYW1lIHRoYXQgcmVwcmVzZW50 cyB0aGUgZ29hbCBvZiB0aGlzIGFjdGl2aXR5IG1vcmUNCmFjY3VyYXRlbHkgdGhhbiBBUE9ORiBh bmQgYWxzbyBhIG5ldyBtYWlsaW5nIGxpc3QgdGhhdCB1c2VzIHRoaXMgbmV3IG5hbWUuDQpTb21l IHRpbWUgYWdvIHRoZSBuYW1lIFBBTkFNQSBoYWQgYmVlbiBwcm9wb3NlZCENCg0KUGxlYXNlIGV4 cHJlc3MgeW91ciBvcGluaW9uIG9uIHdoaWNoIG9mIHRoZSB0d28gb3B0aW9ucyB3ZSBzaG91bGQg Y2hvb3NlPw0KDQpCZXN0IHJlZ2FyZHMsDQpHZW9yZ2lvcw0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KVmFuOiBPcGVudjYgW29wZW52Ni1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpvcGVudjYtYm91bmNlc0BpZXRmLm9yZz5dIG5hbWVucyBKdW4gQmkgW2p1bmJpQHRz aW5naHVhLmVkdS5jbjxtYWlsdG86anVuYmlAdHNpbmdodWEuZWR1LmNuPl0NClZlcnpvbmRlbjog dnJpamRhZyAyNSBqdWxpIDIwMTQgMToyOA0KQWFuOiBvcGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9w ZW52NkBpZXRmLm9yZz4NCk9uZGVyd2VycDogUmU6IFtPcGVudjZdIG5ldyBBUE9ORiBnb2FscyBi YXNlZCBvbiBBUE9ORiBiYXIgQk9GIG1lZXRpbmcNCg0KQlRXLCBzaGFsbCB3ZSBjaGFuZ2UgdGhl IG5hbWUgb2YgbWFpbGluZy1saXN0IHRvIGFwb25mQGlldGYub3JnPG1haWx0bzphcG9uZkBpZXRm Lm9yZz4gPw0KDQpUaGFua3MsDQpKdW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IEp1biBCaSBbbWFpbHRvOmp1bmJpQHRzaW5naHVhLmVkdS5jbl0NClNlbnQ6IFRodXJzZGF5 LCBKdWx5IDI0LCAyMDE0IDc6MjcgUE0NClRvOiAnb3BlbnY2QGlldGYub3JnPG1haWx0bzpvcGVu djZAaWV0Zi5vcmc+Jw0KU3ViamVjdDogUkU6IFtPcGVudjZdIG5ldyBBUE9ORiBnb2FscyBiYXNl ZCBvbiBBUE9ORiBiYXIgQk9GIG1lZXRpbmcNCg0KT25lIGV4YW1wbGUgdG8gdXNlIEFQT05GIGZv ciBTQVZJIChzb3VyY2UgYWRkcmVzcyB2YWxpZGF0aW9uIGltcHJvdmVtZW50cykuDQoNClRoYW5r cyENCg0KSnVuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKdW4gQmkgW21h aWx0bzpqdW5iaUB0c2luZ2h1YS5lZHUuY25dDQpTZW50OiBUaHVyc2RheSwgSnVseSAyNCwgMjAx NCAxMToyMyBBTQ0KVG86ICdUb20gVGF5bG9yJzsgJ2thcmFnaWFuQGNzLnV0d2VudGUubmw8bWFp bHRvOmthcmFnaWFuQGNzLnV0d2VudGUubmw+JzsgJ29wZW52NkBpZXRmLm9yZzxtYWlsdG86b3Bl bnY2QGlldGYub3JnPicNClN1YmplY3Q6IFJFOiBbT3BlbnY2XSBuZXcgQVBPTkYgZ29hbHMgYmFz ZWQgb24gQVBPTkYgYmFyIEJPRiBtZWV0aW5nDQoNCkkgaGF2ZSBhIHN1Z2dlc3Rpb24gdG8gY2hh bmdlIHRoZSB0ZXJtaW5vbG9neS4NCg0KRm9yIGZpZ3VyZSAxIG9uIHBhZ2UgNCwgdGhlICJlbmQg dXNlciBhcHBsaWNhdGlvbiIgaXMgbm90IGEgZ29vZCB0ZXJtLg0KDQpJIG5vdGljZWQgdGhhdCB0 aGUgZmlndXJlIGluIHRoZSBsYXRlc3QgUFBUIGZyb20gR2Vvcmdpb3MgYW5kIFRpbmEsICIgZW5k DQp1c2VyIGFwcGxpY2F0aW9uIiB3YXMgY2hhbmdlZCB0byAibmV0d29yayBzZXJ2aWNlIi4gSSB0 aGluayBpdCBpcyBnb29kLg0KDQpTbyBvbmUgcGFnZSA1IG9mIEFQT05GIHByb2JsZW0gc3RhdGVt ZW50IGRyYWZ0Og0KDQoiTmV0d29yayBNYW5hZ2VtZW50IEFwcGxpY2F0aW9uOiBPcGVyYXRpb25h bCBTdXBwb3J0IFN5c3RlbSAoT1NTKSBsaWtlDQphcHBsaWNhdGlvbnMgdGhhdCBoZWxwIGEgY29t bXVuaWNhdGlvbiBzZXJ2aWNlIHByb3ZpZGVyIHRvIG1vbml0b3IsIGNvbnRyb2wsDQphbmFseXpl IGFuZCBtYW5hZ2UgYSBjb21tdW5pY2F0aW9uIG5ldHdvcmsuIg0KDQpDb3VsZCB3ZSBjaGFuZ2Ug IiBOZXR3b3JrIE1hbmFnZW1lbnQgQXBwbGljYXRpb24iIHRvICJOZXR3b3JrIFNlcnZpY2UiLCB0 bw0KYmUgY29uc2lzdCB3aXRoIHRoZSBsYXRlc3QgZmlndXJlID8NCg0KDQpJbiBhZGRpdGlvbiwg bWF5IEkgcHJvcG9zZSB3ZSBhbHNvIGNoYW5nZSAiTmV0d29yayBNYW5hZ2VtZW50IEFwcGxpY2F0 aW9uDQpTeXN0ZW0iIHRvICJOZXR3b3JrIFNlcnZpY2UgU3lzdGVtIiA/DQoNCkNoYW5nZSB0aGUg ZGVmaW5pdGlvbiAiTmV0d29yayBtYW5hZ2VtZW50IGFwcGxpY2F0aW9uIHN5c3RlbXM6IFN5c3Rl bXMgb3INCnBsYXRmb3JtcyB0aGF0IHJ1biB0aGUgbmV0d29yayBtYW5hZ2VtZW50IGFwcGxpY2F0 aW9uLiINClRvDQoiTmV0d29yayBTZXJ2aWNlIFN5c3RlbXM6IFN5c3RlbXMgb3IgcGxhdGZvcm1z IHRoYXQgcnVuIHRoZSBuZXR3b3JrDQpzZXJ2aWNlLiINCg0KQmVzdCBSZWdhcmRzLA0KSnVuIEJp DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3BlbnY2LWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm9wZW52Ni1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9wZW52Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNClRvbSBUYXlsb3INClNlbnQ6IFR1ZXNkYXks IEp1bHkgMjIsIDIwMTQgNjoyNiBQTQ0KVG86IGthcmFnaWFuQGNzLnV0d2VudGUubmw8bWFpbHRv OmthcmFnaWFuQGNzLnV0d2VudGUubmw+OyBvcGVudjZAaWV0Zi5vcmc8bWFpbHRvOm9wZW52NkBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT3BlbnY2XSBuZXcgQVBPTkYgZ29hbHMgYmFzZWQgb24g QVBPTkYgYmFyIEJPRiBtZWV0aW5nDQoNCkZvbGxvdy11cCBiZWxvdywgZXhwcmVzc2luZyBteSB1 bmRlcnN0YW5kaW5nIG9mIGZ1cnRoZXIgZGV0YWlscyBhZ3JlZWQgbGFzdA0KbmlnaHQuDQoNCg0K T24gMTQtMDctMjIgMDU6MTMgUE0sIGthcmFnaWFuQGNzLnV0d2VudGUubmw8bWFpbHRvOmthcmFn aWFuQGNzLnV0d2VudGUubmw+IHdyb3RlOg0KSGkgYWxsLA0KDQpUbyBiZSBpbmZvcm1lZCENCg0K UGxlYXNlIG5vdGUgdGhhdCB0aGlzIHZlcnNpb24gaXMgbW9kaWZpZWQgYmFzZWQgb24gdGhlIGNv bW1lbnRzIHRoYXQNCndlIHJlY2VpdmVkIHllc3RlcmRheSBkdXJpbmcgdGhlIGJhciBCT0YgbWVl dGluZy4NCg0KLi4uDQoNClByb2NlZHVyYWxseTogd2hlbiBhIG5ldyBzZXJ2aWNlIGlzIGRlZmlu ZWQsIHRoZSBOZXR3b3JrIE1hbmFnZW1lbnQgKE5NKQ0KQXBwbGljYXRpb24gZnVuY3Rpb24gZG93 bmxvYWRzIGFuIGluaXRpYWwgbmV0d29yayBzZXJ2aWNlIGdyYXBoIHRvIHRoZSBOTQ0KQ29udHJv bCBmdW5jdGlvbi4gVGhlIGRhdGEgaW5jbHVkZXMgdHJpZ2dlcnMgZm9yIE5NIENvbnRyb2wgdG8g ZmVlZCBiYWNrDQp1cGRhdGVzIHRvIHRoZSBncmFwaC4gV2hlbiBvbmUgb2YgdGhlc2UgdHJpZ2dl cnMgaXMgZW5nYWdlZCwgTk0gQ29udHJvbA0Kc2VuZHMgYmFjayBhIHJlZnJlc2hlZCBuZXR3b3Jr IHNlcnZpY2UgZ3JhcGguDQoNCkRpc2N1c3Npb24gUG9pbnQgMTogSSBhbSB0cnlpbmcgdG8gcmVs YXRlIHRoaXMgdG8gU0ZDIGFzIGEgc2VydmljZS4gVGhlDQpzdGFydGluZyBwb2ludCBpcyB0aGUg U2VydmljZSBGdW5jdGlvbiBDaGFpbi4gVGhpcyBoYXMgdG8gYmUgdHJhbnNsYXRlZCBpbnRvDQpv bmUgb3IgbW9yZSBpbnN0YW5jZXMgb2YgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGgsIHdoaWNoIGdl dCBwYXNzZWQgdG8gdGhlDQpTZXJ2aWNlIENsYXNzaWZpZXIuIFBhdGggZGVyaXZhdGlvbiBpcyBs b2dpY2FsbHkgc29tZXRoaW5nIE5NIENvbnRyb2wgd291bGQNCmJlIHJlc3BvbnNpYmxlIGZvci4g V2hpY2ggQVBPTkYgZnVuY3Rpb24gd291bGQgYmUgcmVzcG9uc2libGUgZm9yDQpkaXN0cmlidXRp bmcgdGhlIHBhdGggaW5mb3JtYXRpb24gdG8gdGhlIENsYXNzaWZpZXIocyk/DQoNCkRpc2N1c3Np b24gUG9pbnQgMjogdG8gZG8gaXRzIG1hcHBpbmcgYmV0d2VlbiBpbmZvcm1hdGlvbiBnYXRoZXJl ZCBmcm9tDQpOZXR3b3JrIEVsZW1lbnRzIChORSkgYW5kIHRoZSBuZXR3b3JrIHNlcnZpY2UgZ3Jh cGhzLCBOTSBDb250cm9sIG5lZWRzIGENCmRhdGFiYXNlIGFzc29jaWF0aW5nIE5FLXByb3ZpZGVk IGF0dHJpYnV0ZXMgd2l0aCBzZXJ2aWNlLXNwZWNpZmljIGxhYmVscy4NCldvdWxkIGRvd25sb2Fk aW5nIG9mIHN1Y2ggYSBkaWN0aW9uYXJ5IGJlIHBhcnQgb2YgQVBPTkYgcmVzcG9uc2liaWxpdGll cywgb3INCndvdWxkIHdlIGxlYXZlIGNyZWF0aW9uIG9mIHRoZSBkYXRhYmFzZSB0byBiZSBhbiBv cGVyYXRvci1zcGVjaWZpYyBtYXR0ZXI/DQoNCkkgc3RhbmQgdG8gYmUgY29ycmVjdGVkIG9uIG15 IGJhc2ljIHVuZGVyc3RhbmRpbmcgb2YgQVBPTkYgb3BlcmF0aW9uLCBhbmQNCndlbGNvbWUgY29t bWVudHMgb24gdGhlIGRpc2N1c3Npb24gcG9pbnRzLg0KDQpUb20gVGF5bG9yDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPcGVudjYgbWFpbGluZyBs aXN0DQpPcGVudjZAaWV0Zi5vcmc8bWFpbHRvOk9wZW52NkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BlbnY2DQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9wZW52NiBtYWlsaW5nIGxpc3QNCk9wZW52 NkBpZXRmLm9yZzxtYWlsdG86T3BlbnY2QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vcGVudjYNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPcGVudjYgbWFpbGluZyBsaXN0DQpPcGVudjZAaWV0Zi5vcmc8bWFp bHRvOk9wZW52NkBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb3BlbnY2DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9wZW52NiBtYWlsaW5nIGxpc3QNCk9wZW52NkBpZXRmLm9yZzxtYWlsdG86T3BlbnY2 QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcGVudjYN Cg0KyOe5+8T6tO3O873TytXBy7jD08q8/qOsx+vNqLn9tefX09PKvP7Bory0zajWqs7Sw8eho8fr u9i4tNPKvP61vWhxcy1zcG1jQGNoaW5hdW5pY29tLmNuPG1haWx0bzpocXMtc3BtY0BjaGluYXVu aWNvbS5jbj6jrLy0v8nS1M3Ltqm0y9PKvP6ho87Sw8e9q8GivLS9q8T6tcTQxc+itNPO0sPHtcS3 osvNxL/CvNbQyb6z/aGjIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwuIFBsZWFzZSByZXBseSB0byBo cXMtc3BtY0BjaGluYXVuaWNvbS5jbjxtYWlsdG86aHFzLXNwbWNAY2hpbmF1bmljb20uY24+IGlm IHlvdSB3YW50IHRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0 ZWx5IHJlbW92ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20gb3VyIHNlbmRpbmcgY2F0YWxvZ3VlLg0K DQrI57n7xPq07c7zvdPK1cHLuMPTyrz+o6zH682ouf2159fT08q8/sGivLTNqNaqztLDx6Gjx+u7 2Li008q8/rW9aHFzLXNwbWNAY2hpbmF1bmljb20uY26jrLy0v8nS1M3Ltqm0y9PKvP6ho87Sw8e9 q8GivLS9q8T6tcTQxc+itNPO0sPHtcS3osvNxL/CvNbQyb6z/aGjIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBl LW1haWwuIFBsZWFzZSByZXBseSB0byBocXMtc3BtY0BjaGluYXVuaWNvbS5jbjxtYWlsdG86aHFz LXNwbWNAY2hpbmF1bmljb20uY24+IGlmIHlvdSB3YW50IHRvIHVuc3Vic2NyaWJlIGZyb20gdGhp cyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0ZWx5IHJlbW92ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20g b3VyIHNlbmRpbmcgY2F0YWxvZ3VlLg0K --_000_C9B5F12337F6F841B35C404CF0554ACB5FF667F8SZXEMA509MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear Tina, Ying et al,

 <= /p>

The mailing list supa@ietf.org was just created. https://www.ietf.org/mailman/listinfo/supa

 <= /p>

We=A1=AFve asked the secr= etary to add all openv6 subscribers there. However, it seems that there are= only around 10 successfully moved there due to the system problem.  We are trying to manually fix this. You may also subscribe with the = link in this email. Then, we can continue our discussion there.<= /span>

 <= /p>

Regards,

Will

 <= /p>

From: Openv6 [mailto:openv6-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Tuesday, August 19, 2014 6:01 PM
To: Ying Cheng
Cc: openv6@ietf.org; kireeti@juniper.net; 'Jose Saldana'; 'Jun Bi'; = karagian@cs.utwente.nl; spencerdawkins.ietf@gmail.com; andrew.qu@mediatek.c= om
Subject: Re: [Openv6] regarding name of our activity and mailing lis= t name

 =

Dear Ying et al,

 <= /p>

Thank you for asking.

 <= /p>

As far as I know, the mai= l administrators are working with Spencer and IETF secretary to create supa@ietf.org, auto subscribe everyone= in openv6@ietf.org to the new list, and also copy the mail archieves to th= ere. Pls stay tuned.

 <= /p>

Regarding the protocol sp= ecs, I=A1=AFm aware that people like Georgios, Luis, Will, Jun, Kireeti, An= drew, Juergen, JF et al are discussing offline about the Network Model for a programmable interface to virtual links:

Describe the network configuration.

Describe the layer 0-7 ne= twork topology, including the relationship between intra-layer and inter-la= yer connections.

 

It would be good if they = could bring some discussion to the mailing list for broader audience.<= /o:p>

 <= /p>

 <= /p>

Thank you,

Tina

=B7=A2=BC=FE=C8=CB=A3=BA Yi= ng Cheng

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2014-08-18 17:42:18

=CA=D5=BC=FE=C8=CB=A3=BA Ju= n Bi; 'Tina TSOU'; 'Jose Saldana'; 'spencer dawkins'

=D6=F7=CC=E2=A3=BA Re: RE: = [Openv6] regarding name of our activity and mailing list name

 

Dear all,

 

I am not sure whether I have captured all the points.

 

Shall we subscribe the new email reflector supa@ietf.org?  Additionally, wha= t are the possible protocol specifications for SUPA?

 

Thanks and best regards,<= /o:p>

Ying 

 

 

 

2014-08-18

Ying CHENG  =B3=CC=D3=A8
China Unicom Network Technology Research Institute =D6=D0= =B9=FA=C1=AA=CD=A8=CD=F8=C2=E7=BC=BC=CA=F5=D1=D0=BE=BF=D4=BA
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

=B7=A2=BC=FE=C8=CB=A3=BA Ju= n Bi

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2014-08-04  15:57:10

=CA=D5=BC=FE=C8=CB=A3=BA 'T= ina TSOU'; 'Jose Saldana'; 'spencer dawkins'

=B3=AD=CB=CD=A3=BA Ying Che= ng(=C1=AA=CD=A8=BC=AF=CD=C5=C1=AA=CD=A8=CD=F8=C2=E7=BC=BC= =CA=F5=D1=D0=BE=BF=D4=BA); kireeti@juniper.net; andrew.qu@mediatek.com; openv6@ietf.= org; 'Liushucheng (Will)'; karagian@cs.utwente.nl <= /o:p>

=D6=F7=CC=E2=A3=BA RE: [Ope= nv6] regarding name of our activity and mailing list name

Good.

 

Thanks,

Jun

 

From: openv6-bounces@ietf.org [mailto:openv6-bounces@ietf.org] On Behalf Of Tina TSOU
Sent: Monday, August 4, 2014 2:42 PM
To: Jose Saldana; spencer dawkins
Cc: Ying Cheng; kireeti@junip= er.net; andrew.qu@mediatek.com; openv6@ietf.org; Liushucheng (Will); junbi@tsinghua.edu.cn; karagian@cs.utwente.nl
Subject: Re: [Openv6] regarding name of our activity and mailing lis= t name

 

Dear all,

 =

It seems that the consen= sus is to change openv6@ietf.org to supa@ietf.org.

 =

 =

Dear Spencer, =

 =

Would you help to get it= done?

 =

 =

Thank you,

Tina


On Jul 31, 2014, at 4:46 PM, "Jose Saldana" <jsaldana@unizar.es> wrote:

+1

 

Jose

 

De: Openv6 [mailto:openv6-bounces@ietf.org] En nombre de Ying Cheng
Enviado el: jueves, 31 de julio de 2014 9:11
Para: Liushucheng (Will); = karagian@cs.utwente.nl; Tina TSOU; junbi@tsinghua.edu.cn
CC: andrew.qu@mediatek.com= ; kireeti@juniper.net; openv6@ietf.org=
Asunto: Re: [Openv6] regarding name of our activity and mailing list= name

 

Dear all,=

 

Thanks for Tina's suggestion.

 

From my personal opinion, SUPA can better reflect our act= ual work.

 

BR,

Ying

 

 

 

 

2014-07-31

Ying CHENG  =B3=CC=D3=A8
China Unicom Network Technology Research Institute =D6=D0= =B9=FA=C1=AA=CD=A8=CD=F8=C2=E7=BC=BC=CA=F5=D1=D0=BE=BF=D4=BA
Tel: +86-10-68799999-7702
Mobile: +86-18601102971

=B7=A2=BC=FE=C8=CB=A3=BA Li= ushucheng (Will)

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2014-07-29  14:18:01

=CA=D5=BC=FE=C8=CB=A3=BA k= aragian@cs.utwente.nl; Tina TSOU; junbi@tsinghua.edu.cn <= span style=3D"color:black">

=D6=F7=CC=E2=A3=BA Re: [Ope= nv6] regarding name of our activity and mailing list name

+1, the shorter, the = easier to remember.

 

Regards,

Will (Shucheng LIU)

 

From: Openv6 [mailto:o= penv6-bounces@ietf.org] On Behalf Of karagian@cs.u= twente.nl
Sent: Tuesday, July 29, 2014 2:01 AM
To: Tina TSOU; junbi@tsingh= ua.edu.cn
Cc: andrew.qu@mediatek.com= ; kireeti@juniper.net; openv6@ietf.org=
Subject: Re: [Openv6] regarding name of our activity and mailing lis= t name

 =

Deae Tina, Dear all,

 

Thank you very much!

I would perefer the name SUPA, since it is repre= senting our activity more accurately than what the name PANAMA is represent= ing.

 

Best regards,=

Georgios=

 

 

 

Van: Tina TSOU [Tina.Tsou.Zouting@huawei.com]
Verzonden: maandag 28 juli 2014 5:37
Aan: Jun Bi
CC: Karagiannis, G. (EWI); openv6= @ietf.org; andrew.qu@mediatek.com; kireeti@juniper.net
Onderwerp: Re: [Openv6] regarding name of our activity and mailing l= ist name

Dear Ju= n, Georgios et al,

 

How abou= t

 

SUPA:<= /p>

Shared Unified Policy Au= tomation

 =

or

 =

PANAMA:

Polices for Application-= based Network Administration & Management Automation<= /p>

 =

?=

 

 

Thank yo= u,

Tina


On Jul 25, 2014, at 5:23 PM, "Jun Bi" <junbi@tsinghua.edu.cn> wrote:

Then let's propose a new name of the WG.



-----Original Message-----
From: openv6-b= ounces@ietf.org [mailto:openv6-bounces@ietf.org] On Behalf Of
karagian@cs.utw= ente.nl
Sent: Friday, July 25, 2014 4:01 AM
To: junbi@tsingh= ua.edu.cn; openv6@ietf.org Subject: [Openv6] regarding name of our activity and mailing list name

Hi Jin, Hi all,

Thank you very much for your suggestion!
There are two possible paths that we could follow:

1) Keep the name APONF and create a new mailing list with name:
aponf@ietf.org
Drawback: the name contains the words "Network Functions" which m= ight be
misleiding

2) Create a new name that represents the goal of this activity more
accurately than APONF and also a new mailing list that uses this new name.<= br> Some time ago the name PANAMA had been proposed!

Please express your opinion on which of the two options we should choose?
Best regards,
Georgios
________________________________________
Van: Openv6 [o= penv6-bounces@ietf.org] namens Jun Bi [junbi@tsinghua.edu.cn]
Verzonden: vrijdag 25 juli 2014 1:28
Aan: openv6@ietf.org
Onderwerp: Re: [Openv6] new APONF goals based on APONF bar BOF meeting

BTW, shall we change the name of mailing-list to aponf@ietf.org ?

Thanks,
Jun

-----Original Message-----
From: Jun Bi [ma= ilto:junbi@tsinghua.edu.cn]
Sent: Thursday, July 24, 2014 7:27 PM
To: 'openv6@ietf.org'
Subject: RE: [Openv6] new APONF goals based on APONF bar BOF meeting

One example to use APONF for SAVI (source address validation improvements).=

Thanks!

Jun

-----Original Message-----
From: Jun Bi [ma= ilto:junbi@tsinghua.edu.cn]
Sent: Thursday, July 24, 2014 11:23 AM
To: 'Tom Taylor'; 'karagian@cs.utwente.nl'; 'openv6@ietf.org'
Subject: RE: [Openv6] new APONF goals based on APONF bar BOF meeting

I have a suggestion to change the terminology.

For figure 1 on page 4, the "end user application" is not a good = term.

I noticed that the figure in the latest PPT from Georgios and Tina, " = end
user application" was changed to "network service". I think = it is good.

So one page 5 of APONF problem statement draft:

"Network Management Application: Operational Support System (OSS) like=
applications that help a communication service provider to monitor, control= ,
analyze and manage a communication network."

Could we change " Network Management Application" to "Networ= k Service", to
be consist with the latest figure ?


In addition, may I propose we also change "Network Management Applicat= ion
System" to "Network Service System" ?

Change the definition "Network management application systems: Systems= or
platforms that run the network management application."
To
"Network Service Systems: Systems or platforms that run the network service."

Best Regards,
Jun Bi



-----Original Message-----
From: openv6-b= ounces@ietf.org [mailto:openv6-bounces@ietf.org] On Behalf Of
Tom Taylor
Sent: Tuesday, July 22, 2014 6:26 PM
To: karagian@cs= .utwente.nl; openv6@ietf.org Subject: Re: [Openv6] new APONF goals based on APONF bar BOF meeting

Follow-up below, expressing my understanding of further details agreed last=
night.


On 14-07-22 05:13 PM, karagian@cs.utwente.nl wrote:=

Hi all,<= /span>

 

To be in= formed!

 

Please n= ote that this version is modified based on the comments that

we recei= ved yesterday during the bar BOF meeting.

 

...

Procedurally: when a new service is defined, the Network Management (NM) Application function downloads an initial network service graph to the NM Control function. The data includes triggers for NM Control to feed back updates to the graph. When one of these triggers is engaged, NM Control
sends back a refreshed network service graph.

Discussion Point 1: I am trying to relate this to SFC as a service. The
starting point is the Service Function Chain. This has to be translated int= o
one or more instances of a Service Function Path, which get passed to the Service Classifier. Path derivation is logically something NM Control would=
be responsible for. Which APONF function would be responsible for
distributing the path information to the Classifier(s)?

Discussion Point 2: to do its mapping between information gathered from
Network Elements (NE) and the network service graphs, NM Control needs a database associating NE-provided attributes with service-specific labels. Would downloading of such a dictionary be part of APONF responsibilities, o= r
would we leave creation of the database to be an operator-specific matter?<= br>
I stand to be corrected on my basic understanding of APONF operation, and welcome comments on the discussion points.

Tom Taylor

_______________________________________________
Openv6 mailing list
Openv6@ietf.org = https://www.ietf.org/mailman/listinfo/openv6


_______________________________________________
Openv6 mailing list
Openv6@ietf.org = https://www.ietf.org/mailman/listinfo/openv6
_______________________________________________
Openv6 mailing list
Openv6@ietf.org = https://www.ietf.org/mailman/listinfo/openv6


_______________________________________________
Openv6 mailing list
Openv6@ietf.org = https://www.ietf.org/mailman/listinfo/openv6

=C8= =E7=B9=FB=C4=FA=B4=ED=CE=F3=BD=D3=CA=D5=C1=CB=B8=C3=D3=CA=BC=FE=A3=AC=C7=EB= =CD=A8=B9=FD=B5=E7=D7=D3=D3=CA=BC=FE=C1=A2=BC=B4=CD=A8=D6=AA=CE=D2=C3=C7=A1= =A3=C7=EB=BB=D8=B8=B4=D3=CA=BC=FE=B5=BD<= a href=3D"mailto:hqs-spmc@chinaunicom.cn">hqs-spmc@chinaunicom.cn=A3=AC= =BC=B4=BF=C9=D2=D4=CD=CB=B6=A9=B4=CB=D3=CA=BC=FE=A1=A3=CE=D2=C3=C7=BD=AB=C1= =A2=BC=B4=BD=AB=C4=FA=B5=C4=D0=C5=CF=A2=B4=D3=CE=D2=C3=C7=B5=C4=B7=A2=CB=CD= =C4=BF=C2=BC=D6=D0=C9=BE=B3=FD=A1=A3 If you have received this email in error please notify us immediately by e= -mail. Please reply to hqs-spmc@chinaunicom.cn if y= ou want to unsubscribe from this mail. We will immediately remove your info= rmation from our sending catalogue.

=C8=E7=B9=FB=C4= =FA=B4=ED=CE=F3=BD=D3=CA=D5=C1=CB=B8=C3=D3=CA=BC=FE=A3=AC=C7=EB=CD=A8=B9=FD= =B5=E7=D7=D3=D3=CA=BC=FE=C1=A2=BC=B4=CD=A8=D6=AA=CE=D2=C3=C7=A1=A3=C7=EB=BB= =D8=B8=B4=D3=CA=BC=FE=B5=BDhqs-spmc@chinaunicom.cn=A3=AC=BC=B4=BF=C9=D2=D4=CD=CB=B6=A9= =B4=CB=D3=CA=BC=FE=A1=A3=CE=D2=C3=C7=BD=AB=C1=A2=BC=B4=BD=AB=C4=FA=B5=C4=D0= =C5=CF=A2=B4=D3=CE=D2=C3=C7=B5=C4=B7=A2=CB=CD=C4=BF=C2=BC=D6=D0=C9=BE=B3=FD= =A1=A3 If you have received this email in error please notify us imm= ediately by e-mail. Please reply to hqs-= spmc@chinaunicom.cn if you want to unsubscribe from this mail. We will = immediately remove your information from our sending catalogue.<= /p>

--_000_C9B5F12337F6F841B35C404CF0554ACB5FF667F8SZXEMA509MBSchi_-- From nobody Sat Aug 30 11:42:19 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E493F1A06E3 for ; Sat, 30 Aug 2014 11:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 C3Gq1ZKlFNt8 for ; Sat, 30 Aug 2014 11:42:14 -0700 (PDT) Received: from tsinghua.edu.cn (smtp02.tsinghua.edu.cn [166.111.204.31]) by ietfa.amsl.com (Postfix) with ESMTP id D9F561A06D5 for ; Sat, 30 Aug 2014 11:42:13 -0700 (PDT) Received: from junbithinkpadx1 (unknown [221.194.157.106]) by app6 (Coremail) with SMTP id D8xvpgBHKDEDGwJUDrBDAA--.6498S2; Sun, 31 Aug 2014 02:42:11 +0800 (CST) From: "Jun Bi" To: Date: Sun, 31 Aug 2014 02:42:05 +0800 Message-ID: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01CFC4C5.274553D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJw== Content-Language: zh-cn X-CM-TRANSID: D8xvpgBHKDEDGwJUDrBDAA--.6498S2 X-Coremail-Antispam: 1UD129KBjvJXoW3WrWUWr1rJF4UZFyfKr4kWFg_yoW7GFWrpF W5WF48Aa12g3Wjgr4xZ3WruFsYgrs5CwsxCwnrJw1DZwnIyr1FgF1agr1Yqr48CryrJr18 Z390qF15uw1avrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUICb7Iv0xC_Kw4lb4IE77IF4wAFc2x0x2IEx4CE42xK8VAvwI8I cIk0rVWrJVCq3wA2ocxC64kIII0Yj41le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67 k08I80eVWrJVW7JwAqx4xG6c804VAFz4xC04v7Mc02F40Ew4AK048IF2xKxVW8JVW5JwAq x4xG6xAIxVCFxsxG0wAv7VCjz48v1sIEY20_Kr1UJr1lOx8S6xCaFVCjc4AY6r1j6r4UM4 x0Y48IcxkI7VAKI48JMx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_XwCF04k20xvY 0x0EwIxGrwCF04k20xvE74AGY7Cv6cx26w4UJr1UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxGrbIY CTnIWIevJa73UjIFyTuYvj7UU6uPUUUUU X-CM-SenderInfo: xmxquxo6wvx0pjkxthxhgxhubq/ Archived-At: http://mailarchive.ietf.org/arch/msg/supa/TFiiS2g2mg_e72_We7046FGihUY Subject: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Aug 2014 18:42:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0083_01CFC4C5.274553D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the "mapping" here means ? Do we have an example ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure and service function interdependencies can be realized using a network service graph. A network service graph is a graph specified by a Network Service Provider that defines how one or more network services are applied to traffic flowing through a set of nodes of the graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and represented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) and their interdependencies o) mapping between service function (and their service function interdependencies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by network service systems to map the network service graph instance into specific network management policies, i.e., into device level configuration models. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services that help a communication service provider to monitor, control, analyze and manage a communication network. In this context, network services can be used to provide the required configuration and application programming interfaces to network service developers. Subsequently, a network service can use the service based demands and possibly update its associated network service graph. The main goal of SUPA is to provide application based policies and means to model and program the abstract view of network infrastructure and service function interdependencies in order to support and feed network management and controlling policies (e.g., dynamic network configuration, I2RS routing strategies). This can be realized by: (1) modeling the network service graph, which among others include application based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (fresh) network service graphs in a secure and efficient manner between network service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs provided by network service systems into specific network management and controlling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely and efficiently distribute up to date (fresh) network service graphs between network service systems and network management and controlling systems o) provide guidelines for mechanisms that can dynamically map attributes, including application based policies, of network service graphs into specific network management and controlling policies, such as dynamic network configuration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and their associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. ------=_NextPart_000_0083_01CFC4C5.274553D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to trigger the discussion on SUPA = charter.

 

The latest version of SUPA draft charter I received is = below.

 

I would ask questions about items in milestones, may I = ask,

 

    I-D 'Guidelines = on mapping network service graphs into specific network  =

    management = and controlling policies' as an Informational RFC.=

=  

What specific technologies the “mapping” here means ? Do = we have an example ?

=  

=
    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model = and Protocol

    Specification' Standards Track = RFC.

=  

What would be included into this protocol specification  ? =

 

Thanks,

Jun

 

 

SUPA (Shared Unified Policy = Automation) charter

Target Area:

Description of Working = Group:

Today network operators are challenged to create an = abstract view of their network infrastructure and help service = developers on using and programming this abstraction rather than = manipulating individual devices. An abstract view of a network = infrastructure and service function interdependencies can be realized = using a network service graph. A network service graph is a graph = specified by a Network Service Provider that defines how one or more = network services are applied to traffic flowing through a set of nodes = of the graph, which includes attributes such as:

 

o) network topology, based on I2RS, SFC based network topologies = and represented by a graph of links and nodes

 

o) service functions = (e.g., policing function, NAT, Firewall, DNS, DHCP) and their = interdependencies

 

o) mapping between = service function (and their service function interdependencies) and = network topology (similar to ALTO mapping)

 

o) application based = policies (actions and access policies) generated by network service = systems to map the network service graph instance into specific network = management policies, i.e., into device level configuration models. Such = application based demands are:

   *) Configuration types:

       o) request to dynamically = configure a node

       o) request to place a service = function on a network

          functio= n

   *) Data plane = types:

    =    o) request to steer a traffic = flow

       = o) request prioritize a traffic flow

       o) request to = encapsulate/de-capsulate a traffic flow

       o) request block or admit a = traffic flow

   *) Control = plane / Routing plane types:

       o) request to change the = routing state on a network

          functio= n

Network services are enhanced = Operational Support System (OSS) services that help a communication = service provider to monitor, control, analyze and manage a communication = network. In this context, network services can be used to provide the = required configuration and application programming interfaces to network = service developers. Subsequently, a network service can use the service = based demands and possibly update its associated network service = graph.

 

The main goal of SUPA is to provide application based policies and = means to model and program the abstract view of network infrastructure = and service function interdependencies in order to support and feed = network management and controlling policies (e.g., dynamic network = configuration, I2RS routing strategies).

This can be realized by:

 

(1) modeling the = network service graph, which among others include application based = policies, using YANG,

 

(2) applying NETCONF = (or RESTCONF) to enable dissemination of up to date (fresh) network = service graphs in a secure and efficient manner between network service = systems and network management and controlling systems, =

 

(3) providing guidelines on mapping attributes of network service = graphs provided by network service systems into specific network = management and controlling policies.

 


Work items related = to SUPA include:

o) specify the network = service graph based on YANG models

 

o) specify and = standardize how NETCONF/YANG (or RESTCONF/YANG) can be used to securely = and efficiently distribute up to date (fresh) network service graphs = between network service systems and network management and controlling = systems

 

o) provide guidelines for mechanisms that can dynamically map = attributes, including application based policies, of network service = graphs into specific network management and controlling policies, such = as dynamic network configuration, I2RS routing = strategies

 

o) document how to use NETCONF (or RESTCONF) authentication and = authorization mechanisms to achieve protection and = isolation

 

The following items are out of the SUPA = scope:

 

o) specification of the network management and controlling = policies and their associated device configuration = models

 

Milestones:

    I-D 'Problem Statement and = Use Cases' as an Informational RFC.


    I-D 'Guidelines on mapping network service = graphs into specific network 

    management and controlling policies' as an = Informational RFC.

 

    I-D = 'Guidelines on using NETCONF (or RESTCONF) authentication and =

    authori= zation mechanisms to achieve security protection and isolation' =

    as an = Informational RFC.

 

    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model = and Protocol

    Specification' Standards Track = RFC.

 

------=_NextPart_000_0083_01CFC4C5.274553D0-- From nobody Sun Aug 31 00:17:59 2014 Return-Path: X-Original-To: supa@ietfa.amsl.com Delivered-To: supa@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196E81A87D2 for ; Sun, 31 Aug 2014 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 phGcDcKxejyf for ; Sun, 31 Aug 2014 00:17:52 -0700 (PDT) Received: from out49-ams.mf.surf.net (out49-ams.mf.surf.net [145.0.1.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCAA1A87D1 for ; Sun, 31 Aug 2014 00:17:50 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s7V7HlLP009783; Sun, 31 Aug 2014 09:17:47 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 31 Aug 2014 09:18:00 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXMBX31.ad.utwente.nl (130.89.4.146) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 31 Aug 2014 09:17:46 +0200 Received: from EXMBX31.ad.utwente.nl ([130.89.4.146]) by EXMBX31.ad.utwente.nl ([130.89.4.146]) with mapi id 15.00.0913.011; Sun, 31 Aug 2014 09:17:46 +0200 From: To: , Thread-Topic: [Supa] Discussion on SUPA draft chatter Thread-Index: Ac/Egg4rnM3Ac+nuTf6RywsQVZWuJwAaL1f3 Date: Sun, 31 Aug 2014 07:17:46 +0000 Message-ID: <626d708fa5b94a238efcd5c50e29dbda@EXMBX31.ad.utwente.nl> References: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> In-Reply-To: <008201cfc482$191b5d10$4b521730$@tsinghua.edu.cn> Accept-Language: nl-NL, nl-BE, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_626d708fa5b94a238efcd5c50e29dbdaEXMBX31adutwentenl_" MIME-Version: 1.0 X-Bayes-Prob: 0.495 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMJjhLib - 9706157d71d0 - 20140831 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/supa/iyw_vCj2qrMD9Y9e_3zkTa6u2ho Subject: Re: [Supa] Discussion on SUPA draft chatter X-BeenThere: supa@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 07:17:55 -0000 --_000_626d708fa5b94a238efcd5c50e29dbdaEXMBX31adutwentenl_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jun, Thank you very much for your email! Please note that we are working on providing preliminary versions of drafts= that are providing the information associated with these milestones. Please also note that in order to show why the SUPA activity is useful for = the IETF community we are also working on a state of the art/gap analysis. Best regards, Georgios ________________________________ Van: Supa namens Jun Bi Verzonden: zaterdag 30 augustus 2014 20:42 Aan: supa@ietf.org Onderwerp: [Supa] Discussion on SUPA draft chatter Hi all, I would like to trigger the discussion on SUPA charter. The latest version of SUPA draft charter I received is below. I would ask questions about items in milestones, may I ask, I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. What specific technologies the =93mapping=94 here means ? Do we have an exa= mple ? I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. What would be included into this protocol specification ? Thanks, Jun SUPA (Shared Unified Policy Automation) charter Target Area: Description of Working Group: Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can= be realized using a network service graph. A network service graph is a gr= aph specified by a Network Service Provider that defines how one or more ne= twork services are applied to traffic flowing through a set of nodes of the= graph, which includes attributes such as: o) network topology, based on I2RS, SFC based network topologies and repres= ented by a graph of links and nodes o) service functions (e.g., policing function, NAT, Firewall, DNS, DHCP) an= d their interdependencies o) mapping between service function (and their service function interdepend= encies) and network topology (similar to ALTO mapping) o) application based policies (actions and access policies) generated by ne= twork service systems to map the network service graph instance into specif= ic network management policies, i.e., into device level configuration model= s. Such application based demands are: *) Configuration types: o) request to dynamically configure a node o) request to place a service function on a network function *) Data plane types: o) request to steer a traffic flow o) request prioritize a traffic flow o) request to encapsulate/de-capsulate a traffic flow o) request block or admit a traffic flow *) Control plane / Routing plane types: o) request to change the routing state on a network function Network services are enhanced Operational Support System (OSS) services tha= t help a communication service provider to monitor, control, analyze and ma= nage a communication network. In this context, network services can be used= to provide the required configuration and application programming interfac= es to network service developers. Subsequently, a network service can use t= he service based demands and possibly update its associated network service= graph. The main goal of SUPA is to provide application based policies and means to= model and program the abstract view of network infrastructure and service = function interdependencies in order to support and feed network management = and controlling policies (e.g., dynamic network configuration, I2RS routing= strategies). This can be realized by: (1) modeling the network service graph, which among others include applicat= ion based policies, using YANG, (2) applying NETCONF (or RESTCONF) to enable dissemination of up to date (f= resh) network service graphs in a secure and efficient manner between netwo= rk service systems and network management and controlling systems, (3) providing guidelines on mapping attributes of network service graphs pr= ovided by network service systems into specific network management and cont= rolling policies. Work items related to SUPA include: o) specify the network service graph based on YANG models o) specify and standardize how NETCONF/YANG (or RESTCONF/YANG) can be used = to securely and efficiently distribute up to date (fresh) network service g= raphs between network service systems and network management and controllin= g systems o) provide guidelines for mechanisms that can dynamically map attributes, i= ncluding application based policies, of network service graphs into specifi= c network management and controlling policies, such as dynamic network conf= iguration, I2RS routing strategies o) document how to use NETCONF (or RESTCONF) authentication and authorizati= on mechanisms to achieve protection and isolation The following items are out of the SUPA scope: o) specification of the network management and controlling policies and the= ir associated device configuration models Milestones: I-D 'Problem Statement and Use Cases' as an Informational RFC. I-D 'Guidelines on mapping network service graphs into specific network management and controlling policies' as an Informational RFC. I-D 'Guidelines on using NETCONF (or RESTCONF) authentication and authorization mechanisms to achieve security protection and isolation' as an Informational RFC. I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Protocol Specification' Standards Track RFC. --_000_626d708fa5b94a238efcd5c50e29dbdaEXMBX31adutwentenl_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Jun,

 

Thank you very much for your email!

Please note that we are working on providing preliminary versions of dra= fts that are providing the information associated with these milestones.

 

Please also note that in order to show why the SUPA activity is useful f= or the IETF community we are also working on a state of the art/gap analysi= s.

 

Best regards,

Georgios

Van: Supa <supa-bounce= s@ietf.org> namens Jun Bi <junbi@tsinghua.edu.cn>
Verzonden: zaterdag 30 augustus 2014 20:42
Aan: supa@ietf.org
Onderwerp: [Supa] Discussion on SUPA draft chatter
 

Hi all,

 

I would like to trigger the discussion on SUPA charter.

 

The latest version of SUPA draft charter I received is below.<= /p>

 

I would ask questions about items in milestones, may I ask,

 

    I-D 'Guidelines on mapping network serv= ice graphs into specific network 

    management and controlling policie= s' as an Informational RFC.

 

What specific technologies the =93mapping=94 here means ? Do we have = an example ?

 


    I-D 'SUPA NETCONF/YANG (or RESTCONF/YANG) model and Pro= tocol

    Specification' Standards Track RFC= .

 

What would be included into this protocol specification  ?

 

Thanks,

Jun

 

 

SUPA (Shared Unified Policy Automation) charter

Target Area:

Description of Working Group:

Today network operators are challenged to create an abstract view of their = network infrastructure and help service developers on using and programming= this abstraction rather than manipulating individual devices. An abstract = view of a network infrastructure and service function interdependencies can be realized using a network ser= vice graph. A network service graph is a graph specified by a Network Servi= ce Provider that defines how one or more network services are applied to tr= affic flowing through a set of nodes of the graph, which includes attributes such as:<= /p>

 

o) network topology, based on I2RS, SFC based network topo= logies and represented by a graph of links and nodes

 

o) service functions (e.g., policing function, NAT, Firewa= ll, DNS, DHCP) and their interdependencies

 

o) mapping between service function (and their service fun= ction interdependencies) and network topology (similar to ALTO mapping)

 

o) application based policies (actions and access policies= ) generated by network service systems to map the network service graph ins= tance into specific network management policies, i.e., into device level configuration models. Such application based deman= ds are:

   *) Configuration types:

       o) request to dynamic= ally configure a node

       o) request to place a= service function on a network

         &nbs= p;function

   *) Data plane types:

       o) request to steer a= traffic flow

       o) request prioritize= a traffic flow

       o) request to encapsu= late/de-capsulate a traffic flow

       o) request block or a= dmit a traffic flow

   *) Control plane / Routing plane types:

       o) request to change = the routing state on a network

         &nbs= p;function

Network services are enhanced Operational Support System (= OSS) services that help a communication service provider to monitor, contro= l, analyze and manage a communication network. In this context, network services can be used to provide the required configu= ration and application programming interfaces to network service developers= . Subsequently, a network service can use the service based demands and pos= sibly update its associated network service graph.

 

The main goal of SUPA is to provide application based poli= cies and means to model and program the abstract view of network infrastruc= ture and service function interdependencies in order to support and feed network management and controlling policies (e.g., dyn= amic network configuration, I2RS routing strategies).

This can be realized by:

 

(1) modeling the network service graph, which among others= include application based policies, using YANG,

 

(2) applying NETCONF (or RESTCONF) to enable dissemination= of up to date (fresh) network service graphs in a secure and efficient man= ner between network service systems and network management and controlling systems,

 

(3) providing guidelines on mapping attributes of network = service graphs provided by network service systems into specific network ma= nagement and controlling policies.

 


Work items related to SUPA include:

o) specify the network service graph based on YANG models<= /span>

 

o) specify and standardize how NETCONF/YANG (or RESTCONF/Y= ANG) can be used to securely and efficiently distribute up to date (fresh) = network service graphs between network service systems and network management and controlling systems

 

o) provide guidelines for mechanisms that can dynamically = map attributes, including application based policies, of network service gr= aphs into specific network management and controlling policies, such as dynamic network configuration, I2RS routing strategies

 

o) document how to use NETCONF (or RESTCONF) authenticatio= n and authorization mechanisms to achieve protection and isolation

 

The following items are out of the SUPA scope:

 

o) specification of the network management and controlling= policies and their associated device configuration models

 

Milestones:

    I-D 'Problem Statement and Use Cases' as an Informationa= l RFC.


    I-D 'Guidelines on mapping network service graphs into s= pecific network 

    management and controlling policie= s' as an Informational RFC.

 

    I-D 'Guidelines on using = NETCONF (or RESTCONF) authentication and

    authorization mechan= isms to achieve security protection and isolation'

    as an Informational = RFC.

 

    I-D 'SUPA NETCONF/YANG (or RESTCONF/YAN= G) model and Protocol

    Specification' Standards Track RFC= .

 

--_000_626d708fa5b94a238efcd5c50e29dbdaEXMBX31adutwentenl_--