From nobody Tue Mar 2 12:00:28 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EF13A10A2 for ; Tue, 2 Mar 2021 12:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=WRwQdw6W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wL1noGkA 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 PTBVe7z0AfYY for ; Tue, 2 Mar 2021 12:00:20 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0B5E3A102E for ; Tue, 2 Mar 2021 12:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13457; q=dns/txt; s=iport; t=1614715215; x=1615924815; h=from:to:subject:date:message-id:mime-version; bh=zI/R+qTS3jWCwz3MpUBdUqQjmdnpPborxjvkWclWtjo=; b=WRwQdw6W+ovhvFpEhKS3QSZ5wkVPd5TOgFkXDGJSnDwRWrgZEf11b4GT SgII1XUeJ4TIxmxMFQChsUw/zhR1yCOeTss7ctbgFif8/12OVm7/1XVDJ zSxR4lDXUJ5FhRdo9GmqzS9m425qKIB4AjTwHbvSrDE+bFej2D4HrrLPx M=; X-IPAS-Result: =?us-ascii?q?A0CYCgApmD5g/4QNJK1ig3swKSgHdlo2MYRBg0gDhTmIV?= =?us-ascii?q?pQxhHOBQoERA1QLAQEBDQEBKAoCBAEBhE0ZgWMCJTgTAgMBAQEDAgMBAQEBB?= =?us-ascii?q?QEBAQIBBgRxhWEBDIZuHQEBKQ8RAQYSMgIEMCcELYJWAYF+VwMvAQ6RYZBqA?= =?us-ascii?q?ooldoEygwQBAQaCTYJYGIISAwaBOIJ2hAYBAYJRhBocgUlCgREnHIIpg0gBA?= =?us-ascii?q?QOBI2eCaTSCK4FYgVpTMDZpCjkCJgmUCIdHniAKgnyJP5JhAx+DN4pPlVCUV?= =?us-ascii?q?Ys9kieEOQICAgIEBQIOAQEGgWsjgVdwFWUBggoBM1AXAg2PQgEJgkKFFIVFc?= =?us-ascii?q?zgCBgEJAQEDCXyLFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Awgwa7xQPWQUTJIQHyT8W4df+I9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,217,1610409600"; d="scan'208,217";a="655144261" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Mar 2021 20:00:14 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 122K0BHk003564 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Tue, 2 Mar 2021 20:00:14 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 2 Mar 2021 14:00:14 -0600 Received: from xfe-aln-004.cisco.com (173.37.135.124) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 2 Mar 2021 15:00:13 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Tue, 2 Mar 2021 14:00:13 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IT1VbtmBrxK4Eavhybhxq/dl26qLFeHndB8G+aaWD0ReO298HavyhrOKKR+ZZ0yIbdzpZhKcnUnCo3wby9beAz03HuQJapUUY9DpEK5tLPjSL709X8QB9ezGVwcmSBnj1Vp/2AV/fs+0PTbc57Z6He/u+MdsSRc46Zj7AytWZZjLaZZHjbzjQfbzdqXAZCNBq9QB+BAgc7mPtMav4CPwHUYNb6HM5JHcqBfVzsS0e6ArCN8Yjya9Ap5B+Q3jtLmAZ2e5aVyPvqf8vWsuW+RqKnMqd7KKBw82AgAoyDMhDdLY22S6QuYu+eFE4W182fpgmB3pcNY077HJfuUOx+Rq6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zI/R+qTS3jWCwz3MpUBdUqQjmdnpPborxjvkWclWtjo=; b=BWND1IrEHbVnpGcYIQh34Tn4stift731cFfq5Wu2YbyJWUTZSlA5gr0G/VQGSN+u7ub8sqHBEl4rY/2VBTlVuIdjAx3g+6FI+I+Vq911zPGfPCJngFmK8AVVXtGXG7H7inz+QeFqPdCca2IaU1b0JVAFxpI1G6h/kxxCIWA0UZTJYUutTXJJYgKFomXKy0y9TZipwJ1BdcVnvpEN7P+bjuAUIT9sLabEnXUep+Ln7R7xLE5MZ9C5jyXR/4RpZBtxy9u0X1bpA31NUxiRKtszaHcC123aHK1zpky8lgspCiuMER0osVGnj5hduzPP+iz0SeWj3HPh9kHZlbJiae7JVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zI/R+qTS3jWCwz3MpUBdUqQjmdnpPborxjvkWclWtjo=; b=wL1noGkAMCByJ/knDxv8VR33wPNkIWgiEM2sAtS9/lBkJZQN/mxfzHg1LdfIJ/rtfppwWHEIalM25XPLEY0t0B8df0Bo9ScPgr8FKPkZsyOnAVzXW+Hhqq1GKAt0WYMp078qIrWsOLihnRnPT9R6fAOM+EHh9Weab5lS7mLpVrI= Received: from SA2PR11MB4972.namprd11.prod.outlook.com (2603:10b6:806:fb::21) by SN6PR11MB2542.namprd11.prod.outlook.com (2603:10b6:805:60::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Tue, 2 Mar 2021 20:00:11 +0000 Received: from SA2PR11MB4972.namprd11.prod.outlook.com ([fe80::840f:b6a1:ef4d:ab32]) by SA2PR11MB4972.namprd11.prod.outlook.com ([fe80::840f:b6a1:ef4d:ab32%3]) with mapi id 15.20.3868.036; Tue, 2 Mar 2021 20:00:11 +0000 From: "Eric Vyncke (evyncke)" To: "int-dir@ietf.org" Thread-Topic: Summary and actions after the INT-DIR pre-IETF meeting Thread-Index: AQHXD56nxB150d7JkE+gyDG9FOGu2Q== Date: Tue, 2 Mar 2021 20:00:11 +0000 Message-ID: <141A71B3-252C-47C9-96EB-808366D4EC2D@cisco.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:e194:1527:5634:7bc1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 935a79c7-c691-4e46-4fe4-08d8ddb5c9a9 x-ms-traffictypediagnostic: SN6PR11MB2542: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UScSmHPP4rdoD2ftBwqNnaPiUIwR7/NuOfpmRBfhPcfFPe2kx/pNyRT/AfD9UjEXsfTyWYsXzOixaICthsNCZq71LTMhJjsVkUEILyZFpgmXBU1X+AL8Gt7WunKyfJq+ZH+dyiO8CFdYQ3JGGWUxj9YYAANSe3TkpWYPDs7k2tNyiQq/0lMDbMJmm7wfQEEx49SyuFicEj3BGrtIwf4WUQ0SJ+01vxqivWkPxuMmEp4EaN22mq6kJlrlIRHlurewUcRnAJVIRxpjG3wNcjTLshPG1YwlqMzdnp/7hjkVn7xM6zrE3dM3i/b7rzyaAFDAafa/17djuPA6rhJqGN965ZCfKDhj4dHHaYp/ISivbsaHpCbgxOz5a7YEnyJJSxTvwkObLsR/3tdLWVMQvLFIlavWXN9IoT794KT3CK0cPzQ9h5dvo37wwAgP3RWwoHhi3GDFxPWDgL+Xvk0rki/mXXpRZhB5QtWk8VDHeI2FFdwQQv8jiBzE2bHoukiuwcrjjsJ9WkgGgq02B+YJoMmFBeXNPNOGlHYo4gwUwW1YPIQNmw7DsGMTBmwMx+PaOVIGAbjUh27FzT1zP+SJ63X8hKcGADNMJl/KBn0Zh3uoHwCkBD3J/h2LXUBMSxbL0D0e222Q0Jow3MpNKK4wFyqs+A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB4972.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(366004)(376002)(39860400002)(966005)(6486002)(6916009)(478600001)(2616005)(83380400001)(186003)(86362001)(71200400001)(36756003)(66946007)(6512007)(8936002)(5660300002)(66556008)(91956017)(6506007)(2906002)(8676002)(66446008)(33656002)(66476007)(166002)(316002)(64756008)(76116006)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?emQzUFp0VXM4MGdKUHUzQUV5MlNlMEVlT3dXOGNIUjc1d0szY25WTXRXV1dj?= =?utf-8?B?L3h4eWFJUmI0WHRUbnJ3ckZpTFBIejB2MnYwaFRqcmdvYS9zc1I1djNwZjRJ?= =?utf-8?B?c3lldndMWTl6RFl2RlhmbUpxQ0txQVpkb2RpeHQvWXU5VXhSRDhYOXBXWThU?= =?utf-8?B?RWtEVk9CSTJralRXRDJEZ0NUZUlOQkZOTGdkNkppbU5MN2ZnOHZQMHdIaDdQ?= =?utf-8?B?UHlhdFRYUUkvNFBSZTlQVGNLaXJISVlyVEFCUytLSS9iVklBTGtTYUpXcU92?= =?utf-8?B?UzU1bVpsQUwzSUx4SFE4elNWcEZVeXcxVTNGRExRRDhGcVdnYkNlb2VCZ04w?= =?utf-8?B?NGRSakQvRVVoanlmUjJDU2crYVZ5TFdiTkJrMnVwS3RYUFBJcDZFOWhUNlEy?= =?utf-8?B?eTRydVdrU1gzRTZvZHdiTlBvZ094bkdpU21MK2prYXQwb2VuZERsbGVtTDRW?= =?utf-8?B?dFQ2SmRVWUNFZEtYc0VZeVlKSmhCVmFla2IxQkU4RXRhQ1ZrVmpyQUwyR3Iv?= =?utf-8?B?T3FoaktCTGJFM0RCVlBCL09aQmJFTUdMSkJSU0FVait5TEZ1Zk83M3VFOEF5?= =?utf-8?B?YUMwVmVPekRQS2RsSXJiZVp1Z3RwdVAzbTUyWXRIdEZiTHpLTkxTVGRiS0ho?= =?utf-8?B?emNuMnAycW9oU0kwM3Y2NDl6MUx5akplYUxhTUxnR3l3T0ZhQ0svbzM2SUpq?= =?utf-8?B?VGtKd2NaYnZ0Q2gvMDR6dHprRSszbWg5enlYTzdpR2lYcmUzWUpsa3dSdTFQ?= =?utf-8?B?ZlRQS2VzQ0hETkc2TjJFQXFCb2tsaG9uUXEzUlNRc0M5T1pwWFIrbng4SnVD?= =?utf-8?B?YUdDQjBlVjFNTTQ2dWxtZDk1QmFobmYvZU1YanZqYlFlSElnaHlCcEtDdnZy?= =?utf-8?B?Q2RGamI0OVRUSTI4cGY4L2pSa3ZaMStxRHdmcnJuYkF0aFlJZWpDOEEvV1BX?= =?utf-8?B?MU9EUE0rVWZqcytRTUpxRzJtSmY3bEsvMmFWdUFZWG1mdzQ0Mk93aGxqc3pU?= =?utf-8?B?dndQblZDVUt1S2duS2UvQTBXZk5XbnNXcExzYUx6c2V2amVQSEZpSVJaWG5E?= =?utf-8?B?RWtnbWRTUVlHeUs1TGhaNmdCMThMZ1lBTzEyYy9QSXRzUVpxbkhEZ2tvWjRl?= =?utf-8?B?ZWtsRFZPMnRrM0dXSXhzUkVNcnZwaWo5WjREWlp0UUVNOW1Zbk96a1VyeUJ3?= =?utf-8?B?R0V3MGc3SkxkQWdpbmtSMTJqQ0xNczc1OVZmcnorcUVZaUdpTHFDdFArRGlF?= =?utf-8?B?bmU0aExLbVJGV2ZYeTA3YkdqYlhOME11UDMraUQzbkpKbzlxN3pMRXU1Qk9I?= =?utf-8?B?T0xJL2FsVjZWM2ExOUUxZGJxWFV4Smpycy84cndDeEphQXFKVXJORnRpSHZC?= =?utf-8?B?SER6OGw2QVhYNUNCRWV4THB0dG1zTGhUUGR0N3g5UE1BM0hnWjV1aVU5NENi?= =?utf-8?B?bXIyVlA1TU9lVUs4V2tJZ3VJQ0FBeHRuejFaQXcySFh1UFgvaHc5d1AxcThw?= =?utf-8?B?RUg0YWFkT281V3kyN0JVMlI1K3J0VkhrSDRoeFQwTG9OMk84Q2ZHaklzRWh2?= =?utf-8?B?N0E5dTJBRDZycnBCcENtM0s0VDNwbVZDamR2T3ZzL3loYlI4UWZ5QzVlM29K?= =?utf-8?B?d1hxWUtRejdtMXZyM0xlYnp3RkdWc0h2b09aTG9WRHR6NEVpVTRqbkVGL2cv?= =?utf-8?B?NDdJWEJXVnF1MDIvTEl4SW9wRnc2QUVlOVkwNjUrYUEwZUVvV1RMZkxHbHRG?= =?utf-8?B?SmJBOEs1aTVQaFEyNjMvMFZZL1IwRFBSamNTc1NZRlo4TTN0bVR4QUhpUmVQ?= =?utf-8?B?ZVpnaDlGdnJRRnRxTk5JTFQvc2lCU0w3bVhEUGd2bGkyZ2ZGREJSZWsyM0RS?= =?utf-8?Q?aB4Qv2k57p71C?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_141A71B3252C47C996EB808366D4EC2Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB4972.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 935a79c7-c691-4e46-4fe4-08d8ddb5c9a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2021 20:00:11.4284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nFvT4+v3E34N8nUWNB2fI68MoTBohYU/NPzEOW2pqDMesl8iNl2tMLUtUJHcaXCQtCDpCEoi6Q4Xu/wKV81g6w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2542 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: [Int-dir] Summary and actions after the INT-DIR pre-IETF meeting X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2021 20:00:27 -0000 --_000_141A71B3252C47C996EB808366D4EC2Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBkaXJlY3RvcmF0ZSBtZW1iZXJzLA0KDQpUaGFuayB5b3UgZm9yIHRob3NlIG9mIHlvdSB3 aG8gd2VyZSBhYmxlIHRvIGpvaW4gdGhpcyBtZWV0aW5nLg0KDQpXZWxjb21lIHRvIG91ciBuZXcg bWVtYmVyczogU3V6YW5uZSBXb29sZiwgV2Fzc2ltIEhhZGRhZCwgSnVhbiBDYXJsb3MgWsO6w7Fp Z2EsIEJvYiBIaW5kZW4sIE9sZSBUcm9hbiwgQnJpYW4gSGFiZXJtYW4sIFN1cmVzaCBLcmlzaG5h biwgVG9tbXkgUGF1bHksIGFuZCBUaW0gV2ludGVycy4gVGhleSB3aWxsIGJyaW5nIG5ldyBleWVz IGFuZCBhZGRpdGlvbmFsIGV4cGVydGlzZS4NCg0KQmVzaWRlIHNvbWUgV0cgbmV3cyBzaGFyZWQg YnkgdGhlaXIgcmVzcGVjdGl2ZSBjaGFpcnMsIHdlIGFsc28gZGlzY3Vzc2VkIGFib3V0IHRoZSBk aXJlY3RvcmF0ZSDigJhjaGFydGVy4oCZDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2dy b3VwL2ludGRpci9hYm91dC8NCg0KVGhpcyBjaGFydGVyIHdhcyB3cml0dGVuIGEgbG9uZyB0aW1l IGFnbyB3aGVuIHRoZSBnb2FscyBvZiBhIGRpcmVjdG9yYXRlIHdlcmUgbm90IHdlbGwga25vd24u IFRoZXJlZm9yZSwgdGhpcyDigJhjaGFydGVy4oCZIHNob3VsZCBiZSByZWZyZXNoZWQgYW5kIHdl IGFyZSBsb29raW5nIGZvciB2b2x1bnRlZXJzIChlc3AgbmV3IHBhaXJzIG9mIGV5ZXMpIHRvIGhh dmUgYSByZXZpZXcgb2YgaXQgKGFuZCBzaG9ydGVuIGl0KS4gTm90aGluZyB1cmdlbnQsIHRoaXMg Y2FuIGJlIGRvbmUgQXByaWwgb3IgTWF5LiBTdXphbm5lIGtpbmRseSBhY2NlcHRlZCB0byBoYXZl IGEgZmlyc3QgZHJhZnQuDQoNCldlIGFsc28gZGlzY3Vzc2VkIG9uIGhvdyB0byBwcm92aWRlIHNv bWUgYmVuZWZpdHMgKGJleW9uZCB0aGUgZmFtZSA7LSkgKSBmb3IgbWVtYmVyczoNCg0KICAqICAg SW4gdGhlIGRhdGF0cmFja2VyIElFVEYgcHJvZmlsZTogYWRkaW5nIGhvdyBtYW55IHJldmlld3Mg ZG9uZSBzaW5jZSBsYXN0IElFVEYgbWVldGluZywgLi4uDQogICogICBIYXZpbmcgbWVtYmVycyB3 b3JraW5nIGZvci93aXRoIG90aGVyIFNETyBvciBpbmR1c3RyeSBhbGxpYW5jZXMgKGUuZy4sIFdC QSwgSUVFRSwgZXRjLikgdG8gcXVpY2tseSByZXBvcnQgd2hhdCBpcyBuZXcgYW5kIGludGVyZXN0 aW5nIGZvciBJTlQgYXJlYSB0byB0aGlzIHByZS1JRVRGIGNhbGxzDQogICogICAuLi4NCg0KV2hh dCBkbyBtZW1iZXJzIHRoaW5rIGFib3V0IHRoZSBhYm92ZSA/DQoNCkFib3V0IHRoZSByZXZpZXdz LCBpdCB3b3VsZCBiZSBuaWNlIGZvciBhbGwgbWVtYmVycyB0byBhZGQgdG8gdGhlaXIgcHJvZmls ZXMgYW55IHNwZWNpZmljIHRvcGljIHRoZXkgd2FudCB0byByZXZpZXcgKGUuZy4sIEROUywgSVB2 NiwgLi4uIG9yIOKAmGFueeKAmSBhcyBhIHdpbGRjYXJkKSArIHRoZSBmcmVxdWVuY3kgKG1vbnRo bHksIHdlZWx5LCAuLi4pLiBUaGUgY2hhaXJzIChCZXJuaWUgYW5kIENhcmxvcykgd2lsbCB0cnkg dG8gcmVzcGVjdCB0aG9zZSB3aXNoZXMuIFRoZSBjaGFpcnMgYW5kIG15c2VsZiB3b3VsZCBsaWtl IGFsc28gdG8gc3RyZXNzIHRoYXQgd2hlbiBhIHJldmlldyByZXF1ZXN0IGlzIHNlbnQgdG8geW91 LCBwbGVhc2UgYWNjZXB0IG9yIGRlY2xpbmUgcXVpY2tseSwgdGhpcyB3aWxsIGFsbG93IGZvciBy ZXJvdXRpbmcgdGhlIHJlcXVlc3QgdG8gYW5vdGhlciBtZW1iZXIuDQoNCkZpbmFsbHksIGZvciB0 aGUgV0cgY2hhaXJzLCB0aGVyZSBpcyBhbHdheXMgdGhlIHBvc3NpYmlsaXR5IGluIHRoZSBkYXRh IHRyYWNrZXIgdG8gYXNrIGZvciBhbiDigJhlYXJseSByZXZpZXfigJggYnkgYW55IGRpcmVjdG9y YXRlIChzbyBhbHNvIFlBTkcgZG9jdG9ycyk7IGUuZy4sIGJlZm9yZSBhIFdHTEMuDQoNClRoYW5r IHlvdSBpbiBhZHZhbmNlIGZvciB5b3VyIGNvbnRpbnVlZCBwYXJ0aWNpcGF0aW9uDQoNClJlZ2Fy ZHMNCg0KLcOpcmljIC1lcmlrIC1iZXJuaWUgLWNhcmxvcw0K --_000_141A71B3252C47C996EB808366D4EC2Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWls U3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxMjc1MTQwMjEwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxOTcyMTExODIyIDI1MDc1ODE4IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NTsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUJFIiBsaW5r PSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiI+RGVhciBkaXJlY3RvcmF0ZSBtZW1iZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmsg eW91IGZvciB0aG9zZSBvZiB5b3Ugd2hvIHdlcmUgYWJsZSB0byBqb2luIHRoaXMgbWVldGluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPldlbGNvbWUgdG8gb3VyIG5ldyBtZW1iZXJzOiBTdXphbm5lIFdv b2xmLCBXYXNzaW0gSGFkZGFkLCBKdWFuIENhcmxvcyBaw7rDsWlnYSwgQm9iIEhpbmRlbiwgT2xl IFRyb2FuLCBCcmlhbiBIYWJlcm1hbiwgU3VyZXNoIEtyaXNobmFuLCBUb21teSBQYXVseSwgYW5k IFRpbSBXaW50ZXJzLiBUaGV5IHdpbGwgYnJpbmcgbmV3IGV5ZXMgYW5kIGFkZGl0aW9uYWwgZXhw ZXJ0aXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzaWRlIHNvbWUgV0cgbmV3cyBzaGFyZWQgYnkg dGhlaXIgcmVzcGVjdGl2ZSBjaGFpcnMsIHdlIGFsc28gZGlzY3Vzc2VkIGFib3V0IHRoZSBkaXJl Y3RvcmF0ZSDigJhjaGFydGVy4oCZPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZ3JvdXAvaW50ZGlyL2Fib3V0LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9ncm91cC9pbnRkaXIvYWJvdXQvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBjaGFydGVy IHdhcyB3cml0dGVuIGEgbG9uZyB0aW1lIGFnbyB3aGVuIHRoZSBnb2FscyBvZiBhIGRpcmVjdG9y YXRlIHdlcmUgbm90IHdlbGwga25vd24uIFRoZXJlZm9yZSwgdGhpcyDigJhjaGFydGVy4oCZIHNo b3VsZCBiZSByZWZyZXNoZWQgYW5kIHdlIGFyZSBsb29raW5nIGZvciB2b2x1bnRlZXJzIChlc3Ag bmV3IHBhaXJzIG9mIGV5ZXMpIHRvIGhhdmUgYSByZXZpZXcgb2YNCiBpdCAoYW5kIHNob3J0ZW4g aXQpLiBOb3RoaW5nIHVyZ2VudCwgdGhpcyBjYW4gYmUgZG9uZSBBcHJpbCBvciBNYXkuIFN1emFu bmUga2luZGx5IGFjY2VwdGVkIHRvIGhhdmUgYSBmaXJzdCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPldlIGFsc28gZGlzY3Vzc2VkIG9uIGhvdyB0byBwcm92aWRlIHNvbWUgYmVuZWZpdHMgKGJl eW9uZCB0aGUgZmFtZSA7LSkgKSBmb3IgbWVtYmVyczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZSBkYXRhdHJhY2tlciBJRVRGIHByb2ZpbGU6IGFk ZGluZyBob3cgbWFueSByZXZpZXdzIGRvbmUgc2luY2UgbGFzdCBJRVRGIG1lZXRpbmcsIC4uLjxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48c3BhbiBsYW5nPSJFTi1V UyI+SGF2aW5nIG1lbWJlcnMgd29ya2luZyBmb3Ivd2l0aCBvdGhlciBTRE8gb3IgaW5kdXN0cnkg YWxsaWFuY2VzIChlLmcuLCBXQkEsIElFRUUsIGV0Yy4pIHRvIHF1aWNrbHkgcmVwb3J0IHdoYXQg aXMgbmV3IGFuZCBpbnRlcmVzdGluZyBmb3IgSU5UIGFyZWEgdG8gdGhpcyBwcmUtSUVURg0KIGNh bGxzPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIGxhbmc9 IkVOLVVTIj4uLi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgZG8gbWVtYmVycyB0 aGluayBhYm91dCB0aGUgYWJvdmUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFib3V0IHRoZSBy ZXZpZXdzLCBpdCB3b3VsZCBiZSBuaWNlIGZvciBhbGwgbWVtYmVycyB0byBhZGQgdG8gdGhlaXIg cHJvZmlsZXMgYW55IHNwZWNpZmljIHRvcGljIHRoZXkgd2FudCB0byByZXZpZXcgKGUuZy4sIERO UywgSVB2NiwgLi4uIG9yIOKAmGFueeKAmSBhcyBhIHdpbGRjYXJkKSArIHRoZSBmcmVxdWVuY3kg KG1vbnRobHksIHdlZWx5LCAuLi4pLiBUaGUgY2hhaXJzIChCZXJuaWUNCiBhbmQgQ2FybG9zKSB3 aWxsIHRyeSB0byByZXNwZWN0IHRob3NlIHdpc2hlcy4gVGhlIGNoYWlycyBhbmQgbXlzZWxmIHdv dWxkIGxpa2UgYWxzbyB0byBzdHJlc3MgdGhhdCB3aGVuIGEgcmV2aWV3IHJlcXVlc3QgaXMgc2Vu dCB0byB5b3UsIHBsZWFzZSBhY2NlcHQgb3IgZGVjbGluZSBxdWlja2x5LCB0aGlzIHdpbGwgYWxs b3cgZm9yIHJlcm91dGluZyB0aGUgcmVxdWVzdCB0byBhbm90aGVyIG1lbWJlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZpbmFsbHksIGZvciB0aGUgV0cgY2hhaXJzLCB0aGVyZSBpcyBhbHdheXMgdGhl IHBvc3NpYmlsaXR5IGluIHRoZSBkYXRhIHRyYWNrZXIgdG8gYXNrIGZvciBhbiDigJhlYXJseSBy ZXZpZXfigJggYnkgYW55IGRpcmVjdG9yYXRlIChzbyBhbHNvIFlBTkcgZG9jdG9ycyk7IGUuZy4s IGJlZm9yZSBhIFdHTEMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UgaW4gYWR2YW5jZSBm b3IgeW91ciBjb250aW51ZWQgcGFydGljaXBhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+LcOpcmljIC1lcmlrIC1iZXJuaWUgLWNhcmxvczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_141A71B3252C47C996EB808366D4EC2Dciscocom_-- From nobody Wed Mar 17 03:56:43 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CA63A1245; Wed, 17 Mar 2021 03:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 DG176oc0EHct; Wed, 17 Mar 2021 03:56:37 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2099.outbound.protection.outlook.com [40.107.93.99]) (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 EEED93A1233; Wed, 17 Mar 2021 03:56:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cotQnU3udrstQY0cUyAyMH8mO0KpLUU3dV8lwCcvM16Zm7tZoZo+ODAAVsAO1YVt52J4M6fwCkcFTu1sj8e/NeiIf2yxBzNPX921vOgEvfHYi/X+qI8as1B/Mpn+iBqi2Z+38bkKmKoi4uGqd4koAA3zC4x9w/F4q/YPxFCsnQdCXGGgLOdhNCBnA0GrOsx0Hhdql9RK7OGVkxwwmkE5qe+ZeAe83/K5zdaIUo++D+nbTuWU3F2rhKVZczmPlDRl/Rd4gfMYzfiWTRdjtRS2/SiMxh1CwfUoZ7JizsobuJlDwNEBPjCIdzXRWDAUT6xyL+OkXGodlwpHJl87p55w0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fge+KXxyoItXCpUS36WpzbVxdOQ1ICyJpwngfq6MfqA=; b=cvQQc5PxdH1meCRoaZaswo9ZEWTFZhGgQ4utF+BesVqVjRx4hca6jpl0XO6GyHZNRmVjk3AjT+Da3rFjb2ZfDQXiZHCHaY731iT5NxJndbv8H5qHTvjFcJBGwWsz5SoSM77t6nUup8EYvZ1FXif9O7ZfnHJT/uybSt806gTzzR97TJh/4gn8omhzlqn9xi0jmPNyNquIg6IzN6eYmyzPqfEVEQXqIbSEWJ8DAMkwRWdJdlAsfnduuV7svCNMJ07aUWOt4bUMRuAyPzUeuN3Uhh8/gmbCiL4v5L1A7AkWDvHp38NHpATpILbacY8EXbZrZFuWV3+dH8NxW9x3uYj7sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fge+KXxyoItXCpUS36WpzbVxdOQ1ICyJpwngfq6MfqA=; b=w+f8LZl0HbIC/g7TpOivl76YjhJ2UV12n9wvwrWoTyFVF/jSjAhdvFsF4x6A6jMPjd0pesbsw72MsXmRT7x4J+/WBsWtAopIpgty1Ne2Xrak9CJKhKjQQP6YkhYKyQhXEh53y10GEJqJCDauVJBdWsDMumy8h3mf1IU7QUdj8rY= Received: from MWHPR08MB3520.namprd08.prod.outlook.com (2603:10b6:301:61::15) by MWHPR08MB2798.namprd08.prod.outlook.com (2603:10b6:300:cc::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Wed, 17 Mar 2021 10:56:04 +0000 Received: from MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::3df6:7840:7369:73a6]) by MWHPR08MB3520.namprd08.prod.outlook.com ([fe80::3df6:7840:7369:73a6%6]) with mapi id 15.20.3933.032; Wed, 17 Mar 2021 10:56:04 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: Jean-Michel Combes , "int-dir@ietf.org" CC: "bess@ietf.org" , "draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org" , "last-call@ietf.org" Thread-Topic: Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 Thread-Index: AQHW724azrWDKaoe40WMynsH9VAKhaqGvSFX Date: Wed, 17 Mar 2021 10:56:03 +0000 Message-ID: References: <161117591453.11763.14808972528115094239@ietfa.amsl.com> In-Reply-To: <161117591453.11763.14808972528115094239@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [79.156.144.227] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 63592539-e136-425a-68ed-08d8e9334283 x-ms-traffictypediagnostic: MWHPR08MB2798: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fe8rinlzgtVP9M7wj7E9+jXMUAvr2fOjO/LdrFruTb6HhSL9lcr4a0L74MiNya0AqSpg71552Q9LbEDzoTfCU4oZqurnCgVBPN4XCHv5jreXolifkWifWh6kzjK9PsdRjJEp42HlYo2fyIsQhHf2O2iCZkkQNdiwXlE2i8ulWssy37yD9V75+/eMNJUPVCvd+yJbTBLm9WEVTvO/S6CFQp9/lO/MPNvhgp5RIwNxWyWAhfp0bDLjaU0LD808u5ZjMu1/2VrdM2ngGYi2ifWim2Ysr7/NrXV+mCWyJ4OBFSDlW73HM6w8le+kf9Sx9eOVgEGuQ+sZZEbWUhTBobr+ZsBQPME2aZ+HNqhONu/F2QkgomXsN37rmCndOU0+z0a3V9iF3lZLhf5+9HrkNxSWKr5pEp1yN7R/vJa8MK3iRarFMcUUaEMOHJEydeIR4RKwjCItgb4Gk1bGVa4m6Kh6i/qFHgGYe7Ux3M0oywDgMhBI+ebSpJwMJtPonXhPgVUX5sQz7Vxl/8P9VZ1J7cb+W7k4xNo/hCuUeIizKxVdUF/i2Kr5Yk1XEOgSLDxOtf2v2mfrVo1Lku2bnO/O0AR92x8LxDFDaoMozMby/jWvn2ilgMsa0FdOlYszYrS8tFvyotu51j7fO+4NCCJjMyWzBQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR08MB3520.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(39860400002)(346002)(366004)(396003)(186003)(64756008)(966005)(4326008)(66476007)(2906002)(166002)(478600001)(53546011)(66946007)(66556008)(6506007)(8676002)(33656002)(7696005)(71200400001)(76116006)(8936002)(91956017)(83380400001)(66446008)(110136005)(86362001)(55016002)(54906003)(9686003)(5660300002)(316002)(30864003)(66574015)(52536014)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?FJ8/JZIWYmwYmDhFqo77fX9pRvoY+pzv4WupigP15c1vWcsjuy9xIiuu?= =?Windows-1252?Q?W0HiTqRJOlMtQIold+PxoSgJIQ4c0KuXxBIQz0jko5a/nv8cF6Ffguh2?= =?Windows-1252?Q?Hn/HRv3dxNKZ1Rm1JqG8xM2q1uXVONsjO0FHLixkpdUvH0hps0yJcrkj?= =?Windows-1252?Q?tuixmSIaT6UyKluO7IlgW5MOw4Vm9wwmMcU6Jsm8RMXYahbeeTo6bp78?= =?Windows-1252?Q?hM6WUtQe3JS7eC4T4omS+ykwZZ/cKAQ4tHrKGYhzLuBF0cpqAZGqKO5H?= =?Windows-1252?Q?mruVlNaisGm8FdMOd+aCOeHWFZImFNBoIRwYpXtxKDQdHeqUay1TEfY3?= =?Windows-1252?Q?S36di/p0Me3uM8gX4gdQ2DQtjPpWE7Q+eUg5eE2uJcZr9omc6ZREPzzi?= =?Windows-1252?Q?1V0grvemQuIbVif25sFhlkNaHhVxQPsHROW0Rr4uRubdgit5n8Gj52Jw?= =?Windows-1252?Q?0cDqdTeWd6SLDroNFPPlutH74QR3zoOMXoKHkXexvrpCQuNOsNXueE80?= =?Windows-1252?Q?dLtTtppr+chabmgviVVpjchjCY5Z6KVSTfn65hSJQbiWhcXxLeGfYIAS?= =?Windows-1252?Q?G4XS8e43PM+5/lrJyWTuo6uRCgDC5MMWHuzzm8ZqkYjk+/6pclv5pxbu?= =?Windows-1252?Q?8+RxUGCS292k2+w6CwEWEoZVmuTDWSryU8BgydKCmy26lXFRIF5jIQX9?= =?Windows-1252?Q?HFdEUSuO6jQKbHrmIu5peGAK1cTlaTlXwY/mW2erda6C6vd1jxihW0q8?= =?Windows-1252?Q?PzEG8zHZqhstgKSqrELxhQN8OBwscpOLghWZCIvmKk1toOclcWvQRHhs?= =?Windows-1252?Q?I14462jPcrPcmtoUubX3usNxPne/m3eHyf0U+W6XdMfD23wbfAoekv2u?= =?Windows-1252?Q?c5vbk4yRJKaM54hlLRrXzniZd17sum4NdyJJP6W4cUzYAR31sQO/aOOD?= =?Windows-1252?Q?nhcJo+dRf9u2Ar661aHn2uk8znMt1HorR+jJnA5drgQnrcl/BxT1MftI?= =?Windows-1252?Q?Ic9BQ0tUK7XRSRF55/jdW5OJu0rXD6YgC1BpqUUxhJXXS5ax3AqI8mr5?= =?Windows-1252?Q?UOmDFFhe0BIvsT0BmbQusFdOQZsdLA6Vg2txIUZavbMBt2ao33oZCY71?= =?Windows-1252?Q?+Bn4as5y5A4VJ0tC/gCx5Hyu2UBHGp7oDGtOLS61HNe1DPSU6AYsPRqk?= =?Windows-1252?Q?6Dcx23O8FmlUfSrXQ158EbVffaspBRvpn/dQTGU4+zU5h11jjfiRdW0/?= =?Windows-1252?Q?/xFB3tik7MriJJE/e4tRfuUMLCAQRT8N76F/kGruNhV3yeEbg9ZNaMEm?= =?Windows-1252?Q?lXvUQwEnBntsZsIOPsCbf9mecCkPy/IJOpufkwVBxd/lD/IPInBo4XtJ?= =?Windows-1252?Q?uF0Q3rjsLgls3eNycHu8L6ZaCWtHHd5moufE1UjN2a0SRlxrg2GJD8kr?= =?Windows-1252?Q?FbVpsp3t2g23mq82LGAMmg=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9MWHPR08MB3520namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR08MB3520.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63592539-e136-425a-68ed-08d8e9334283 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2021 10:56:03.8848 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aTEqk534PbXtDhIjQvM5CVSioJ3+bhBQafso+/OBVu5zDYw5HoJkJ38wjhjKzJ4fItILtzgGdyb4ERjcnnygXA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2798 Archived-At: Subject: Re: [Int-dir] Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2021 10:56:41 -0000 --_000_MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9MWHPR08MB3520namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Jean-Michel, Thank you very much for the thorough review and my apologies for the delay = in my reply. Please see my comments in-line with [jorge]. Thank you. Jorge From: Jean-Michel Combes via Datatracker Date: Wednesday, January 20, 2021 at 9:52 PM To: int-dir@ietf.org Cc: bess@ietf.org , draft-ietf-bess-evpn-proxy-arp-nd.all@ie= tf.org , last-call@ietf.org= Subject: Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd-11 Reviewer: Jean-Michel Combes Review result: Almost Ready Hi, Please find my review, as member of the INT Area Directorate, of the follow= ing document: *** GENERAL COMMENT(S)/QUESTION(S) *** o Forwarding a packet I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN allows a PE to forward a packet when the CE owning the MAC destination addr= ess and the CE owning the MAC source address are not on the same L2 link. If my assumption is wrong, that should change deeply my review. */ [jorge] let me try to clarify since I agree this is important. In your e= xample, both CEs are on the same L2 link. Suppose you have two CEs connecte= d to an EVPN BD (as in the document) CE1----PE1---evpn---PE2---CE2 In EVPN terminology we say CE1 and CE2 are in the same Broadcast Domain (BD= , a broadcast from one CE will reach the other CE without any modification = on the frame) and they belong to the same subnet. What that means is that C= E1 needs to resolve CE2=92s IP address (via ARP/ND) and once it does, CE1 s= ends a unicast frame to CE2 and neither PE1 nor PE2 change the MAC SA or MA= C DA of that frame. Frames between CE1 and CE2 will have the same behavior = as if they were connected to the same L2 switch or L2 link. Does this help? */ o State of the art There are no reference to RFC 4349 and RFC 6957, at least. Previous works have been done on =93Proxy-ND=94 and potential issues alread= y analyzed/solved. Please my comments/questions inside: - Section 3.6 - Secti= on 6 */ [jorge] RFC4349 seems to be =93High-Level Data Link Control (HDLC) Frame= s over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)=94 =96 not sure what = the link is with proxy-ND, is this the RFC you intended to refer to? Sorry = if I am missing something. About RFC6957, thanks for pointing that out. However, the scenario is diffe= rent IMHO =96 RFC6957 refers to a point-to-multipoint topologies with a spl= it-horizon forwarding, where the =91CEs=92 have no direct communication wit= hin the same L2 link. That is not the same as in an EVPN BD, where the CEs = have direct communication at L2. Please let me know if that makes sense. */ *** DEEP REVIEW *** BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Updates: 7432 (if approved) K. Nagaraj Intended status: Standards Track G. Hankins Expires: July 11, 2021 Nokia T. King DE-CIX January 7, 2021 Operational Aspects of Proxy-ARP/ND in EVPN Networks draft-ietf-bess-evpn-proxy-arp-nd-11 1. Terminology BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic. BD: Broadcast Domain. ARP: Address Resolution Protocol. GARP: Gratuitous ARP message. ND: Neighbor Discovery Protocol. NS: Neighbor Solicitation message. NA: Neighbor Advertisement. IXP: Internet eXchange Point. IXP-LAN: the IXP's large Broadcast Domain to where Internet routers are connected. DC: Data Center. IP->MAC: an IP address associated to a MAC address. IP->MAC entries are programmed in Proxy-ARP/ND tables and may be of three different types: dynamic, static or EVPN-learned. SN-multicast address: Solicited-Node IPv6 multicast address used by NS messages. NUD: Neighbor Unreachability Detection, as per [RFC4861]. DAD: Duplicate Address Detection, as per [RFC4861]. SLLA: Source Link Layer Address, as per [RFC4861]. TLLA: Target Link Layer Address, as per [RFC4861]. R Flag: Router Flag in NA messages, as per [RFC4861]. O Flag: Override Flag in NA messages, as per [RFC4861]. S Flag: Solicited Flag in NA messages, as per [RFC4861]. RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as per [RFC7432]. MAC or IP DA: MAC or IP Destination Address. MAC or IP SA: MAC or IP Source Address. AS-MAC: Anti-spoofing MAC. LAG: Link Aggregation Group. BD: Broadcast Domain. BD is already defined at the beginning of the list. /* [jorge] good catch! Removed. Thanks! */ 3. Solution Description As PE3 learns more and more host entries in the Proxy-ARP/ND table, the flooding of ARP Request messages is reduced and in some cases it can even be suppressed. In a network where most of the participant CEs are not moving between PEs and they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding as well as the unknown unicast flooding can practically be suppressed. In an EVPN- based IXP network, where all the entries are Static, the ARP/ND flooding is in fact totally suppressed. IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address Detection (DAD) is remaining, even when the entries are all Static: cf. RFC 4862, Section 5.4. /* [jorge] I should probably clarify that the PEs doing proxy-ARP/ND do not= have any assigned IPv6 address of their own in the BD. I agree with you th= at CEs connected to the PEs must do DAD, and PEs doing proxy-ND will reply = to the DAD messages. If all the CEs attached to the same BD have static ent= ries on the PEs, ND flooding *among* PEs should be practically suppressed. = I included the phrase =93among PEs=94 to avoid confusion, let me know if th= at helps please: =93As PE3 learns more and more host entries in the Proxy-ARP/ND table, the = flooding of ARP Request messages among PEs is reduced and in some cases it = can even be suppressed. In a network where most of the participant CEs are = not moving between PEs and they advertise their presence with GARPs or unso= licited NA messages, the ARP/ND flooding among PEs, as well as the unknown = unicast flooding, can practically be suppressed. In an EVPN-based IXP netwo= rk, where all the entries are Static, the ARP/ND flooding among PEs is in f= act totally suppressed.=93 */ The Proxy-ARP/ND function can be structured in six sub-functions or procedures: 1. Learning sub-function 2. Reply sub-function 3. Unicast-forward sub-function 4. Maintenance sub-function 5. Flooding reduction/suppression sub-function 6. Duplicate IP detection sub-function A Proxy-ARP/ND implementation MAY support all those sub-functions or only a subset of them. The following sections describe each individual sub-function. No sub-function is mandatory to have =93Proxy-ARP/ND=94 working correctly? If not, please, add text saying which ones MUST be implemented. /* [jorge] I agree, I changed it to: =93A Proxy-ARP/ND implementation MUST at least support the Learning, Reply = and Maintenance sub-functions. The following sections describe each individ= ual sub-function.=94 */ 3.2. Reply Sub-Function This sub-function will reply to Address Resolution requests/ solicitations upon successful lookup in the Proxy-ARP/ND table for a given IP address. The following considerations should be taken into account: a. When replying to ARP Request or NS messages, the PE SHOULD use the Proxy-ARP/ND entry MAC address as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. What is the IP source address in the NA message? What is the Target link-layer address in the NA message? /* [jorge] I added the following, let me know if it addresses your question= s please: The following considerations should be taken into account, assuming that the ARP Request/NS lookup hits a Proxy-ARP/ND entry IP1->MAC1: a. When replying to ARP Request or NS messages: - the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as MAC SA. This is RECOMMENDED so that the resolved MAC can be learned in the MAC FIB of potential layer-2 switches sitting between the PE and the CE requesting the Address Resolution. - for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and MAC1 addresses in the Sender Protocol Address and Hardware Address fields, respectively. - for an NA message in response to an address resolution NS or DAD NS, the PE MUST use IP1 as the IP SA and Target Address. M1 MUST be used as the Target Link Local Address. */ 3.3. Unicast-forward Sub-Function As discussed in Section 3.2, in some cases the operator may want to 'unicast-forward' certain ARP-Request and NS messages as opposed to reply to them. The operator SHOULD be able to activate this option with one of the following parameters: a. unicast-forward always b. unicast-forward unknown-options If 'unicast-forward always' is enabled, the PE will perform a Proxy- ARP/ND table lookup and in case of a hit, the PE will forward the packet to the owner of the MAC found in the Proxy-ARP/ND table. This is irrespective of the options carried in the ARP/ND packet. This option provides total transparency in the BD and yet reduces the amount of flooding significantly. If 'unicast-forward unknown-options' is enabled, upon a successful Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' action only if the ARP-Request or NS messages carry unknown options, as explained in Section 3.2. The 'unicast-forward unknown-options' configuration allows the support of new applications using ARP/ND in the BD while still reducing the flooding. What happens, for these two options, when there is no hit inside =93Proxy-A= RP/ND Table=94? /* [jorge] good point, thanks, I added this: =93Irrespective of the enabled option, if there is no successful Proxy- ARP/ND lookup, the unknown ARP-Request/NS will be flooded in the context of the BD, as per Section 3.6.=94 */ 3.5. Flooding (to Remote PEs) Reduction/Suppression The Proxy-ARP/ND function implicitly helps reducing the flooding of ARP Request and NS messages to remote PEs in an EVPN network. However, in certain use-cases, the flooding of ARP/NS/NA messages (and even the unknown unicast flooding) to remote PEs can be suppressed completely in an EVPN network. For instance, in an IXP network, since all the participant CEs are well known and will not move to a different PE, the IP->MAC entries may be all provisioned by a management system. Assuming the entries for the CEs are all provisioned on the local PE, a given Proxy-ARP/ND table will only contain static and EVPN-learned entries. In this case, the operator may choose to suppress the flooding of ARP/NS/NA to remote PEs completely. Cf. my comment about DAD in section 3. /* [jorge] following up on my response to your comment, the DAD messages fr= om the CE will be replied by the proxy-ND function on the connected PE if t= here is a hit. Otherwise it should be flooded. The above case for IXPs with= all static entries is an exception that assumes there is always a successf= ul lookup on the proxy-ND table, hence flooding could be avoided. I also ad= ded a sentence for the next paragraph: The flooding may also be suppressed completely in IXP networks with dynamic Proxy-ARP/ND entries assuming that all the CEs are directly connected to the PEs and they all advertise their presence with a GARP/unsolicited-NA when they connect to the network. If any of those two assumptions is not true and any of the PEs may not learn all the local Proxy-ARP/ND entries, flooding of the ARP/NS/NA messages from the local PE to the remote PEs SHOULD NOT be suppressed, or the address resolution process for some CEs will not be completed. */ 3.6. Duplicate IP Detection The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. Duplicate Address Detection is mandatory: s/SHOULD/MUST IMHO, it would be useful to add text explaining why RFC 6957 doesn=92t solv= e your issues and so you need to specify a solution =93from scratch=94. */ [jorge] Since DAD is still performed by the CEs, we wanted to make this = duplicate IP detection on the PEs as a recommendation rather than a MUST. A= lso there are many proxy-ND implementations for EVPN BDs out there that do = not do this and we didn=92t want to make them non-compliant unless it is ab= solutely necessary. Let me know if it is ok to keep it as SHOULD. Also, I added this to address your comment about RFC6957, let me know if it= is ok: The Proxy-ARP/ND function SHOULD support duplicate IP detection so that ARP/ND-spoofing attacks or duplicate IPs due to human errors can be detected. For IPv6 addresses, CEs will continue to carry out the DAD procedures as per [RFC4862]. The solution described in this section is an additional security mechanism carried out by the PEs that guarantees IPv6 address moves between PEs are legit and not the result of an attack. [RFC6957] describes a solution for IPv6 Duplicate Address Detection Proxy, however, it is defined for point- to-multipoint topologies with a split-horizon forwarding, where the 'CEs' have no direct communication within the same L2 link and therefore it is not suitable for EVPN Broadcast Domains. In addition, the solution described in this section includes the use of the AS-MAC for additional security. */ 5.1. All Dynamic Learning In this scenario for minimum security and mitigation, EVPN is deployed in the peering network with the Proxy-ARP/ND function shutdown. PEs do not intercept ARP/ND requests and flood all requests, as in a conventional layer-2 network. ND messages are IP based: s/layer-2/layer-3 /* [jorge] the =93layer-2=94 refers to the network between the CEs and not = the nature of the CEs or the messages they sent. I modified the sentence to= clarify, let me know if it helps please: PEs do not intercept ARP/ND requests and flood all requests issued by the CEs, as a conventional layer-2 network among those CEs would do. */ 6. Security Considerations The solution also provides protection against Denial Of Service attacks that use ARP/ND-spoofing as a first step. The Duplicate IP Detection and the use of an AS-MAC as explained in Section 3.6 protects the BD against ARP/ND spoofing. You are assuming that the attacker and the victim are not on the same L2-Li= nk. Is it always the case in your scenarios (i.e., only P2P links between PE an= d CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. /* [jorge] the attacker and the victim are in the same L2 broadcast domain,= as discussed at the beginning of the email. Does that change your comment?= Let me know if it doesn=92t please. */ I would some text about the fact that your proposal cannot/will not work if there is a (current or future) security mechanism securing ARP/ND exchanges (e.g., SEND) because the PE is not able to secure "proxied" ND messages (i.= e., with SEND, the PE is not aware of the security credentials linked to an IP address). /* [jorge] Based on Russ=92 review https://mailarchive.ietf.org/arch/msg/be= ss/wi_uxXT1HGfxCGphJL6fDmeqPa4/ - I removed any references to SEND in the t= ext. Other than that, I added this: Finally, it is worth noting that the Proxy-ARP/ND solution in this document will not work if there is a mechanism securing ARP/ND exchanges among CEs, because the PE is not able to secure the "proxied" ND messages. Taking your words as a model=85 Let me know if this addresses your concern,= please. */ Thanks in advance for your replies. /* [jorge] thank YOU for such thorough review of the ND aspects! */ Best regards, JMC. --_000_MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9MWHPR08MB3520namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Jean-Michel,

 

