From nobody Mon Oct 5 05:35:45 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA31ACCE6 for ; Mon, 5 Oct 2015 05:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.754 X-Spam-Level: X-Spam-Status: No, score=-95.754 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] 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 R72LFIY-xs6T for ; Mon, 5 Oct 2015 05:35:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A60801ACCEB for ; Mon, 5 Oct 2015 05:35:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.84.146; From: "Susan Hares" To: References: In-Reply-To: Date: Mon, 5 Oct 2015 08:35:32 -0400 Message-ID: <006f01d0ff6a$53897d00$fa9c7700$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0070_01D0FF48.CC798AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxXZ0XDQXU3m9rhLScoTvDMrdnnJ4cGUtg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Ibnemo] FW: What is service based intent? X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 12:35:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0070_01D0FF48.CC798AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: Could someone help me with service-based intent? Is service-based intent telling the layers what do for services? I'm working on a service layer topology document for I2RS expresses the ephemeral state needs of the service models. The overall service topology is a combination of the services underneath such as L3VPN, L2VPN, and other topologies at a device layer. The L3SM work is proposing a service model. http://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/ I think that the intent layers should be able to signal this service. Can anyone help me with an example? Sue Hares ------=_NextPart_000_0070_01D0FF48.CC798AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

Could someone help me with service-based intent? = Is service-based intent telling the layers what do for = services?

I’m = working on a service layer topology document for I2RS expresses the = ephemeral state needs of the service models. The overall service = topology is a combination of the services underneath such as = L3VPN, L2VPN, and other topologies at a device layer. The = L3SM work is proposing a service model.

http://datatracker.ietf.org/doc/draft-ietf-l3sm-l3vpn-service-model/=

I think that = the intent layers should be able to signal this service. Can = anyone help me with an example?

Sue Hares =

------=_NextPart_000_0070_01D0FF48.CC798AB0-- From nobody Mon Oct 5 05:49:23 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35D31A1A67 for ; Mon, 5 Oct 2015 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 YpYgfeL5x2kJ for ; Mon, 5 Oct 2015 05:49:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C74D1A1A16 for ; Mon, 5 Oct 2015 05:49:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.146; From: "Susan Hares" To: Date: Mon, 5 Oct 2015 08:49:06 -0400 Message-ID: <007c01d0ff6c$392a9ff0$ab7fdfd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01D0FF4A.B21B22D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdD/aqmyUp7sg4w4RXmPgeaWSWaBvA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 12:49:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007D_01D0FF4A.B21B22D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: Can all policies be expressed an Intent? I'm trying to determine what policies can or cannot be expressed. Any example would be helpful. Here's three policies I'd like to discuss: 1) Traffic flow policies 2) BGP policies for route flow 3) Policy filters controlling routes, I'm working on the I2RS extensions for Filter-Based RIB and BGP (normal and flow filters). The I2RS Filter-based RIB allow for policies for routing (forwarding a layer 3) to be associated with a set of interfaces. For example, Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 And the rest get forwarded to the default RIB which 128/8 nexthop 128.2.1.3 The intent is that customer 1 has 128.2/16, and customer 2 has 128.5.1/24. This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3). All other traffic goes to the Internet. How do I link this to the normal example of Intent? Can we render intent down to this level or should I be using a higher level? Sue Hares ------=_NextPart_000_007D_01D0FF4A.B21B22D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

Can all policies be expressed an Intent? = I’m trying to determine what policies can or cannot be = expressed. Any example would be helpful.

Here’s = three policies I’d like to discuss:

1) = Traffic flow policies =

2) = BGP policies for route flow

3) = Policy filters controlling routes, =

I’m working on the I2RS extensions for = Filter-Based RIB and BGP (normal and flow filters). = The I2RS Filter-based RIB allow for policies for = routing (forwarding a layer 3) to be associated with a set of = interfaces. For example,

Forwarding = filter 1: 128.2/16 nexthop 128.2.1.1 =

Forwarding = filters 2: 128.5.1/24 nexthop 128.2.1.2 =

And the rest get forwarded to the default RIB which =

&= nbsp; 128/8 nexthop = 128.2.1.3

The intent is that customer 1 has 128.2/16, and = customer 2 has 128.5.1/24. This node links to these VPNs via = 128.2.1.1 (customer1), and 128.2.1.2 (customer 3). All other = traffic goes to the Internet.

How do I = link this to the normal example of Intent? Can we render = intent down to this level or should I be using a higher level? =

Sue Hares

------=_NextPart_000_007D_01D0FF4A.B21B22D0-- From nobody Mon Oct 5 07:49:36 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B051ACE9F for ; Mon, 5 Oct 2015 07:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 DJ57o3rb44Dy for ; Mon, 5 Oct 2015 07:49:31 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E18D1ACE90 for ; Mon, 5 Oct 2015 07:49:29 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C3D89E014B; Mon, 5 Oct 2015 16:49:26 +0200 (CEST) Received: from ESTGVMSP103.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id A2A02E01CD; Mon, 5 Oct 2015 16:49:26 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.50) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Oct 2015 16:49:25 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0638.eurprd06.prod.outlook.com (10.161.13.144) with Microsoft SMTP Server (TLS) id 15.1.280.20; Mon, 5 Oct 2015 14:49:23 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0280.017; Mon, 5 Oct 2015 14:49:23 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Susan Hares , "ibnemo@ietf.org" Thread-Topic: Policies and Intent-Based Networking Thread-Index: AQHQ/30GUp7sg4w4RXmPgeaWSWaBvA== Date: Mon, 5 Oct 2015 14:49:23 +0000 Message-ID: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0638; 5:YnHXxzj3IwY81FzCDnNMIQwlHwOAlaMokUt/bx5lb6SM1+mG7o4Yy6aLJEkKSCmZMjdbtsrkyB92HNHC18IXsZ37vqP5ryKRAFZPPkRn6Y8PVKcKcOwO+NT8VIkaG5gDanxdMj1NzeqvJflBf8mcRw==; 24:DNoZ2rzeg6vmHYuwTU6w0CwIrkHABTZ8H6PJJSUq81VnHx3OBrj+Wlv2BrA8XpdLbj9+4jmRR3b8tIt5GyeE4bkYag0BKFVFYWI2vEuMS20=; 20:fokhf0eD0/OS86yf4RTGw71+X+kEpQg8AtYAIinlD0gCTddix8CoUxT5tshJjUStlqkA5y03sv/0AJr9hJ8EUw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0638; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001); SRVR:DB4PR06MB0638; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0638; x-forefront-prvs: 07200C0526 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(189002)(52604005)(199003)(122556002)(64706001)(36756003)(4001350100001)(5004730100002)(16236675004)(40100003)(2900100001)(50986999)(19580405001)(15187005004)(2501003)(54356999)(68736005)(101416001)(105586002)(77156002)(33656002)(11100500001)(19580395003)(15975445007)(5008740100001)(5002640100001)(10400500002)(189998001)(19300405004)(5001830100001)(575784001)(62966003)(19625215002)(5007970100001)(86362001)(77096005)(5001770100001)(97736004)(5001960100002)(81156007)(66066001)(92566002)(5001860100001)(4001540100001)(106116001)(46102003)(102836002)(82746002)(87936001)(106356001)(83506001)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0638; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CF22CCE751544C9F8E939C1A908DAD77telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2015 14:49:23.3924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0638 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 14:49:35 -0000 --_000_CF22CCE751544C9F8E939C1A908DAD77telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3VlLA0KDQpUaGFua3MgZm9yIGNsYXJpZnlpbmfigKYgdGhpcyBpcyBhIGdvb2QgZm9vZCBm b3IgdGhvdWdodC4gQW5zd2VycyBpbmxpbmXigKYNCg0KL1BBDQoNCkRlOiBTdWUgSGFyZXMNCkZl Y2hhOiBsdW5lcywgNSBkZSBvY3R1YnJlIGRlIDIwMTUsIDE0OjQ5DQpQYXJhOiAiaWJuZW1vQGll dGYub3JnPG1haWx0bzppYm5lbW9AaWV0Zi5vcmc+Ig0KQ0M6ICdaaG91dGlhbnJhbicsICInQmVy dCBXaWpuZW4gKElFVEYpJyIsIHBhYWcNCkFzdW50bzogUG9saWNpZXMgYW5kIEludGVudC1CYXNl ZCBOZXR3b3JraW5nDQoNCkhpIGFsbDoNCg0KQ2FuIGFsbCBwb2xpY2llcyBiZSBleHByZXNzZWQg YW4gSW50ZW50Pw0KDQpPSywgdGhlbiB3ZSBlbmQgdXAgd2l0aCBzb21ldGhpbmcgd2UgZGlkbuKA mXQgcXVpdGUgbGlrZS9hZ3JlZSB1cG9uIGluIFByYWd1ZTogdGhlcmUgYXJlIGRpZmZlcmVudCBw bGF5ZXJzIHdpdGggZGlmZmVyZW50IGludGVyZXN0cyBhbmQgYmFja2dyb3VuZC4gVGhlcmVmb3Jl LCB0aGVyZSB3aWxsIGJlIGRpZmZlcmVudCBpbnRlbnRzIChzY29wZWQgYnkgdGhlIGFjdG9y4oCZ cyB2aWV3IG9mIHRoZSB3b3JsZCkgYW5kIG1heWJlIGRpZmZlcmVudCB3YXlzIG9mIGV4cHJlc3Np bmcgaW50ZW50LCBkZXBlbmRpbmcgb24gdGhlIHVzZXLigJlzIGJhY2tncm91bmQuDQoNCknigJlt IHRyeWluZyB0byBkZXRlcm1pbmUgd2hhdCBwb2xpY2llcyBjYW4gb3IgY2Fubm90IGJlIGV4cHJl c3NlZC4gIEFueSBleGFtcGxlIHdvdWxkIGJlIGhlbHBmdWwuDQoNCkhlcmXigJlzIHRocmVlIHBv bGljaWVzIEnigJlkIGxpa2UgdG8gZGlzY3VzczoNCg0KDQoxKSAgICAgIFRyYWZmaWMgZmxvdyBw b2xpY2llcw0KDQoyKSAgICAgIEJHUCBwb2xpY2llcyBmb3Igcm91dGUgZmxvdw0KDQozKSAgICAg IFBvbGljeSBmaWx0ZXJzIGNvbnRyb2xsaW5nIHJvdXRlcywNCg0KSeKAmW0gd29ya2luZyBvbiB0 aGUgSTJSUyBleHRlbnNpb25zIGZvciBGaWx0ZXItQmFzZWQgUklCIGFuZCBCR1AgKG5vcm1hbCBh bmQgZmxvdyBmaWx0ZXJzKS4gICAgVGhlIEkyUlMgRmlsdGVyLWJhc2VkIFJJQiBhbGxvdyBmb3Ig cG9saWNpZXMgZm9yIHJvdXRpbmcgKGZvcndhcmRpbmcgYSBsYXllciAzKSB0byBiZSBhc3NvY2lh dGVkIHdpdGggYSBzZXQgb2YgaW50ZXJmYWNlcy4gICBGb3IgZXhhbXBsZSwNCg0KRm9yd2FyZGlu ZyBmaWx0ZXIgMTogIDEyOC4yLzE2IG5leHRob3AgMTI4LjIuMS4xDQpGb3J3YXJkaW5nIGZpbHRl cnMgMjogICAxMjguNS4xLzI0IG5leHRob3AgMTI4LjIuMS4yDQoNCkFuZCB0aGUgcmVzdCBnZXQg Zm9yd2FyZGVkIHRvIHRoZSBkZWZhdWx0IFJJQiB3aGljaA0KICAgICAgICAgICAgICAgICAgMTI4 LzggIG5leHRob3AgMTI4LjIuMS4zDQoNClRoZSBpbnRlbnQgIGlzIHRoYXQgY3VzdG9tZXIgMSBo YXMgMTI4LjIvMTYsIGFuZCBjdXN0b21lciAyIGhhcyAxMjguNS4xLzI0LiAgIFRoaXMgbm9kZSBs aW5rcyB0byB0aGVzZSBWUE5zIHZpYSAxMjguMi4xLjEgKGN1c3RvbWVyMSksIGFuZCAxMjguMi4x LjIgKGN1c3RvbWVyIDMpLiAgQWxsIG90aGVyIHRyYWZmaWMgZ29lcyB0byB0aGUgSW50ZXJuZXQu DQpIb3cgZG8gSSBsaW5rIHRoaXMgdG8gdGhlIG5vcm1hbCBleGFtcGxlIG9mIEludGVudD8gICBD YW4gd2UgcmVuZGVyIGludGVudCBkb3duIHRvIHRoaXMgbGV2ZWwgb3Igc2hvdWxkIEkgYmUgdXNp bmcgYSBoaWdoZXIgbGV2ZWw/DQoNCg0KTGV0IG1lIHRyeSBhIGhhbmRzLW9uIGluIE5FTU8gOy0p DQoNClNvIHdlIGhhdmUgdHdvIExpbmtNb2RlbHM6DQoNCkxpbmtNb2RlbCBWUE4gUHJvcGVydHkg SVBQcmVmaXg6bmV4dEhvcCwgSVBQcmVmaXg6ZGVzdGluYXRpb25QcmVmaXg7DQpMaW5rTW9kZWwg SW50ZXJuZXQgUHJvcGVydHkgSVBQcmVmaXg6bmV4dEhvcDsNCg0KQW5kIHRocmVlIExpbmtzDQoN CkxpbmsgVlBOMSBUeXBlIFZQTiBQcm9wZXJ0eSBuZXh0SG9wOuKAnTEyOC4yLjEuMS8zMuKAnSwg ZGVzdGluYXRpb25QcmVmaXg64oCdMTI4LjIvMTbigJ0gOw0KTGluayBWUE4yIFR5cGUgVlBOIFBy b3BlcnR5IG5leHRIb3A64oCdMTI4LjIuMS4yLzMy4oCdLCBkZXN0aW5hdGlvblByZWZpeDrigJ0x MjguNS4xLzI04oCdIDsNCkxpbmsgRGVmYXVsdCBUeXBlIEludGVybmV0IFByb3BlcnR5IG5leHRI b3A64oCdMTI4LjIuMS4zLzMy4oCdIDsNCg0KVGhlbiB3ZSB3b3VsZCBuZWVkIDIgTm9kZU1vZGVs czoNCg0KTm9kZU1vZGVsIFZQTlRlcm1pbmF0aW9uIFByb3BlcnR5IElQUHJlZml4OklELCBsaXN0 KElQUHJlZml4KTogc3VibmV0cyA7DQpOb2RlTW9kZWwgSW50ZXJuZXROb2RlIFByb3BlcnR5IElQ UHJlZml4OklEOw0KDQpBbmQgdGhlbiB0aGUgbm9kZXM6DQoNCk5vZGUgVlBOVGVybWluYXRpb24x IFR5cGUgVlBOVGVybWluYXRpb24gUHJvcGVydHkgSUQ64oCdMTI4LjIuMS4xLzMy4oCdLCBzdWJu ZXRzOuKAnTEyOC4yLzE24oCdIDsNCk5vZGUgVlBOVGVybWluYXRpb24yIFR5cGUgVlBOVGVybWlu YXRpb24gUHJvcGVydHkgSUQ64oCdMTI4LjIuMS4yLzMy4oCdLCBzdWJuZXRzOuKAnTEyOC41LjEv MjTigJ0gOw0KTm9kZSBJbnRlcm5ldEFjY2VzcyBUeXBlIEludGVybmV0Tm9kZSBQcm9wZXJ0eSBJ RDrigJ0xMjguMi4xLjMvMzLigJ0gOw0KDQpBbmQgZmluYWxseSB0aGUgY29ubmVjdGlvbnMgYmV0 d2VlbiB0aGUgbm9kZXM6DQoNCkxpbmsgVlBOMSBUeXBlIFZQTiBFbmROb2RlcyB0aGlzTm9kZSxW UE5UZXJtaW5hdGlvbjEgOw0KTGluayBWUE4yIFR5cGUgVlBOIEVuZE5vZGVzIHRoaXNOb2RlLFZQ TlRlcm1pbmF0aW9uMiA7DQpMaW5rIERlZmF1bHQgVHlwZSBJbnRlcm5ldCBFbmROb2RlcyB0aGlz Tm9kZSxJbnRlcm5ldEFjY2VzcyA7DQoNClNvDQoNCkNvbmNsdXNpb24gbm8uIDE6IFllcyB3ZSBj YW7igKYNCkNvbmNsdXNpb24gbm8uMjogTWF5YmUgYSBiaXQgcmVkdW5kYW50LCByaWdodD8gQnV0 IHRoaXMgY2FuIGFsc28gYmUgcG9zaXRpdmUsIGJlY2F1c2UgaXQgd291bGQgYWxsb3cgZm9yIGEg bG90IG9mIGNvbnNpc3RlbmN5IGNoZWNraW5nIOKApg0KDQpEdW5ubyB3aGF0IG90aGVycyB0aGlu a+KApg0KDQpNeSAuMDIgY2VudHMsDQoNCi0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6ly cmV6DQoNClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJbm5vdmF0aW9uICYgVmly dHVhbGlzYXRpb24NCmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBj b20NClRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8NCkMvIFp1cmJhcsOh biwxMg0KMjgwMTAgTWFkcmlkLCBTcGFpbg0KDQpGcmFnZW4gc2luZCBuaWNodCBkYSwgdW0gYmVh bnR3b3J0ZXQgenUgd2VyZGVuLg0KRnJhZ2VuIHNpbmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRl bi4NCkdlb3JnIEtyZWlzbGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUg YSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lh ZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBv IGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRp Y2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uDQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24g aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0 aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBu b3QgcmVhZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVs ZXRlIGl0Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNp dmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHBy aXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVz c29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBk ZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwg dXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28g cG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBT ZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBj b211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3Vh IGRlc3RydWnDp8Ojbw0K --_000_CF22CCE751544C9F8E939C1A908DAD77telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <47025AD66E363E4CA45A629B0F0E7459@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQpIaSBTdWUsPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQpUaGFua3MgZm9yIGNsYXJpZnlpbmfigKYgdGhpcyBpcyBhIGdvb2QgZm9vZCBmb3Ig dGhvdWdodC4gQW5zd2VycyBpbmxpbmXigKY8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij4NCi9QQTwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIg c3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBN UycsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBB RERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47 IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25l OyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EZTog PC9zcGFuPlN1ZSBIYXJlczxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5GZWNo YTogPC9zcGFuPmx1bmVzLCA1IGRlIG9jdHVicmUgZGUgMjAxNSwgMTQ6NDk8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UGFyYTogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0 bzppYm5lbW9AaWV0Zi5vcmciPmlibmVtb0BpZXRmLm9yZzwvYT4mcXVvdDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q0M6IDwvc3Bhbj4nWmhvdXRpYW5yYW4nLCAmcXVvdDsn QmVydCBXaWpuZW4gKElFVEYpJyZxdW90OywgcGFhZzxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Bc3VudG86IDwvc3Bhbj5Qb2xpY2llcyBhbmQgSW50ZW50LUJhc2VkIE5ldHdv cmtpbmcNCjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4 bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQu Y29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMg Ki8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjE1Nzg1MTUzODQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xMzU2Mzc0MTAgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIGFsbDogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiBhbGwgcG9saWNpZXMg YmUgZXhwcmVzc2VkIGFuIEludGVudD88L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQpPSywgdGhlbiB3ZSBlbmQgdXAgd2l0aCBzb21ldGhpbmcgd2UgZGlkbuKAmXQgcXVpdGUgbGlr ZS9hZ3JlZSB1cG9uIGluIFByYWd1ZTogdGhlcmUgYXJlIGRpZmZlcmVudCBwbGF5ZXJzIHdpdGgg ZGlmZmVyZW50IGludGVyZXN0cyBhbmQgYmFja2dyb3VuZC4gVGhlcmVmb3JlLCB0aGVyZSB3aWxs IGJlIGRpZmZlcmVudCBpbnRlbnRzIChzY29wZWQgYnkgdGhlIGFjdG9y4oCZcyB2aWV3IG9mIHRo ZSB3b3JsZCkgYW5kIG1heWJlIGRpZmZlcmVudCB3YXlzIG9mDQogZXhwcmVzc2luZyBpbnRlbnQs IGRlcGVuZGluZyBvbiB0aGUgdXNlcuKAmXMgYmFja2dyb3VuZC48L2Rpdj4NCjxkaXYgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxi bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i Qk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAw IDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1s bnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2No ZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJltIHRyeWluZyB0byBkZXRlcm1pbmUgd2hhdCBwb2xpY2llcyBjYW4gb3IgY2Fu bm90IGJlIGV4cHJlc3NlZC4mbmJzcDsgQW55IGV4YW1wbGUgd291bGQgYmUgaGVscGZ1bC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZeKAmXMgdGhyZWUgcG9saWNpZXMgSeKAmWQgbGlrZSB0 byBkaXNjdXNzOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhLS1baWYgIXN1cHBvcnRMaXN0 c10tLT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBm b250LXNpemU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhLS1bZW5kaWZdLS0+VHJhZmZpYyBmbG93IHBvbGljaWVzICZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNp emU6IDdwdDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhLS1b ZW5kaWZdLS0+QkdQIHBvbGljaWVzIGZvciByb3V0ZSBmbG93IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXNpemU6IDdwdDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nOyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhLS1bZW5kaWZdLS0+UG9s aWN5IGZpbHRlcnMgY29udHJvbGxpbmcgcm91dGVzLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SeKAmW0gd29ya2luZyBvbiB0aGUgSTJSUyBleHRlbnNpb25zIGZvciBGaWx0ZXItQmFzZWQgUklC IGFuZCBCR1AgKG5vcm1hbCBhbmQgZmxvdyBmaWx0ZXJzKS4gJm5ic3A7Jm5ic3A7Jm5ic3A7VGhl IEkyUlMgRmlsdGVyLWJhc2VkIFJJQiBhbGxvdyBmb3IgcG9saWNpZXMgZm9yIHJvdXRpbmcgKGZv cndhcmRpbmcgYSBsYXllciAzKSB0byBiZSBhc3NvY2lhdGVkIHdpdGggYSBzZXQgb2YgaW50ZXJm YWNlcy4mbmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGUsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Rm9yd2FyZGluZyBmaWx0ZXIgMTombmJzcDsgMTI4LjIvMTYgbmV4dGhvcCAxMjguMi4xLjEgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Gb3J3YXJkaW5nIGZpbHRlcnMgMjombmJzcDsmbmJzcDsgMTI4LjUuMS8yNCBuZXh0aG9wIDEy OC4yLjEuMiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoZSByZXN0IGdldCBm b3J3YXJkZWQgdG8gdGhlIGRlZmF1bHQgUklCIHdoaWNoIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7MTI4LzgmbmJzcDsgbmV4dGhvcCAxMjguMi4xLjMgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBpbnRlbnQgJm5ic3A7aXMgdGhhdCBjdXN0b21lciAxIGhhcyAxMjguMi8xNiwg YW5kIGN1c3RvbWVyIDIgaGFzIDEyOC41LjEvMjQuJm5ic3A7ICZuYnNwO1RoaXMgbm9kZSBsaW5r cyB0byB0aGVzZSBWUE5zIHZpYSAxMjguMi4xLjEgKGN1c3RvbWVyMSksIGFuZCAxMjguMi4xLjIg KGN1c3RvbWVyIDMpLiZuYnNwOyBBbGwgb3RoZXIgdHJhZmZpYyBnb2VzIHRvIHRoZSBJbnRlcm5l dC48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PHNw YW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIg eG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPkhvdyBkbyBJIGxpbmsgdGhpcyB0byB0aGUgbm9ybWFs IGV4YW1wbGUgb2YgSW50ZW50PyZuYnNwOyAmbmJzcDtDYW4gd2UgcmVuZGVyIGludGVudCBkb3du IHRvIHRoaXMgbGV2ZWwgb3Igc2hvdWxkIEkgYmUgdXNpbmcgYSBoaWdoZXIgbGV2ZWw/PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29k ZSBNUycsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUg TVMnLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCkxldCBtZSB0cnkgYSBoYW5kcy1v biBpbiBORU1PIDstKSZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPg0KU28gd2UgaGF2ZSB0d28gTGlua01vZGVsczo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyI+PGZvbnQgZmFjZT0iTW9uYWNvIj5MaW5rTW9kZWwgVlBOIFByb3Bl cnR5IElQUHJlZml4Om5leHRIb3AsIElQUHJlZml4OmRlc3RpbmF0aW9uUHJlZml4OzwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48Zm9udCBmYWNlPSJNb25h Y28iPkxpbmtNb2RlbCBJbnRlcm5ldCBQcm9wZXJ0eSBJUFByZWZpeDpuZXh0SG9wOzwvZm9udD48 L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7Ij48Zm9udCBmYWNlPSJNb25h Y28iPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij5BbmQgdGhyZWUgTGlua3M8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 Ij48Zm9udCBmYWNlPSJNb25hY28iPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iTW9uYWNvIj5MaW5rIFZQTjEgVHlwZSBWUE4gUHJvcGVydHkgbmV4dEhvcDrigJ0xMjguMi4x LjEvMzLigJ0sJm5ic3A7ZGVzdGluYXRpb25QcmVmaXg64oCdMTI4LjIvMTbigJ0gOzwvZm9udD48 L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9Ik1vbmFjbyI+TGluayBWUE4yIFR5cGUgVlBO IFByb3BlcnR5IG5leHRIb3A64oCdMTI4LjIuMS4yLzMy4oCdLCZuYnNwO2Rlc3RpbmF0aW9uUHJl Zml4OuKAnTEyOC41LjEvMjTigJ0gOzwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iTW9u YWNvIj5MaW5rIERlZmF1bHQgVHlwZSBJbnRlcm5ldCBQcm9wZXJ0eSBuZXh0SG9wOuKAnTEyOC4y LjEuMy8zMuKAnSA7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMt c2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7Ij48YnI+DQo8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDE1cHg7Ij5UaGVuIHdlIHdvdWxkIG5lZWQgMiBOb2RlTW9kZWxzOjwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTVweDsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9Ik1vbmFjbyI+Tm9kZU1vZGVsIFZQTlRlcm1pbmF0aW9uIFByb3BlcnR5 IElQUHJlZml4OklELCBsaXN0KElQUHJlZml4KTogc3VibmV0cyA7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJNb25hY28iPk5vZGVNb2RlbCBJbnRlcm5ldE5vZGUgUHJvcGVydHkgSVBQ cmVmaXg6SUQ7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE1cHg7Ij48YnI+DQo8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDE1cHg7Ij5BbmQgdGhlbiB0aGUgbm9kZXM6PC9zcGFuPjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxNXB4OyI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i TW9uYWNvIj5Ob2RlIFZQTlRlcm1pbmF0aW9uMSBUeXBlIFZQTlRlcm1pbmF0aW9uIFByb3BlcnR5 IElEOuKAnTEyOC4yLjEuMS8zMuKAnSwgc3VibmV0czrigJ0xMjguMi8xNuKAnSA7PC9mb250Pjwv ZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29s b3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxl ZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBw eCAwcHggNXB4OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1s IiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5z Onc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6 Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+PGZvbnQgZmFjZT0iTW9uYWNvIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+PC9kaXY+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxmb250IGZhY2U9Ik1vbmFjbyI+Tm9kZSBWUE5UZXJt aW5hdGlvbjIgVHlwZSZuYnNwOzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IE1vbmFj bzsiPlZQTlRlcm1pbmF0aW9uIFByb3BlcnR5IElEPC9zcGFuPjxmb250IGZhY2U9Ik1vbmFjbyI+ OuKAnTEyOC4yLjEuMi8zMuKAnSwmbmJzcDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBNb25hY287Ij5zdWJuZXRzPC9zcGFuPjxmb250IGZhY2U9Ik1vbmFjbyI+OuKAnTEyOC41LjEv MjTigJ0gOzwvZm9udD48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBNb25h Y287Ij5Ob2RlPC9zcGFuPjxmb250IGZhY2U9Ik1vbmFjbyI+Jm5ic3A7SW50ZXJuZXRBY2Nlc3Mg VHlwZSBJbnRlcm5ldE5vZGUgUHJvcGVydHkgSUQ64oCdMTI4LjIuMS4zLzMy4oCdIDs8L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iTW9uYWNvIj48YnI+DQo8L2ZvbnQ+PC9k aXY+DQo8ZGl2PkFuZCBmaW5hbGx5IHRoZSBjb25uZWN0aW9ucyBiZXR3ZWVuIHRoZSBub2Rlczo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pjxmb250 IGZhY2U9Ik1vbmFjbyI+TGluayBWUE4xIFR5cGUgVlBOIEVuZE5vZGVzIHRoaXNOb2RlLFZQTlRl cm1pbmF0aW9uMSA7PC9mb250PjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBz dHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLWxlZnQt d2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAwcHggMHB4IDBw eCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGRpdiBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+PGZvbnQgZmFjZT0iTW9uYWNv Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PC9kaXY+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJNb25hY28iPkxpbmsgVlBOMiBUeXBlIFZQTiBFbmROb2RlcyB0aGlzTm9k ZSxWUE5UZXJtaW5hdGlvbjIgOzwvZm9udD48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IGJvcmRl ci1sZWZ0LXdpZHRoOiA1cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZzogMHB4 IDBweCAwcHggNXB4OyBtYXJnaW46IDBweCAwcHggMHB4IDVweDsiPg0KPGRpdiB4bWxuczp2PSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmlj ZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4N CjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxmb250IGZhY2U9 Ik1vbmFjbyI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjwvZGl2Pg0KPC9mb250PjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRp dj4NCjxkaXY+PGZvbnQgZmFjZT0iTW9uYWNvIj5MaW5rIERlZmF1bHQgVHlwZSBJbnRlcm5ldCBF bmROb2RlcyB0aGlzTm9kZSxJbnRlcm5ldEFjY2VzcyA7PC9mb250PjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRS SUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5 NiwgMjIzKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlk OyBwYWRkaW5nOiAwcHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8 ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jv c29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RS L1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+PGZvbnQgZmFjZT0iTW9uYWNvIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PC9kaXY+ DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjxk aXY+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+U28mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNvbmNsdXNpb24gbm8uIDE6IFllcyB3 ZSBjYW7igKYmbmJzcDs8L2Rpdj4NCjxkaXY+Q29uY2x1c2lvbiBuby4yOiBNYXliZSBhIGJpdCBy ZWR1bmRhbnQsIHJpZ2h0PyBCdXQgdGhpcyBjYW4gYWxzbyBiZSBwb3NpdGl2ZSwgYmVjYXVzZSBp dCB3b3VsZCBhbGxvdyBmb3IgYSBsb3Qgb2YgY29uc2lzdGVuY3kgY2hlY2tpbmcg4oCmPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5EdW5ubyB3aGF0IG90aGVycyB0aGlua+KApjwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgLjAyIGNlbnRzLDwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij4tLS08L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5E ci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5UZWNobm9sb2d5 IEV4cGxvcmF0aW9uIC08L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsg Zm9udC1zaXplOiBtZWRpdW07Ij5OZXR3b3JrIElubm92YXRpb24gJmFtcDsgVmlydHVhbGlzYXRp b248L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBt ZWRpdW07Ij5lbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBkMHQgY29tPC9k aXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVt OyI+VGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbzwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkMvIFp1cmJh csOhbiwxMjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNp emU6IG1lZGl1bTsiPjI4MDEwIE1hZHJpZCwgU3BhaW48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5GcmFnZW4g c2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkZyYWdlbiBzaW5k IGRhLCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWls eTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+R2VvcmcgS3JlaXNsZXI8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48YnI+ DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFk YSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8g ZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGlj YWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOzbiwg ZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9o aWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlk byBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVl IGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1 Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFu c21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVu ZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwN CiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0 bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4g ZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNl bmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBh bmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9z IHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29u dGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1 c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOp IHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRv IGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7Nw aWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxl Z2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJv Z2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNt YSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_CF22CCE751544C9F8E939C1A908DAD77telefonicacom_-- From nobody Mon Oct 5 08:36:05 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84ED41B317E for ; Mon, 5 Oct 2015 08:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 PUPtYROSJk1z for ; Mon, 5 Oct 2015 08:36:00 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8161B2A1B for ; Mon, 5 Oct 2015 08:35:59 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 41024A68DCE4E; Mon, 5 Oct 2015 15:35:54 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t95FZrOK017340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Oct 2015 17:35:56 +0200 Received: from [172.27.205.161] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 5 Oct 2015 17:35:52 +0200 To: PEDRO ANDRES ARANDA GUTIERREZ , Susan Hares , "ibnemo@ietf.org" References: From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France Message-ID: <561298D8.8050200@alcatel-lucent.com> Date: Mon, 5 Oct 2015 17:35:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010908000900050809020707" X-Originating-IP: [135.239.27.41] Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:36:03 -0000 --------------010908000900050809020707 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Hello, My naive opinion on the topic would be as follows: -Can all policies be expressed as an Intent? Yes, in the sense that Intent is the "mother" of all policies; this is what the user initially wants the system to achieve. -Should all policies be expressed as Intent? Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the majority of policy-based systems does). A key, hidden point is the policy continuum: 1)-at which level of abstraction the policy starts, 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform), 3)-what mechanisms exist to translate from 1) to 2), taking into account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..) Wrt. Sue's example, I would see an intent-policy defined as: "Steer customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right gateways, etc.) HTH, best regards, Laurent. On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote: > Hi Sue, > > Thanks for clarifying� this is a good food for thought. Answers inline� > > /PA > > De: Sue Hares > Fecha: lunes, 5 de octubre de 2015, 14:49 > Para: "ibnemo@ietf.org " > CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag > Asunto: Policies and Intent-Based Networking > > Hi all: > > Can all policies be expressed an Intent? > > > OK, then we end up with something we didn�t quite like/agree upon in > Prague: there are different players with different interests and > background. Therefore, there will be different intents (scoped by the > actor�s view of the world) and maybe different ways of expressing > intent, depending on the user�s background. > > I�m trying to determine what policies can or cannot be expressed. > Any example would be helpful. > > Here�s three policies I�d like to discuss: > > 1)Traffic flow policies > > 2)BGP policies for route flow > > 3)Policy filters controlling routes, > > I�m working on the I2RS extensions for Filter-Based RIB and BGP > (normal and flow filters). The I2RS Filter-based RIB allow for > policies for routing (forwarding a layer 3) to be associated with > a set of interfaces. For example, > > Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 > > Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 > > And the rest get forwarded to the default RIB which > > 128/8 nexthop 128.2.1.3 > > The intent is that customer 1 has 128.2/16, and customer 2 has > 128.5.1/24. This node links to these VPNs via 128.2.1.1 > (customer1), and 128.2.1.2 (customer 3). All other traffic goes > to the Internet. > > How do I link this to the normal example of Intent? Can we > render intent down to this level or should I be using a higher level? > > > > Let me try a hands-on in NEMO ;-) > > So we have two LinkModels: > > LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; > LinkModel Internet Property IPPrefix:nextHop; > > And three Links > > Link VPN1 Type VPN Property > nextHop:�128.2.1.1/32�, destinationPrefix:�128.2/16� ; > Link VPN2 Type VPN Property > nextHop:�128.2.1.2/32�, destinationPrefix:�128.5.1/24� ; > Link Default Type Internet Property nextHop:�128.2.1.3/32� ; > > Then we would need 2 NodeModels: > > NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ; > NodeModel InternetNode Property IPPrefix:ID; > > And then the nodes: > > Node VPNTermination1 Type VPNTermination Property ID:�128.2.1.1/32�, > subnets:�128.2/16� ; > > Node VPNTermination2 Type VPNTermination Property ID:�128.2.1.2/32�, > subnets:�128.5.1/24� ; > Node InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ; > > And finally the connections between the nodes: > > Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; > > Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; > > Link Default Type Internet EndNodes thisNode,InternetAccess ; > > > So > > Conclusion no. 1: Yes we can� > Conclusion no.2: Maybe a bit redundant, right? But this can also be > positive, because it would allow for a lot of consistency checking � > > Dunno what others think� > > My .02 cents, > > --- > Dr. Pedro A. Aranda Guti�rrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telef�nica, Investigaci�n y Desarrollo > C/ Zurbar�n,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > ------------------------------------------------------------------------ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener informaci�n privilegiada o confidencial y > es para uso exclusivo de la persona o entidad de destino. Si no es > usted. el destinatario indicado, queda notificado de que la lectura, > utilizaci�n, divulgaci�n y/o copia sin autorizaci�n puede estar > prohibida en virtud de la legislaci�n vigente. Si ha recibido este > mensaje por error, le rogamos que nos lo comunique inmediatamente por > esta misma v�a y proceda a su destrucci�n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual > or entity named above. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. > If you have received this transmission in error, do not read it. > Please immediately reply to the sender that you have received this > communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat�rio, pode conter informa��o privilegiada ou confidencial e � > para uso exclusivo da pessoa ou entidade de destino. Se n�o � vossa > senhoria o destinat�rio indicado, fica notificado de que a leitura, > utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode estar proibida > em virtude da legisla��o vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destrui��o > > > _______________________________________________ > Ibnemo mailing list > Ibnemo@ietf.org > https://www.ietf.org/mailman/listinfo/ibnemo -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------010908000900050809020707 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Hello,

