From nobody Mon Oct 2 06:17:29 2017 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB3E134639; Mon, 2 Oct 2017 06:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.621 X-Spam-Level: X-Spam-Status: No, score=-12.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 bCS0f3otEJ20; Mon, 2 Oct 2017 06:17:27 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A65134637; Mon, 2 Oct 2017 06:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5512; q=dns/txt; s=iport; t=1506950244; x=1508159844; h=from:to:cc:subject:date:message-id:mime-version; bh=9NofT1x220OSE4poUWTMlwrb14bHeo1xyRFIb3gPfgw=; b=IdEZg8l9HzR0JE7tB5Ny5DhWcJVF/2+eusm3QMsIWyFn9LsVCVln0gD4 6G7wEOmwdUZwa71S2IcuVSnPqgb54iWu+A+4cw2raW6MHlKUOjQbDyp7a 18Wh1h4yY6o4QBiARYr3b4tAJtfk/AiqEI+lEQVtIMb7HVPjOB+Xp2Ydz 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAABVO9JZ/5RdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9uZG4nB4Nyih+PYoFUgm+FdogrhT6CEgqFOxyEJj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFQgpMEgFHAwIEMBMBEwQBDQWJTEwDFaUFgicnixEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdgy2CAoFRghULhVCFOS+CMgWILAyQIIgePAKBa44FhHOTCYx?= =?us-ascii?q?wiDcCERkBgTgBHziBDngVWwGHCnaJAYEQAQEB?= X-IronPort-AV: E=Sophos;i="5.42,469,1500940800"; d="scan'208,217";a="302486939" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 13:17:23 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v92DHNWD024511 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Oct 2017 13:17:23 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Oct 2017 08:17:23 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1320.000; Mon, 2 Oct 2017 08:17:23 -0500 From: "Alvaro Retana (aretana)" To: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" CC: "aretana.ietf@yahoo.com" Subject: Change of Affiliation (Alvaro Retana) Thread-Topic: Change of Affiliation (Alvaro Retana) Thread-Index: AQHTO4DI5sNP6sYW10CCMw6xGJdmAQ== Date: Mon, 2 Oct 2017 13:17:22 +0000 Message-ID: <044C5811-9045-4A20-8748-45C4E30C0EE7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.150.44.127] Content-Type: multipart/alternative; boundary="_000_044C581190454A20874845C4E30C0EE7ciscocom_" MIME-Version: 1.0 Archived-At: X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2017 13:17:28 -0000 --_000_044C581190454A20874845C4E30C0EE7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNClN0YXJ0aW5nIHRvZGF5IEkgYW0gbm8gbG9uZ2VyIGFmZmlsaWF0ZWQgd2l0aCBDaXNj by4NCg0KSSB3aWxsIGNvbnRpbnVlIHdpdGggbXkgZHV0aWVzIGFzIEFELCBhbmQgcGxhbiB0byBi ZSBpbiBTaW5nYXBvcmUuICBJIGRvbuKAmXQgYW50aWNpcGF0ZSBhbnkgY2hhbmdlcyByZWxhdGVk IHRvIFdHIGFzc2lnbm1lbnRzLg0KDQpJIHdpbGwgYW5ub3VuY2UgYSBuZXcgYWZmaWxpYXRpb24g YXMgc29vbiBhcyBJIGhhdmUgYSBuZXcgZS1tYWlsIGFkZHJlc3MuICBGb3Igbm93LCB5b3UgY2Fu IHJlYWNoIG1lIGF0IGFyZXRhbmEuaWV0ZkB5YWhvby5jb208bWFpbHRvOmFyZXRhbmEuaWV0ZkB5 YWhvby5jb20+Lg0KDQpUaGFua3MhDQoNCkFsdmFyby4NCg0K --_000_044C581190454A20874845C4E30C0EE7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <807267503337E24B9842D96D19B20A0D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4ubXNvSW5zDQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNyIv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkhpITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+U3RhcnRpbmcgdG9kYXkgSSBhbSBubyBsb25nZXIgYWZmaWxpYXRlZCB3aXRoIENp c2NvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSB3aWxsIGNv bnRpbnVlIHdpdGggbXkgZHV0aWVzIGFzIEFELCBhbmQgcGxhbiB0byBiZSBpbiBTaW5nYXBvcmUu Jm5ic3A7IEkgZG9u4oCZdCBhbnRpY2lwYXRlIGFueSBjaGFuZ2VzIHJlbGF0ZWQgdG8gV0cgYXNz aWdubWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdp bGwgYW5ub3VuY2UgYSBuZXcgYWZmaWxpYXRpb24gYXMgc29vbiBhcyBJIGhhdmUgYSBuZXcgZS1t YWlsIGFkZHJlc3MuJm5ic3A7IEZvciBub3csIHlvdSBjYW4gcmVhY2ggbWUgYXQNCjxhIGhyZWY9 Im1haWx0bzphcmV0YW5hLmlldGZAeWFob28uY29tIj5hcmV0YW5hLmlldGZAeWFob28uY29tPC9h Pi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcyE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFsdmFyby48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_044C581190454A20874845C4E30C0EE7ciscocom_-- From nobody Mon Oct 9 13:05:53 2017 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355A31342FE; Mon, 9 Oct 2017 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.45 X-Spam-Level: * X-Spam-Status: No, score=1.45 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MSGID_YAHOO=1.549, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uA1MDGQAdAUb; Mon, 9 Oct 2017 13:05:46 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE4713234B; Mon, 9 Oct 2017 13:05:42 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id q4so45386135qtq.8; Mon, 09 Oct 2017 13:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=0/7uQQXoZPeECGEHSJKIThjkHWqawXztfbnTQYJjA54=; b=GUkdlU2Mynq4y+QGKhLvGV7bsgH87quzcn5B1s3/xUwGqHLJkrVPColpFBMPUz9j7W iwyY7hE2Lr8NhNubu4t8W2gytn+q8fWKA2ANuzecagUfBFn2zd+rynEErWyG/TxbxftO QftrW5+/D4BJvVwnnouIo8B+6/GmQebYGCRiu8dfQFalsXs7qHBg/e0s3LhGlfe7LwRF xNRpVzZz3eY2DOU2E2Haw3CpP0Pblyj3Oj3gnVFOThdNw3k2ihQlM1S/HN0/pEPgn3gl BoW7ealo4CwFPQ1y8ccwnoC3HAjg5WtOdT6DlceM07y++dNVm2Lc8EcZlNKl1Yvh7RwV Fcjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=0/7uQQXoZPeECGEHSJKIThjkHWqawXztfbnTQYJjA54=; b=IJf25VKJ3M1AAsgq/23sMVhiQvD0sKHNxbS+k9TF2rF7AvRIZ3DgUAE+S+5N698e0a rGrYChSI9ST3nmYkJWE9A5LyNVNclJjy/xRmFasGrK1LP5O/gmASEiVTc0oQekmsm5iO ewMqcEhR9/Og2jEABMTPi1dIbT7bpG21r7SBE5BZquYbwzxCNWz7BbAWS+LAA6sJf5B+ GmvcBg9tLYaAQKB/LmkPDBCeYHdCisIOH7hNyY+kUrmy6Vc16iBNvTCz9YpIougCX6mg JG82eR7NB2jJVpTGALDC9EBeaLEkpMVpzlxXXkdF/qQTtO0fW4qMT6lGpwgYUSef0XKg PrCw== X-Gm-Message-State: AMCzsaVfP0KXmloIuYNCYezo4Gi8xVo5oFeIMbmkhOeXJKPcP6/iAHsU fR70gIGDIH4Rumm3/0ecNFreSQ== X-Google-Smtp-Source: AOwi7QDVqkQaWEn9BBNjOQHfnbsW2zmEZWQ6IMemUn/RyVWCnQAd49mmEFcQ1xZ9mCbAOZsGjnvuxQ== X-Received: by 10.129.48.10 with SMTP id w10mr582966yww.378.1507579541806; Mon, 09 Oct 2017 13:05:41 -0700 (PDT) Received: from [192.168.1.144] (cpe-65-190-24-92.nc.res.rr.com. [65.190.24.92]) by smtp.gmail.com with ESMTPSA id y196sm58407ywg.31.2017.10.09.13.05.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Oct 2017 13:05:41 -0700 (PDT) User-Agent: Microsoft-MacOutlook/f.26.0.170902 Date: Mon, 09 Oct 2017 16:05:41 -0400 Subject: Re: Change of Affiliation (Alvaro Retana) From: Alvaro Retana To: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" Message-ID: Thread-Topic: Change of Affiliation (Alvaro Retana) References: <044C5811-9045-4A20-8748-45C4E30C0EE7@cisco.com> In-Reply-To: <044C5811-9045-4A20-8748-45C4E30C0EE7@cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3590409941_1129720480" Archived-At: X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 20:05:47 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3590409941_1129720480 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Just FYI=E2=80=A6 =20 I am now affiliated with Huawei.=C2=A0 My new e-mail address is alvaro.retana@h= uawei.com. =20 I=E2=80=99ll keep using my personal address (aretana.ietf@gmail.com) for now=E2=80=A6 =20 Alvaro. =20 =20 =20 From: "Alvaro Retana (aretana)" Date: Monday, October 2, 2017 at 9:17 AM To: "rtg-dir@ietf.org" , "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" Cc: "aretana.ietf@yahoo.com" Subject: Change of Affiliation (Alvaro Retana) =20 Hi! =20 Starting today I am no longer affiliated with Cisco. =20 I will continue with my duties as AD, and plan to be in Singapore. I don=E2=80= =99t anticipate any changes related to WG assignments. =20 I will announce a new affiliation as soon as I have a new e-mail address. = For now, you can reach me at aretana.ietf@yahoo.com. =20 Thanks! =20 Alvaro. =20 --B_3590409941_1129720480 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Just FYI=E2=80=A6

 