Thank you very much for the thorough review and my apologies for the dela= y in my reply.

Please see my comments in-line with [jorge].

 

Thank you.

Jorge

 

From: Jean-Michel Combes via Datatracker <n= oreply@ietf.org>
Date: Wednesday, January 20, 2021 at 9:52 PM
To: int-dir@ietf.org <int-dir@ietf.org>
Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-proxy-= arp-nd.all@ietf.org <draft-ietf-bess-evpn-proxy-arp-nd.all@ietf.org>,= last-call@ietf.org <last-call@ietf.org>
Subject: Intdir telechat review of draft-ietf-bess-evpn-proxy-arp-nd= -11

Reviewer: Jean-Michel Combes
Review result: Almost Ready

Hi,

Please find my review, as member of the INT Area Directorate, of the follow= ing
document:

*** GENERAL COMMENT(S)/QUESTION(S) ***
o Forwarding a packet
I am not aware of EVPN mechanisms: for this review, I am assuming that EVPN=
allows a PE to forward a packet when the CE owning the MAC destination addr= ess
and the CE owning the MAC source address are not on the same L2 link. If my=
assumption is wrong, that should change deeply my review.

*/ [jorge] let me try to clarify since I agree this is important. In you= r example, both CEs are on the same L2 link. Suppose you have two CEs conne= cted to an EVPN BD (as in the document)