My naive opinion on the topic would be as follows:
�� -Can all policies be expressed as an Intent?
�� Yes, in the sense that Intent is the "mother" of all policies; this is what the user initially wants the system to achieve.

�� -Should all policies be expressed as Intent?
�� Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the majority of policy-based systems does).

A key, hidden point is the policy continuum:
�� 1)-at which level of abstraction the policy starts,
�� 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform),
�� 3)-what mechanisms exist to translate from 1) to 2), taking into account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..)

Wrt. Sue's example, I would see an intent-policy defined as: "Steer customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right gateways, etc.)

HTH, best regards, Laurent.

On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote:

Hi Sue,

Thanks for clarifying� this is a good food for thought. Answers inline�

/PA

De: Sue Hares
Fecha: lunes, 5 de octubre de 2015, 14:49
Para: "ibnemo@ietf.org"
CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: Policies and Intent-Based Networking

Hi all:

�

Can all policies be expressed an Intent?

OK, then we end up with something we didn�t quite like/agree upon in Prague: there are different players with different interests and background. Therefore, there will be different intents (scoped by the actor�s view of the world) and maybe different ways of expressing intent, depending on the user�s background.

I�m trying to determine what policies can or cannot be expressed.� Any example would be helpful.

�

Here�s three policies I�d like to discuss:

�

1)�� Traffic flow policies ��

2)�� BGP policies for route flow

3)�� Policy filters controlling routes,

�

I�m working on the I2RS extensions for Filter-Based RIB and BGP (normal and flow filters). ��The I2RS Filter-based RIB allow for policies for routing (forwarding a layer 3) to be associated with a set of interfaces.� �For example,

�

Forwarding filter 1:� 128.2/16 nexthop 128.2.1.1 ��

Forwarding filters 2:�� 128.5.1/24 nexthop 128.2.1.2 �

�

And the rest get forwarded to the default RIB which

��128/8� nexthop 128.2.1.3

�

The intent �is that customer 1 has 128.2/16, and customer 2 has 128.5.1/24.� �This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3).� All other traffic goes to the Internet.

How do I link this to the normal example of Intent?� �Can we render intent down to this level or should I be using a higher level?

Let me try a hands-on in NEMO ;-)�

So we have two LinkModels:

LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix;

LinkModel Internet Property IPPrefix:nextHop;

And three Links

Link VPN1 Type VPN Property nextHop:�128.2.1.1/32�,�destinationPrefix:�128.2/16� ;

Link VPN2 Type VPN Property nextHop:�128.2.1.2/32�,�destinationPrefix:�128.5.1/24� ;

Link Default Type Internet Property nextHop:�128.2.1.3/32� ;

Then we would need 2 NodeModels:

NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ;

NodeModel InternetNode Property IPPrefix:ID;

And then the nodes:

Node VPNTermination1 Type VPNTermination Property ID:�128.2.1.1/32�, subnets:�128.2/16� ;

Node VPNTermination2 Type�VPNTermination Property ID:�128.2.1.2/32�,�subnets:�128.5.1/24� ;

Node�InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ;

And finally the connections between the nodes:

Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;

Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;

Link Default Type Internet EndNodes thisNode,InternetAccess ;

So�

Conclusion no. 1: Yes we can��

Conclusion no.2: Maybe a bit redundant, right? But this can also be positive, because it would allow for a lot of consistency checking �

Dunno what others think�

My .02 cents,

---

Dr. Pedro A. Aranda Guti�rrez

Technology Exploration -

Network Innovation & Virtualisation

email: pedroa d0t aranda At telefonica d0t com

Telef�nica, Investigaci�n y Desarrollo

C/ Zurbar�n,12

28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.

Fragen sind da, um gestellt zu werden.

Georg Kreisler

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci�n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia sin autorizaci�n puede estar prohibida en virtud de la legislaci�n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v�a y proceda a su destrucci�n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat�rio, pode conter informa��o privilegiada ou confidencial e � para uso exclusivo da pessoa ou entidade de destino. Se n�o � vossa senhoria o destinat�rio indicado, fica notificado de que a leitura, utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode estar proibida em virtude da legisla��o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui��o
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org
https://www.ietf.org/mailman/listinfo/ibnemo

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------010908000900050809020707-- From nobody Mon Oct 5 11:53:13 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4E11B3360 for ; Mon, 5 Oct 2015 11:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] 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 eVBz5VFHJR3o for ; Mon, 5 Oct 2015 11:53:08 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E69F1B3366 for ; Mon, 5 Oct 2015 11:53:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.146; From: "Susan Hares" To: "'PEDRO ANDRES ARANDA GUTIERREZ'" , References: In-Reply-To: Date: Mon, 5 Oct 2015 14:53:00 -0400 Message-ID: <005901d0ff9f$0ed24a90$2c76dfb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01D0FF7D.87C53E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYi6VW8yTYlY6yo4uGSUI9ifSYBJ5OJj5A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:53:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005A_01D0FF7D.87C53E70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Pedro:=20 =20 I agree that: =20 a) We can expresse the policy-based routing (l3 forwarding).=20 b) IB-nemo provides a lot of consistency checking for the routes.=20 =20 Does this make easier for the network administrator to configure the = routes? How can Intent make that work easier?=20 =20 Sue=20 =20 From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of PEDRO ANDRES = ARANDA GUTIERREZ Sent: Monday, October 05, 2015 10:49 AM To: Susan Hares; ibnemo@ietf.org Subject: Re: [Ibnemo] Policies and Intent-Based Networking =20 Hi Sue, =20 Thanks for clarifying=E2=80=A6 this is a good food for thought. Answers = inline=E2=80=A6 =20 /PA =20 De: Sue Hares Fecha: lunes, 5 de octubre de 2015, 14:49 Para: "ibnemo@ietf.org" CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag Asunto: Policies and Intent-Based Networking=20 =20 Hi all:=20 =20 Can all policies be expressed an Intent? =20 OK, then we end up with something we didn=E2=80=99t quite like/agree = upon in Prague: there are different players with different interests and = background. Therefore, there will be different intents (scoped by the = actor=E2=80=99s view of the world) and maybe different ways of = expressing intent, depending on the user=E2=80=99s background. =20 I=E2=80=99m trying to determine what policies can or cannot be = expressed. Any example would be helpful. =20 Here=E2=80=99s three policies I=E2=80=99d like to discuss:=20 =20 1) Traffic flow policies =20 2) BGP policies for route flow=20 3) Policy filters controlling routes,=20 =20 I=E2=80=99m working on the I2RS extensions for Filter-Based RIB and BGP = (normal and flow filters). The I2RS Filter-based RIB allow for = policies for routing (forwarding a layer 3) to be associated with a set = of interfaces. For example,=20 =20 Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 =20 Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 =20 =20 And the rest get forwarded to the default RIB which=20 128/8 nexthop 128.2.1.3=20 =20 The intent is that customer 1 has 128.2/16, and customer 2 has = 128.5.1/24. This node links to these VPNs via 128.2.1.1 (customer1), = and 128.2.1.2 (customer 3). All other traffic goes to the Internet. How do I link this to the normal example of Intent? Can we render = intent down to this level or should I be using a higher level? =20 =20 Let me try a hands-on in NEMO ;-)=20 =20 So we have two LinkModels: =20 LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; LinkModel Internet Property IPPrefix:nextHop; =20 And three Links =20 Link VPN1 Type VPN Property nextHop:=E2=80=9D128.2.1.1/32=E2=80=9D, = destinationPrefix:=E2=80=9D128.2/16=E2=80=9D ; Link VPN2 Type VPN Property nextHop:=E2=80=9D128.2.1.2/32=E2=80=9D, = destinationPrefix:=E2=80=9D128.5.1/24=E2=80=9D ; Link Default Type Internet Property = nextHop:=E2=80=9D128.2.1.3/32=E2=80=9D ; =20 Then we would need 2 NodeModels: =20 NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ; NodeModel InternetNode Property IPPrefix:ID; =20 And then the nodes: =20 Node VPNTermination1 Type VPNTermination Property = ID:=E2=80=9D128.2.1.1/32=E2=80=9D, subnets:=E2=80=9D128.2/16=E2=80=9D ; Node VPNTermination2 Type VPNTermination Property = ID:=E2=80=9D128.2.1.2/32=E2=80=9D, subnets:=E2=80=9D128.5.1/24=E2=80=9D = ; Node InternetAccess Type InternetNode Property = ID:=E2=80=9D128.2.1.3/32=E2=80=9D ; =20 And finally the connections between the nodes: =20 Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; Link Default Type Internet EndNodes thisNode,InternetAccess ; =20 So=20 =20 Conclusion no. 1: Yes we can=E2=80=A6=20 Conclusion no.2: Maybe a bit redundant, right? But this can also be = positive, because it would allow for a lot of consistency checking = =E2=80=A6 =20 Dunno what others think=E2=80=A6 =20 My .02 cents, =20 --- Dr. Pedro A. Aranda Guti=C3=A9rrez =20 Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=C3=B3nica, Investigaci=C3=B3n y Desarrollo C/ Zurbar=C3=A1n,12 28010 Madrid, Spain =20 Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler =20 =20 _____ =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, = puede contener informaci=C3=B3n privilegiada o confidencial y es para = uso exclusivo de la persona o entidad de destino. Si no es usted. el = destinatario indicado, queda notificado de que la lectura, = utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede = estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n. The information contained in this transmission is privileged and = confidential information intended only for the use of the individual or = entity named above. If the reader of this message is not the intended = recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately = reply to the sender that you have received this communication in error = and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou = confidencial e =C3=A9 para uso exclusivo da pessoa ou entidade de = destino. Se n=C3=A3o =C3=A9 vossa senhoria o destinat=C3=A1rio indicado, = fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, = divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode = estar proibida em virtude da legisla=C3=A7=C3=A3o vigente. Se recebeu = esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente = por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o ------=_NextPart_000_005A_01D0FF7D.87C53E70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Pedro:

I agree = that:

a) = We can = expresse the policy-based routing (l3 forwarding). =

b) = IB-nemo = provides a lot of consistency checking for the routes. =

Does this make easier = for the network administrator to configure the routes?=C2=A0 How can = Intent make that work easier?

Sue =

From:= = Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of PEDRO ANDRES = ARANDA GUTIERREZ
Sent: Monday, October 05, 2015 10:49 = AM
To: Susan Hares; ibnemo@ietf.org
Subject: Re: = [Ibnemo] Policies and Intent-Based = Networking

Hi Sue,

Thanks for clarifying=E2=80=A6 = this is a good food for thought. Answers = inline=E2=80=A6

/PA

De: = Sue Hares
Fecha: lunes, = 5 de octubre de 2015, 14:49
Para: "ibnemo@ietf.org"
CC: = 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: = Policies and Intent-Based Networking

<= p class=3DMsoNormal>

Hi all: =

Can all policies be = expressed an = Intent?

OK, then we end up with something = we didn=E2=80=99t quite like/agree upon in Prague: there are different = players with different interests and background. Therefore, there will = be different intents (scoped by the actor=E2=80=99s view of the world) = and maybe different ways of expressing intent, depending on the = user=E2=80=99s background.

I=E2=80=99m trying to = determine what policies can or cannot be expressed. Any example = would be helpful.

Here=E2=80=99s three = policies I=E2=80=99d like to discuss:

1) = Traffic flow = policies

2) = BGP policies = for route flow

3) = Policy = filters controlling routes,

I=E2=80=99m working on the = I2RS extensions for Filter-Based RIB and BGP (normal and flow filters). = The I2RS Filter-based RIB allow for policies for = routing (forwarding a layer 3) to be associated with a set of = interfaces. For example,

Forwarding filter 1: = 128.2/16 nexthop 128.2.1.1 =

Forwarding filters 2: 128.5.1/24 = nexthop 128.2.1.2