I am now affiliated with Huawei.=C2=A0 My new e-mail address is alvaro.retana@huawei.com.

 

I=E2=80=99ll keep= using my personal address (aretana= .ietf@gmail.com) for now=E2=80=A6

 

Alvaro.

 

 

 

From: "Alvaro Retana (aretana)" <aretana@cisco.com>
Date: Monday, October 2, 2017 at 9:17 AM
To: "rtg-dir@ie= tf.org" <rtg-dir@ietf.org>, "routing-discussion@ietf.org&quo= t; <routing-discussion@ietf.org>, "rtg-chairs@ietf.org" <= rtg-chairs@ietf.org>
Cc: "aretana.ietf@yahoo.com" <= ;aretana.ietf@yahoo.com>
Subject: Change of Affiliation (Alvaro= Retana)

 

Hi!

 

Starting today I am no longer affiliated with Cisco.=

&nbs= p;

I = will continue with my duties as AD, and plan to be in Singapore.  I don= =E2=80=99t anticipate any changes related to WG assignments.

=

 

I will announce a new af= filiation as soon as I have a new e-mail address.  For now, you can rea= ch me at aretana.ietf@yahoo.com.=

&nbs= p;

Th= anks!

 

Alvaro.

 

--B_3590409941_1129720480-- From nobody Wed Oct 25 08:02:13 2017 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665F7132939; Wed, 11 Oct 2017 17:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8S2kNlMi87Ll; Wed, 11 Oct 2017 17:00:30 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5975B1342FA; Wed, 11 Oct 2017 17:00:24 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e64so2509586pfk.9; Wed, 11 Oct 2017 17:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EoGSZr1uzmC5qWEDfcv8vQbJVaYxYGcE/NexrCRI/sI=; b=LF9k667nTdA80qd6IQRWrGJ9XonUV8lV8zsUoKQIYGB8opzVJW2NgGCr6rybArWqa6 cAaTykJyga+VGIpuvUq47eUmJVwBF5MZMvipiT+3krqUzjeXj3oL3gj3VMoWEwtxZlfd C7Dx77juYRRb81XJDslwZGXrXKrS283N4b6n11ZFhu1hftgm+TkpxHHaNbUSr+G+5hVx V8/IXEQVUTU36rsjitbGfEOnEEOx7SD1h9hLDZQ50BZ6/zWWrde7uP2Ueuj6EyahcIfK DWPa3UrEIbZ0/P2pkFuU4ezUlWM1MMpKXKbqlbnY3B4hBCXAdqsGPho6ZGk0L2YiMPPA 9xkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EoGSZr1uzmC5qWEDfcv8vQbJVaYxYGcE/NexrCRI/sI=; b=AsMfQRdpqgcBu8wa08242M6TSozhaHjhbyrbsyXLrI0d88/TKRFVoluP8JSsmgEcpP 60bmbK5JPlK8AYUo8vgXmks1W6jungHYNGQvrcEUSHeiGII9kpvZZe5NKwSLN2oVJjNh 9Cu6L5MjKWMFIqu5SuUTL2ZZPXzmr5sXC3WkOg5e22TGJAKyOQgiHCzhtrQGOLZl4Dqp 9m0XGgN/gypIXiwrKg3K9GTq2Nh8esmeh3QAqo511P8NqoEQFORrs5TGXp0NpwkUmjFe 3WfVUsw7FDX6TZyxU9uyBHIhC6h9FPxkLYCfmwPRwSS8eqoNIQBcs8nMCFeuCO6q8VBU 3vCg== X-Gm-Message-State: AMCzsaXFUSUWwjg4lsNxNkaj2iz/ifpt2ZBQjzaUIn2KnnH6SZ660Ru+ I0bc49Z98JtyKYzaUKuHpv41nfk= X-Google-Smtp-Source: AOwi7QCcYdQQ3W+tQvmIQa74QzzisYhB0dKoYOOOe4N9tStNf0y+j9COnH/Xo9FM9QCuleE8DPRorA== X-Received: by 10.98.252.71 with SMTP id e68mr532722pfh.319.1507766423455; Wed, 11 Oct 2017 17:00:23 -0700 (PDT) Received: from ?IPv6:2600:1010:b04c:26b6:35c4:532e:4231:b8de? ([2600:1010:b04c:26b6:35c4:532e:4231:b8de]) by smtp.gmail.com with ESMTPSA id y5sm28685292pfd.89.2017.10.11.17.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 17:00:21 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409 Mime-Version: 1.0 (1.0) Subject: Re: [lisp] IDEAS @IETF98 Minutes From: Sharon X-Mailer: iPhone Mail (15A421) In-Reply-To: Date: Wed, 11 Oct 2017 17:00:20 -0700 Cc: ideas@ietf.org, LISP mailing list list , NVO3 , routing-discussion@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Padma Pillay-Esnault Archived-At: X-Mailman-Approved-At: Wed, 25 Oct 2017 08:02:11 -0700 X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 00:00:34 -0000 --Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Discussed these 2 ID networking items with Albert and others, perhaps this i= s a good thread: 1. MAMBO -=20 Map-Assisted Measurnent Based Overlay The notion here is that identity based overlays offer global (map-assisted) c= hoices hop by hop underlays do not. One factor in making these choices can b= e by measuring the pearson correlation coefficient (pcc) between the tunnels= . If considered when selecting between VTEP X or VTEP Y to reach a multi hom= e EID or a load balanced EID it can double-quadruple overall overlay capacit= y.=20 2. Lisp-Lambda - A serverless (or virtual-appliance-less) alternative to service function cha= ining which is hard to scale and dev-ops. Its done by mapping flows at the I= TR, ETR, or STR (segment) to queues, and using the mapping to invoke the (ca= ched) function on the flow queue packets rather then hair pining the packets= in and out of function virtual appliances. Saves nic-ram-nic-ram... costly l= ifting. There are reference implementations and simulations to both if theres intere= st.=20 --szb > On Apr 13, 2017, at 12:01 AM, Padma Pillay-Esnault w= rote: >=20 > =20 >=20 >=20 > Please find below the minutes of the meeting. >=20 > Many thanks to our two scribes: Toerless Eckert and Uma Chunduri. >=20 >=20 > If you have any comments/corrections please let us know. >=20 > Thanks >=20 > Padma >=20 >=20 >=20 > IDEAS Side Meeting Minutes=20 >=20 > =20 >=20 > 1. Slides >=20 > Please find below a pointer to the slides >=20 > https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=3D= sharing >=20 > =20 >=20 > =20 >=20 > 2. Agenda=20 >=20 > 2.1. Introduction and Problem Statement for IDEAS - Padma Pillay-Esnault >=20 > =20 >=20 > https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-0= 1.txt =20 >=20 > =20 >=20 > IDEAS Introduction >=20 > =20 >=20 > IDEAS aims to be the forum where common issues across all ID Enabled Netwo= rks can be discussed. >=20 > Goals: >=20 > - to create awareness >=20 > - to present the work proposed in IDEAS >=20 > - A generic architecture that is scalable, extensible, robust, secur= e, and flexible for future ID enabled networks >=20 > - to sollicit comments and feedback from the community on the draft= s >=20 > - to call for new contributions >=20 > =20 >=20 > Problem Statement >=20 > Motivation: Why Now? >=20 > ID solutions can address diverse areas >=20 > IOT, M2M communication, Discovery, privacy, Latency, Virtualiz= ation >=20 > Beneficial to have standardized common infra across ID protocols >=20 > =20 >=20 > Key Issues Identified >=20 > Lack of common Infrastructure cause harder to deploy a common solution E2E= >=20 > - No Common Management due to disjoint nature >=20 > - No Common/consistent policy framework >=20 > - Risk of fragmented communication >=20 > Identifier Lifecycle >=20 > - No guidance or allocation scheme for public IDs >=20 > - Agreed upon ID format and scope in cross-domain communication >=20 > - Recycling IDs >=20 > - Better address merging of networks >=20 > Security of Mapping Systems >=20 > - Secured access to the MS >=20 > - data integrity, Confidentiality, Anonymity, Access control >=20 > - DDOS attack prone >=20 > =20 >=20 > Proposal >=20 > - To investigate the opportunity of a new specification effort to ad= dress some specific problems from an ID Enabled Networks perspective. >=20 > - To find a common solution and infrastructure that can be shared by= current protocols and facilitate the introduction of new ID-based services w= hile avoiding rehashing the same problems again each time a new service pops= up >=20 > - Generic Resilient ID Services (GRIDS) infrastructure with standard= ized access and multiple services. The services include >=20 > - secured registration >=20 > - discovery >=20 > - updates with data integrity, >=20 > - mapping and resolution capabilities, >=20 > - define relationships between IDs or group of IDs >=20 > - access control policy and security >=20 > - Other Related Work/ Groups >=20 > - LISP (ALT, DDT) >=20 > - HIP uses DNS >=20 > - NVO3 WG >=20 > =20 >=20 > Questions: >=20 > Eric Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifi= er. Are you considering "what is an identifier", clearly this is not about U= RI, how about IP in IP with IPsec ? Is one of them an identifier the other o= ne a locator. Even LISP was not clear cut between locator/identifier as one c= ould be routed locally. >=20 > =20 >=20 > Padma Pillay-Esnault: Regarding scope, the way we thinking about this, the= re can be multiple scopes with multiple allocation systems. The range of sol= utions is so vast that it may not be appropriate to only have one solution. P= lenty options of where to put it and how to put. GRIDS can be used as local,= proximity, global instance just as possible to have Private ID. >=20 > =20 >=20 > Bob Moskovitz: Concept of Identity and Identifier is important and I have= been involved and saw some form of this for the last 20 years may be more. I= t really does to be discussed in the list. Definitely it needs to be fleshed= out a lot more about >=20 > what identifiers are, should be part of the work, tough problem with lots o= f opinions. >=20 > =20 >=20 > =20 >=20 > 2.2. Requirements for Generic Resilient Identity Services (GRIDS) in IDEAS= - Alex Clemm >=20 > =20 >=20 > https://www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt >=20 > =20 >=20 > - This is the core infrastructure document which captures all requirements= >=20 > - Talked on Core components of GRIDS >=20 > - GRIDS-MS, GRIDS-IS are covered >=20 > - Grouping and Meta data are not described yet >=20 > - Identity and Identifier definitions elaborated >=20 > - Talked in details about mapping services >=20 > - Identity related services are detailed >=20 > - Structured and unstructured identifiers >=20 > - Grouping related services >=20 > - Requirement (Distribution, Redundancy, Performance and Scale..) >=20 > - Key performance requirements >=20 > - Security requirements >=20 > - GRIDS should be able to be deployed in private space as well as in p= ublic domain >=20 > =20 >=20 > - The naming evolved from mapping system, which was too functionally const= rained. >=20 > =20 >=20 > Questions:=20 >=20 > Ravi Ravindran: Trying to understand scope: trying to expand LISP ? >=20 > What is the scope ?=20 >=20 > =20 >=20 > Alex Clemm: No, not planning to just "expand lisp", that should be done in= LISP WG. Some of those questions are better answered in the use cases, clea= r which ones are not resolved by LISP. >=20 > =20 >=20 > Benjamin Damm: How is this different from Multicast DNS ? >=20 > =20 >=20 > Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that= would not be a great idea but there would be a lot of >=20 > problems, DDoS, etc.. Think that metadata is not optional but must be call= ed mandatory. Determined by use case. >=20 > =20 >=20 > Alex Clemm: Note taken >=20 > =20 >=20 > Dino Farinacci: rfc8060 defines multiple RLOC types, eg: LISP can support= those. Does this look like multicast DNS ? No, this is network layer mappin= g information mapping addresses to addresses. >=20 > =20 >=20 > Eric Nordmark: Multicast DNS is a local service, this is meant to be globa= l. >=20 > =20 >=20 > =20 >=20 > 2.3. A Blockchain-based Mapping System - Jordi Paillisse=20 >=20 > - Blockchain is decentralized and secured >=20 > - Add blocks of data one after other >=20 > - Blockchain work flow >=20 > - Transaction with a data, Senders Signature and Senders Public Key t= o a P2P network >=20 > - Properties >=20 > - Decentralized, No prior trust is required >=20 > Data can be added but not modifiable >=20 > - Basic Idea >=20 > - Store mappings in blockchain >=20 > - EID prefixes are distributed to all participants >=20 > - Pros and Cons >=20 > - Infrastructure less, Decentralized, fast lookup, secure, no prio= r trust, simple rekeying >=20 > - Cons >=20 > - Slow updates, costly boot strapping >=20 > - Comparison with LISP DDT >=20 > - No Infra, easy management >=20 > - Issues with RPKI >=20 > - Anonymity (prefix linked to owner name) >=20 > - Revocation issues (block chain doesn=E2=80=99t use certificates= ) >=20 > - Scalability >=20 > - Growth similar to BGP Churn >=20 > - Prefix delegation + Mappings >=20 > - Design considerations >=20 > - Bitcoin is too restrictive >=20 > - New technologies - More scalable and more contracts >=20 > - Dedicated chains.. >=20 > =20 >=20 > Questions: >=20 > Toerless Eckert: what is the incentive model for participants to deploy th= e necessary infrastructure for this system ? In bitcoin, the security is ach= ieved through tremendous amount of calculation, the cost for that hardware i= s financed by handing out bitcoins for successful calculations. Do we need t= o hand out IPv4 addresses to pay for IDEAS bitchain calculations ? >=20 > =20 >=20 > Jordi Paillisee: Good question, there are some new blockchain methods with= other incentive structures. See references on last slide of the slide deck.= >=20 > Regarding incentive it is about security. >=20 > =20 >=20 > Dino Farinacci:=20 >=20 > When a new registration added (Say Jordi first and then 100000 more record= s added. Now the entry moved to the end. This solution will have >=20 > complete history of movements. Q1: can the really old stuff be chopped off= . Q2: if RLOCs change etc. is it not really slow when you need to look throu= gh a lot of other newer mappings ? >=20 > Jordi Paillisee : Q1 Answer: It can be mitigated through implementation >=20 > Q2 answer: implementation detail. Database should have latest data for all= entities, not in sequential order of evens. >=20 > =20 >=20 > Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-bloc= kain group) met in the morning, sees overlap with that work, how could we cr= eate alignment. Whom to talk to coordinate ?=20 >=20 > Padma Pillay-Esnault: Let=E2=80=99s discuss this offline. >=20 > =20 >=20 > 2.4. Use Cases for IDEAS - Tom Herbert >=20 > https://www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt >=20 > =20 >=20 > - Mapping essentially a distributed key/value store >=20 > - Key is fixed size per mapping DB >=20 > - Maps "virtual address" to "physical address" >=20 > - Mapping table is assumed to be distributed and possibly shared fo= r load >=20 > - Rate of entry is important characteristic >=20 > =20 >=20 > - Use Cases: >=20 > - Common Control plane >=20 > - Mobility >=20 > - Network Virtualization (for network simplification) >=20 > - Heterogeneous Multi-Access (hetnet) >=20 > - Security >=20 > - Device Discovery >=20 > - Mobility >=20 > - Map entity to its current location for forwarding >=20 > - Variants =20 >=20 > - Encap: IP Mobility, IPIP, GTP etc.. >=20 > - ID/LOC: LISP, ILA >=20 > - Properties >=20 > - Mobility sub-cases >=20 > - Within a single mobile network >=20 > - Mobility between mobile networks >=20 > - Multi-homed devices >=20 > - Hetnet environments >=20 > - Whole networks are mobile (WIFI in bus) >=20 > - Network Virtualization >=20 > - Variants >=20 > - Encap: Map virtual IP address to Physical address >=20 > - ID/LOC split >=20 > - Properties >=20 > - Mostly in DC >=20 > - Address resolution static tunnels >=20 > - Could be used as alternative means to resolve L2/L3 >=20 > - Host Routes >=20 > - A network could implement virtualization simply by creating a= host route >=20 > =20 >=20 > Questions: >=20 > Bob Moskovitz: We have been mobile since 1993. We need to start looking at= mobility as baseline. Would almost challenge in discussion the starting poi= nt. Take rate of mobility (how fast it can move) as distinguishing attribute= . >=20 > =20 >=20 > Tom Herbert: Agree. How quickly is my "device" going from one network to a= nother. With higher rate, updates become a problem. Also get more and more u= se cases where latency becomes an issue. Hope we could avoid relying on a di= stributed system. Control path is critical system, keeping everything in syn= c with low latency and secure, reliable, available. Can we design this syste= m with applicability across different use cases. >=20 > =20 >=20 > Mike McBride: There are applications like AR/VR that have strict requireme= nts hopefully, that is also included in use cases. >=20 > =20 >=20 > Tom Herbert: Yes this has been discussed in the draft. >=20 > =20 >=20 > Padma Pillay-Esnault: Yes there different strict requirements depending on= the different use cases. Earlier there was a question regarding IOT use cas= es. The requirements may vary for example depending if the type of IOT devic= e. If it battery operated (supposed to last 10 years) then it may have only= one way communication (such as a pet tracker or sensor) and may even be on n= on-IP. In some cases proximity and context may be important too. >=20 > =20 >=20 > 2.5. Mobility First and Global Name Resolution Service - Parishad Karimi >=20 > https://www.ietf.org/id/draft-karimi-ideas-gnrs-00.txt >=20 > =20 >=20 > -Name based communications >=20 > - Name based Architectures IP =3D=3D> LISP, HIP at IETF MF and NDN (= in academia) >=20 > - MF - Mobility First Background >=20 > - MF started in 2010 under NSF, FIA >=20 > - MF Protocol Layers >=20 > - GUID (global Unique Identifiers) >=20 > - We seek to use global name resolution system for resolution >=20 > - Name Resolution Requirements >=20 > - Low propagation and response Latency >=20 > - Storage and load scalability >=20 > - Security and reliability >=20 > - Extensibility and flexibility >=20 > - Structure of mapping should not be limited >=20 > - Why can=E2=80=99t DNS can be supported (DNS Deficiencies) >=20 > - TTL based caching >=20 > - High Mobility makes caching ineffective >=20 > - Static Placement of AUTH Servers >=20 > - Reliance on hierarchal (relating root) >=20 > - For MF we have looked into DMAP and GMAP and Auspice >=20 > - Comparison of all three systems >=20 > - Conclusion - We need a global mapping system with MF project >=20 > =20 >=20 > =20 >=20 > 2.6 Conclusion & Next steps - Padma Pillay-Esnault >=20 > Where do we want to go from here ? >=20 > Next Steps Slide: >=20 > - We need more collaboration from the community and looking forward for mo= re participation on topics such as Blockchain and distributed trust, Late bi= nding, Fast Caching, Security, DDOS protection .... >=20 > =20 >=20 > - Let=E2=80=99s take discussions to the alias >=20 > - Discuss the scope of work=20 >=20 > =20 >=20 > 3. Other Info >=20 > Mailing list: IDEAS >=20 > List address: ideas@ietf.org >=20 > Archive: https://mailarchive.ietf.org/arch/search/?email_list=3Dideas >=20 > To subscribe: https://www.ietf.org/mailman/listinfo/ideas >=20 > =20 >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Discussed these 2 ID networking items w= ith Albert and others, perhaps this is a good thread:

1.= MAMBO - 

Map-Assisted Measurnent Based Overlay
= The notion here is that identity based overlays offer global (map-assisted) c= hoices hop by hop underlays do not. One factor in making these choices can b= e by measuring the pearson correlation coefficient (pcc) between the tunnels= . If considered when selecting between VTEP X or VTEP Y to reach a multi hom= e EID or a load balanced EID it can double-quadruple overall overlay capacit= y. 

2. Lisp-Lambda -
A serverless (or virtual-applianc= e-less) alternative to service function chaining which is hard to scale and d= ev-ops. Its done by mapping flows at the ITR, ETR, or STR (segment) to queue= s, and using the mapping to invoke the (cached) function on the flow queue p= ackets rather then hair pining the packets in and out of function virtual ap= pliances. Saves nic-ram-nic-ram... costly lifting.

= There are reference implementations and simulations to both if theres intere= st. 


--szb

On A= pr 13, 2017, at 12:01 AM, Padma Pillay-Esnault <padma.ietf@gmail.com> wrote:

 =

Please find below the minutes of the meeting.

Many thanks to our two scribes= : Toerless Eckert and Uma Chunduri.


If you have any comments/corrections p= lease let us know.

Thanks=

Padma


IDEAS Side Meeting Minutes 

 

1. Slides