CE1----PE1---evpn---PE2---CE2

In EVPN terminology we say CE1 and CE2 are in the same Broadcast Domain = (BD, a broadcast from one CE will reach the other CE without any modificati= on on the frame) and they belong to the same subnet. What that means is tha= t CE1 needs to resolve CE2=92s IP address (via ARP/ND) and once it does, CE1 sends a unicast frame to CE2 an= d neither PE1 nor PE2 change the MAC SA or MAC DA of that frame. Frames bet= ween CE1 and CE2 will have the same behavior as if they were connected to t= he same L2 switch or L2 link. Does this help?

*/

o State of the art
There are no reference to RFC 4349 and RFC 6957, at least.
Previous works have been done on =93Proxy-ND=94 and potential issues alread= y
analyzed/solved. Please my comments/questions inside: - Section 3.6 - Secti= on 6

*/ [jorge] RFC4349 seems to be =93High-Level Data Link Control (HDLC) Fr= ames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)=94 =96 not sure what= the link is with proxy-ND, is this the RFC you intended to refer to? Sorry= if I am missing something.

About RFC6957, thanks for pointing that out. However, the scenario is di= fferent IMHO =96 RFC6957 refers to a point-to-multipoint topologies with a = split-horizon forwarding, where the =91CEs=92 have no direct communication = within the same L2 link. That is not the same as in an EVPN BD, where the CEs have direct communication at L2. Plea= se let me know if that makes sense.