And the rest get forwarded = to the default RIB which

&nb= sp; 128/8 = nexthop 128.2.1.3

The intent is that = customer 1 has 128.2/16, and customer 2 has 128.5.1/24. This = node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 = (customer 3). All other traffic goes to the = Internet.

How do I link this to the = normal example of Intent? Can we render intent down to this = level or should I be using a higher = level?

Let me try a hands-on in NEMO = ;-)

So we have two = LinkModels:

LinkM= odel VPN Property IPPrefix:nextHop, = IPPrefix:destinationPrefix;

LinkM= odel Internet Property IPPrefix:nextHop;

And three = Links

Link VPN1 Type = VPN Property = nextHop:=E2=80=9D128.2.1.1/32=E2=80=9D, destinationPrefix:=E2=80=9D1= 28.2/16=E2=80=9D ;

Link VPN2 Type = VPN Property = nextHop:=E2=80=9D128.2.1.2/32=E2=80=9D, destinationPrefix:=E2=80=9D1= 28.5.1/24=E2=80=9D ;

Link Default = Type Internet Property nextHop:=E2=80=9D128.2.1.3/32=E2=80=9D = ;

Then we would need 2 = NodeModels:

NodeModel = VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets = ;

NodeModel = InternetNode Property IPPrefix:ID;

And then the = nodes:

Node = VPNTermination1 Type VPNTermination Property = ID:=E2=80=9D128.2.1.1/32=E2=80=9D, subnets:=E2=80=9D128.2/16=E2=80=9D = ;

Node = VPNTermination2 Type VPNTermination Property = ID:=E2=80=9D128.2.1.2/32=E2=80=9D, subnets:=E2=80=9D128.5.1/24=E2=80= =9D ;

Node Interne= tAccess Type InternetNode Property ID:=E2=80=9D128.2.1.3/32=E2=80=9D = ;

And finally the connections between the = nodes:

Link VPN1 Type = VPN EndNodes thisNode,VPNTermination1 ;

Link VPN2 Type = VPN EndNodes thisNode,VPNTermination2 ;

Link Default = Type Internet EndNodes thisNode,InternetAccess ;

Conclusion no. 1: Yes we = can=E2=80=A6

Conclusion no.2: Maybe a bit redundant, right? But this = can also be positive, because it would allow for a lot of consistency = checking =E2=80=A6

Dunno what others = think=E2=80=A6

My .02 = cents,

---

Dr. Pedro A. = Aranda Guti=C3=A9rrez

Technology = Exploration -

Network = Innovation & Virtualisation

email: = pedroa d0t aranda At telefonica d0t = com

Telef=C3=B3ni= ca, Investigaci=C3=B3n y Desarrollo

C/ = Zurbar=C3=A1n,12

28010 = Madrid, Spain

Fragen sind = nicht da, um beantwortet zu werden.

Fragen sind = da, um gestellt zu werden.

Georg = Kreisler

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

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

Esta mensagem e seus = anexos se dirigem exclusivamente ao seu destinat=C3=A1rio, pode conter = informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 para uso = exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa = senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, = utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem = autoriza=C3=A7=C3=A3o pode estar proibida em virtude da = legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por erro, = rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua destrui=C3=A7=C3=A3o

------=_NextPart_000_005A_01D0FF7D.87C53E70-- From nobody Mon Oct 5 11:57:44 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B0C1B3367 for ; Mon, 5 Oct 2015 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] 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 YK3e0FvUJIyW for ; Mon, 5 Oct 2015 11:57:38 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34841B3362 for ; Mon, 5 Oct 2015 11:57:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.146; From: "Susan Hares" To: "'Laurent Ciavaglia'" , "'PEDRO ANDRES ARANDA GUTIERREZ'" , References: <561298D8.8050200@alcatel-lucent.com> In-Reply-To: <561298D8.8050200@alcatel-lucent.com> Date: Mon, 5 Oct 2015 14:57:27 -0400 Message-ID: <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0067_01D0FF7E.271C1B60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYi6VW8yTYlY6yo4uGSUI9ifSYBAHDjkOjnkAKsrA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 18:57:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0067_01D0FF7E.271C1B60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Laurent:=20 I agree that the important part of this discussion is:=20 a) At which level of abstraction we start (end-user level, administrator for network),=20 b) At which level the =93end-systems) operate =96 =93user = end-systems=94 or =93routers that provide entry to network=94,=20 c) What mechanisms exist to translate from a) starting abstraction = to b) ending abstraction.=20 =20 In earlier discussions, we simply looked at the end user as (a) and the router in a large network as (b). Do you think this is the right = place to start?=20 Thanks for the insight,=20 Sue=20 From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Laurent = Ciavaglia Sent: Monday, October 05, 2015 11:36 AM To: PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org Subject: Re: [Ibnemo] Policies and Intent-Based Networking =20 Hello, My naive opinion on the topic would be as follows: -Can all policies be expressed as an Intent?=20 Yes, in the sense that Intent is the "mother" of all policies; this = is what the user initially wants the system to achieve.=20 -Should all policies be expressed as Intent?=20 Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the = majority of policy-based systems does). A key, hidden point is the policy continuum:=20 1)-at which level of abstraction the policy starts,=20 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform), 3)-what mechanisms exist to translate from 1) to 2), taking into = account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..) Wrt. Sue's example, I would see an intent-policy defined as: "Steer = customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right = gateways, etc.) HTH, best regards, Laurent. On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote: Hi Sue, =20 Thanks for clarifying=85 this is a good food for thought. Answers = inline=85 =20 /PA =20 De: Sue Hares Fecha: lunes, 5 de octubre de 2015, 14:49 Para: "ibnemo@ietf.org" CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag Asunto: Policies and Intent-Based Networking=20 =20 Hi all:=20 =20 Can all policies be expressed an Intent? =20 OK, then we end up with something we didn=92t quite like/agree upon in = Prague: there are different players with different interests and background. Therefore, there will be different intents (scoped by the actor=92s view = of the world) and maybe different ways of expressing intent, depending on = the user=92s background. =20 I=92m trying to determine what policies can or cannot be expressed. Any example would be helpful. =20 Here=92s three policies I=92d like to discuss:=20 =20 1) Traffic flow policies =20 2) BGP policies for route flow=20 3) Policy filters controlling routes,=20 =20 I=92m working on the I2RS extensions for Filter-Based RIB and BGP = (normal and flow filters). The I2RS Filter-based RIB allow for policies for = routing (forwarding a layer 3) to be associated with a set of interfaces. For example,=20 =20 Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 =20 Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 =20 =20 And the rest get forwarded to the default RIB which=20 128/8 nexthop 128.2.1.3=20 =20 The intent is that customer 1 has 128.2/16, and customer 2 has = 128.5.1/24. This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3). All other traffic goes to the Internet. How do I link this to the normal example of Intent? Can we render = intent down to this level or should I be using a higher level? =20 =20 Let me try a hands-on in NEMO ;-)=20 =20 So we have two LinkModels: =20 LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; LinkModel Internet Property IPPrefix:nextHop; =20 And three Links =20 Link VPN1 Type VPN Property nextHop:=94128.2.1.1/32=94, destinationPrefix:=94128.2/16=94 ; Link VPN2 Type VPN Property nextHop:=94128.2.1.2/32=94, destinationPrefix:=94128.5.1/24=94 ; Link Default Type Internet Property nextHop:=94128.2.1.3/32=94 ; =20 Then we would need 2 NodeModels: =20 NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ; NodeModel InternetNode Property IPPrefix:ID; =20 And then the nodes: =20 Node VPNTermination1 Type VPNTermination Property ID:=94128.2.1.1/32=94, subnets:=94128.2/16=94 ; Node VPNTermination2 Type VPNTermination Property ID:=94128.2.1.2/32=94, subnets:=94128.5.1/24=94 ; Node InternetAccess Type InternetNode Property ID:=94128.2.1.3/32=94 ; =20 And finally the connections between the nodes: =20 Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; Link Default Type Internet EndNodes thisNode,InternetAccess ; =20 So=20 =20 Conclusion no. 1: Yes we can=85=20 Conclusion no.2: Maybe a bit redundant, right? But this can also be positive, because it would allow for a lot of consistency checking =85 =20 Dunno what others think=85 =20 My .02 cents, =20 --- Dr. Pedro A. Aranda Guti=E9rrez =20 Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=F3nica, Investigaci=F3n y Desarrollo C/ Zurbar=E1n,12 28010 Madrid, Spain =20 Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler =20 =20 _____ =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci=F3n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, = utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede estar prohibida en = virtud de la legislaci=F3n vigente. Si ha recibido este mensaje por error, le rogamos = que nos lo comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately reply to = the sender that you have received this communication in error and then = delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=E1rio, pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso = exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o = destinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, = divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude da = legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui=E7=E3o _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo =20 --=20 Bien cordialement, Best regards, =20 Laurent Ciavaglia Secure Cloud Networking Bell Labs | Alcatel Lucent =20 phone: +33 160 402 636=20 email: laurent.ciavaglia@alcatel-lucent.com linkedin: = laurentciavaglia address: Route de Villejust | 91620 Nozay | France ------=_NextPart_000_0067_01D0FF7E.271C1B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Laurent: =

I agree that the important part of this = discussion is:

a) = At which = level of abstraction we start (end-user level,=A0 administrator for = network),

b) = At which = level the “end-systems)=A0 operate – “user = end-systems” or “routers that provide entry to = network”,

c) = What = mechanisms exist to translate from a) starting abstraction to b) ending = abstraction.

In earlier = discussions, we simply looked at the end user as (a) and the router in a = large network as (b).=A0 =A0=A0Do you think this is the right place to = start?

Thanks for the insight,

Sue =

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowt= ext'>From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of = Laurent Ciavaglia
Sent: Monday, October 05, 2015 11:36 = AM
To: PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; = ibnemo@ietf.org
Subject: Re: [Ibnemo] Policies and = Intent-Based Networking

Hello,

My naive opinion on = the topic would be as follows:
    -Can all policies = be expressed as an Intent?
     Yes, in the = sense that Intent is the "mother" of all policies; this is = what the user initially wants the system to achieve. =

    -Should all policies be expressed as Intent? =
     Not necessarily. Systems limitations and = complexity make it more simple/direct to write a low-level = policy/command (i.e. what the majority of policy-based systems = does).

A key, hidden point is the policy continuum: =
    1)-at which level of abstraction the policy = starts,
    2)-which level of abstraction the end = systems (those receiving the policy) "understand" (the level = of support may be non-uniform),
    3)-what mechanisms = exist to translate from 1) to 2), taking into account possible = intermediate levels/layers (e.g. user or service level, network level, = function level, protocol level, resource level..)

Wrt. Sue's = example, I would see an intent-policy defined as: "Steer customer = traffic to relevant customer gateway, and all other traffic to default = (Internet) gateway." (i.e. the "system" will have to = figure out how to understand and translate different customers, what are = the right gateways, etc.)

HTH, best regards, = Laurent.

On = 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ = wrote:

Hi Sue,

Thanks for clarifying… this is a good = food for thought. Answers inline…

/PA

De: Sue Hares
Fecha: lunes, 5 de octubre de = 2015, 14:49
Para: "ibnemo@ietf.org"
CC: = 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: = Policies and Intent-Based Networking

Hi all:

Can all policies be expressed an = Intent?

OK, then we end up with something we = didn’t quite = like/agree upon in Prague: there are different players with different = interests and background. Therefore, there will be different intents = (scoped by the actor’s view of the = world) and maybe different ways of expressing intent, depending on the = user’s = background.

I’m trying to determine what = policies can or cannot be expressed. Any example would be = helpful.

Here’s three policies I’d like to discuss: =

1) = Traffic flow = policies

2) = BGP policies = for route flow

3) = Policy = filters controlling routes,

I’m working on the I2RS = extensions for Filter-Based RIB and BGP (normal and flow filters). = The I2RS Filter-based RIB allow for policies for = routing (forwarding a layer 3) to be associated with a set of = interfaces. For example,

Forwarding filter 1: 128.2/16 = nexthop 128.2.1.1

Forwarding filters 2: = 128.5.1/24 nexthop 128.2.1.2

And the rest get forwarded to the = default RIB which

= 128/8 nexthop = 128.2.1.3

How do I link this to the normal = example of Intent? Can we render intent down to this level = or should I be using a higher = level?

Let me try a hands-on in NEMO = ;-)

So we have two = LinkModels:

LinkModel VPN Property IPPrefix:nextHop, = IPPrefix:destinationPrefix;

LinkModel Internet Property IPPrefix:nextHop;

And three = Links

= Link VPN1 Type VPN Property = nextHop:”128.2.1.1/32”, destinationPrefix:”128.2/1= 6” ;

= Link VPN2 Type VPN Property = nextHop:”128.2.1.2/32”, destinationPrefix:”128.5.1= /24” ;

= Link Default Type Internet Property nextHop:”128.2.1.3/32” = ;

Then we would need 2 = NodeModels:

= NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets = ;

= NodeModel InternetNode Property IPPrefix:ID;

And then the = nodes:

= Node VPNTermination1 Type VPNTermination Property = ID:”128.2.1.1/32”, subnets:”128.2/16” = ;

= Node VPNTermination2 Type VPNTermination Property = ID:”128.2.1.2/32”, subnets:”128.5.1/24” = ;

= Node InternetAccess Type InternetNode Property = ID:”128.2.1.3/32” ;

And finally the connections between the = nodes:

= Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;

= Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;

= Link Default Type Internet EndNodes thisNode,InternetAccess = ;

Conclusion no. 1: Yes we = can…

Conclusion no.2: Maybe a bit redundant, right? But this = can also be positive, because it would allow for a lot of consistency = checking …

Dunno what others = think…

My .02 = cents,

---

Dr. Pedro A. Aranda Guti=E9rrez

Technology Exploration -

Network Innovation & = Virtualisation

email: pedroa d0t aranda At telefonica d0t = com

Telef=F3nica, Investigaci=F3n y = Desarrollo

C/ Zurbar=E1n,12

28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu = werden.

Fragen sind da, um gestellt zu = werden.

Georg Kreisler

Este mensaje y sus adjuntos se dirigen exclusivamente = a su destinatario, puede contener informaci=F3n privilegiada o = confidencial y es para uso exclusivo de la persona o entidad de destino. = Si no es usted. el destinatario indicado, queda notificado de que la = lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede = estar prohibida en virtud de la legislaci=F3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem = exclusivamente ao seu destinat=E1rio, pode conter informa=E7=E3o = privilegiada ou confidencial e =E9 para uso exclusivo da pessoa ou = entidade de destino. Se n=E3o =E9 vossa senhoria o destinat=E1rio = indicado, fica notificado de que a leitura, utiliza=E7=E3o, = divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em = virtude da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, = rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua destrui=E7=E3o

_______________________________________________

Ibnemo mailing =
list

Ibnemo@ietf.orghttps://www.ietf.or=
g/mailman/listinfo/ibnemo
 
-- 

Bien cordialement, Best =
regards,
 
<=
span lang=3DEN-GB style=3D'font-size:10.0pt'>Laurent =
Ciavaglia
Secure Cloud Networking
Bell Labs | Alcatel Lucent
 
phone: +33 160 =
402 636 
email: laurent.ciavaglia@al=
catel-lucent.com
linkedin: laurentciavaglia<=
/p>
address: Route de Villejust | =
91620 Nozay | France