Please find below a pointer to the slides

https://drive.google.com/drive/folders/0BwYx7u1T_20RODdLaWpIdk9feHc?usp=3D= sharing

 

 

2. Agenda 

2.1. Introduction and Problem Statement for IDEAS  - Padma Pillay-Esnau= lt

 

= https://www.ietf.org/internet-drafts/draft-padma-ideas-problem-statement-01.= txt    

 

IDEAS Introd= uction

 

=

IDEAS aims to be the forum where common issues across all ID Enabled Networks can b= e discussed.

 Goals:

-       to create awareness

-       to present the work proposed= in IDEAS

-       A generic architecture that i= s scalable, extensible, robust, secure, and flexible for future ID enabled networks

-        to sollicit comments a= nd feedback from the community on the drafts

-       to call for new contributions<= span>

  

Problem Statement

Motivation: Why Now?

ID solutions can address diverse areas

   = ;         IOT, M2M communication, Di= scovery, privacy, Latency, Virtualization

Beneficial to have standardized common infra across ID protocols

 

=

Key Issues Identified

Lack of common Infrastructure cause harder to deploy a common solution E2E=

  -&n= bsp;      No Common Management due to disjoint nature

  -       No Common/consistent policy framework

  -     &n= bsp; Risk of fragmented communication

 Identifier Lifecycle

  -       No guidance or allocation scheme for public IDs

  -       Agreed upon ID format and scope in cross-domain communication

  -       Recycling IDs

  -  &n= bsp;    Bet= ter address merging of networks

 Security of Mapping Systems

  -       Secured access to the MS

  -  &= nbsp;    da= ta integrity, Confidentiality, Anonymity, Access control