*/



*** DEEP REVIEW ***

BESS Workgroup          &= nbsp;           &nbs= p;            &= nbsp;       J. Rabadan, Ed.
Internet-Draft          &= nbsp;           &nbs= p;            &= nbsp;          S. Sathappan Updates: 7432 (if approved)        =             &nb= sp;            =   K. Nagaraj
Intended status: Standards Track       &= nbsp;           &nbs= p;          G. Hankins
Expires: July 11, 2021         = ;            &n= bsp;            = ;           Nokia
            &nb= sp;            =             &nb= sp;            =             &nb= sp;  T. King
            &nb= sp;            =             &nb= sp;            =             &nb= sp;   DE-CIX
            &nb= sp;            =             &nb= sp;            =        January 7, 2021

          Operational Aspects = of Proxy-ARP/ND in EVPN Networks
            &nb= sp;     draft-ietf-bess-evpn-proxy-arp-nd-11

<snip>

1.  Terminology

<snip>

   BCP14 [RFC2119] [RFC8174] when, and only when, they appear in = all
   capitals, as shown here.

   BUM: Broadcast, Unknown unicast and Multicast layer-2 traffic.=

   BD: Broadcast Domain.

   ARP: Address Resolution Protocol.

   GARP: Gratuitous ARP message.

   ND: Neighbor Discovery Protocol.

   NS: Neighbor Solicitation message.

   NA: Neighbor Advertisement.

   IXP: Internet eXchange Point.

   IXP-LAN: the IXP's large Broadcast Domain to where Internet ro= uters
   are connected.

   DC: Data Center.

   IP->MAC: an IP address associated to a MAC address.  I= P->MAC entries
   are programmed in Proxy-ARP/ND tables and may be of three diff= erent
   types: dynamic, static or EVPN-learned.

   SN-multicast address: Solicited-Node IPv6 multicast address us= ed by
   NS messages.

   NUD: Neighbor Unreachability Detection, as per [RFC4861].

   DAD: Duplicate Address Detection, as per [RFC4861].

   SLLA: Source Link Layer Address, as per [RFC4861].

   TLLA: Target Link Layer Address, as per [RFC4861].

   R Flag: Router Flag in NA messages, as per [RFC4861].

   O Flag: Override Flag in NA messages, as per [RFC4861].

   S Flag: Solicited Flag in NA messages, as per [RFC4861].

   RT2: EVPN Route type 2 or EVPN MAC/IP Advertisement route, as = per
   [RFC7432].

   MAC or IP DA: MAC or IP Destination Address.

   MAC or IP SA: MAC or IP Source Address.

   AS-MAC: Anti-spoofing MAC.

   LAG: Link Aggregation Group.

   BD: Broadcast Domain.