------=_NextPart_000_0067_01D0FF7E.271C1B60-- From nobody Mon Oct 5 23:16:17 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECA41A0470 for ; Mon, 5 Oct 2015 23:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 wD1R0Puxhf3T for ; Mon, 5 Oct 2015 23:16:12 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8921A0406 for ; Mon, 5 Oct 2015 23:16:11 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BF4ED604B1; Tue, 6 Oct 2015 08:16:08 +0200 (CEST) Received: from ESTGVMSP102.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 92C196048A; Tue, 6 Oct 2015 08:16:08 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.49) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 6 Oct 2015 08:16:07 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0640.eurprd06.prod.outlook.com (10.161.13.146) with Microsoft SMTP Server (TLS) id 15.1.286.20; Tue, 6 Oct 2015 06:16:06 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0280.017; Tue, 6 Oct 2015 06:16:06 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Susan Hares , "ibnemo@ietf.org" Thread-Topic: [Ibnemo] Policies and Intent-Based Networking Thread-Index: AQHQ/30GUp7sg4w4RXmPgeaWSWaBvJ5dPyIAgADgYYA= Date: Tue, 6 Oct 2015 06:16:06 +0000 Message-ID: <51EE2164-2C53-43FA-8AA8-02946F0350A1@telefonica.com> References: <005901d0ff9f$0ed24a90$2c76dfb0$@ndzh.com> In-Reply-To: <005901d0ff9f$0ed24a90$2c76dfb0$@ndzh.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0640; 5:CQylka1GO7m86K7y0kPMOfswZ8MkmYRv/nhmrKYAFGTZaqsP53/9odJocYCpfXQpqXaZM4jRlKp+/THsrMQE6UuUMDwT/ox6j6JticI+XmwFT1AV4pDhbeNK1/HpKzGDTdMQMaOvPl3mTljx7xZfOQ==; 24:DI7W6V9eYrxs0gj8GecClpwM5rMQaHaYjP6lfc6xHFTZxOnSFoEkYFPH9Yzp0+n8V8u1rCnrPlLquYIXexKYjyaBfr8N4QCaOSP6yKFjUA0=; 20:jYm/SIUXNjyqTWAxpHa8uyeXYxUIzx9LzJz54sDEDOFydkFEq2hayLkh/WB2wPS874RAl+TJt/ItznF6qOO+VQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0640; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001); SRVR:DB4PR06MB0640; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0640; x-forefront-prvs: 07215D0470 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(102836002)(15975445007)(33656002)(64706001)(66066001)(106356001)(11100500001)(5001770100001)(2950100001)(107886002)(2900100001)(5001960100002)(92566002)(106116001)(16236675004)(5002640100001)(77096005)(105586002)(36756003)(19580395003)(575784001)(83506001)(83716003)(19580405001)(2501003)(19300405004)(86362001)(87936001)(97736004)(82746002)(81156007)(46102003)(4001350100001)(122556002)(5008740100001)(40100003)(189998001)(10400500002)(19625215002)(101416001)(5004730100002)(5007970100001)(54356999)(50986999)(76176999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0640; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_51EE21642C5343FA8AA802946F0350A1telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2015 06:16:06.5957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0640 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 06:16:16 -0000 --_000_51EE21642C5343FA8AA802946F0350A1telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VlLA0KDQpBbnN3ZXJzIGlubGluZQ0KRGU6IFN1ZSBIYXJlcw0KRmVjaGE6IGx1bmVzLCA1IGRl IG9jdHVicmUgZGUgMjAxNSwgMjA6NTMNClBhcmE6IHBhYWcsICJpYm5lbW9AaWV0Zi5vcmc8bWFp bHRvOmlibmVtb0BpZXRmLm9yZz4iDQpBc3VudG86IFJFOiBbSWJuZW1vXSBQb2xpY2llcyBhbmQg SW50ZW50LUJhc2VkIE5ldHdvcmtpbmcNCg0KUGVkcm86DQoNCuKApg0KRG9lcyB0aGlzIG1ha2Ug ZWFzaWVyIGZvciB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIHRvIGNvbmZpZ3VyZSB0aGUgcm91 dGVzPw0KDQpJdCBjb3VsZC4gSSBzZWUgdHdvIGNhc2VzIGZvciBlcXVpcG1lbnQgcHJvdmlkZXJz IHdpdGggZGl2ZXJnaW5nIENMSXM6DQoxLiBNYW5hZ2luZyBhIG5ldHdvcmsgd2l0aCBkaWZmZXJl bnQgZXF1aXBtZW50IHByb3ZpZGVycw0KMi4gTWlncmF0aW5nIGEgbmV0d29yayBmcm9tIGFuIGVx dWlwbWVudCBwcm92aWRlciB0byBhIG5ldyBlcXVpcG1lbnQgcHJvdmlkZXINCg0KICBIb3cgY2Fu IEludGVudCBtYWtlIHRoYXQgd29yayBlYXNpZXI/DQoNCllvdSBhbHdheXMgZXhwcmVzcyB3aGF0 IHlvdSB3YW50IHRoZSBuZXR3b3JrIHRvIGRvIGFuZCB0aGF0IGRvZXNu4oCZdCBjaGFuZ2UNCg0K DQpTdWUNCg0KSG9wZSBpdCBoZWxwcywgL1BBDQotLS0NCkRyLiBQZWRybyBBLiBBcmFuZGEgR3V0 acOpcnJleg0KDQpUZWNobm9sb2d5IEV4cGxvcmF0aW9uIC0NCk5ldHdvcmsgSW5ub3ZhdGlvbiAm IFZpcnR1YWxpc2F0aW9uDQplbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBk MHQgY29tDQpUZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBEZXNhcnJvbGxvDQpDLyBadXJi YXLDoW4sMTINCjI4MDEwIE1hZHJpZCwgU3BhaW4NCg0KRnJhZ2VuIHNpbmQgbmljaHQgZGEsIHVt IGJlYW50d29ydGV0IHp1IHdlcmRlbi4NCkZyYWdlbiBzaW5kIGRhLCB1bSBnZXN0ZWxsdCB6dSB3 ZXJkZW4uDQpHZW9yZyBLcmVpc2xlcg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1l bnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmls ZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNv bmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8g aW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOz biwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBw cm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNp YmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5p cXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVz dHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNz aW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBv bmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4g SWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGll bnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3Ry aWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwg ZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRo YXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVu IGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhj bHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8Oj byBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRh IHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlh IG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1 cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOn w6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50 ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9z IG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBh IHN1YSBkZXN0cnVpw6fDo28NCg== --_000_51EE21642C5343FA8AA802946F0350A1telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <60D13EC5BA63B34383962ABC6CF0EBAD@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5z LXNlcmlmOyI+DQpTdWUsPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMtc2Vy aWY7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlm OyI+DQpBbnN3ZXJzIGlubGluZTwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9O Ij4NCjxkaXYgc3R5bGU9ImNvbG9yOiBibGFjazsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogQ2FsaWJyaTsgdGV4dC1hbGlnbjogbGVmdDsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1l ZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IHBhZGRpbmc6IDNwdCAwaW4gMGlu OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7Ij4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5EZTogPC9zcGFuPlN1ZSBIYXJlczxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5GZWNoYTogPC9zcGFuPmx1bmVzLCA1IGRlIG9jdHVicmUgZGUgMjAx NSwgMjA6NTM8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+UGFyYTogPC9zcGFu PnBhYWcsICZxdW90OzxhIGhyZWY9Im1haWx0bzppYm5lbW9AaWV0Zi5vcmciPmlibmVtb0BpZXRm Lm9yZzwvYT4mcXVvdDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+QXN1bnRv OiA8L3NwYW4+UkU6IFtJYm5lbW9dIFBvbGljaWVzIGFuZCBJbnRlbnQtQmFzZWQgTmV0d29ya2lu Zzxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXpl OiAxNHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9D S1FVT1RFIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9y ZGVyLWxlZnQtd2lkdGg6IDVweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBwYWRkaW5nOiAw cHggMHB4IDBweCA1cHg7IG1hcmdpbjogMHB4IDBweCAwcHggNXB4OyI+DQo8ZGl2IHhtbG5zOnY9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2Zm aWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAi Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmls dGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJ cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJBcmlhbCBVbmljb2RlIE1TIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287 DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlxAQXJpYWwgVW5pY29kZSBNUyI7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGlu Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29uVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTc4NTE1Mzg0Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTM1NjM3NDEwIDY3Njk4NzA1IDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6 LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMQ0KCXttc28tbGlzdC1pZDoxODc2NTgxMTQzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotNzIzMzQ1MDM2IDY3Njk4NzExIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250 LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+UGVkcm86IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBjb2xvcj0iIzFmNDk3ZCI+4oCmPC9mb250PjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWls eTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+RG9lcyB0aGlzIG1ha2UgZWFzaWVyIGZvciB0aGUgbmV0d29yayBhZG1pbmlzdHJh dG9yIHRvIGNvbmZpZ3VyZSB0aGUgcm91dGVzPzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycs IHNhbnMtc2VyaWY7Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBz YW5zLXNlcmlmOyI+DQpJdCBjb3VsZC4gSSBzZWUgdHdvIGNhc2VzIGZvciBlcXVpcG1lbnQgcHJv dmlkZXJzIHdpdGggZGl2ZXJnaW5nIENMSXM6PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBN UycsIHNhbnMtc2VyaWY7Ij4NCjEuIE1hbmFnaW5nIGEgbmV0d29yayB3aXRoIGRpZmZlcmVudCBl cXVpcG1lbnQgcHJvdmlkZXJzPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29kZSBNUycsIHNhbnMt c2VyaWY7Ij4NCjIuIE1pZ3JhdGluZyBhIG5ldHdvcmsgZnJvbSBhbiBlcXVpcG1lbnQgcHJvdmlk ZXIgdG8gYSBuZXcgZXF1aXBtZW50IHByb3ZpZGVyPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAnQXJpYWwgVW5pY29k ZSBNUycsIHNhbnMtc2VyaWY7Ij4NCiZuYnNwOyZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19T UkNfQk9EWV9TRUNUSU9OIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8Ymxv Y2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJP UkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAw IDU7Ij4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5z Om89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53 My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7IEhvdyBjYW4gSW50ZW50IG1h a2UgdGhhdCB3b3JrIGVhc2llcj88L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WW91IGFsd2F5 cyBleHByZXNzIHdoYXQgeW91IHdhbnQgdGhlIG5ldHdvcmsgdG8gZG8gYW5kIHRoYXQgZG9lc27i gJl0IGNoYW5nZTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiIgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1mYW1pbHk6ICdBcmlhbCBVbmljb2RlIE1TJywgc2Fucy1zZXJpZjsiPg0KPGJsb2NrcXVv dGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVIt TEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+ DQo8ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1p Y3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3Jn L1RSL1JFQy1odG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+U3VlPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkhvcGUgaXQgaGVscHMsIC9Q QTwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPi0tLTwvZGl2Pg0K PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkRy LiBQZWRybyBBLiBBcmFuZGEgR3V0acOpcnJlejwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPlRlY2hub2xvZ3kg RXhwbG9yYXRpb24gLTwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBm b250LXNpemU6IG1lZGl1bTsiPk5ldHdvcmsgSW5ub3ZhdGlvbiAmYW1wOyBWaXJ0dWFsaXNhdGlv bjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1l ZGl1bTsiPmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBjb208L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07 Ij5UZWxlZsOzbmljYSwgSW52ZXN0aWdhY2nDs24geSBEZXNhcnJvbGxvPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+Qy8gWnVyYmFy w6FuLDEyPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6 ZTogbWVkaXVtOyI+MjgwMTAgTWFkcmlkLCBTcGFpbjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1m YW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkZyYWdlbiBz aW5kIG5pY2h0IGRhLCB1bSBiZWFudHdvcnRldCB6dSB3ZXJkZW4uPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+RnJhZ2VuIHNpbmQg ZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5HZW9yZyBLcmVpc2xlcjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4N CkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRh IG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBl bnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNh ZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhDQogbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBk aXZ1bGdhY2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hp YmlkYSBlbiB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRv IGVzdGUgbWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUg aW5tZWRpYXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVj Y2nDs24uPGJyPg0KPGJyPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5z bWlzc2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5k ZWQgb25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJv dmUuIElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLA0K IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFu ZCB0aGVuIGRlbGV0ZSBpdC48YnI+DQo8YnI+DQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mg c2UgZGlyaWdlbSBleGNsdXNpdmFtZW50ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250 ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVnaWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVz byBleGNsdXNpdm8gZGEgcGVzc29hIG91IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kg dm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5hdMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8g ZGUgcXVlIGENCiBsZWl0dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3Bp YSBzZW0gYXV0b3JpemHDp8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVn aXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9n YW1vcy1saGUgcXVlIG5vcyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21h IHZpYSBlIHByb2NlZGEgYSBzdWEgZGVzdHJ1acOnw6NvPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_51EE21642C5343FA8AA802946F0350A1telefonicacom_-- From nobody Tue Oct 6 08:43:15 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245D41A1A7E for ; Tue, 6 Oct 2015 08:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 GqApNh8zneB4 for ; Tue, 6 Oct 2015 08:43:09 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C25D1A01D8 for ; Tue, 6 Oct 2015 08:43:08 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 5BD33AFCE9D9C; Tue, 6 Oct 2015 15:43:02 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t96Fh2tx016243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Oct 2015 15:43:03 GMT Received: from [135.224.17.126] (135.5.27.18) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 6 Oct 2015 11:43:01 -0400 To: Susan Hares , "'PEDRO ANDRES ARANDA GUTIERREZ'" , References: <561298D8.8050200@alcatel-lucent.com> <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com> From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France Message-ID: <5613EC02.4010907@alcatel-lucent.com> Date: Tue, 6 Oct 2015 17:42:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com> Content-Type: multipart/alternative; boundary="------------000103090504080203020407" X-Originating-IP: [135.5.27.18] Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 15:43:13 -0000 --------------000103090504080203020407 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Dear Sue, all, Please see inline... On 05/10/2015 20:57, Susan Hares wrote: > > Laurent: > > I agree that the important part of this discussion is: > > a)At which level of abstraction we start (end-user level, > administrator for network), > > b)At which level the �end-systems) operate � �user end-systems� or > �routers that provide entry to network�, > > c)What mechanisms exist to translate from a) starting abstraction to > b) ending abstraction. > > In earlier discussions, we simply looked at the end user as (a) and > the router in a large network as (b). Do you think this is the > right place to start? > It is surely good enough to start with network operator/administrator and routers in a large network as policy "end points". My initial comment was more to stress the levels of _abstraction_ considered: if the policy entry point is quite abstract (cf previous policy example) and the policy exit point understands "only" low level commands, then the mechanism(s) in between will have to cope with such "distance" between the policy end points, ensuring the continuum of the policy from the top to the bottom levels. The main challenge is thus to identify in the defined policy what are the informational elements (here the modeling is key), these elements shall then be interpreted (semantics/ontology come to mind), and finally translated in a format understandable by the next element in the policy chain. We have defined such mechanisms for policy continuum in a recent research project (www.univerself-project.eu), applied to autonomic networking. Best regards, Laurent. > Thanks for the insight, > > Sue > > *From:*Ibnemo [mailto:ibnemo-bounces@ietf.org] *On Behalf Of *Laurent > Ciavaglia > *Sent:* Monday, October 05, 2015 11:36 AM > *To:* PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org > *Subject:* Re: [Ibnemo] Policies and Intent-Based Networking > > Hello, > > My naive opinion on the topic would be as follows: > -Can all policies be expressed as an Intent? > Yes, in the sense that Intent is the "mother" of all policies; > this is what the user initially wants the system to achieve. > > -Should all policies be expressed as Intent? > Not necessarily. Systems limitations and complexity make it more > simple/direct to write a low-level policy/command (i.e. what the > majority of policy-based systems does). > > A key, hidden point is the policy continuum: > 1)-at which level of abstraction the policy starts, > 2)-which level of abstraction the end systems (those receiving the > policy) "understand" (the level of support may be non-uniform), > 3)-what mechanisms exist to translate from 1) to 2), taking into > account possible intermediate levels/layers (e.g. user or service > level, network level, function level, protocol level, resource level..) > > Wrt. Sue's example, I would see an intent-policy defined as: "Steer > customer traffic to relevant customer gateway, and all other traffic > to default (Internet) gateway." (i.e. the "system" will have to figure > out how to understand and translate different customers, what are the > right gateways, etc.) > > HTH, best regards, Laurent. > > On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > Hi Sue, > > Thanks for clarifying�this is a good food for thought. Answers inline� > > /PA > > *De: *Sue Hares > *Fecha: *lunes, 5 de octubre de 2015, 14:49 > *Para: *"ibnemo@ietf.org " > *CC: *'Zhoutianran', "'Bert Wijnen (IETF)'", paag > *Asunto: *Policies and Intent-Based Networking > > Hi all: > > Can all policies be expressed an Intent? > > OK, then we end up with something we didn�t quite like/agree upon > in Prague: there are different players with different interests > and background. Therefore, there will be different intents (scoped > by the actor�s view of the world) and maybe different ways of > expressing intent, depending on the user�s background. > > I�m trying to determine what policies can or cannot be > expressed. Any example would be helpful. > > Here�s three policies I�d like to discuss: > > 1)Traffic flow policies > > 2)BGP policies for route flow > > 3)Policy filters controlling routes, > > I�m working on the I2RS extensions for Filter-Based RIB and > BGP (normal and flow filters). The I2RS Filter-based RIB > allow for policies for routing (forwarding a layer 3) to be > associated with a set of interfaces. For example, > > Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 > > Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 > > And the rest get forwarded to the default RIB which > > 128/8 nexthop 128.2.1.3 > > The intent is that customer 1 has 128.2/16, and customer 2 > has 128.5.1/24. This node links to these VPNs via 128.2.1.1 > (customer1), and 128.2.1.2 (customer 3). All other traffic > goes to the Internet. > > How do I link this to the normal example of Intent? Can we > render intent down to this level or should I be using a higher > level? > > Let me try a hands-on in NEMO ;-) > > So we have two LinkModels: > > LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; > > LinkModel Internet Property IPPrefix:nextHop; > > And three Links > > Link VPN1 Type VPN Property > nextHop:�128.2.1.1/32�, destinationPrefix:�128.2/16� ; > > Link VPN2 Type VPN Property > nextHop:�128.2.1.2/32�, destinationPrefix:�128.5.1/24� ; > > Link Default Type Internet Property nextHop:�128.2.1.3/32� ; > > Then we would need 2 NodeModels: > > NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): > subnets ; > > NodeModel InternetNode Property IPPrefix:ID; > > And then the nodes: > > Node VPNTermination1 Type VPNTermination Property > ID:�128.2.1.1/32�, subnets:�128.2/16� ; > > Node VPNTermination2 Type VPNTermination Property > ID:�128.2.1.2/32�, subnets:�128.5.1/24� ; > > Node InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ; > > And finally the connections between the nodes: > > Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; > > Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; > > Link Default Type Internet EndNodes thisNode,InternetAccess ; > > So > > Conclusion no. 1: Yes we can� > > Conclusion no.2: Maybe a bit redundant, right? But this can also > be positive, because it would allow for a lot of consistency > checking � > > Dunno what others think� > > My .02 cents, > > --- > > Dr. Pedro A. Aranda Guti�rrez > > Technology Exploration - > > Network Innovation & Virtualisation > > email: pedroa d0t aranda At telefonica d0t com > > Telef�nica, Investigaci�n y Desarrollo > > C/ Zurbar�n,12 > > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > > Fragen sind da, um gestellt zu werden. > > Georg Kreisler > > ------------------------------------------------------------------------ > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener informaci�n privilegiada o > confidencial y es para uso exclusivo de la persona o entidad de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia > sin autorizaci�n puede estar prohibida en virtud de la legislaci�n > vigente. Si ha recibido este mensaje por error, le rogamos que nos > lo comunique inmediatamente por esta misma v�a y proceda a su > destrucci�n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the > individual or entity named above. If the reader of this message is > not the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this transmission in > error, do not read it. Please immediately reply to the sender that > you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat�rio, pode conter informa��o privilegiada ou confidencial > e � para uso exclusivo da pessoa ou entidade de destino. Se n�o � > vossa senhoria o destinat�rio indicado, fica notificado de que a > leitura, utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode > estar proibida em virtude da legisla��o vigente. Se recebeu esta > mensagem por erro, rogamos-lhe que nos o comunique imediatamente > por esta mesma via e proceda a sua destrui��o > > > > _______________________________________________ > > Ibnemo mailing list > > Ibnemo@ietf.org > > https://www.ietf.org/mailman/listinfo/ibnemo > > -- > > Bien cordialement, Best regards, > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------000103090504080203020407 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear Sue, all,

Please see inline...

On 05/10/2015 20:57, Susan Hares wrote:

Laurent:

I agree that the important part of this discussion is:

a)�� At which level of abstraction we start (end-user level,� administrator for network),

b)�� At which level the �end-systems)� operate � �user end-systems� or �routers that provide entry to network�,

c)�� What mechanisms exist to translate from a) starting abstraction to b) ending abstraction.

�

In earlier discussions, we simply looked at the end user as (a) and the router in a large network as (b).� ��Do you think this is the right place to start?

It is surely good enough to start with network operator/administrator and routers in a large network as policy "end points".
My initial comment was more to stress the levels of abstraction considered: if the policy entry point is quite abstract (cf previous policy example) and the policy exit point understands "only" low level commands, then the mechanism(s) in between will have to cope with such "distance" between the policy end points, ensuring the continuum of the policy from the top to the bottom levels.
The main challenge is thus to identify in the defined policy what are the informational elements (here the modeling is key), these elements shall then be interpreted (semantics/ontology come to mind), and finally translated in a format understandable by the next element in the policy chain.
We have defined such mechanisms for policy continuum in a recent research project (www.univerself-project.eu), applied to autonomic networking.

Best regards, Laurent.

Thanks for the insight,

Sue

From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Laurent Ciavaglia
Sent: Monday, October 05, 2015 11:36 AM
To: PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org
Subject: Re: [Ibnemo] Policies and Intent-Based Networking

�

Hello,

My naive opinion on the topic would be as follows:
�� -Can all policies be expressed as an Intent?
�� Yes, in the sense that Intent is the "mother" of all policies; this is what the user initially wants the system to achieve.

�� -Should all policies be expressed as Intent?
�� Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the majority of policy-based systems does).

A key, hidden point is the policy continuum:
�� 1)-at which level of abstraction the policy starts,
�� 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform),
�� 3)-what mechanisms exist to translate from 1) to 2), taking into account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..)

Wrt. Sue's example, I would see an intent-policy defined as: "Steer customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right gateways, etc.)

HTH, best regards, Laurent.

On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote:
Hi Sue,

�

Thanks for clarifying� this is a good food for thought. Answers inline�

�

/PA

�

De: Sue Hares
Fecha: lunes, 5 de octubre de 2015, 14:49
Para: "ibnemo@ietf.org"
CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: Policies and Intent-Based Networking

�

Hi all:

�

Can all policies be expressed an Intent?

�

OK, then we end up with something we didn�t quite like/agree upon in Prague: there are different players with different interests and background. Therefore, there will be different intents (scoped by the actor�s view of the world) and maybe different ways of expressing intent, depending on the user�s background.

�

I�m trying to determine what policies can or cannot be expressed.� Any example would be helpful.

�

Here�s three policies I�d like to discuss:

�

1)�� Traffic flow policies ��

2)�� BGP policies for route flow

3)�� Policy filters controlling routes,

�

I�m working on the I2RS extensions for Filter-Based RIB and BGP (normal and flow filters). ��The I2RS Filter-based RIB allow for policies for routing (forwarding a layer 3) to be associated with a set of interfaces.� �For example,

�

Forwarding filter 1:� 128.2/16 nexthop 128.2.1.1 ��

Forwarding filters 2:�� 128.5.1/24 nexthop 128.2.1.2 �

�

And the rest get forwarded to the default RIB which

��128/8� nexthop 128.2.1.3

�

The intent �is that customer 1 has 128.2/16, and customer 2 has 128.5.1/24.� �This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3).� All other traffic goes to the Internet.

How do I link this to the normal example of Intent?� �Can we render intent down to this level or should I be using a higher level?

�

�

Let me try a hands-on in NEMO ;-)�

�

So we have two LinkModels:

�

LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix;

LinkModel Internet Property IPPrefix:nextHop;

�

And three Links

�

Link VPN1 Type VPN Property nextHop:�128.2.1.1/32�,�destinationPrefix:�128.2/16� ;

Link VPN2 Type VPN Property nextHop:�128.2.1.2/32�,�destinationPrefix:�128.5.1/24� ;

Link Default Type Internet Property nextHop:�128.2.1.3/32� ;

�

Then we would need 2 NodeModels:

�

NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ;

NodeModel InternetNode Property IPPrefix:ID;

�

And then the nodes:

�

Node VPNTermination1 Type VPNTermination Property ID:�128.2.1.1/32�, subnets:�128.2/16� ;

Node VPNTermination2 Type�VPNTermination Property ID:�128.2.1.2/32�,�subnets:�128.5.1/24� ;

Node�InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ;

�

And finally the connections between the nodes:

�

Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;

Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;

Link Default Type Internet EndNodes thisNode,InternetAccess ;

�

So�

�

Conclusion no. 1: Yes we can��

Conclusion no.2: Maybe a bit redundant, right? But this can also be positive, because it would allow for a lot of consistency checking �

�

Dunno what others think�

�

My .02 cents,

�

---

Dr. Pedro A. Aranda Guti�rrez

�

Technology Exploration -

Network Innovation & Virtualisation

email: pedroa d0t aranda At telefonica d0t com

Telef�nica, Investigaci�n y Desarrollo

C/ Zurbar�n,12

28010 Madrid, Spain

�

Fragen sind nicht da, um beantwortet zu werden.

Fragen sind da, um gestellt zu werden.

Georg Kreisler

�

�

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci�n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia sin autorizaci�n puede estar prohibida en virtud de la legislaci�n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v�a y proceda a su destrucci�n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat�rio, pode conter informa��o privilegiada ou confidencial e � para uso exclusivo da pessoa ou entidade de destino. Se n�o � vossa senhoria o destinat�rio indicado, fica notificado de que a leitura, utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode estar proibida em virtude da legisla��o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui��o
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org
https://www.ietf.org/mailman/listinfo/ibnemo
�

--

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------000103090504080203020407-- From nobody Tue Oct 6 11:26:44 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98021AD358 for ; Tue, 6 Oct 2015 11:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, USER_IN_WHITELIST=-100] 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 eiUwGc85Gk8i for ; Tue, 6 Oct 2015 11:26:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DEF71AD352 for ; Tue, 6 Oct 2015 11:26:31 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.84.146; From: "Susan Hares" To: "'Laurent Ciavaglia'" , "'PEDRO ANDRES ARANDA GUTIERREZ'" , References: <561298D8.8050200@alcatel-lucent.com> <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com> <5613EC02.4010907@alcatel-lucent.com> In-Reply-To: <5613EC02.4010907@alcatel-lucent.com> Date: Tue, 6 Oct 2015 14:26:23 -0400 Message-ID: <014f01d10064$81542500$83fc6f00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0150_01D10042.FA489F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYi6VW8yTYlY6yo4uGSUI9ifSYBAHDjkOjAUKdINUCYvH4Bp4kWNxQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 18:26:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0150_01D10042.FA489F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Laurent:=20 Thank you for letting me know the use case of a network administrator is valid. Could you send me a direct pointer to the policy continuum = paper. I am having trouble finding it on the site. The research at www.univerself-project.eu is very interesting, but I just cannot find = the specific paper you mention.=20 Sue Hares=20 =20 From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]=20 Sent: Tuesday, October 06, 2015 11:43 AM To: Susan Hares; 'PEDRO ANDRES ARANDA GUTIERREZ'; ibnemo@ietf.org Subject: Re: [Ibnemo] Policies and Intent-Based Networking =20 Dear Sue, all, Please see inline... On 05/10/2015 20:57, Susan Hares wrote: Laurent:=20 I agree that the important part of this discussion is:=20 a) At which level of abstraction we start (end-user level, administrator for network),=20 b) At which level the =93end-systems) operate =96 =93user = end-systems=94 or =93routers that provide entry to network=94,=20 c) What mechanisms exist to translate from a) starting abstraction = to b) ending abstraction.=20 =20 In earlier discussions, we simply looked at the end user as (a) and the router in a large network as (b). Do you think this is the right = place to start?=20 It is surely good enough to start with network operator/administrator = and routers in a large network as policy "end points". My initial comment was more to stress the levels of abstraction = considered: if the policy entry point is quite abstract (cf previous policy example) = and the policy exit point understands "only" low level commands, then the mechanism(s) in between will have to cope with such "distance" between = the policy end points, ensuring the continuum of the policy from the top to = the bottom levels. The main challenge is thus to identify in the defined policy what are = the informational elements (here the modeling is key), these elements shall = then be interpreted (semantics/ontology come to mind), and finally translated = in a format understandable by the next element in the policy chain. We have defined such mechanisms for policy continuum in a recent = research project (www.univerself-project.eu), applied to autonomic networking. Best regards, Laurent. Thanks for the insight,=20 Sue=20 From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Laurent = Ciavaglia Sent: Monday, October 05, 2015 11:36 AM To: PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org Subject: Re: [Ibnemo] Policies and Intent-Based Networking =20 Hello, My naive opinion on the topic would be as follows: -Can all policies be expressed as an Intent?=20 Yes, in the sense that Intent is the "mother" of all policies; this = is what the user initially wants the system to achieve.=20 -Should all policies be expressed as Intent?=20 Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the = majority of policy-based systems does). A key, hidden point is the policy continuum:=20 1)-at which level of abstraction the policy starts,=20 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform), 3)-what mechanisms exist to translate from 1) to 2), taking into = account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..) Wrt. Sue's example, I would see an intent-policy defined as: "Steer = customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right = gateways, etc.) HTH, best regards, Laurent. On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote: Hi Sue, =20 Thanks for clarifying=85 this is a good food for thought. Answers = inline=85 =20 /PA =20 De: Sue Hares Fecha: lunes, 5 de octubre de 2015, 14:49 Para: "ibnemo@ietf.org" CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag Asunto: Policies and Intent-Based Networking=20 =20 Hi all:=20 =20 Can all policies be expressed an Intent? =20 OK, then we end up with something we didn=92t quite like/agree upon in = Prague: there are different players with different interests and background. Therefore, there will be different intents (scoped by the actor=92s view = of the world) and maybe different ways of expressing intent, depending on = the user=92s background. =20 I=92m trying to determine what policies can or cannot be expressed. Any example would be helpful. =20 Here=92s three policies I=92d like to discuss:=20 =20 1) Traffic flow policies =20 2) BGP policies for route flow=20 3) Policy filters controlling routes,=20 =20 I=92m working on the I2RS extensions for Filter-Based RIB and BGP = (normal and flow filters). The I2RS Filter-based RIB allow for policies for = routing (forwarding a layer 3) to be associated with a set of interfaces. For example,=20 =20 Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 =20 Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 =20 =20 And the rest get forwarded to the default RIB which=20 128/8 nexthop 128.2.1.3=20 =20 The intent is that customer 1 has 128.2/16, and customer 2 has = 128.5.1/24. This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3). All other traffic goes to the Internet. How do I link this to the normal example of Intent? Can we render = intent down to this level or should I be using a higher level? =20 =20 Let me try a hands-on in NEMO ;-)=20 =20 So we have two LinkModels: =20 LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; LinkModel Internet Property IPPrefix:nextHop; =20 And three Links =20 Link VPN1 Type VPN Property nextHop:=94128.2.1.1/32=94, destinationPrefix:=94128.2/16=94 ; Link VPN2 Type VPN Property nextHop:=94128.2.1.2/32=94, destinationPrefix:=94128.5.1/24=94 ; Link Default Type Internet Property nextHop:=94128.2.1.3/32=94 ; =20 Then we would need 2 NodeModels: =20 NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ; NodeModel InternetNode Property IPPrefix:ID; =20 And then the nodes: =20 Node VPNTermination1 Type VPNTermination Property ID:=94128.2.1.1/32=94, subnets:=94128.2/16=94 ; Node VPNTermination2 Type VPNTermination Property ID:=94128.2.1.2/32=94, subnets:=94128.5.1/24=94 ; Node InternetAccess Type InternetNode Property ID:=94128.2.1.3/32=94 ; =20 And finally the connections between the nodes: =20 Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; Link Default Type Internet EndNodes thisNode,InternetAccess ; =20 So=20 =20 Conclusion no. 1: Yes we can=85=20 Conclusion no.2: Maybe a bit redundant, right? But this can also be positive, because it would allow for a lot of consistency checking =85 =20 Dunno what others think=85 =20 My .02 cents, =20 --- Dr. Pedro A. Aranda Guti=E9rrez =20 Technology Exploration - Network Innovation & Virtualisation email: pedroa d0t aranda At telefonica d0t com Telef=F3nica, Investigaci=F3n y Desarrollo C/ Zurbar=E1n,12 28010 Madrid, Spain =20 Fragen sind nicht da, um beantwortet zu werden. Fragen sind da, um gestellt zu werden. Georg Kreisler =20 =20 _____ =20 Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci=F3n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, = utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede estar prohibida en = virtud de la legislaci=F3n vigente. Si ha recibido este mensaje por error, le rogamos = que nos lo comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution = or copying of this communication is strictly prohibited. If you have = received this transmission in error, do not read it. Please immediately reply to = the sender that you have received this communication in error and then = delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu = destinat=E1rio, pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso = exclusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o = destinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, = divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude da = legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui=E7=E3o _______________________________________________ Ibnemo mailing list Ibnemo@ietf.org https://www.ietf.org/mailman/listinfo/ibnemo =20 --=20 Bien cordialement, Best regards, =20 Laurent Ciavaglia Secure Cloud Networking Bell Labs | Alcatel Lucent =20 phone: +33 160 402 636=20 email: laurent.ciavaglia@alcatel-lucent.com linkedin: = laurentciavaglia address: Route de Villejust | 91620 Nozay | France =20 --=20 Bien cordialement, Best regards, =20 Laurent Ciavaglia Secure Cloud Networking Bell Labs | Alcatel Lucent =20 phone: +33 160 402 636=20 email: laurent.ciavaglia@alcatel-lucent.com linkedin: = laurentciavaglia address: Route de Villejust | 91620 Nozay | France ------=_NextPart_000_0150_01D10042.FA489F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Laurent: =