=   -     = ;  DDOS attack prone<= /span>

 

=

Proposal

-  = ;     To investigate the opportu= nity of a new specification effort to address some specific problems from an ID Enabled Networks perspective.

- &= nbsp;     To find a common solution a= nd infrastructure that can be shared by current protocols and facilitate the introduction of new ID-based service= s while avoiding rehashing the same problems again each time a new service pop= s up

-=        Generic Resilient ID Servi= ces (GRIDS) infrastructure with standardized access and multiple services.  The services include

      -       <= /span>secured registration=

   =   -       discovery

      -    &n= bsp;  updates with da= ta integrity,

      -       = mapping and resolution capabilities,

      -       = define relationships between IDs or group of IDs

      -       <= /span>access control policy and security

- Other Related Work/ Groups

    &nb= sp;  - LISP (ALT, DDT)

    &nb= sp;  - HIP uses DNS

    &nb= sp;  - NVO3 WG

 

Questions:<= /span>

Eric Nordmark: What=E2=80=99s unclear is what is out of scope re. Identifier. Are= you considering "what is an identifier", clearly this is not about URI, how about IP in IP with IPsec ? Is one of them an identifier the other one a= locator. Even LISP was not clear cut between locator/identifier as one could= be routed locally.

 

Padma Pillay-Esnault: Regarding scope, the way we thinking about this, there can b= e multiple scopes with multiple allocation systems. The range of solutions is s= o vast that it may not be appropriate to only have one solution. Plenty option= s of where to put it and how to put. GRIDS can be used as local, proximity, global instance just as possible to have Private ID.

 