<JMC>
BD is already defined at the beginning of the list.
</JMC>

/* [jorge] good catch! Removed. Thanks! */



<snip>

3.  Solution Description

<snip>

   As PE3 learns more and more host entries in the Proxy-ARP/ND t= able,
   the flooding of ARP Request messages is reduced and in some ca= ses it
   can even be suppressed.  In a network where most of the p= articipant
   CEs are not moving between PEs and they advertise their presen= ce with
   GARPs or unsolicited NA messages, the ARP/ND flooding as well = as the
   unknown unicast flooding can practically be suppressed.  = In an EVPN-
   based IXP network, where all the entries are Static, the ARP/N= D
   flooding is in fact totally suppressed.

<JMC>
IMHO, it is not possible to suppress ALL ND flooding: Duplicate Address
Detection (DAD) is remaining, even when the entries are all Static: cf. RFC=
4862, Section 5.4. </JMC>

/* [jorge] I should probably clarify that the PEs doing proxy-ARP/ND do = not have any assigned IPv6 address of their own in the BD. I agree with you= that CEs connected to the PEs must do DAD, and PEs doing proxy-ND will rep= ly to the DAD messages. If all the CEs attached to the same BD have static entries on the PEs, ND flooding *a= mong* PEs should be practically suppressed. I included the phrase =93among = PEs=94 to avoid confusion, let me know if that helps please:=

=93As PE3 learns more and more host entries in the Proxy-ARP/ND table, the = flooding of ARP Request messages among PEs is reduced and in some cases it can even be suppressed. In= a network where most of the participant CEs are not moving between PEs and= they advertise their presence with GARPs or unsolicited NA messages, the ARP/ND flooding among PEs, as well as the unknown unicast floodi= ng, can practically be suppressed. In an EVPN-based IXP network, where all = the entries are Static, the ARP/ND flooding among PEs is in fact totally suppressed.=93=

*/

   The Proxy-ARP/ND function can be structured in six sub-functio= ns or
   procedures:

   1.  Learning sub-function

   2.  Reply sub-function

   3.  Unicast-forward sub-function

   4.  Maintenance sub-function

   5.  Flooding reduction/suppression sub-function

   6.  Duplicate IP detection sub-function

   A Proxy-ARP/ND implementation MAY support all those sub-functi= ons or
   only a subset of them.  The following sections describe e= ach
   individual sub-function.