Thank you for letting me know the use case of a = network administrator is valid.=A0 Could you send me a direct pointer to = the policy continuum paper.=A0 I am having trouble finding = it on the site.=A0 The research at www.univerself-project.eu = is very interesting, but I just cannot find the specific paper you = mention.

Sue Hares

<= span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowt= ext'>From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] =
Sent: Tuesday, October 06, 2015 11:43 AM
To: Susan = Hares; 'PEDRO ANDRES ARANDA GUTIERREZ'; = ibnemo@ietf.org
Subject: Re: [Ibnemo] Policies and = Intent-Based Networking

Dear Sue, all,

Please see = inline...

On = 05/10/2015 20:57, Susan Hares = wrote:

Laurent: =
I agree = that the important part of this discussion is:
a)      = At which level of = abstraction we start (end-user level, administrator for network), =
b)      = At which level the = “end-systems) operate – “user end-systems” = or “routers that provide entry to network”, =
c)       = What mechanisms = exist to translate from a) starting abstraction to b) ending = abstraction.

In earlier discussions, we simply = looked at the end user as (a) and the router in a large network as = (b).   Do you think this is the right place to start? =

It is surely good enough to start with network = operator/administrator and routers in a large network as policy = "end points".
My initial comment was more to stress the = levels of abstraction considered: if the policy entry point is = quite abstract (cf previous policy example) and the policy exit point = understands "only" low level commands, then the mechanism(s) = in between will have to cope with such "distance" between the = policy end points, ensuring the continuum of the policy from the top to = the bottom levels.
The main challenge is thus to identify in the = defined policy what are the informational elements (here the modeling is = key), these elements shall then be interpreted (semantics/ontology come = to mind), and finally translated in a format understandable by the next = element in the policy chain.
We have defined such mechanisms for = policy continuum in a recent research project (www.univerself-project.eu),= applied to autonomic networking.

Best regards, = Laurent.

Thanks for = the insight,

Sue =

<= span lang=3DEN-GB = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowt= ext'>From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Laurent Ciavaglia
Sent: Monday, October = 05, 2015 11:36 AM
To: PEDRO ANDRES ARANDA GUTIERREZ; Susan = Hares; ibnemo@ietf.org
Subject: = Re: [Ibnemo] Policies and Intent-Based Networking

On = 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ = wrote:

Hi Sue,

Thanks for = clarifying… this is a good food for thought. Answers = inline…

/PA

De: Sue Hares
Fecha: lunes, 5 de octubre de = 2015, 14:49
Para: "ibnemo@ietf.org"
CC: = 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: = Policies and Intent-Based Networking

Hi all:

Can all policies be expressed an = Intent?

OK, then we end = up with something we didn’t quite like/agree upon in Prague: there = are different players with different interests and background. = Therefore, there will be different intents (scoped by the actor’s = view of the world) and maybe different ways of expressing intent, = depending on the user’s background.

I’m = trying to determine what policies can or cannot be expressed. Any = example would be helpful.

Here’s three policies = I’d like to discuss:

1)      = Traffic flow = policies
2)      = BGP policies for = route flow
3)      = Policy filters = controlling routes,

I’m working on the I2RS extensions for Filter-Based = RIB and BGP (normal and flow filters).    The I2RS = Filter-based RIB allow for policies for routing (forwarding a layer 3) = to be associated with a set of interfaces. For example, =

Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 =
Forwarding filters 2:   128.5.1/24 nexthop = 128.2.1.2

And the rest get forwarded to the default RIB which =
          =         128/8 nexthop = 128.2.1.3

The intent is that customer 1 has 128.2/16, and = customer 2 has 128.5.1/24. This node links to these VPNs via = 128.2.1.1 (customer1), and 128.2.1.2 (customer 3). All other = traffic goes to the = Internet.
How do I link this to the normal = example of Intent? Can we render intent down to this level = or should I be using a higher = level?

Let me try a = hands-on in NEMO ;-)

So we have two = LinkModels:

LinkModel VPN Property IPPrefix:nextHop, = IPPrefix:destinationPrefix;
LinkModel Internet Property IPPrefix:nextHop;

And three = Links

= Link VPN1 Type VPN Property = nextHop:”128.2.1.1/32”, destinationPrefix:”128.2/1= 6” ;
= Link VPN2 Type VPN Property = nextHop:”128.2.1.2/32”, destinationPrefix:”128.5.1= /24” ;
= Link Default Type Internet Property nextHop:”128.2.1.3/32” = ;

Then we would = need 2 NodeModels:

= NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets = ;
= NodeModel InternetNode Property IPPrefix:ID;

And then the = nodes:

= Node VPNTermination1 Type VPNTermination Property = ID:”128.2.1.1/32”, subnets:”128.2/16” = ;
= Node VPNTermination2 Type VPNTermination Property = ID:”128.2.1.2/32”, subnets:”128.5.1/24” = ;
= Node InternetAccess Type InternetNode Property = ID:”128.2.1.3/32” ;

And finally the connections between the = nodes:

= Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;
= Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;
= Link Default Type Internet EndNodes thisNode,InternetAccess = ;

So

Conclusion no. 1: Yes we can…
Conclusion no.2: Maybe a bit redundant, right? But = this can also be positive, because it would allow for a lot of = consistency checking …

Dunno what others think…

My .02 cents,

---
Dr. Pedro A. Aranda Guti=E9rrez

Technology Exploration -
Network Innovation & Virtualisation
email: pedroa d0t aranda At telefonica d0t com
Telef=F3nica, Investigaci=F3n y Desarrollo
C/ Zurbar=E1n,12
28010 Madrid, Spain

Fragen sind nicht da, um beantwortet zu werden.
Fragen sind da, um gestellt zu werden.
Georg Kreisler

Este mensaje y sus adjuntos se dirigen exclusivamente = a su destinatario, puede contener informaci=F3n privilegiada o = confidencial y es para uso exclusivo de la persona o entidad de destino. = Si no es usted. el destinatario indicado, queda notificado de que la = lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede = estar prohibida en virtud de la legislaci=F3n vigente. Si ha recibido = este mensaje por error, le rogamos que nos lo comunique inmediatamente = por esta misma v=EDa y proceda a su destrucci=F3n.

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

Esta mensagem e seus anexos se dirigem = exclusivamente ao seu destinat=E1rio, pode conter informa=E7=E3o = privilegiada ou confidencial e =E9 para uso exclusivo da pessoa ou = entidade de destino. Se n=E3o =E9 vossa senhoria o destinat=E1rio = indicado, fica notificado de que a leitura, utiliza=E7=E3o, = divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em = virtude da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, = rogamos-lhe que nos o comunique imediatamente por esta mesma via e = proceda a sua destrui=E7=E3o
_______________________________________________<=
/o:p>
Ibnemo mailing =
list
Ibnemo@ietf.orghttps://www.ietf.or=
g/mailman/listinfo/ibnemo

Bien cordialement, Best = regards,

<= span lang=3DEN-GB style=3D'font-size:10.0pt'>Laurent = Ciavaglia

Secure Cloud = Networking

Bell Labs | Alcatel = Lucent

phone: +33 160 = 402 636

email: laurent.ciavaglia@al= catel-lucent.com

linkedin: laurentciavaglia<= /p>

address: Route de Villejust | = 91620 Nozay | France

Bien cordialement, Best = regards,

<= span lang=3DEN-GB style=3D'font-size:10.0pt'>Laurent = Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

phone: +33 160 = 402 636

email: laurent.ciavaglia@al= catel-lucent.com

linkedin: laurentciavaglia<= /p>

address: Route de Villejust | = 91620 Nozay | France

------=_NextPart_000_0150_01D10042.FA489F80-- From nobody Tue Oct 6 13:49:51 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB0E1B332B for ; Tue, 6 Oct 2015 13:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-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 Si17Xx0ri3Bz for ; Tue, 6 Oct 2015 13:49:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247FE1B3324 for ; Tue, 6 Oct 2015 13:49:39 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 009BABD11B9DC; Tue, 6 Oct 2015 20:49:32 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id t96KnWHA004781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Oct 2015 20:49:33 GMT Received: from [135.224.17.126] (135.5.27.16) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 6 Oct 2015 16:49:28 -0400 To: Susan Hares , "'PEDRO ANDRES ARANDA GUTIERREZ'" , References: <561298D8.8050200@alcatel-lucent.com> <006601d0ff9f$ae261a40$0a724ec0$@ndzh.com> <5613EC02.4010907@alcatel-lucent.com> <014f01d10064$81542500$83fc6f00$@ndzh.com> From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France Message-ID: <561433D5.8010002@alcatel-lucent.com> Date: Tue, 6 Oct 2015 22:49:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <014f01d10064$81542500$83fc6f00$@ndzh.com> Content-Type: multipart/alternative; boundary="------------030308090806060502050804" X-Originating-IP: [135.5.27.16] Archived-At: Subject: Re: [Ibnemo] Policies and Intent-Based Networking X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2015 20:49:46 -0000 --------------030308090806060502050804 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Sue, Quickly, I can point you to two references (pdf files): -Technical report D24, sections 3.3 and 4.1. (http://tinyurl.com/mr6rhgn) -Use case on Network and Service Governance (http://tinyurl.com/pqmvu8r) For more papers on the topic, I will have to check with the main authors, please let me know... Best regards, Laurent. On 06/10/2015 20:26, Susan Hares wrote: > > Laurent: > > Thank you for letting me know the use case of a network administrator > is valid. Could you send me a direct pointer to the policy continuum > paper. I am having trouble finding it on the site. The research at > www.univerself-project.eu is very > interesting, but I just cannot find the specific paper you mention. > > Sue Hares > > *From:*Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com] > *Sent:* Tuesday, October 06, 2015 11:43 AM > *To:* Susan Hares; 'PEDRO ANDRES ARANDA GUTIERREZ'; ibnemo@ietf.org > *Subject:* Re: [Ibnemo] Policies and Intent-Based Networking > > Dear Sue, all, > > Please see inline... > > On 05/10/2015 20:57, Susan Hares wrote: > > Laurent: > > I agree that the important part of this discussion is: > > a)At which level of abstraction we start (end-user level, > administrator for network), > > b)At which level the �end-systems) operate � �user end-systems� or > �routers that provide entry to network�, > > c)What mechanisms exist to translate from a) starting abstraction > to b) ending abstraction. > > In earlier discussions, we simply looked at the end user as (a) > and the router in a large network as (b). Do you think this is > the right place to start? > > It is surely good enough to start with network operator/administrator > and routers in a large network as policy "end points". > My initial comment was more to stress the levels of _abstraction_ > considered: if the policy entry point is quite abstract (cf previous > policy example) and the policy exit point understands "only" low level > commands, then the mechanism(s) in between will have to cope with such > "distance" between the policy end points, ensuring the continuum of > the policy from the top to the bottom levels. > The main challenge is thus to identify in the defined policy what are > the informational elements (here the modeling is key), these elements > shall then be interpreted (semantics/ontology come to mind), and > finally translated in a format understandable by the next element in > the policy chain. > We have defined such mechanisms for policy continuum in a recent > research project (www.univerself-project.eu > ), applied to autonomic networking. > > Best regards, Laurent. > > > > > Thanks for the insight, > > Sue > > *From:*Ibnemo [mailto:ibnemo-bounces@ietf.org] *On Behalf Of *Laurent > Ciavaglia > *Sent:* Monday, October 05, 2015 11:36 AM > *To:* PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org > > *Subject:* Re: [Ibnemo] Policies and Intent-Based Networking > > Hello, > > My naive opinion on the topic would be as follows: > -Can all policies be expressed as an Intent? > Yes, in the sense that Intent is the "mother" of all policies; > this is what the user initially wants the system to achieve. > > -Should all policies be expressed as Intent? > Not necessarily. Systems limitations and complexity make it more > simple/direct to write a low-level policy/command (i.e. what the > majority of policy-based systems does). > > A key, hidden point is the policy continuum: > 1)-at which level of abstraction the policy starts, > 2)-which level of abstraction the end systems (those receiving the > policy) "understand" (the level of support may be non-uniform), > 3)-what mechanisms exist to translate from 1) to 2), taking into > account possible intermediate levels/layers (e.g. user or service > level, network level, function level, protocol level, resource level..) > > Wrt. Sue's example, I would see an intent-policy defined as: "Steer > customer traffic to relevant customer gateway, and all other traffic > to default (Internet) gateway." (i.e. the "system" will have to figure > out how to understand and translate different customers, what are the > right gateways, etc.) > > HTH, best regards, Laurent. > > > On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote: > > Hi Sue, > > Thanks for clarifying� this is a good food for thought. Answers > inline� > > /PA > > *De: *Sue Hares > *Fecha: *lunes, 5 de octubre de 2015, 14:49 > *Para: *"ibnemo@ietf.org " > *CC: *'Zhoutianran', "'Bert Wijnen (IETF)'", paag > *Asunto: *Policies and Intent-Based Networking > > Hi all: > > Can all policies be expressed an Intent? > > OK, then we end up with something we didn�t quite like/agree upon > in Prague: there are different players with different interests > and background. Therefore, there will be different intents (scoped > by the actor�s view of the world) and maybe different ways of > expressing intent, depending on the user�s background. > > I�m trying to determine what policies can or cannot be > expressed. Any example would be helpful. > > Here�s three policies I�d like to discuss: > > 1)Traffic flow policies > > 2)BGP policies for route flow > > 3)Policy filters controlling routes, > > I�m working on the I2RS extensions for Filter-Based RIB and > BGP (normal and flow filters). The I2RS Filter-based RIB > allow for policies for routing (forwarding a layer 3) to be > associated with a set of interfaces. For example, > > Forwarding filter 1: 128.2/16 nexthop 128.2.1.1 > > Forwarding filters 2: 128.5.1/24 nexthop 128.2.1.2 > > And the rest get forwarded to the default RIB which > > 128/8 nexthop 128.2.1.3 > > The intent is that customer 1 has 128.2/16, and customer 2 > has 128.5.1/24. This node links to these VPNs via 128.2.1.1 > (customer1), and 128.2.1.2 (customer 3). All other traffic > goes to the Internet. > > How do I link this to the normal example of Intent? Can we > render intent down to this level or should I be using a higher > level? > > Let me try a hands-on in NEMO ;-) > > So we have two LinkModels: > > LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix; > > LinkModel Internet Property IPPrefix:nextHop; > > And three Links > > Link VPN1 Type VPN Property > nextHop:�128.2.1.1/32�, destinationPrefix:�128.2/16� ; > > Link VPN2 Type VPN Property > nextHop:�128.2.1.2/32�, destinationPrefix:�128.5.1/24� ; > > Link Default Type Internet Property nextHop:�128.2.1.3/32� ; > > Then we would need 2 NodeModels: > > NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): > subnets ; > > NodeModel InternetNode Property IPPrefix:ID; > > And then the nodes: > > Node VPNTermination1 Type VPNTermination Property > ID:�128.2.1.1/32�, subnets:�128.2/16� ; > > Node VPNTermination2 Type VPNTermination Property > ID:�128.2.1.2/32�, subnets:�128.5.1/24� ; > > Node InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ; > > And finally the connections between the nodes: > > Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ; > > Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ; > > Link Default Type Internet EndNodes thisNode,InternetAccess ; > > So > > Conclusion no. 1: Yes we can� > > Conclusion no.2: Maybe a bit redundant, right? But this can also > be positive, because it would allow for a lot of consistency > checking � > > Dunno what others think� > > My .02 cents, > > --- > > Dr. Pedro A. Aranda Guti�rrez > > Technology Exploration - > > Network Innovation & Virtualisation > > email: pedroa d0t aranda At telefonica d0t com > > Telef�nica, Investigaci�n y Desarrollo > > C/ Zurbar�n,12 > > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > > Fragen sind da, um gestellt zu werden. > > Georg Kreisler > > ------------------------------------------------------------------------ > > > Este mensaje y sus adjuntos se dirigen exclusivamente a su > destinatario, puede contener informaci�n privilegiada o > confidencial y es para uso exclusivo de la persona o entidad de > destino. Si no es usted. el destinatario indicado, queda > notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia > sin autorizaci�n puede estar prohibida en virtud de la legislaci�n > vigente. Si ha recibido este mensaje por error, le rogamos que nos > lo comunique inmediatamente por esta misma v�a y proceda a su > destrucci�n. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the > individual or entity named above. If the reader of this message is > not the intended recipient, you are hereby notified that any > dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this transmission in > error, do not read it. Please immediately reply to the sender that > you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat�rio, pode conter informa��o privilegiada ou confidencial > e � para uso exclusivo da pessoa ou entidade de destino. Se n�o � > vossa senhoria o destinat�rio indicado, fica notificado de que a > leitura, utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode > estar proibida em virtude da legisla��o vigente. Se recebeu esta > mensagem por erro, rogamos-lhe que nos o comunique imediatamente > por esta mesma via e proceda a sua destrui��o > > > > > _______________________________________________ > > Ibnemo mailing list > > Ibnemo@ietf.org > > https://www.ietf.org/mailman/listinfo/ibnemo > > -- > > > Bien cordialement, Best regards, > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > > -- > > Bien cordialement, Best regards, > > *Laurent Ciavaglia* > > Secure Cloud Networking > > Bell Labs | Alcatel Lucent > > phone: +33 160 402 636 > > email: laurent.ciavaglia@alcatel-lucent.com > > > linkedin: laurentciavaglia > > address: Route de Villejust | 91620 Nozay | France > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------030308090806060502050804 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Sue,
Quickly, I can point you to two references (pdf files):
�� -Technical report D24, sections 3.3 and 4.1. (http://tinyurl.com/mr6rhgn)
�� -Use case on Network and Service Governance (http://tinyurl.com/pqmvu8r)
For more papers on the topic, I will have to check with the main authors, please let me know...

Best regards, Laurent.

On 06/10/2015 20:26, Susan Hares wrote:

Laurent:

Thank you for letting me know the use case of a network administrator is valid.� Could you send me a direct pointer to the policy continuum paper.� I am having trouble finding it on the site.� The research at www.univerself-project.eu is very interesting, but I just cannot find the specific paper you mention.

Sue Hares

�

From: Laurent Ciavaglia [mailto:Laurent.Ciavaglia@alcatel-lucent.com]
Sent: Tuesday, October 06, 2015 11:43 AM
To: Susan Hares; 'PEDRO ANDRES ARANDA GUTIERREZ'; ibnemo@ietf.org
Subject: Re: [Ibnemo] Policies and Intent-Based Networking

�

Dear Sue, all,

Please see inline...

On 05/10/2015 20:57, Susan Hares wrote:

Laurent:

I agree that the important part of this discussion is:

a)�� At which level of abstraction we start (end-user level,� administrator for network),

b)�� At which level the �end-systems)� operate � �user end-systems� or �routers that provide entry to network�,

c)�� What mechanisms exist to translate from a) starting abstraction to b) ending abstraction.

�

In earlier discussions, we simply looked at the end user as (a) and the router in a large network as (b).� ��Do you think this is the right place to start?

It is surely good enough to start with network operator/administrator and routers in a large network as policy "end points".
My initial comment was more to stress the levels of abstraction considered: if the policy entry point is quite abstract (cf previous policy example) and the policy exit point understands "only" low level commands, then the mechanism(s) in between will have to cope with such "distance" between the policy end points, ensuring the continuum of the policy from the top to the bottom levels.
The main challenge is thus to identify in the defined policy what are the informational elements (here the modeling is key), these elements shall then be interpreted (semantics/ontology come to mind), and finally translated in a format understandable by the next element in the policy chain.
We have defined such mechanisms for policy continuum in a recent research project (www.univerself-project.eu), applied to autonomic networking.

Best regards, Laurent.

Thanks for the insight,

Sue

From: Ibnemo [mailto:ibnemo-bounces@ietf.org] On Behalf Of Laurent Ciavaglia
Sent: Monday, October 05, 2015 11:36 AM
To: PEDRO ANDRES ARANDA GUTIERREZ; Susan Hares; ibnemo@ietf.org
Subject: Re: [Ibnemo] Policies and Intent-Based Networking

�

Hello,

My naive opinion on the topic would be as follows:
�� -Can all policies be expressed as an Intent?
�� Yes, in the sense that Intent is the "mother" of all policies; this is what the user initially wants the system to achieve.

�� -Should all policies be expressed as Intent?
�� Not necessarily. Systems limitations and complexity make it more simple/direct to write a low-level policy/command (i.e. what the majority of policy-based systems does).

A key, hidden point is the policy continuum:
�� 1)-at which level of abstraction the policy starts,
�� 2)-which level of abstraction the end systems (those receiving the policy) "understand" (the level of support may be non-uniform),
�� 3)-what mechanisms exist to translate from 1) to 2), taking into account possible intermediate levels/layers (e.g. user or service level, network level, function level, protocol level, resource level..)

Wrt. Sue's example, I would see an intent-policy defined as: "Steer customer traffic to relevant customer gateway, and all other traffic to default (Internet) gateway." (i.e. the "system" will have to figure out how to understand and translate different customers, what are the right gateways, etc.)

HTH, best regards, Laurent.

On 05/10/2015 16:49, PEDRO ANDRES ARANDA GUTIERREZ wrote:
Hi Sue,

�

Thanks for clarifying� this is a good food for thought. Answers inline�

�

/PA

�

De: Sue Hares
Fecha: lunes, 5 de octubre de 2015, 14:49
Para: "ibnemo@ietf.org"
CC: 'Zhoutianran', "'Bert Wijnen (IETF)'", paag
Asunto: Policies and Intent-Based Networking

�

Hi all:

�

Can all policies be expressed an Intent?

�

OK, then we end up with something we didn�t quite like/agree upon in Prague: there are different players with different interests and background. Therefore, there will be different intents (scoped by the actor�s view of the world) and maybe different ways of expressing intent, depending on the user�s background.

�

I�m trying to determine what policies can or cannot be expressed.� Any example would be helpful.

�

Here�s three policies I�d like to discuss:

�

1)�� Traffic flow policies ��

2)�� BGP policies for route flow

3)�� Policy filters controlling routes,

�

I�m working on the I2RS extensions for Filter-Based RIB and BGP (normal and flow filters). ��The I2RS Filter-based RIB allow for policies for routing (forwarding a layer 3) to be associated with a set of interfaces.� �For example,

�

Forwarding filter 1:� 128.2/16 nexthop 128.2.1.1 ��

Forwarding filters 2:�� 128.5.1/24 nexthop 128.2.1.2 �

�

And the rest get forwarded to the default RIB which

��128/8� nexthop 128.2.1.3

�

The intent �is that customer 1 has 128.2/16, and customer 2 has 128.5.1/24.� �This node links to these VPNs via 128.2.1.1 (customer1), and 128.2.1.2 (customer 3).� All other traffic goes to the Internet.

How do I link this to the normal example of Intent?� �Can we render intent down to this level or should I be using a higher level?

�

�

Let me try a hands-on in NEMO ;-)�

�

So we have two LinkModels:

�

LinkModel VPN Property IPPrefix:nextHop, IPPrefix:destinationPrefix;

LinkModel Internet Property IPPrefix:nextHop;

�

And three Links

�

Link VPN1 Type VPN Property nextHop:�128.2.1.1/32�,�destinationPrefix:�128.2/16� ;

Link VPN2 Type VPN Property nextHop:�128.2.1.2/32�,�destinationPrefix:�128.5.1/24� ;

Link Default Type Internet Property nextHop:�128.2.1.3/32� ;

�

Then we would need 2 NodeModels:

�

NodeModel VPNTermination Property IPPrefix:ID, list(IPPrefix): subnets ;

NodeModel InternetNode Property IPPrefix:ID;

�

And then the nodes:

�

Node VPNTermination1 Type VPNTermination Property ID:�128.2.1.1/32�, subnets:�128.2/16� ;