Bob Moskovitz: Concept of Identity and Identifier is important and  I have been involved and saw some form of this for the last 20 years may be more. I= t really does to be discussed in the list. Definitely it needs to be fleshed o= ut a lot more about

what identifiers are, should be part of the work, tough problem with lots of opinions.

 

 

2.2. Requirements for Generic Resilient Identity Services (GRIDS) in IDEAS  - Alex Clemm

 

https://= www.ietf.org/internet-drafts/draft-padma-ideas-req-grids-00.txt

 

- This is the core infrastructure document which captures all requirements

   = ;  - Talked on Core components of GRIDS

   = ;  - GRIDS-MS, GRIDS-IS are covered

   = ;  - Grouping and Meta data are not described yet

=

   = ;  - Identity and Identifier definitions elaborated

   = ;  - Talked in details about mapping services

   = ;  - Identity related services are detailed

   = ;       - Structured and unstructured identifiers

   = ;       - Grouping related services

   = ;  - Requirement (Distribution, Redundancy, Performance and Scale..)

   = ;  - Key performance requirements

   = ;  - Security requirements

   = ;  - GRIDS should be able to be deployed in private space as well as in public domain

 

- The naming evolved from mapping system, which was too functionally constrain= ed.

 

Questions: <= span>

Ravi Ravindran: Trying to understand scope: trying to expand LISP ?<= /span>

What is the scope ? 

 

Alex Clemm: No, not planning to just "expand lisp", that should be done in LISP WG. Some of those questions are better answered in the use cases, clear= which ones are not resolved by LISP.

 

Benjamin Damm: How is this different from Multicast DNS ?

 

Bob Moskovitz: I can totally implement everything in GRIDS in DNS but that would= not be a great idea but there would be a lot of

problems, DDoS, etc.. Think that metadata is not optional but must be called mandatory= . Determined by use case.

 

Alex Clemm: Note taken

 

Dino Farinacci:  rfc8060 defines multiple RLOC types, eg: LISP can support t= hose. Does this look like multicast DNS ? No, this is network layer mapping information mapping addresses to addresses.

 

Eric Nordmark: Multicast DNS is a local service, this is meant to be global.

 

 

2.3. A Blockchain-based Mapping System - Jordi Paillisse 

- Blockchain is decentralized and secured

    &nb= sp;- Add blocks of data one after other

   = ;  - Blockchain work flow

   = ;  - Transaction with a data, Senders Signature and Senders Public Key to a P2P= network

   = ;  - Properties

   = ;     - Decentralized, No prior trust is required

   = ;        Data can be added but not modifiable

   = ;  - Basic Idea

   = ;     - Store mappings in blockchain

   = ;     - EID prefixes are distributed to all participants

   = ;  - Pros and Cons

   = ;     - Infrastructure less, Decentralized, fast lookup, secure, no prior trust, simple rekeying

   = ;     - Cons

   = ;         - Slow updates, costly boot strapping

   = ;  - Comparison with LISP DDT

   = ;     - No Infra, easy management

     - Issues with RPKI

   = ;      - Anonymity (prefix linked to owner name)

   = ;      - Revocation issues (block chain doesn=E2=80=99t use certificates)

   = ;  - Scalability

   = ;      - Growth similar to BGP Churn

   = ;      - Prefix delegation + Mappings

   = ;  - Design considerations

   = ;        - Bitcoin is too restrictive

   = ;        - New technologies - More scalable and more contracts

   = ;  - Dedicated chains..

 

Questions:<= /span>

Toerless Eckert: what is the incentive model for participants to deploy the necessary= infrastructure for this system ? In bitcoin, the security is achieved  through tremendous amount of calculation, the cost for that hardware is financed by handing out bitcoins for successful calculations. Do we need to hand out IPv4 addresses to pay for IDEAS bitchain calculations ?

 