<JMC>
No sub-function is mandatory to have =93Proxy-ARP/ND=94 working correctly?<= br> If not, please, add text saying which ones MUST be implemented.
</JMC>

/* [jorge] I agree, I changed it to:

=93A Proxy-ARP/ND implementation MUST at least support the Learning, Rep= ly and Maintenance sub-functions. The following sections describe each indi= vidual sub-function.=94

*/

<snip>

3.2.  Reply Sub-Function

   This sub-function will reply to Address Resolution requests/    solicitations upon successful lookup in the Proxy-ARP/ND table= for a
   given IP address.  The following considerations should be= taken into
   account:

   a.  When replying to ARP Request or NS messages, the PE S= HOULD use
       the Proxy-ARP/ND entry MAC address as = MAC SA.  This is
       RECOMMENDED so that the resolved MAC c= an be learned in the MAC
       FIB of potential layer-2 switches sitt= ing between the PE and the
       CE requesting the Address Resolution.<= br>
<JMC>
What is the IP source address in the NA message?
What is the Target link-layer address in the NA message?
</JMC>

/* [jorge] I added the following, let me know if it addresses your quest= ions please:

   The following considerations s= hould be taken into

   account, assuming that the ARP= Request/NS lookup hits a Proxy-ARP/ND

   entry IP1->MAC1:=

 

   a.  When replying to ARP = Request or NS messages:

 

       - = ; the PE SHOULD use the Proxy-ARP/ND entry MAC address MAC1 as

       &= nbsp;  MAC SA.  This is RECOMMENDED so that the resolved MAC can = be

       &= nbsp;  learned in the MAC FIB of potential layer-2 switches sitting

       &= nbsp;  between the PE and the CE requesting the Address Resolution.

 

       - = ; for an ARP reply, the PE MUST use the Proxy-ARP entry IP1 and<= /span>

       &= nbsp;  MAC1 addresses in the Sender Protocol Address and Hardware=

       &= nbsp;  Address fields, respectively.

 

       - = ; for an NA message in response to an address resolution NS or

       &= nbsp;  DAD NS, the PE MUST use IP1 as the IP SA and Target Address.

       &= nbsp;  M1 MUST be used as the Target Link Local Address.

 

*/

  <snip>