Node VPNTermination2 Type�VPNTermination Property ID:�128.2.1.2/32�,�subnets:�128.5.1/24� ;

Node�InternetAccess Type InternetNode Property ID:�128.2.1.3/32� ;

�

And finally the connections between the nodes:

�

Link VPN1 Type VPN EndNodes thisNode,VPNTermination1 ;

Link VPN2 Type VPN EndNodes thisNode,VPNTermination2 ;

Link Default Type Internet EndNodes thisNode,InternetAccess ;

�

So�

�

Conclusion no. 1: Yes we can��

Conclusion no.2: Maybe a bit redundant, right? But this can also be positive, because it would allow for a lot of consistency checking �

�

Dunno what others think�

�

My .02 cents,

�

---

Dr. Pedro A. Aranda Guti�rrez

�

Technology Exploration -

Network Innovation & Virtualisation

email: pedroa d0t aranda At telefonica d0t com

Telef�nica, Investigaci�n y Desarrollo

C/ Zurbar�n,12

28010 Madrid, Spain

�

Fragen sind nicht da, um beantwortet zu werden.

Fragen sind da, um gestellt zu werden.

Georg Kreisler

�

�

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci�n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci�n, divulgaci�n y/o copia sin autorizaci�n puede estar prohibida en virtud de la legislaci�n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v�a y proceda a su destrucci�n.

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

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat�rio, pode conter informa��o privilegiada ou confidencial e � para uso exclusivo da pessoa ou entidade de destino. Se n�o � vossa senhoria o destinat�rio indicado, fica notificado de que a leitura, utiliza��o, divulga��o e/ou c�pia sem autoriza��o pode estar proibida em virtude da legisla��o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui��o
_______________________________________________
Ibnemo mailing list
Ibnemo@ietf.org
https://www.ietf.org/mailman/listinfo/ibnemo
�

--

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

�

--

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

Bien cordialement, Best regards,

�

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

�

phone: +33�160 402�636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------030308090806060502050804-- From nobody Thu Oct 8 01:53:23 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D421A8AD7 for ; Thu, 8 Oct 2015 01:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 QxvLAahyMgCv for ; Thu, 8 Oct 2015 01:53:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF941A8AD6 for ; Thu, 8 Oct 2015 01:53:17 -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 BYN16975; Thu, 08 Oct 2015 08:53:15 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 8 Oct 2015 09:53:13 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0235.001; Thu, 8 Oct 2015 16:53:10 +0800 From: Zhoutianran To: "ibnemo@ietf.org" Thread-Topic: Hackathon activity in Yokohama Thread-Index: AdEBpsEkQ8Ytg2btTWiXbjeWqy0HRg== Date: Thu, 8 Oct 2015 08:53:09 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ibnemo] Hackathon activity in Yokohama X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2015 08:53:21 -0000 Hi All, We are going to host a hackathon topic on IBNEMO and the intent description= language in Yokohama IETF meeting. The proposal was listed on the IETF hackathon wiki page at: https://www.iet= f.org/registration/MeetingWiki/wiki/94hackathon And the sign up is at: https://www.ietf.org/registration/ietf94/hackathonre= gistration.py The hands on code will be based on the NEMO project in Opendaylight. I also attached the following information for your convenience. It's an opportunity to play on the NEMO language and discuss the features. Welcome to join us and enjoy. Cheers, Tianran ---------------------------------- IBNEMO(Intent Based Network Modeling)=20 NEMO Language is an Intent oriented network DSL (domain specific language) = and NBI. Operator/End-user or 3rd party can use it to program network resou= rce and behaviour in their service applications. It's now being implemented= in Opendaylight (https://wiki.opendaylight.org/view/NEMO:Main). -Tasks --set up the integration environment --develop applications to use the NEMO API --develop useful tools=20 -Possible use cases --virtual private cloud integrating NetID --end to end carrier network including vCPE -Champions --Tianran Zhou (zhoutianran@huawei.com) --Pedro Aranda (pedroa.aranda@telefonica.com) --Qiao Fu (fuqiao@chinamobile.com) From nobody Sun Oct 11 00:22:14 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D75A1B29D6 for ; Sun, 11 Oct 2015 00:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 psYjcuNtPRZX for ; Sun, 11 Oct 2015 00:22:09 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA441B29D4 for ; Sun, 11 Oct 2015 00:22:08 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 350032F00A0; Sun, 11 Oct 2015 09:22:05 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 1C8772F007D; Sun, 11 Oct 2015 09:22:05 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 11 Oct 2015 09:22:04 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.293.16; Sun, 11 Oct 2015 07:21:02 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0293.007; Sun, 11 Oct 2015 07:21:02 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Zhoutianran , "ibnemo@ietf.org" Thread-Topic: [Ibnemo] Hackathon activity in Yokohama Thread-Index: AdEBpsEkQ8Ytg2btTWiXbjeWqy0HRgCX2QCA Date: Sun, 11 Oct 2015 07:21:02 +0000 Message-ID: <6252FA71-FE1F-4EB1-AB35-368CB0C43C34@telefonica.com> References: In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [83.50.99.12] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:1OV8EmRQx1i8Yha98ODcwRcRAiEi4QoCFR6owc0ZZTkeaGjKoUnJnfTLk0cEqoquLyoiEitjULPMRioyykYCAMvaaPfiGS/SCRT15nln/1e+V83ZFUfC9dwGn/kxtC6zq6CjoxBXazh1TDJFzRG+jg==; 24:fw7juO56uSVN0c4MGcIjvtqEAdC3JGZVus4S4dicATv87g1vtENU/ZLWmZK13tNR4pGjaBYzft1otlWzUH0iy1e7n4a8zpflZ43vmuk6GL8=; 20:O8CT6r4kXafQC4tez6ktMyFrAXtJI1j8sbhKmCy//PGNx+xUjteKnDf9K6Ywi0sMh3GA1TP0LUZ+CtvXlsvQHw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 0726B2D7A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(59124003)(199003)(53754006)(40100003)(122556002)(101416001)(5001770100001)(10400500002)(46102003)(83506001)(107886002)(82746002)(5890100001)(87936001)(97736004)(64706001)(54356999)(83716003)(76176999)(4001350100001)(81156007)(2501003)(5008740100001)(102836002)(11100500001)(66066001)(106356001)(561944003)(33656002)(575784001)(5007970100001)(5004730100002)(86362001)(5001960100002)(105586002)(19580395003)(92566002)(77096005)(50986999)(36756003)(189998001)(15975445007)(19580405001)(2900100001)(5002640100001)(2950100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <417529FC95E42F42ABBE2FD1BF382CB9@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2015 07:21:02.6652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [Ibnemo] Hackathon activity in Yokohama X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 07:22:13 -0000 SGksDQoNCkFscmVhZHkgc2lnbmVkIHVwLiBJIHdpbGwgYmUgYnJpbmdpbmcgdGhlIGxhdGVzdCBO RU1PIGVkaXRvciB3ZSBoYXZlIGRldmVsb3BlZCBpbiB0aGUgTmV0SURFIHByb2plY3QoaHR0cDov L3d3dy5uZXRpZGUuZXUpLg0KSXTigJlzIEVjbGlwc2UgKFh0ZXh0KSBiYXNlZCBhbmQgSeKAmW0g c3VyZSB0aGUgaGFja2F0aG9uIHdpbGwgYmUgYSB3b25kZXJmdWwgb3Bwb3J0dW5pdHkgdG8gZmlu ZSB0dW5lIGl0IDotKQ0KDQovUEENCi0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6 DQoNClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJbm5vdmF0aW9uICYgVmlydHVh bGlzYXRpb24NCmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBjb20N ClRlbGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8NCkMvIFp1cmJhcsOhbiwx Mg0KMjgwMTAgTWFkcmlkLCBTcGFpbg0KDQpGcmFnZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3 b3J0ZXQgenUgd2VyZGVuLg0KRnJhZ2VuIHNpbmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi4N Ckdlb3JnIEtyZWlzbGVyDQoNCg0KDQoNCg0KDQoNCg0KDQotLS0tLU1lbnNhamUgb3JpZ2luYWwt LS0tLQ0KRGU6IElibmVtbyBlbiBub21icmUgZGUgWmhvdXRpYW5yYW4NCkZlY2hhOiBqdWV2ZXMs IDggZGUgb2N0dWJyZSBkZSAyMDE1LCAxMDo1Mw0KUGFyYTogImlibmVtb0BpZXRmLm9yZyINCkFz dW50bzogW0libmVtb10gSGFja2F0aG9uIGFjdGl2aXR5IGluIFlva29oYW1hDQoNCj5IaSBBbGws DQo+DQo+V2UgYXJlIGdvaW5nIHRvIGhvc3QgYSBoYWNrYXRob24gdG9waWMgb24gSUJORU1PIGFu ZCB0aGUgaW50ZW50IGRlc2NyaXB0aW9uIGxhbmd1YWdlIGluIFlva29oYW1hIElFVEYgbWVldGlu Zy4NCj5UaGUgcHJvcG9zYWwgd2FzIGxpc3RlZCBvbiB0aGUgSUVURiBoYWNrYXRob24gd2lraSBw YWdlIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vTWVldGluZ1dpa2kvd2lr aS85NGhhY2thdGhvbg0KPkFuZCB0aGUgc2lnbiB1cCBpcyBhdDogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmVnaXN0cmF0aW9uL2lldGY5NC9oYWNrYXRob25yZWdpc3RyYXRpb24ucHkNCj4NCj5UaGUg aGFuZHMgb24gY29kZSB3aWxsIGJlIGJhc2VkIG9uIHRoZSBORU1PIHByb2plY3QgaW4gT3BlbmRh eWxpZ2h0Lg0KPkkgYWxzbyBhdHRhY2hlZCB0aGUgZm9sbG93aW5nIGluZm9ybWF0aW9uIGZvciB5 b3VyIGNvbnZlbmllbmNlLg0KPkl0J3MgYW4gb3Bwb3J0dW5pdHkgdG8gcGxheSBvbiB0aGUgTkVN TyBsYW5ndWFnZSBhbmQgZGlzY3VzcyB0aGUgZmVhdHVyZXMuDQo+V2VsY29tZSB0byBqb2luIHVz IGFuZCBlbmpveS4NCj4NCj5DaGVlcnMsDQo+VGlhbnJhbg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj5JQk5FTU8oSW50ZW50IEJhc2VkIE5ldHdvcmsgTW9kZWxpbmcp DQo+DQo+TkVNTyBMYW5ndWFnZSBpcyBhbiBJbnRlbnQgb3JpZW50ZWQgbmV0d29yayBEU0wgKGRv bWFpbiBzcGVjaWZpYyBsYW5ndWFnZSkgYW5kIE5CSS4gT3BlcmF0b3IvRW5kLXVzZXIgb3IgM3Jk IHBhcnR5IGNhbiB1c2UgaXQgdG8gcHJvZ3JhbSBuZXR3b3JrIHJlc291cmNlIGFuZCBiZWhhdmlv dXIgaW4gdGhlaXIgc2VydmljZSBhcHBsaWNhdGlvbnMuIEl0J3Mgbm93IGJlaW5nIGltcGxlbWVu dGVkIGluIE9wZW5kYXlsaWdodCAoaHR0cHM6Ly93aWtpLm9wZW5kYXlsaWdodC5vcmcvdmlldy9O RU1POk1haW4pLg0KPg0KPi1UYXNrcw0KPi0tc2V0IHVwIHRoZSBpbnRlZ3JhdGlvbiBlbnZpcm9u bWVudA0KPi0tZGV2ZWxvcCBhcHBsaWNhdGlvbnMgdG8gdXNlIHRoZSBORU1PIEFQSQ0KPi0tZGV2 ZWxvcCB1c2VmdWwgdG9vbHMNCj4NCj4tUG9zc2libGUgdXNlIGNhc2VzDQo+LS12aXJ0dWFsIHBy aXZhdGUgY2xvdWQgaW50ZWdyYXRpbmcgTmV0SUQNCj4tLWVuZCB0byBlbmQgY2FycmllciBuZXR3 b3JrIGluY2x1ZGluZyB2Q1BFDQo+DQo+LUNoYW1waW9ucw0KPi0tVGlhbnJhbiBaaG91ICh6aG91 dGlhbnJhbkBodWF3ZWkuY29tKQ0KPi0tUGVkcm8gQXJhbmRhIChwZWRyb2EuYXJhbmRhQHRlbGVm b25pY2EuY29tKQ0KPi0tUWlhbyBGdSAoZnVxaWFvQGNoaW5hbW9iaWxlLmNvbSkNCj4NCj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPklibmVtbyBtYWls aW5nIGxpc3QNCj5JYm5lbW9AaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2libmVtbw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpF c3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50ZSBhIHN1 IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVnaWFkYSBv IGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25hIG8gZW50 aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGluZGljYWRv LCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVs Z2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRh IGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0 ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1l ZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOz bi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlzc2lvbiBpcyBw cml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQgb25seSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHRoZSBy ZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIGRvIG5vdCBy ZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0aGF0IHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhlbiBkZWxldGUg aXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1l bnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmls ZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Eg b3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3Rp bmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0dXJhLCB1dGls aXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHDp8OjbyBwb2Rl IGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2VudGUuIFNlIHJl Y2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5vcyBvIGNvbXVu aXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEgYSBzdWEgZGVz dHJ1acOnw6NvDQo= From nobody Sun Oct 11 02:42:10 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714461A6F51 for ; Sun, 11 Oct 2015 02:42:08 -0700 (PDT) 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, J_CHICKENPOX_66=0.6, 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 c26q8NjApyOO for ; Sun, 11 Oct 2015 02:42:05 -0700 (PDT) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD751A6F49 for ; Sun, 11 Oct 2015 02:42:05 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud3.xs4all.net with ESMTP id Tlhx1r00M3vXPcr01lhzff; Sun, 11 Oct 2015 11:42:03 +0200 To: PEDRO ANDRES ARANDA GUTIERREZ , Zhoutianran , "ibnemo@ietf.org" References: <6252FA71-FE1F-4EB1-AB35-368CB0C43C34@telefonica.com> From: "Bert Wijnen (IETF)" Message-ID: <561A2EE6.3000301@bwijnen.net> Date: Sun, 11 Oct 2015 11:41:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6252FA71-FE1F-4EB1-AB35-368CB0C43C34@telefonica.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ibnemo] Hackathon activity in Yokohama X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2015 09:42:08 -0000 I also registered. But only checked the Sunday box. I will be arriving during the day Saturday, and probably need some slee first when I arrive. Bert On 11/10/15 09:21, PEDRO ANDRES ARANDA GUTIERREZ wrote: > Hi, > > Already signed up. I will be bringing the latest NEMO editor we have developed in the NetIDE project(http://www.netide.eu). > It’s Eclipse (Xtext) based and I’m sure the hackathon will be a wonderful opportunity to fine tune it :-) > > /PA > --- > Dr. Pedro A. Aranda Gutiérrez > > Technology Exploration - > Network Innovation & Virtualisation > email: pedroa d0t aranda At telefonica d0t com > Telefónica, Investigación y Desarrollo > C/ Zurbarán,12 > 28010 Madrid, Spain > > Fragen sind nicht da, um beantwortet zu werden. > Fragen sind da, um gestellt zu werden. > Georg Kreisler > > > > > > > > > > -----Mensaje original----- > De: Ibnemo en nombre de Zhoutianran > Fecha: jueves, 8 de octubre de 2015, 10:53 > Para: "ibnemo@ietf.org" > Asunto: [Ibnemo] Hackathon activity in Yokohama > >> Hi All, >> >> We are going to host a hackathon topic on IBNEMO and the intent description language in Yokohama IETF meeting. >> The proposal was listed on the IETF hackathon wiki page at: https://www.ietf.org/registration/MeetingWiki/wiki/94hackathon >> And the sign up is at: https://www.ietf.org/registration/ietf94/hackathonregistration.py >> >> The hands on code will be based on the NEMO project in Opendaylight. >> I also attached the following information for your convenience. >> It's an opportunity to play on the NEMO language and discuss the features. >> Welcome to join us and enjoy. >> >> Cheers, >> Tianran >> >> ---------------------------------- >> IBNEMO(Intent Based Network Modeling) >> >> NEMO Language is an Intent oriented network DSL (domain specific language) and NBI. Operator/End-user or 3rd party can use it to program network resource and behaviour in their service applications. It's now being implemented in Opendaylight (https://wiki.opendaylight.org/view/NEMO:Main). >> >> -Tasks >> --set up the integration environment >> --develop applications to use the NEMO API >> --develop useful tools >> >> -Possible use cases >> --virtual private cloud integrating NetID >> --end to end carrier network including vCPE >> >> -Champions >> --Tianran Zhou (zhoutianran@huawei.com) >> --Pedro Aranda (pedroa.aranda@telefonica.com) >> --Qiao Fu (fuqiao@chinamobile.com) >> >> _______________________________________________ >> Ibnemo mailing list >> Ibnemo@ietf.org >> https://www.ietf.org/mailman/listinfo/ibnemo > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição > _______________________________________________ > Ibnemo mailing list > Ibnemo@ietf.org > https://www.ietf.org/mailman/listinfo/ibnemo I From nobody Wed Oct 14 07:16:11 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262B1A87AF for ; Wed, 14 Oct 2015 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.554 X-Spam-Level: X-Spam-Status: No, score=-94.554 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, FILL_THIS_FORM=0.001, FILL_THIS_FORM_LONG=2, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] 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 KEtaKgOQjFGW for ; Wed, 14 Oct 2015 07:16:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974BD1A87A8 for ; Wed, 14 Oct 2015 07:16:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=195.53.52.170; From: "Susan Hares" To: Date: Wed, 14 Oct 2015 10:15:44 -0400 Message-ID: <001401d1068a$d204abb0$760e0310$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01D10669.4AF7C6A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdEGaY5x7K1ZMvNqQMSG+MSLkrTEsw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Ibnemo] service based intent X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 14:16:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0015_01D10669.4AF7C6A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: I could really use some help this week on service-based intent as I'm trying to link service-based intent to the various service modes. At IETF 93, we described the application expressing their service level needs at a service level by expressing the service needs, and letting the Intent based work negotiate the service. I would like to explore how this works for five different types of services: L3VPN, L2VPN, and EVPN, Cable-network services, B-2B. However, let me start with the L3VPN which has an IETF service level description (draft-ietf-l3sm-l3vpn-service-model-01) or https://tools.ietf.org/pdf/draft-ietf-l3sm-l3vpn-service-model-01.pdf. See the bottom of the page for the diagram of an L3VPN network. L3SM The L3VPN Service model limits is description to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]. The L3SM model is input to the orchestration system shown in the diagram below this text. The L3SM provides two top level information: 1) vpn-svc [name] 2) sites* [site-id] vpn-svc [name] list has the following components per service: . name, id, customer-name, topology id, cloud access, mpls, multicast tree sites [id] list has the following components per site: . Site-id . Apply-template (yes/no) . site level parameters [start/stop service time, location, site diversity, availability, management, vpn policies, maximum number of routes, management, VPN policies, customer-info, security, physical attachment (aka bearer), service parameters (bandwidth in/out, QOS, traffic protection, mpls, protocols-run), site templates An example from draft-ietf-l3sm-l3vpn-service-model-01 is: ZKITYHJ054687 12456487

CUSTOMER_1

any-to-any

true

1.1.1.1

IB-Nemo Intent to Create this L3SM Concept: IBNemo - would have the sites become nodes with specific EndNodes as the end nodes at each site. The L3VPN would be created by the following statement: Create Connection ZKITYHJ054687 Type L3SM EndNodes . Property id: 1245487; customer-name: Customer1; topology: any-to-any; cloud-access-cloud-identifier: 51; cloud-access-nat-enabled: true; cloud-access-nat-address: 1.1.1.1; mpls-signaling-type: BGP; multicast-tree: SSM; The problem is that one would like hierarchy in the property so that one can give cloud access the following type of syntax: Create Property cloud-access [id] { identifier: 51; nat-enabled: true; nat-address: 1.1.1.1; } Is this possible with Nemo properties? This would shorten the definition to: Create Connection ZKITYHJ054687 Type L3SM EndNodes . Property id: 1245487; customer-name: Customer1; topology: any-to-any; cloud-access: 51; mpls-signaling-type: BGP; multicast-tree: SSM; Thank you. Background info ------------------ The sites is a list of sites where each site has the following information: . Site-id . Apply-template (yes/no) . site level parameters: o Requested start/stop o Actual start/stop o Location: address, zip, city, country code, o Site diversity - (type, site-group) o Availability (Availability type (service-type, access-type), Loadsharing: type) o Management: Type, transport, address o VPN policies o Maximum number of routes o Customer specified information o Security (apply template, authentication, encryption) o Attachment (apply template, bearer, ip-connection) o Service (apply template, Bandwidth In, Bandwith out, svc-mtu, QOS, traffic protection, mpls, multicast, prototype type) o Site-templates ASCII diagram for L3VPN-SVC Model L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | +----------------+ | | | | Netconf/CLI ... | | +------------------------------------------------+ Network +++++++ + AAA + +++++++ +++++++ Bearer ++++++++ ++++++++ +++++++ + CEA + ------- + PE A + + PE B + ----- + CEB + +++++++ Cnct ++++++++ ++++++++ +++++++ Site A Site B ------=_NextPart_000_0015_01D10669.4AF7C6A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all: =

I could really use some help this week on = service-based intent as I’m trying to link service-based intent to = the various service modes. At IETF 93, we described the = application expressing their service level needs at a service level by = expressing the service needs, and letting the Intent based work = negotiate the service.

I would like = to explore how this works for five different types of services: = L3VPN, L2VPN, and EVPN, Cable-network services, B-2B. However, let me = start with the L3VPN which has an IETF service level description = (draft-ietf-l3sm-l3vpn-service-model-01) or

https://tools.ietf.org/pdf/draft-ietf-l3sm-l3vpn-service-model-01.p= df. See the bottom of the page for the diagram of an = L3VPN network.

L3SM

The = L3VPN Service model limits is description to BGP PE-Based VPNs as = described in [RFC4110] and [RFC4364]. The L3SM model is input to = the orchestration system shown in the diagram below this text. The = L3SM provides two top level information:

1) = vpn-svc [name]

2) = sites* [site-id]

vpn-svc = [name] list has the following components per service: =

· = name, id, customer-name, topology id, = cloud access, mpls, multicast tree

sites [id] list has the following components per site: =

· = Site-id

· = Apply-template (yes/no)