Jordi Paillisee: Good question, there are some new blockchain methods with other incentive structures. See references on last slide of the slide deck.<= /span>

Regarding incentive it is about security.

 

Dino Farinacci: 

When a new registration added (Say Jordi first and then 100000 more records added= . Now the entry moved to the end. This solution will have<= /p>

complete history of movements. Q1: can the really old stuff be chopped off. Q2: if RL= OCs change etc. is it not really slow when you need to look through a lot of oth= er newer mappings ?

Jordi Paillisee : Q1 Answer: It can be mitigated through implementation

Q2 answer: implementation detail. Database should have latest data for all entities, not in sequential order of evens.

 

Manu Sporny: Blockchain developer. Referring to blockchain group (w3c-blockain group) met in the morning, sees overlap with that work, how could we create alignment. Whom to talk to coordinate ? 

Padma Pillay-Esnault: Let=E2=80=99s discuss this offline.

 

2.4. Use Cases for IDEAS - Tom Herbert

https://= www.ietf.org/internet-drafts/draft-padma-ideas-use-cases-00.txt

 

- Mapping essentially a distributed key/value store

   = ;    - Key is fixed size per mapping DB

   = ;   - Maps "virtual address" to "physical address"

   = ;    - Mapping table is assumed to be distributed and possibly shared for load

   = ;    - Rate of entry is important characteristic

 

   = ;    - Use Cases:

   = ;           - Common Control plane

   = ;           - Mobility

   = ;           - Network Virtualization (for network simplification)

   = ;           - Heterogeneous Multi-Access (hetnet)

   = ;           - Security

   = ;           - Device Discovery

   = ;    - Mobility

   = ;        - Map entity to its current location for forwarding

   = ;        - Variants         

   = ;            - Encap: IP Mobility, IPIP, GTP etc..

   = ;            - ID/LOC: LISP, ILA

   = ;        - Properties

   = ;    - Mobility sub-cases

   = ;        - Within a single mobile network

   = ;        - Mobility between mobile networks

   = ;        - Multi-homed devices

   = ;        - Hetnet environments

   = ;        - Whole networks are mobile (WIFI in bus)

   = ;    - Network Virtualization

   = ;        - Variants

   = ;           - Encap: Map virtual IP address to Physical address

   = ;           - ID/LOC split

   = ;        - Properties

   = ;           - Mostly in DC

   = ;    - Address resolution static tunnels

   = ;        - Could be used as alternative means to resolve L2/L3

   = ;    - Host Routes

   = ;        - A network could implement virtualization simply by creating a host route

 

Questions:<= /span>

Bob Moskovitz: We have been mobile since 1993. We need to start looking at mobil= ity as baseline. Would almost challenge in discussion the starting point. Take r= ate of mobility (how fast it can move) as distinguishing attribute.=

 

Tom Herbert: Agree. How quickly is my "device" going from one network to another. With higher rate, updates become a problem. Also get more and more u= se cases where latency becomes an issue. Hope we could avoid relying on a distributed system. Control path is critical system, keeping everything in s= ync with low latency and secure, reliable, available. Can we design this system with applicability across different use cases.

 

Mike McBride: There are applications like AR/VR that have strict requirements hopefully, that is also included in use cases.

 

Tom Herbert: Yes this has been discussed in the draft.

 

Padma Pillay-Esnault: Yes there different strict requirements depending on the different use cases. Earlier there was a question regarding IOT use cases. T= he requirements may vary for example depending if the type of IOT device. If it= battery  operated (supposed to last 10 years) then it may have only one= way communication (such as a pet tracker or sensor) and may even be on non-I= P. In some cases proximity and context may be important too.

 

2.5. Mobility First and Global Name Resolution Service - Parishad Karimi

https://www.ietf.org/id/d= raft-karimi-ideas-gnrs-00.txt=

 

-Name based communications

      - Name based Architectures IP =3D=3D> LISP, HIP a= t IETF MF and NDN (in academia)

   = ;   - MF - Mobility First Background

   = ;      - MF started in 2010 under NSF, FIA

   = ;   - MF Protocol Layers

   = ;       - GUID (global Unique Identifiers)

   = ;       - We seek to use global name resolution system for resolution

   = ;   - Name Resolution Requirements

   = ;       - Low propagation and response Latency

   = ;       - Storage and load scalability

   = ;       - Security and reliability

   = ;       - Extensibility and flexibility

   = ;  - Structure of mapping should not be limited

   = ;  - Why can=E2=80=99t DNS can be supported (DNS Deficiencies)

   = ;       - TTL based caching

   = ;       - High Mobility makes caching ineffective

   = ;       - Static Placement of AUTH Servers

   = ;       - Reliance on hierarchal (relating root)

   = ;  - For MF we have looked into DMAP and GMAP and Auspice

   = ;  - Comparison of all three systems

   = ;  - Conclusion - We need a global mapping system with MF project<= /span>

 

 

2.6 Conclusion & Next steps - Padma Pillay-Esnault

Where do we want to go from here ?

Next Steps Slide:

- We need more collaboration from the community and looking forward for more participation on topics such as Blockchain and distributed trust, Late bindi= ng, Fast Caching, Security, DDOS protection ....

 

=

- Let=E2=80=99s take discussions to the alias

- Discuss the scope of work 

 

=

3. Other Info

Mailing list: IDEAS

List address: ideas@ietf.org

Archive: https://mailarchive.ietf.org/arch/sear= ch/?email_list=3Dideas<= /span>

To subscribe: https://www.ietf.org/mailman/listinf= o/ideas

 

____________________= ___________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman= /listinfo/lisp
= --Apple-Mail-2B8E7735-09F6-4E01-801F-EACE7722E409-- From nobody Wed Oct 25 08:14:14 2017 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2922513F3F4; Wed, 25 Oct 2017 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 Ue3zxxavTtdF; Wed, 25 Oct 2017 08:13:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A939F13F3D0; Wed, 25 Oct 2017 08:13:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 87E9D460160; Wed, 25 Oct 2017 08:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1508944427; bh=MRs/LV3BcnotPN+9F219xsr+m6bkbw0jA3rNzmHjDl4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=AM0YuCsAXPdjqIE51gW+R+bPEAHqoP7asqoPIlbmae9Up0QqoVW0ZVDz9ZJ8mWwN2 4cBPuPZWibdYmZyPWTxBQV+Io67BdpuzCr9poIzV2nplaW0FW4FaQ8ovS/S0eA568/ ZUuFixyNzG8MgujQQJjoF8XVfxDDcCrOTACvtsqQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [97.65.134.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A147F2407FB; Wed, 25 Oct 2017 08:13:46 -0700 (PDT) Subject: Re: [lisp] IDEAS @IETF98 Minutes To: Sharon , Padma Pillay-Esnault Cc: ideas@ietf.org, NVO3 , LISP mailing list list , routing-discussion@ietf.org References: From: "Joel M. Halpern" Message-ID: Date: Wed, 25 Oct 2017 11:13:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2017 15:13:54 -0000 Regarding the second of your two points, I am not following you: On 10/11/17 8:00 PM, Sharon wrote: > Discussed these 2 ID networking items with Albert and others, perhaps > this is a good thread: > ... > > 2. Lisp-Lambda - > A serverless (or virtual-appliance-less) alternative to service function > chaining which is hard to scale and dev-ops. Its done by mapping flows > at the ITR, ETR, or STR (segment) to queues, and using the mapping to > invoke the (cached) function on the flow queue packets rather then hair > pining the packets in and out of function virtual appliances. Saves > nic-ram-nic-ram... costly lifting. > I am not asking why or how one can use LISP to direct traffic. I understand that. Rather, the description of service function chaining is veyr confusing. 1) One of the points of SFC is to direct packets to virtual service functions. We are not mandating virtual service functions, but rather enabling their use when operators want to use them. A technique that avoids such direction would seem to prevent such usage, defeating the point. 2) NSH (and more generally SFC) can be used to direct traffic on paths that do not happen to touch any service functions. If the service function path goes through a sequence of service function forwarders, but does not actually visit any service functions, nothing is violated. So while I have no problem with using LISP for chaining (either using LISP mapping to drive NSH SFPs or using LISP multi-hope technology for the data plane) I find the explanation you provided avoce confusing. Yours, Joel From nobody Fri Oct 27 13:57:45 2017 Return-Path: X-Original-To: routing-discussion@ietfa.amsl.com Delivered-To: routing-discussion@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0567213F3F5 for ; Fri, 27 Oct 2017 13:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 inp1130lpal2 for ; Fri, 27 Oct 2017 13:57:42 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DBA13836A for ; Fri, 27 Oct 2017 13:57:42 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id v9so12724015oif.13 for ; Fri, 27 Oct 2017 13:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=2u65vwbEo/96/sAcT3QwuJnIj2Yw63tF6pp22BPXlBI=; b=XoymbWtfq6kH8j7YXSHCIkUg5q3zU7jefwWcNzchvh0DEFDDRIvyDqQmFJ47IH34UE f8g03e2vAlHHJans6P0mQ97QpirMTFWODZAp1YdY/KBUYJQFjmcUczVSXu6xLz14mVp6 /Kx5OWq0AdNjgkh53MU087SYrbGaNOMM3o7MlsN2JEMzYC/murRfXIkaxJftl2HgVRoO 0/cyWCWEFoIuBVjCzgvPO7H4BI2pcM0dyo6Qec6kPCc2FT3V9nFAkfF1IGDR8dWoc7mf zbYOEHpiiAhS8ml83KY+KGpDztEruCQwAObAf3EHUb/oIqVOFqvQv4SPkzddH5BdR1OU G3ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=2u65vwbEo/96/sAcT3QwuJnIj2Yw63tF6pp22BPXlBI=; b=o7OTM/Qdj6vs2p5w7gf0z8vK8u+nPcGig+6Rc+J1ityl2kYAea2f+yN6bTgoCmyAkt zzBJXxtjs5V//Wzf4Pg5IDnQ1dF1gHf//DLtabyFu+b4x5PqZ9qLfGIdvri1K2pcQiU7 kelmx0AvSwV77jztiaCx4phuBsoCQ/bU8G3k8xTRk+ikpxtDha3r5UrKArT367ZqXs1k JQy4UWD7eVxhV/qlliYjNEkge86FCphlzGjC0WR58Q/jybo8DqENKuyllPl2YOduVHR0 Jiv5aQUxqLQ+YZQp+GTAI2yyQ1gTdrHKIe4CTwanGXNyDuNTgddWYoQirXfDKu5B+F3S Vpag== X-Gm-Message-State: AMCzsaVwB/FOqkaYFEIFmBSGhl6s6vtYY6gIVMz4/k1s+/gFANWAySG4 A2AMVaWPFjHZhGPjllUJXFh+xJbscuj0LTn1/lk= X-Google-Smtp-Source: ABhQp+TfTMSwVMvVC5Q89WQx75SIpXxZLY/iMgiJ7Q6c/vFmhqncC0DNV96VejG7BfDK2Fuc8hzu0qx+NmwZQ9yTQ7w= X-Received: by 10.202.197.141 with SMTP id v135mr1090307oif.35.1509137861556; Fri, 27 Oct 2017 13:57:41 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 27 Oct 2017 13:57:41 -0700 From: Alvaro Retana X-Mailer: Airmail (457) MIME-Version: 1.0 Date: Fri, 27 Oct 2017 13:57:41 -0700 Message-ID: Subject: RTG Area Open Meeting @ IETF 100 (rtgarea) To: "routing-discussion@ietf.org" Content-Type: multipart/alternative; boundary="001a11c158c227c1fe055c8d8ab0" Archived-At: X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Routing Area General mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2017 20:57:44 -0000 --001a11c158c227c1fe055c8d8ab0 Content-Type: text/plain; charset="UTF-8" Hi! I just published the rtgarea preliminary agenda for IETF 100. https://datatracker.ietf.org/meeting/100/materials/agenda-100-rtgarea/ As you can see, we have some extra time. If you have a topic you would like to bring up, or anything you think is important to discuss in this context, please let us (rtg-ads@ietf.org) know. Thanks! Alvaro. --001a11c158c227c1fe055c8d8ab0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi!

I just published the rtgarea preliminary agenda for IETF 100.


As you can see, we have some extra tim= e.=C2=A0 If you have a topic you would like to bring up, or anything you th= ink is important to discuss in this context, please let us (rtg-ads@ietf.org) know.

Thanks!

Alvaro.

--001a11c158c227c1fe055c8d8ab0--