3.3.  Unicast-forward Sub-Function

   As discussed in Section 3.2, in some cases the operator may wa= nt to
   'unicast-forward' certain ARP-Request and NS messages as oppos= ed to
   reply to them.  The operator SHOULD be able to activate t= his option
   with one of the following parameters:

   a.  unicast-forward always

   b.  unicast-forward unknown-options

   If 'unicast-forward always' is enabled, the PE will perform a = Proxy-
   ARP/ND table lookup and in case of a hit, the PE will forward = the
   packet to the owner of the MAC found in the Proxy-ARP/ND table= .  This
   is irrespective of the options carried in the ARP/ND packet.&n= bsp; This
   option provides total transparency in the BD and yet reduces t= he
   amount of flooding significantly.

   If 'unicast-forward unknown-options' is enabled, upon a succes= sful
   Proxy-ARP/ND lookup, the PE will perform a 'unicast-forward' a= ction
   only if the ARP-Request or NS messages carry unknown options, = as
   explained in Section 3.2.  The 'unicast-forward unknown-o= ptions'
   configuration allows the support of new applications using ARP= /ND in
   the BD while still reducing the flooding.

<JMC>
What happens, for these two options, when there is no hit inside =93Proxy-A= RP/ND
Table=94? </JMC>

/* [jorge] good point, thanks, I added this:

   =93Irrespective of the ena=
bled option, if there is no successful Proxy-
   ARP/ND lookup, the unknown=
 ARP-Request/NS will be flooded in the
   context of the BD, as per =
Section 3.6.=94

*/

<snip>

3.5.  Flooding (to Remote PEs) Reduction/Suppression

   The Proxy-ARP/ND function implicitly helps reducing the floodi= ng of
   ARP Request and NS messages to remote PEs in an EVPN network.<= br>    However, in certain use-cases, the flooding of ARP/NS/NA messa= ges
   (and even the unknown unicast flooding) to remote PEs can be    suppressed completely in an EVPN network.

   For instance, in an IXP network, since all the participant CEs= are
   well known and will not move to a different PE, the IP->MAC= entries
   may be all provisioned by a management system.  Assuming = the entries
   for the CEs are all provisioned on the local PE, a given Proxy= -ARP/ND
   table will only contain static and EVPN-learned entries. = In this
   case, the operator may choose to suppress the flooding of ARP/= NS/NA
   to remote PEs completely.

<JMC>
Cf. my comment about DAD in section 3.
</JMC>

/* [jorge] following up on my response to your comment, the DAD messages= from the CE will be replied by the proxy-ND function on the connected PE i= f there is a hit. Otherwise it should be flooded. The above case for IXPs w= ith all static entries is an exception that assumes there is always a successful lookup on the proxy-ND table, he= nce flooding could be avoided. I also added a sentence for the next paragra= ph:

The flooding may also be suppressed comple=
tely in IXP networks with
   dynamic Proxy-ARP/ND entries =
assuming that all the CEs are directly
   connected to the PEs and they=
 all advertise their presence with a
   GARP/unsolicited-NA when they=
 connect to the network.  If any of
   those two assumptions is n=
ot true and any of the PEs may not learn
   all the local Proxy-ARP/ND=
 entries, flooding of the ARP/NS/NA
   messages from the local PE=
 to the remote PEs SHOULD NOT be suppressed,
   or the address resolution =
process for some CEs will not be completed.

*/

<snip>

3.6.  Duplicate IP Detection

   The Proxy-ARP/ND function SHOULD support duplicate IP detectio= n so
   that ARP/ND-spoofing attacks or duplicate IPs due to human err= ors can
   be detected.

<JMC>
Duplicate Address Detection is mandatory: s/SHOULD/MUST
IMHO, it would be useful to add text explaining why RFC 6957 doesn=92t solv= e your
issues and so you need to specify a solution =93from scratch=94. </JMC&g= t;

*/ [jorge] Since DAD is still performed by the CEs, we wanted to make th= is duplicate IP detection on the PEs as a recommendation rather than a MUST= . Also there are many proxy-ND implementations for EVPN BDs out there t= hat do not do this and we didn=92t want to make them non-compliant unless it is absolutely necessary. Let me = know if it is ok to keep it as SHOULD.