· = site level parameters [start/stop service = time, location, site diversity, availability, management, vpn policies, = maximum number of routes, management, VPN policies, = customer-info, security, physical attachment (aka bearer), service = parameters (bandwidth in/out, QOS, traffic protection, mpls, = protocols-run), site templates

An example = from draft-ietf-l3sm-l3vpn-service-model-01 is:

<vpn-svc>

<name>ZKITYHJ054687</name>

<customer-name>CUSTOMER_1</customer-name>

<cloud-access>

<cloud-identifier>51</cloud-identifier>

<nat-enabled>true</nat-enabled><= /p>

<nat-address>1.1.1.1</nat-address>

</cloud-access>

</vpn-svc>

IB-Nemo = Intent to Create this L3SM

Concept: = IBNemo – would have the sites become nodes with specific EndNodes = as the end nodes at each site. The L3VPN would be created by = the following statement:

Create = Connection ZKITYHJ054687

&= nbsp; Type L3SM

&= nbsp; EndNodes <site_1> <site_2> <site_3> … = <site_n>

&= nbsp; Property id: 1245487; customer-name: Customer1; topology: = any-to-any;

&= nbsp; &n= bsp; cloud-access-cloud-identifier: 51; =

&= nbsp; &n= bsp; cloud-access-nat-enabled: = true;

&= nbsp; &n= bsp; cloud-access-nat-address: 1.1.1.1; =

&= nbsp; &n= bsp; = mpls-signaling-type: BGP;

&= nbsp; &n= bsp; multicast-tree: SSM;

The problem = is that one would like hierarchy in the property so that one can give = cloud access the following type of syntax:

&= nbsp; Create Property cloud-access [id] = {

&= nbsp; identifier: 51; =

&= nbsp; nat-enabled: = true;

&= nbsp; nat-address: 1.1.1.1; =

&= nbsp;}

Is this possible with Nemo properties? =

&= nbsp;

This would shorten the definition to: =

&= nbsp; Create Connection ZKITYHJ054687

&= nbsp; Type L3SM

&= nbsp; EndNodes <site_1> <site_2> <site_3> … = <site_n>

&= nbsp; Property id: 1245487;

&= nbsp; &n= bsp; customer-name: Customer1; =

&= nbsp; &n= bsp; topology: any-to-any; =

&= nbsp; &n= bsp; cloud-access: 51;

&= nbsp; = &= nbsp; mpls-signaling-type: BGP;

&= nbsp; &n= bsp; multicast-tree: SSM;

Thank = you.

Background = info

------------------

The sites is a list of sites where = each site has the following information:

· = Site-id

· = Apply-template (yes/no)

· = site level parameters:

o Requested = start/stop

o Actual = start/stop

o Location: = address, zip, city, country code,

o Site diversity = – (type, site-group)

o Availability = (Availability type (service-type, access-type), Loadsharing: type) =

o Management: = Type, transport, address

o VPN policies =

o Maximum number = of routes

o Customer = specified information

o Security (apply = template, authentication, encryption)

o Attachment = (apply template, bearer, ip-connection)

o Service (apply = template, Bandwidth In, Bandwith out, svc-mtu, QOS, traffic protection, = mpls, multicast, prototype type)

o Site-templates =

ASCII diagram for L3VPN-SVC Model

L3VPN-SVC = |

= MODEL |

= |

= +------------------+ = +-----+

| Orchestration | < = --- > | OSS |

= +------------------+ = +-----+

= | = |

+----------------+ = |

| Config manager | = |

+----------------+ = |

| = |

| Netconf/CLI ...

| = |

+------------------------------------------------+

Network

+++++++

+ AAA = +

+++++++

+++++++ = Bearer ++++++++ = ++++++++ = +++++++

+ CEA + ------- + = PE A + + PE B + ----- + CEB = +

+++++++ = Cnct ++++++++ = ++++++++ = +++++++

Site = A = = Site B

------=_NextPart_000_0015_01D10669.4AF7C6A0-- From nobody Wed Oct 14 21:49:27 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C49E1B304B for ; Wed, 14 Oct 2015 21:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 W7alJ7eubsEv for ; Wed, 14 Oct 2015 21:49:24 -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 B71F61B304A for ; Wed, 14 Oct 2015 21:49:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCO45305; Thu, 15 Oct 2015 04:49:21 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 15 Oct 2015 05:49:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Thu, 15 Oct 2015 12:49:15 +0800 From: Zhoutianran To: "ibnemo@ietf.org" Thread-Topic: New Version Notification for draft-xia-sdnrg-nemo-language-03.txt Thread-Index: AQHRBvKrb9/TPagVUU+BRQwiBRKr6Z5rY9kAgACXdyA= Date: Thu, 15 Oct 2015 04:49:15 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Ibnemo] FW: New Version Notification for draft-xia-sdnrg-nemo-language-03.txt X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 04:49:26 -0000 SGkgQWxsLA0KDQpJIGp1c3QgdXBkYXRlZCB0aGUgaW50ZW50IGJhc2VkIE5FTU8gbGFuZ3VhZ2Ug c3BlY2lmaWNhdGlvbi4NClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQuDQoNClRoYW5rcywNClRp YW5yYW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LXhpYS1zZG5yZy1uZW1vLWxhbmd1YWdlLTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vz c2Z1bGx5IHN1Ym1pdHRlZCBieSBUaWFucmFuIFpob3UgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQteGlhLXNkbnJnLW5lbW8tbGFuZ3VhZ2UNClJldmlz aW9uOgkwMw0KVGl0bGU6CQlORU1PIChORXR3b3JrIE1PZGVsaW5nKSBMYW5ndWFnZQ0KRG9jdW1l bnQgZGF0ZToJMjAxNS0xMC0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2Vz OgkJMjMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQteGlhLXNkbnJnLW5lbW8tbGFuZ3VhZ2UtMDMudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteGlhLXNkbnJnLW5lbW8tbGFu Z3VhZ2UvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXhpYS1zZG5yZy1uZW1vLWxhbmd1YWdlLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXhpYS1zZG5yZy1uZW1vLWxhbmd1YWdlLTAzDQoN CkFic3RyYWN0Og0KICAgVGhlIE5vcnRoLUJvdW5kIEludGVyZmFjZSAoTkJJKSwgbG9jYXRlZCBi ZXR3ZWVuIHRoZSBjb250cm9sIHBsYW5lDQogICBhbmQgdGhlIGFwcGxpY2F0aW9ucywgaXMgZXNz ZW50aWFsIHRvIGVuYWJsZSB0aGUgYXBwbGljYXRpb24NCiAgIGlubm92YXRpb25zIGFuZCBub3Vy aXNoIHRoZSBlY28tc3lzdGVtIG9mIFNETi4NCg0KICAgV2hpbGUgbW9zdCBvZiB0aGUgTkJJcyBh cmUgcHJvdmlkZWQgaW4gdGhlIGZvcm0gb2YgQVBJLCB0aGlzIGRvY3VtZW50DQogICBwcm9wb3Nl cyB0aGUgTkV0d29yayBNT2RlbGluZyAoTkVNTykgbGFuZ3VhZ2Ugd2hpY2ggaXMgaW50ZW50IGJh c2VkDQogICBpbnRlcmZhY2Ugd2l0aCBub3ZlbCBsYW5ndWFnZSBmYXNoaW9uLiAgQ29uY2VwdCwg bW9kZWwgYW5kIHN5bnRheCBhcmUNCiAgIGludHJvZHVjZWQgaW4gdGhlIGRvY3VtZW50Lg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== From nobody Thu Oct 15 12:00:47 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D421B34EC for ; Thu, 15 Oct 2015 12:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2MHBKYoPJq9n for ; Thu, 15 Oct 2015 12:00:44 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3ED1B34E8 for ; Thu, 15 Oct 2015 12:00:36 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id VX0X1r0013vXPcr01X0YLN; Thu, 15 Oct 2015 21:00:34 +0200 To: "ibnemo@ietf.org" From: "Bert Wijnen (IETF)" Message-ID: <561FF7D1.2010804@bwijnen.net> Date: Thu, 15 Oct 2015 21:00:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Ibnemo] topic: box commands X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:00:46 -0000 Anita (last name?) aked during our bar-bof at IETF93: Network orders outside of the carrier could be done in Nemo and then it would break into the “box commands”. Not 100% sure what she meant with "box commands". Anita, if you are on this list, please elaborate. Possibly she meant that if a customer requests some connectivity between say 2 locations, then "intent" should be able to express that and the IBNEMO engine would translate that into commands for each box (device) that is onvolved in the connection. Potentially that could be CLI commands, or possibly that could be YANG/NETCONF/RESTCONF configuration commands. Anita? Or anyone else who has input/views on this. Bert From nobody Thu Oct 15 12:03:37 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F891B344D for ; Thu, 15 Oct 2015 12:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GInjbXxYi8K3 for ; Thu, 15 Oct 2015 12:03:34 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E3A91AD34D for ; Thu, 15 Oct 2015 12:03:34 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id VX3W1r00D3vXPcr01X3YgR; Thu, 15 Oct 2015 21:03:32 +0200 To: "ibnemo@ietf.org" From: "Bert Wijnen (IETF)" Message-ID: <561FF885.1020904@bwijnen.net> Date: Thu, 15 Oct 2015 21:03:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ibnemo] Configured service models X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:03:36 -0000 During our bar-bof at IETF93, Benoit asked/stated: Configured service models are outside the scope of the IETF. We're not sure what Benoit meant here. Benoit, can you elaborate? If others have views/opinions, pleas make them know to this list. Bert From nobody Thu Oct 15 12:08:24 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97AD1AD34F for ; Thu, 15 Oct 2015 12:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w5Lj-aL4LhuK for ; Thu, 15 Oct 2015 12:08:22 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D5B1AD333 for ; Thu, 15 Oct 2015 12:08:22 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id VX8K1r0033vXPcr01X8L98; Thu, 15 Oct 2015 21:08:20 +0200 To: "ibnemo@ietf.org" From: "Bert Wijnen (IETF)" Message-ID: <561FF9A5.2030609@bwijnen.net> Date: Thu, 15 Oct 2015 21:08:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ibnemo] 80/20 rule for the set of intent expressions/commands X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:08:23 -0000 During the bar-bof at ietf93, it seemed to us that we need additional details on why the 80/20 rule is useful. These details should include: a)What is the long-term benefit for applications? b)Why does a more user-friendly interface help? c)What is the benefit for the service provider? We will try to answer some of this, but discussion and views from a wider audience can be very helpful. None of the IBNEMO stuff is fixed in stone yet. We are only at the beginning. We need to discuss and work together to define a proper set of "intent commands" or "intent statements" and have an idea as to why and how the set we focus on as the 20% of the most used commands can indeed address 80% of the normal application/user needs. Input or discussion is very welcome. Bert From nobody Thu Oct 15 12:12:11 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932021A000D for ; Thu, 15 Oct 2015 12:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9lgp2v3kpKYk for ; Thu, 15 Oct 2015 12:12:08 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89BF1A000E for ; Thu, 15 Oct 2015 12:12:07 -0700 (PDT) Received: from Macintosh.fritz.box ([83.163.239.181]) by smtp-cloud6.xs4all.net with ESMTP id VXC31r00P3vXPcr01XC6WN; Thu, 15 Oct 2015 21:12:06 +0200 To: "ibnemo@ietf.org" From: "Bert Wijnen (IETF)" Message-ID: <561FFA86.9090302@bwijnen.net> Date: Thu, 15 Oct 2015 21:12:06 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Ibnemo] FYI, an IBNEMO presentation/discussion is scheduled for RIPE71 meeting X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 19:12:09 -0000 The exact time is not yet know (i will post it one I know) you can also follow it yourself at: https://ripe71.ripe.net/programme/ If you are there please come to discuss the topic. Bert From nobody Thu Oct 15 19:04:32 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737E21B2A3D for ; Thu, 15 Oct 2015 19:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 uzvP3SXsiXis for ; Thu, 15 Oct 2015 19:04:29 -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 5FD701B2A2D for ; Thu, 15 Oct 2015 19:04:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYW25586; Fri, 16 Oct 2015 02:04:26 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 03:04:25 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 10:04:18 +0800 From: Zhoutianran To: "Bert Wijnen (IETF)" , "ibnemo@ietf.org" Thread-Topic: [Ibnemo] topic: box commands Thread-Index: AQHRB3wW/FIzD4ATlkCzh4KCHKcIOJ5tXnEA Date: Fri, 16 Oct 2015 02:04:17 +0000 Message-ID: References: <561FF7D1.2010804@bwijnen.net> In-Reply-To: <561FF7D1.2010804@bwijnen.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ibnemo] topic: box commands X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 02:04:30 -0000 SSBndWVzcyB5b3UgYXJlIHJpZ2h0IG9uIHdoYXQgQW5pdGEgbWVhbi4NCkFuZCBJIGFncmVlIHRo YXQgaW50ZW50IGlzIGEgaGlnaGVyIGxldmVsIHJlcXVlc3Qgd2hpY2ggY2FuIHRoZW4gYmUgdHJh bnNsYXRlZCBpbnRvIGRldmljZSBjb21tYW5kcy4NCg0KVGlhbnJhbg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElibmVtbyBbbWFpbHRvOmlibmVtby1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQmVydCBXaWpuZW4NCj4gKElFVEYpDQo+IFNlbnQ6IEZyaWRh eSwgT2N0b2JlciAxNiwgMjAxNSAzOjAxIEFNDQo+IFRvOiBpYm5lbW9AaWV0Zi5vcmcNCj4gU3Vi amVjdDogW0libmVtb10gdG9waWM6IGJveCBjb21tYW5kcw0KPiANCj4gQW5pdGEgKGxhc3QgbmFt ZT8pIGFrZWQgZHVyaW5nIG91ciBiYXItYm9mIGF0IElFVEY5MzoNCj4gDQo+ICAgICAgTmV0d29y ayBvcmRlcnMgb3V0c2lkZSBvZiB0aGUgY2FycmllciBjb3VsZCBiZSBkb25lIGluIE5lbW8gYW5k IHRoZW4NCj4gaXQgd291bGQgYnJlYWsgaW50byB0aGUg4oCcYm94IGNvbW1hbmRz4oCdLg0KPiAN Cj4gTm90IDEwMCUgc3VyZSB3aGF0IHNoZSBtZWFudCB3aXRoICJib3ggY29tbWFuZHMiLiBBbml0 YSwgaWYgeW91IGFyZSBvbiB0aGlzDQo+IGxpc3QsIHBsZWFzZSBlbGFib3JhdGUuDQo+IA0KPiBQ b3NzaWJseSBzaGUgbWVhbnQgdGhhdCBpZiBhIGN1c3RvbWVyIHJlcXVlc3RzIHNvbWUgY29ubmVj dGl2aXR5IGJldHdlZW4NCj4gc2F5IDIgbG9jYXRpb25zLCB0aGVuICJpbnRlbnQiIHNob3VsZCBi ZSBhYmxlIHRvIGV4cHJlc3MgdGhhdCBhbmQgdGhlIElCTkVNTw0KPiBlbmdpbmUgd291bGQgdHJh bnNsYXRlIHRoYXQgaW50byBjb21tYW5kcyBmb3IgZWFjaCBib3ggKGRldmljZSkgdGhhdCBpcw0K PiBvbnZvbHZlZCBpbiB0aGUgY29ubmVjdGlvbi4gUG90ZW50aWFsbHkgdGhhdCBjb3VsZCBiZSBD TEkgY29tbWFuZHMsIG9yDQo+IHBvc3NpYmx5IHRoYXQgY291bGQgYmUgWUFORy9ORVRDT05GL1JF U1RDT05GIGNvbmZpZ3VyYXRpb24gY29tbWFuZHMuDQo+IA0KPiBBbml0YT8NCj4gDQo+IE9yIGFu eW9uZSBlbHNlIHdobyBoYXMgaW5wdXQvdmlld3Mgb24gdGhpcy4NCj4gDQo+IEJlcnQNCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElibmVt byBtYWlsaW5nIGxpc3QNCj4gSWJuZW1vQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaWJuZW1vDQo= From nobody Fri Oct 16 03:02:17 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50EB71A004E for ; Fri, 16 Oct 2015 03:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Xb8qCqs8C-xG for ; Fri, 16 Oct 2015 03:02:08 -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 C3AB31A0158 for ; Fri, 16 Oct 2015 03:02:07 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CCQ00698; Fri, 16 Oct 2015 10:02:03 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Oct 2015 11:02:01 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Fri, 16 Oct 2015 18:01:58 +0800 From: Zhoutianran To: Susan Hares , "ibnemo@ietf.org" Thread-Topic: service based intent Thread-Index: AdEGaY5x7K1ZMvNqQMSG+MSLkrTEswBjY9Zw Date: Fri, 16 Oct 2015 10:01:57 +0000 Message-ID: References: <001401d1068a$d204abb0$760e0310$@ndzh.com> In-Reply-To: <001401d1068a$d204abb0$760e0310$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F218315A701nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Ibnemo] service based intent X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2015 10:02:15 -0000 --_000_BBA82579FD347748BEADC4C445EA0F218315A701nkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, You raised a very interesting topic. In the NEMO implementation in ODL, we have some embedded types for Node and= Connection. For example, we will have point to point, point to multi point, and mesh co= nnections with QoS and bandwidth properties. But NEMO language and engine enable the dynamic import of new models. The L3VPN type you shown in the case is a very good example. And I think ma= ny other models developed by IETF can also be used by NEMO language to expr= ess the service intent. The NEMO language could be the glue to connect many models, and instantiate= services, apply policies. WRT your question on the model expression, whether to support hierarchy. It= depend on the demand from use cases, as the intent is going to be simple c= an clear. I current implementation we do not support unfortunately, because= that will increase the complexity. But it's a very good discussion point that 1. whether we really need this? 2. Whether we can find a elegant way to express the hierarchy. I really look forward to your comments and suggestions. Thanks, Tianran From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, October 14, 2015 10:16 PM To: ibnemo@ietf.org Cc: 'PEDRO ANDRES ARANDA GUTIERREZ'; Zhoutianran; 'Bert Wijnen (IETF)' Subject: service based intent Hi all: I could really use some help this week on service-based intent as I'm tryin= g to link service-based intent to the various service modes. At IETF 93, w= e described the application expressing their service level needs at a servi= ce level by expressing the service needs, and letting the Intent based work= negotiate the service. I would like to explore how this works for five different types of services= : L3VPN, L2VPN, and EVPN, Cable-network services, B-2B. However, let me st= art with the L3VPN which has an IETF service level description (draft-ietf-= l3sm-l3vpn-service-model-01) or https://tools.ietf.org/pdf/draft-ietf-l3sm-l3vpn-service-model-01.pdf. Se= e the bottom of the page for the diagram of an L3VPN network. L3SM The L3VPN Service model limits is description to BGP PE-Based VPNs as descr= ibed in [RFC4110] and [RFC4364]. The L3SM model is input to the orchestrat= ion system shown in the diagram below this text. The L3SM provides two top= level information: 1) vpn-svc [name] 2) sites* [site-id] vpn-svc [name] list has the following components per service: * name, id, customer-name, topology id, cloud access, mpls, multicas= t tree sites [id] list has the following components per site: * Site-id * Apply-template (yes/no) * site level parameters [start/stop service time, location, site div= ersity, availability, management, vpn policies, maximum number of routes, = management, VPN policies, customer-info, security, physical attachment (ak= a bearer), service parameters (bandwidth in/out, QOS, traffic protection, m= pls, protocols-run), site templates An example from draft-ietf-l3sm-l3vpn-service-model-01 is: ZKITYHJ054687 12456487

CUSTOMER_1

any-to-any

true

1.1.1.1

IB-Nemo Intent to Create this L3SM Concept: IBNemo - would have the sites become nodes with specific EndNodes = as the end nodes at each site. The L3VPN would be created by the followin= g statement: Create Connection ZKITYHJ054687 Type L3SM EndNodes ... Property id: 1245487; customer-name: Customer1; topology: any-t= o-any; cloud-access-cloud-identifier: 51; cloud-access-nat-enabled: true; cloud-access-nat-address: 1.1.1.1; mpls-signaling-type: BGP; multicast-tree: SSM; The problem is that one would like hierarchy in the property so that one ca= n give cloud access the following type of syntax: Create Property cloud-access [id] { identifier: 51; nat-enabled: true; nat-address: 1.1.1.1; } Is this possible with Nemo properties? This would shorten the definition to: Create Connection ZKITYHJ054687 Type L3SM EndNodes ... Property id: 1245487; customer-name: Customer1; topology: any-to-any; cloud-access: 51; mpls-signaling-type: BGP; multicast-tree: SSM; Thank you. Background info ------------------ The sites is a list of sites where each site has the following information: * Site-id * Apply-template (yes/no) * site level parameters: o Requested start/stop o Actual start/stop o Location: address, zip, city, country code, o Site diversity - (type, site-group) o Availability (Availability type (service-type, access-type), Loadsharin= g: type) o Management: Type, transport, address o VPN policies o Maximum number of routes o Customer specified information o Security (apply template, authentication, encryption) o Attachment (apply template, bearer, ip-connection) o Service (apply template, Bandwidth In, Bandwith out, svc-mtu, QOS, traf= fic protection, mpls, multicast, prototype type) o Site-templates ASCII diagram for L3VPN-SVC Model L3VPN-SVC | MODEL | | +------------------+ +-----+ | Orchestration | < --- > | OSS | +------------------+ +-----+ | | +----------------+ | | Config manager | | +----------------+ | | | | Netconf/CLI ... | | +------------------------------------------------+ Network +++++++ + AAA + +++++++ +++++++ Bearer ++++++++ ++++++++ +++++++ + CEA + ------- + PE A + + PE B + ----- + CEB + +++++++ Cnct ++++++++ ++++++++ +++++++ Site A Site B --_000_BBA82579FD347748BEADC4C445EA0F218315A701nkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

You raised = a very interesting topic.

In the NEMO= implementation in ODL, we have some embedded types for Node and Connection= .

For example= , we will have point to point, point to multi point, and mesh connections w= ith QoS and bandwidth properties.

But NEMO la= nguage and engine enable the dynamic import of new models.

The L3VPN t= ype you shown in the case is a very good example. And I think many other mo= dels developed by IETF can also be used by NEMO language to express the service intent.

The NEMO la= nguage could be the glue to connect many models, and instantiate services, = apply policies.

WRT your qu= estion on the model expression, whether to support hierarchy. It depend on = the demand from use cases, as the intent is going to be simple can clear. I current implementation we do not support unfortunately, becau= se that will increase the complexity.

But it̵= 7;s a very good discussion point that

1. whe= ther we really need this?

2. Whe= ther we can find a elegant way to express the hierarchy.<= /p>

I really lo= ok forward to your comments and suggestions.

Thanks,

Tianran

From: Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, October 14, 2015 10:16 PM
To: ibnemo@ietf.org
Cc: 'PEDRO ANDRES ARANDA GUTIERREZ'; Zhoutianran; 'Bert Wijnen (IETF= )'
Subject: service based intent

Hi all:

I could really use some help th= is week on service-based intent as I’m trying to link service-based i= ntent to the various service modes. At IETF 93, we described the appl= ication expressing their service level needs at a service level by expressing the service needs, and letting the Intent ba= sed work negotiate the service.

I would like to explore how thi= s works for five different types of services: L3VPN, L2VPN, and EVPN,= Cable-network services, B-2B. However, let me start with the L3VPN which h= as an IETF service level description (draft-ietf-l3sm-l3vpn-service-model-0= 1) or

https://tools.ietf.org/p= df/draft-ietf-l3sm-l3vpn-service-model-01.pdf. See the bott= om of the page for the diagram of an L3VPN network.

L3SM

The L3VPN Service model limits = is description to BGP PE-Based VPNs as described in [RFC4110] and [RFC4364]= . The L3SM model is input to the orchestration system shown in the di= agram below this text. The L3SM provides two top level information:

1) &nbs= p; vpn-svc [name]

2) &nbs= p; sites* [site-id] <= /o:p>

vpn-svc [name] list has t= he following components per service:

· name, id, customer-name= , topology id, cloud access, mpls, multicast tree

sites [id] list has the followi= ng components per site:

· Site-id

· Apply-template (yes/no)=

· site level parameters [= start/stop service time, location, site diversity, availability, management= , vpn policies, maximum number of routes, management, VPN policies,&n= bsp; customer-info, security, physical attachment (aka bearer), service parameters (bandwidth in/out, QOS, traffic protectio= n, mpls, protocols-run), site templates

An example from draft-ietf-l3sm= -l3vpn-service-model-01 is:

<vpn-svc>

<name>ZKITYHJ054687</n= ame>

<customer-name>CUSTOMER_1= </customer-name>

<cloud-access>=

<cloud-identifier>51</= cloud-identifier>

<nat-enabled>true</nat= -enabled>

<nat-address>1.1.1.1</= nat-address>

</cloud-access>

</vpn-svc>

IB-Nemo Intent to Create thi= s L3SM

Concept: IBNemo – would h= ave the sites become nodes with specific EndNodes as the end nodes at each = site. The L3VPN would be created by the following statement:

Create Connection ZKITYHJ054687=

&= nbsp; Type L3SM

&= nbsp; EndNodes <site_1> <site_2> <si= te_3> … <site_n>

&= nbsp; Property id: 1245487; customer-name: Cu= stomer1; topology: any-to-any;

&= nbsp; &nbs= p; cloud-access-cloud-= identifier: 51;

&= nbsp; &nbs= p; cloud-access-nat-en= abled: true;

&= nbsp; &nbs= p; cloud-access-nat-address= : 1.1.1.1;

&= nbsp; &nbs= p; &= nbsp; mpls-signaling-type: BGP;

&= nbsp; &nbs= p; multicast-tree: SSM;

The problem is that one would l= ike hierarchy in the property so that one can give cloud access the followi= ng type of syntax:

&= nbsp; Create Property cloud-access [id]&= nbsp; {

&= nbsp; id= entifier: 51;

&= nbsp; nat-= enabled: true;

&= nbsp; nat-addre= ss: 1.1.1.1;

&= nbsp; }

Is this possible with Nemo prop= erties?

&= nbsp;

This would shorten the definiti= on to:

&= nbsp; Create Connection ZKITYHJ054687

&= nbsp; Type L3SM

&= nbsp; EndNodes <site_1> <site_2> <si= te_3> … <site_n>

&= nbsp; Property id: 1245487;

&= nbsp; &nbs= p; customer-name: Cust= omer1;

&= nbsp; &nbs= p; topology: any-to-an= y;

&= nbsp; &nbs= p; cloud-access: 51;

&= nbsp; &nb= sp; = mpls-signaling-type: BGP;

&= nbsp; &nbs= p; multicast-tree: SSM;

<= /p>

Thank you.

Background info

------------------

The sites is a list of sites wh= ere each site has the following information:

· Site-id

· Apply-template (yes/no)=

· site level parameters: =

o Requested start/stop

o Actual start/stop =

o Location: address, zip,= city, country code,

o Site diversity – = (type, site-group)

o Availability (Availabil= ity type (service-type, access-type), Loadsharing: type)

o Management: Type, trans= port, address

o VPN policies

o Maximum number of route= s

o Customer specified info= rmation

o Security (apply templat= e, authentication, encryption)

o Attachment (apply templ= ate, bearer, ip-connection)

o Service (apply template= , Bandwidth In, Bandwith out, svc-mtu, QOS, traffic protection, mpls, multi= cast, prototype type)

o Site-templates

ASCII diagram for L3VPN-SVC Mod= el

L3VPN-SVC |

MODEL = |

&= nbsp; |

= +------------------+ = ; +-----+

= | Orchestration | < --- > | OSS |=

= +------------------+ = ; +-----+

= | |=

+----------------+= ; |

| Config manager | |=

+----------------+= ; |

| = &nb= sp; |

| = Netconf/CLI ...

| = &nb= sp; |

+--------------------= ----------------------------+

Network=

+++++= ++

+ AAA +

+++++= ++

<= /p>

+++++= ++ Bearer ++++++++ = ; ++++++++ &nb= sp; +++++++

+ CEA + ------- &= #43; PE A + + PE B + ----- + CEB &#= 43;

+++++= ++ Cnct ++++++++&= nbsp; ++++++++ = ; +++++++

Site A &= nbsp; &nbs= p; = Site B

--_000_BBA82579FD347748BEADC4C445EA0F218315A701nkgeml512mbxchi_-- From nobody Sun Oct 18 23:03:32 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC79D1A1B9C for ; Sun, 18 Oct 2015 23:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 x2g62_xYbvVD for ; Sun, 18 Oct 2015 23:03:27 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5B01A1BE4 for ; Sun, 18 Oct 2015 23:03:26 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B13EAE00A9; Mon, 19 Oct 2015 08:03:23 +0200 (CEST) Received: from ESTGVMSP105.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id 8B82DE009B; Mon, 19 Oct 2015 08:03:23 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.51) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 08:03:22 +0200 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB189.eurprd06.prod.outlook.com (10.242.155.140) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 06:03:22 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) by DB4PR06MB0639.eurprd06.prod.outlook.com (10.161.13.145) with Microsoft SMTP Server (TLS) id 15.1.300.14; Mon, 19 Oct 2015 06:03:21 +0000 Received: from DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) by DB4PR06MB0639.eurprd06.prod.outlook.com ([10.161.13.145]) with mapi id 15.01.0300.010; Mon, 19 Oct 2015 06:03:21 +0000 From: PEDRO ANDRES ARANDA GUTIERREZ To: Zhoutianran , Susan Hares , "ibnemo@ietf.org" Thread-Topic: service based intent Thread-Index: AQHRCjPb5PSUxpmSqU+aFmjKQa4Iug== Date: Mon, 19 Oct 2015 06:03:20 +0000 Message-ID: <282FE70D-A73A-4C90-A336-144C25869E16@telefonica.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150923 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pedroa.aranda@telefonica.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [195.235.92.36] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0639; 5:h4oAT4frK1vYY9DXGjcGp7XvWUbj+0XPmqH7ikB6Jb0OKBsPScNI8P0CziIz/fYgwlFR1RjJyGF2KXQ9+h2PDfw5nJW2oi0spRX9Vn+BGgwGuwuGTFAbDxPF7HN4tumGfTkdUuEiZYdcG2wbQbONSg==; 24:Kk1DdTlLPsJD8EzkluP+bEH4GGpLQzE7w1YL4hgXfFy0XPykSK+eZ7mb1kH3L98s1Pc+ZIX/FhWcvz4HKs6SxaJrMH6zwmnGyEmHWm6k8rE=; 20:vjHayog+lsLC7458JY7o32MltuZS4/vJx9LTQo0Q0bGq9DsckSLmndioFBJenAdG/TZTraUaSiETgDWPm8ElZQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0639; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:DB4PR06MB0639; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0639; x-forefront-prvs: 07349BFAD2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(101416001)(33656002)(106356001)(16236675004)(106116001)(46102003)(105586002)(92566002)(5008740100001)(50986999)(54356999)(36756003)(87936001)(5001960100002)(4001350100001)(5001770100001)(2900100001)(575784001)(86362001)(10400500002)(19580395003)(102836002)(77096005)(189998001)(5001920100001)(81156007)(97736004)(40100003)(5002640100001)(122556002)(82746002)(66066001)(64706001)(11100500001)(19580405001)(5004730100002)(5007970100001)(83506001)(2501003)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0639; H:DB4PR06MB0639.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_282FE70DA73A4C90A336144C25869E16telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2015 06:03:20.9787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0639 X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB189; 2:zqAAyX8y2SPmeM7uWXXxobkJGgRDzVIdes7eA5jkPtqKmrSg6D3v0luP9s0ftxlIpzsG3rkaLV88EGDpGbxDVnm+O7iGPPO+8oKRVSJCxjpTGpiGRMHr8yKyjVb+486s5RafYBNqz9b7d3q2Jjlm5aI7JuHHT3ztSxdlAQpjYWQ=; 23:2tKt4oKZPbMCf1aWEtqITPs6yH3HPQo3Zg+u7CN5Q00UCoRRzxDrgyTMRwRVo5yEyea7bBdZvx7MQObwOMsyNqowDdXhlKx/oENtBXbDviDhgdxDKZLIMOHPKPPMe2FB2CPxb0iPBSe4bwpPcnB41nldmdUVxDhAKD6uZoHYAy/m2pQrdL6poalmskCVfude X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [Ibnemo] service based intent X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 06:03:31 -0000 --_000_282FE70DA73A4C90A336144C25869E16telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgaXMgcmVhbGx5IGEgbmljZSB0cmlnZ2VyIGZvciBkaXNjdXNzaW9uLiBCZWNh dXNlLCB0cnkgYXMgbXVjaCBhcyBJIHdhbnQsIEkgZG9u4oCZdCBzZWUgaGllcmFyY2h5IGluIHlv dXIgZXhhbXBsZS4gQXMgZmFyIGFzIG15IHVuZGVyc3RhbmRpbmcgZ29lcyBub3csIHdlIGRvIGhh dmUgaGllcmFyY2h5IGZvciBub2Rlcywgc28gd2UgY2FuIGNyZWF0ZSBhIG5vZGUgdGhhdCBhY3R1 YWxseSBjb250YWlucyBub2RlcyBhbmQgbGlua3MsIHJpZ2h0PyBIaWVyYXJjaHkgaW4gcHJvcGVy dGllcyB3b3VsZCBiZSB0aGF0IHlvdSBjcmVhdGUgYSBwcm9wZXJ0eSBhbmQgcmV1c2UgaXQgdG8g YnVpbGQgbmV3IHByb3BlcnRpZXMuIFNvbWV0aGluZyBsaWtlOg0KDQpDcmVhdGUgUHJvcGVydHkg TkFUIHsNCk5BVC1lbmFibGVkOiBUcnVlOw0KTkFULWFkZHJlc3M6IDEuMS4xLjE7DQp9DQoNCkNy ZWF0ZSBQcm9wZXJ0eSBXQU4tTkFUIHsNClByb3BlcnR5OiBOQVQ7DQpMaW5rLWlkOiA1MTsNCmJh bmR3aWR0aDogMk1icHM7DQp9DQoNClNvLCB3aGF0IEkgdW5kZXJzdGFuZCBmcm9tIHlvdXIgcG9z dCBpcyB0aGF0IHdlIG5lZWQgYSB3YXkgdG8gY3JlYXRlIGEgcHJvcGVydHkgYW5kIHRoZW4gYXBw bHkgaXQgb24gb25lIG9yIG1vcmUgbm9kZXMgb3IgbGlua3MuIEFuZCB0aGF04oCZcyBhIG5pY2Ug ZmVhdHVyZSB3aGljaCB3b3VsZCBtYWtlIGEgbG90IG9mIHNlbnNlLg0KDQpGb2xrcywgYmFjayB0 byB0aGUgZHJhd2luZyBib2FyZCA6LSkNCg0KTXkgLjAyIGNlbnRzLA0KL1BBDQoNCkRlOiBaaG91 dGlhbnJhbg0KRmVjaGE6IHZpZXJuZXMsIDE2IGRlIG9jdHVicmUgZGUgMjAxNSwgMTI6MDENClBh cmE6IFN1ZSBIYXJlcywgImlibmVtb0BpZXRmLm9yZzxtYWlsdG86aWJuZW1vQGlldGYub3JnPiIN CkNDOiBwYWFnLCAiJ0JlcnQgV2lqbmVuIChJRVRGKSciDQpBc3VudG86IFJFOiBzZXJ2aWNlIGJh c2VkIGludGVudA0KDQpCdXQgaXTigJlzIGEgdmVyeSBnb29kIGRpc2N1c3Npb24gcG9pbnQgdGhh dA0KDQoxLiAgd2hldGhlciB3ZSByZWFsbHkgbmVlZCB0aGlzPw0KDQoyLiAgV2hldGhlciB3ZSBj YW4gZmluZCBhIGVsZWdhbnQgd2F5IHRvIGV4cHJlc3MgdGhlIGhpZXJhcmNoeS4NCg0KSSByZWFs bHkgbG9vayBmb3J3YXJkIHRvIHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQpUaGUg cHJvYmxlbSBpcyB0aGF0IG9uZSB3b3VsZCBsaWtlIGhpZXJhcmNoeSBpbiB0aGUgcHJvcGVydHkg c28gdGhhdCBvbmUgY2FuIGdpdmUgY2xvdWQgYWNjZXNzIHRoZSBmb2xsb3dpbmcgdHlwZSBvZiBz eW50YXg6DQogICAgICAgICAgIENyZWF0ZSBQcm9wZXJ0eSAgY2xvdWQtYWNjZXNzIFtpZF0gIHsN CiAgICAgICAgICAgICAgICAgICBpZGVudGlmaWVyOiA1MTsNCiAgICAgICAgICAgICAgICAgbmF0 LWVuYWJsZWQ6IHRydWU7DQogICAgICAgICAgICAgICAgIG5hdC1hZGRyZXNzOiAxLjEuMS4xOw0K ICAgICAgICAgIH0NCg0KDQoNCi0tLQ0KRHIuIFBlZHJvIEEuIEFyYW5kYSBHdXRpw6lycmV6DQoN ClRlY2hub2xvZ3kgRXhwbG9yYXRpb24gLQ0KTmV0d29yayBJbm5vdmF0aW9uICYgVmlydHVhbGlz YXRpb24NCmVtYWlsOiBwZWRyb2EgZDB0IGFyYW5kYSBBdCB0ZWxlZm9uaWNhIGQwdCBjb20NClRl bGVmw7NuaWNhLCBJbnZlc3RpZ2FjacOzbiB5IERlc2Fycm9sbG8NCkMvIFp1cmJhcsOhbiwxMg0K MjgwMTAgTWFkcmlkLCBTcGFpbg0KDQpGcmFnZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0 ZXQgenUgd2VyZGVuLg0KRnJhZ2VuIHNpbmQgZGEsIHVtIGdlc3RlbGx0IHp1IHdlcmRlbi4NCkdl b3JnIEtyZWlzbGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0 ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBk ZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBj b25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlk YWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2Fkbywg cXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGEgbGVjdHVyYSwgdXRpbGl6YWNpw7NuLCBkaXZ1bGdh Y2nDs24geS9vIGNvcGlhIHNpbiBhdXRvcml6YWNpw7NuIHB1ZWRlIGVzdGFyIHByb2hpYmlkYSBl biB2aXJ0dWQgZGUgbGEgbGVnaXNsYWNpw7NuIHZpZ2VudGUuIFNpIGhhIHJlY2liaWRvIGVzdGUg bWVuc2FqZSBwb3IgZXJyb3IsIGxlIHJvZ2Ftb3MgcXVlIG5vcyBsbyBjb211bmlxdWUgaW5tZWRp YXRhbWVudGUgcG9yIGVzdGEgbWlzbWEgdsOtYSB5IHByb2NlZGEgYSBzdSBkZXN0cnVjY2nDs24u DQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0cmFuc21pc3Npb24gaXMgcHJp dmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGludGVuZGVkIG9ubHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB0aGUgcmVh ZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9y IGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVh ZCBpdC4gUGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0 Lg0KDQpFc3RhIG1lbnNhZ2VtIGUgc2V1cyBhbmV4b3Mgc2UgZGlyaWdlbSBleGNsdXNpdmFtZW50 ZSBhbyBzZXUgZGVzdGluYXTDoXJpbywgcG9kZSBjb250ZXIgaW5mb3JtYcOnw6NvIHByaXZpbGVn aWFkYSBvdSBjb25maWRlbmNpYWwgZSDDqSBwYXJhIHVzbyBleGNsdXNpdm8gZGEgcGVzc29hIG91 IGVudGlkYWRlIGRlIGRlc3Rpbm8uIFNlIG7Do28gw6kgdm9zc2Egc2VuaG9yaWEgbyBkZXN0aW5h dMOhcmlvIGluZGljYWRvLCBmaWNhIG5vdGlmaWNhZG8gZGUgcXVlIGEgbGVpdHVyYSwgdXRpbGl6 YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBjw7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBl c3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRhIGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNl YmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8sIHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlx dWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3Ry dWnDp8Ojbw0K --_000_282FE70DA73A4C90A336144C25869E16telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <87FCC8958D8BB2449933DBFDD3ED9897@eurprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogJ0FyaWFsIFVuaWNvZGUgTVMnLCBzYW5zLXNlcmlmOyI+DQo8ZGl2 PkhpLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBpcyByZWFsbHkgYSBuaWNl IHRyaWdnZXIgZm9yIGRpc2N1c3Npb24uIEJlY2F1c2UsIHRyeSBhcyBtdWNoIGFzIEkgd2FudCwg SSBkb27igJl0IHNlZSBoaWVyYXJjaHkgaW4geW91ciBleGFtcGxlLiBBcyBmYXIgYXMgbXkgdW5k ZXJzdGFuZGluZyBnb2VzIG5vdywgd2UgZG8gaGF2ZSBoaWVyYXJjaHkgZm9yIG5vZGVzLCBzbyB3 ZSBjYW4gY3JlYXRlIGEgbm9kZSB0aGF0IGFjdHVhbGx5IGNvbnRhaW5zIG5vZGVzIGFuZCBsaW5r cywgcmlnaHQ/DQogSGllcmFyY2h5IGluIHByb3BlcnRpZXMgd291bGQgYmUgdGhhdCB5b3UgY3Jl YXRlIGEgcHJvcGVydHkgYW5kIHJldXNlIGl0IHRvIGJ1aWxkIG5ldyBwcm9wZXJ0aWVzLiBTb21l dGhpbmcgbGlrZTo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkNyZWF0ZSBQcm9wZXJ0 eSBOQVQgezwvZGl2Pg0KPGRpdj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNwYW4iIHN0eWxlPSJ3 aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5OQVQtZW5hYmxlZDogVHJ1ZTs8L2Rpdj4NCjxkaXY+PHNw YW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+ TkFULWFkZHJlc3M6IDEuMS4xLjE7PC9kaXY+DQo8ZGl2Pn08L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkNyZWF0ZSBQcm9wZXJ0eSBXQU4tTkFUIHs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+UHJvcGVy dHk6IE5BVDs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0i d2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+TGluay1pZDogNTE7PC9kaXY+DQo8ZGl2PjxzcGFuIGNs YXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPmJhbmR3 aWR0aDogMk1icHM7PC9kaXY+DQo8ZGl2Pn08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PlNvLCB3aGF0IEkgdW5kZXJzdGFuZCBmcm9tIHlvdXIgcG9zdCBpcyB0aGF0IHdlIG5lZWQgYSB3 YXkgdG8gY3JlYXRlIGEgcHJvcGVydHkgYW5kIHRoZW4gYXBwbHkgaXQgb24gb25lIG9yIG1vcmUg bm9kZXMgb3IgbGlua3MuIEFuZCB0aGF04oCZcyBhIG5pY2UgZmVhdHVyZSB3aGljaCB3b3VsZCBt YWtlIGEgbG90IG9mIHNlbnNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Rm9sa3Ms IGJhY2sgdG8gdGhlIGRyYXdpbmcgYm9hcmQgOi0pPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5NeSAuMDIgY2VudHMsPC9kaXY+DQo8ZGl2Pi9QQTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRl OiA8L3NwYW4+WmhvdXRpYW5yYW48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ RmVjaGE6IDwvc3Bhbj52aWVybmVzLCAxNiBkZSBvY3R1YnJlIGRlIDIwMTUsIDEyOjAxPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlBhcmE6IDwvc3Bhbj5TdWUgSGFyZXMsICZx dW90OzxhIGhyZWY9Im1haWx0bzppYm5lbW9AaWV0Zi5vcmciPmlibmVtb0BpZXRmLm9yZzwvYT4m cXVvdDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q0M6IDwvc3Bhbj5wYWFn LCAmcXVvdDsnQmVydCBXaWpuZW4gKElFVEYpJyZxdW90Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Bc3VudG86IDwvc3Bhbj5SRTogc2VydmljZSBiYXNlZCBpbnRlbnQgPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jywgc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QnV0IGl04oCZcyBhIHZlcnkgZ29vZCBkaXNjdXNz aW9uIHBvaW50IHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdCAxOHB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB0ZXh0LWluZGVudDogLTE4 cHQ7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnLCBzZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4x LjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDdwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nOyI+Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jywgc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+d2hldGhlcg0KIHdlIHJlYWxseSBuZWVkIHRoaXM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQgMThwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgdGV4dC1pbmRlbnQ6IC0xOHB0OyI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3Jywgc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+Mi48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA3cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsiPiZuYnNwOyZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVw dDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldycsIHNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiPldoZXRoZXINCiB3ZSBjYW4gZmluZCBhIGVsZWdhbnQgd2F5IHRvIGV4cHJlc3MgdGhl IGhpZXJhcmNoeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jywgc2VyaWY7IGNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnLCBzZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5JIHJlYWxseSBsb29rIGZvcndhcmQgdG8geW91ciBj b21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlf U0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tR VU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAg NTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHByb2JsZW0gaXMgdGhh dCBvbmUgd291bGQgbGlrZSBoaWVyYXJjaHkgaW4gdGhlIHByb3BlcnR5IHNvIHRoYXQgb25lIGNh biBnaXZlIGNsb3VkIGFjY2VzcyB0aGUgZm9sbG93aW5nIHR5cGUgb2Ygc3ludGF4OjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q3JlYXRlIFByb3BlcnR5 Jm5ic3A7IGNsb3VkLWFjY2VzcyBbaWRdJm5ic3A7IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsgaWRlbnRpZmllcjogNTE7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bmF0LWVuYWJsZWQ6IHRy dWU7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmF0LWFkZHJlc3M6IDEuMS4xLjE7PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij4tLS08L2Rp dj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07 Ij5Eci4gUGVkcm8gQS4gQXJhbmRhIEd1dGnDqXJyZXo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij48YnI+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5UZWNobm9s b2d5IEV4cGxvcmF0aW9uIC08L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xh czsgZm9udC1zaXplOiBtZWRpdW07Ij5OZXR3b3JrIElubm92YXRpb24gJmFtcDsgVmlydHVhbGlz YXRpb248L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXpl OiBtZWRpdW07Ij5lbWFpbDogcGVkcm9hIGQwdCBhcmFuZGEgQXQgdGVsZWZvbmljYSBkMHQgY29t PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVk aXVtOyI+VGVsZWbDs25pY2EsIEludmVzdGlnYWNpw7NuIHkgRGVzYXJyb2xsbzwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkMvIFp1 cmJhcsOhbiwxMjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250 LXNpemU6IG1lZGl1bTsiPjI4MDEwIE1hZHJpZCwgU3BhaW48L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb25zb2xhczsgZm9udC1zaXplOiBtZWRpdW07Ij5GcmFn ZW4gc2luZCBuaWNodCBkYSwgdW0gYmVhbnR3b3J0ZXQgenUgd2VyZGVuLjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IENvbnNvbGFzOyBmb250LXNpemU6IG1lZGl1bTsiPkZyYWdlbiBz aW5kIGRhLCB1bSBnZXN0ZWxsdCB6dSB3ZXJkZW4uPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTogQ29uc29sYXM7IGZvbnQtc2l6ZTogbWVkaXVtOyI+R2VvcmcgS3JlaXNsZXI8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj48 YnI+DQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFtZW50 ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZpbGVn aWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJzb25h IG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlvIGlu ZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYQ0KIGxlY3R1cmEsIHV0aWxpemFjacOz biwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBw cm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNp YmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5p cXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVz dHJ1Y2Npw7NuLjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyB0 cmFuc21pc3Npb24gaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGlu dGVuZGVkIG9ubHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IG5hbWVk IGFib3ZlLiBJZiB0aGUgcmVhZGVyIG9mIHRoaXMgbWVzc2FnZSBpcyBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlv biwNCiBkaXN0cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3Ry aWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhl IHNlbmRlciB0aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciBhbmQgdGhlbiBkZWxldGUgaXQuPGJyPg0KPGJyPg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5l eG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUg Y29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFy YSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6Nv IMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmlj YWRvIGRlIHF1ZSBhDQogbGVpdHVyYSwgdXRpbGl6YcOnw6NvLCBkaXZ1bGdhw6fDo28gZS9vdSBj w7NwaWEgc2VtIGF1dG9yaXphw6fDo28gcG9kZSBlc3RhciBwcm9pYmlkYSBlbSB2aXJ0dWRlIGRh IGxlZ2lzbGHDp8OjbyB2aWdlbnRlLiBTZSByZWNlYmV1IGVzdGEgbWVuc2FnZW0gcG9yIGVycm8s IHJvZ2Ftb3MtbGhlIHF1ZSBub3MgbyBjb211bmlxdWUgaW1lZGlhdGFtZW50ZSBwb3IgZXN0YSBt ZXNtYSB2aWEgZSBwcm9jZWRhIGEgc3VhIGRlc3RydWnDp8Ojbzxicj4NCjwvZm9udD4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_282FE70DA73A4C90A336144C25869E16telefonicacom_-- From nobody Mon Oct 19 06:36:45 2015 Return-Path: X-Original-To: ibnemo@ietfa.amsl.com Delivered-To: ibnemo@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931621A1BBB for ; Mon, 19 Oct 2015 06:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 eqx-ezBFknPa for ; Mon, 19 Oct 2015 06:36:41 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D041B1A1BB8 for ; Mon, 19 Oct 2015 06:36:40 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0D53B38C85B30 for ; Mon, 19 Oct 2015 13:36:36 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9JDaXVK012474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Oct 2015 15:36:38 +0200 Received: from [172.27.205.110] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 19 Oct 2015 15:36:38 +0200 References: <5624EEC3.40509@alcatel-lucent.com> To: "ibnemo@ietf.org" From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France X-Forwarded-Message-Id: <5624EEC3.40509@alcatel-lucent.com> Message-ID: <5624F1E5.20203@alcatel-lucent.com> Date: Mon, 19 Oct 2015 15:36:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5624EEC3.40509@alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------040201000902070901090400" X-Originating-IP: [135.239.27.39] Archived-At: Subject: [Ibnemo] Fwd: IETF94 / 38th NMRG meeting - Call for Contributions on Managing Networks of Adaptive and Cooperative Agents X-BeenThere: ibnemo@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of Nemo, an intent-based North Bound $NB$ interface consisting of an application protocol running over HTTP $RESTful interfaces$ to exchange intent-based primitives between applications and meta-controllers controlling virtual network resources $networks, storage, CPU$." List-Unsubscribe: , List-Archive:

Subject:	IETF94 / 38th NMRG meeting - Call for Contributions on Managing Networks of Adaptive and Cooperative Agents
Date:	Mon, 19 Oct 2015 15:23:15 +0200
From:	Laurent Ciavaglia <Laurent.Ciavaglia@alcatel-lucent.com>
Organization:	Alcatel-Lucent Bell Labs France
To:	nmrg@irtf.org <nmrg@irtf.org>
CC:	Lisandro Zambenedetti Granville <granville@inf.ufrgs.br>, Olivier Festor <Olivier.Festor@inria.fr>