Also, I added this to address your comment about RFC6957, let me know if= it is ok:

   The Proxy-ARP/ND function =
SHOULD support duplicate IP detection so
   that ARP/ND-spoofing attac=
ks or duplicate IPs due to human errors can
   be detected.  For IPv=
6 addresses, CEs will continue to carry out the
   DAD procedures as per [RFC=
4862].  The solution described in this
   section is an additional s=
ecurity mechanism carried out by the PEs
   that guarantees IPv6 addre=
ss moves between PEs are legit and not
   the result of an attack.&n=
bsp; [RFC6957] describes a solution for IPv6
   Duplicate Address Detectio=
n Proxy, however, it is defined for point-
   to-multipoint topologies w=
ith a split-horizon forwarding, where the
   'CEs' have no direct commu=
nication within the same L2 link and
   therefore it is not suitab=
le for EVPN Broadcast Domains.  In
   addition, the solution des=
cribed in this section includes the use of
   the AS-MAC for additional =
security.

 

*/

<snip>

5.1.  All Dynamic Learning

   In this scenario for minimum security and mitigation, EVPN is<= br>    deployed in the peering network with the Proxy-ARP/ND function=
   shutdown.  PEs do not intercept ARP/ND requests and flood= all
   requests, as in a conventional layer-2 network.

<JMC>
ND messages are IP based:
s/layer-2/layer-3
</JMC>

/* [jorge] the =93layer-2=94 refers to the network between the CEs and n= ot the nature of the CEs or the messages they sent. I modified the sentence= to clarify, let me know if it helps please:

   PEs do not intercept ARP/N=
D requests and flood all
   requests issued by the CEs=
, as a conventional layer-2 network among
   those CEs would do.

*/

<snip>

6.  Security Considerations

<snip>

   The solution also provides protection against Denial Of Servic= e
   attacks that use ARP/ND-spoofing as a first step.  The Du= plicate IP
   Detection and the use of an AS-MAC as explained in Section 3.6=
   protects the BD against ARP/ND spoofing.

<JMC>
You are assuming that the attacker and the victim are not on the same L2-Li= nk.
Is it always the case in your scenarios (i.e., only P2P links between PE an= d
CE)? If not, IMHO, it would better to: - s/protects/mitigates - Add text explaining when there is a protection and when there is no protection. <= /JMC>

/* [jorge] the attacker and the victim are in the same L2 broadcast doma= in, as discussed at the beginning of the email. Does that change your comme= nt? Let me know if it doesn=92t please. */



<JMC>
I would some text about the fact that your proposal cannot/will not work if=
there is a (current or future) security mechanism securing ARP/ND exchanges=
(e.g., SEND) because the PE is not able to secure "proxied" ND me= ssages (i.e.,
with SEND, the PE is not aware of the security credentials linked to an IP<= br> address). </JMC>

/* [jorge] Based on Russ=92 review https://mailarchive.ietf.org/arch/msg/bess/wi_uxXT1HGfxCGphJL6fDmeqPa4/= - I removed any references to SEND in the text. Other than that, I added t= his:

   Finally, it is worth notin=
g that the Proxy-ARP/ND solution in this
   document will not work if =
there is a mechanism securing ARP/ND
   exchanges among CEs, becau=
se the PE is not able to secure the
   "proxied" ND mes=
sages.

Taking your words as a model=85 Let me know if this addresses your conce= rn, please.

*/

<snip>

Thanks in advance for your replies.

/* [jorge] thank YOU for such thorough review of the ND aspects! */

Best regards,

JMC.


--_000_MWHPR08MB3520E2AE8AF60C43ED7E8544F76B9MWHPR08MB3520namp_-- From nobody Mon Mar 22 02:09:01 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6EE3A0C3D; Mon, 22 Mar 2021 02:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Carlos Bernardos via Datatracker To: Cc: draft-ietf-ippm-ioam-data.all@ietf.org, ippm@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161640414001.4412.5606895020701581108@ietfa.amsl.com> Reply-To: Carlos Bernardos Date: Mon, 22 Mar 2021 02:09:00 -0700 Archived-At: Subject: [Int-dir] Intdir telechat review of draft-ietf-ippm-ioam-data-12 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 09:09:00 -0000 Reviewer: Carlos Bernardos Review result: Ready with Nits Thanks for this document. I think it is well written and well on track. I include below some comments, mostly from an Internet view point, but not limited to that. - I wonder if some SHOULD/MUST language needs to be used in the following piece, as it talks about important operational considerations: "The operator has to consider the potential operational impact of IOAM to mechanisms such as ECMP processing (e.g. load-balancing schemes based on packet length could be impacted by the increased packet size due to IOAM), path MTU (i.e. ensure that the MTU of all links within a domain is sufficiently large to support the increased packet size due to IOAM) and ICMP message handling (i.e. in case of IPv6, IOAM support for ICMPv6 Echo Request/Reply is desired which would translate into ICMPv6 extensions to enable IOAM-Data-Fields to be copied from an Echo Request message to an Echo Reply message)." - I think a clarification of how an IOAM domain relates to an administrative domain (as mentioned in Section 4) is required. It is not clear if they are the same or an IOAM domain is a subset of an admin domain. - Are there any privacy concerns due to the fact of the information that IOAM discloses and can be analyzed by any node in the domain? There is some text in the Security Considerations, but it does not cover in much detail the new risks that it opens due to the additional information disclosure for that belong to the domain. -Nit: in section 3, some abbreviations follow the approach "XXX: ", while others "YYY ". Please harmonize it. Example of what I mean below: E2E Edge to Edge Geneve: Generic Network Virtualization Encapsulation [I-D.ietf-nvo3-geneve] Thanks, Carlos From nobody Sat Mar 27 11:50:28 2021 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 001153A0CF8; Sat, 27 Mar 2021 11:50:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tommy Pauly via Datatracker To: Cc: draft-zhu-intarea-gma.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161687102694.5055.7842750486811471173@ietfa.amsl.com> Reply-To: Tommy Pauly Date: Sat, 27 Mar 2021 11:50:26 -0700 Archived-At: Subject: [Int-dir] Intdir early review of draft-zhu-intarea-gma-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2021 18:50:27 -0000 Reviewer: Tommy Pauly Review result: Not Ready I am an assigned INT directorate reviewer for draft-zhu-intarea-gma. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . This document does propose several mechanisms that can increase the MTU efficiency of encapsulation protocols in the style of GRE, which seems useful. However, the document needs to be improved for clarity and safety before publication even in the Independent stream, in my opinion. - Some claims in the abstract and introduction need explanation. A device connected to multiple networks doesn’t directly require solutions like GRE that use additional encapsulation; many devices connect without this. Instead, this solution really is isolated to overlays across networks. This needs to be clarified for scope early on. - The GRE references are to an Independent submission of Huawei’s version of GRE. It seems misleading to not be referencing RFC 2784 or RFC 2890 directly. - Section 4 should be broken into multiple sections, one for each format; it is difficult to understand where the details for each mode overlap or contrast. - Many of the reference to IP headers seem to assume IPv4 (such as the IP checksum, not present in IPv6). Any document coming out now should be designed with IPv6 in mind first, and I would suggest breaking out the examples for both IPv6 and IPv4 separately. Similarly, any UDP encapsulation mode needs to be given as a complete example, not just an aside. - Section 5, on fragmentation, may run into some of the problems with fragments in general. Please see RFC 8900. The recommendation is to either remove the fragmentation support, or strongly discourage it and reference RFC 8900. - Similarly, concatenation as described in Section 6 may be better handled at higher layers. QUIC, for example, allows packing multiple packets in single UDP datagrams. From nobody Mon Mar 29 04:01:38 2021 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886433A386B; Mon, 29 Mar 2021 04:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PumzqLdCV5NU; Mon, 29 Mar 2021 04:01:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675E53A3867; Mon, 29 Mar 2021 04:01:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 223C8F407D8; Mon, 29 Mar 2021 04:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at rfc-editor.org Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mag9r4RjNSka; Mon, 29 Mar 2021 04:01:27 -0700 (PDT) Received: from www.rfc-editor.org (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id B73DEF407D4; Mon, 29 Mar 2021 04:01:26 -0700 (PDT) Received: from 84.93.2.51 (SquirrelMail authenticated user rfcpise) by www.rfc-editor.org with HTTP; Mon, 29 Mar 2021 04:01:27 -0700 Message-ID: In-Reply-To: <161687102694.5055.7842750486811471173@ietfa.amsl.com> References: <161687102694.5055.7842750486811471173@ietfa.amsl.com> Date: Mon, 29 Mar 2021 04:01:27 -0700 From: "RFC ISE (Adrian Farrel)" To: "Tommy Pauly" Cc: int-dir@ietf.org, draft-zhu-intarea-gma.all@ietf.org Reply-To: rfc-ise@rfc-editor.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Subject: Re: [Int-dir] Intdir early review of draft-zhu-intarea-gma-08 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 11:01:37 -0000 Thanks Tommy, that's really helpful. Best, Adrian Tommy Pauly via Datatracker wrote: > Reviewer: Tommy Pauly > Review result: Not Ready > > I am an assigned INT directorate reviewer for draft-zhu-intarea-gma. -- Adrian Farrel (ISE), rfc-ise@rfc-editor.org