Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
"Mankamana Mishra (mankamis)" <mankamis@cisco.com> Wed, 17 November 2021 20:11 UTC
Return-Path: <mankamis@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501C23A0415; Wed, 17 Nov 2021 12:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 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_H2=-0.001, SPF_NONE=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=j1zw3M/M; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oF3uS8Dt
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 DbPwXGmlsDrn; Wed, 17 Nov 2021 12:11:49 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB733A0410; Wed, 17 Nov 2021 12:11:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35375; q=dns/txt; s=iport; t=1637179909; x=1638389509; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2Jrd+P7NYJP3vd5Z5spSZOnPw71gywoKJhFtPQs91ug=; b=j1zw3M/MKQjQKgMa+FqNsdFHp9JVGNjWusvzXsRHldvcnsg27P4L5jGf bRITyCoWwTHHG+hFbPIu37dCg0DxjV7MhQCAe2STt3+F6PiG4XcC1c5br SMfL/I+3fUnGpCbikTXl24lezGfWuCTBT2kbLbRAeuJxQK9IBOwcns89c I=;
X-IPAS-Result: A0D3AABDYZVhl4kNJK1agQmBWYEhMSkoflo3MYgOA4U5hQ6DAgOLBYUlimOBLhSBEQNUCwEBAQ0BATUMBAEBhQQCgmYCJTQJDgECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQEdBwYMBQ4QJ4U7CCUNhkIBAQEBAxIIJgEBMAcBDwIBCA4DAwECIQENIREdCAIEAQ0FCBqCTwGBflcDLwEOoRsBgToCih94gTOBAYIIAQEGBASBSkGCfw0LgjUDBoE6gw6EHIMAhAYnHIFJRIEVQ4JnPoIhQgIDgSgBCwcBCBseDYMigi6PSyUIPgYBPSYBAyIZGBQDOCwETAINDwIBEQUBAQEBDQELEwEKOpE1JwQHCoJuiVw7nTSBAzRoCoM5ilKORgSGBBWDbIt0A5dKlhUfgiGKNYNIkEgYhGkCBAIEBQIOAQEGgWE5a3BwFTuCaVEZD4U3iHUNCRVvAQEBgkmFFIVKdDgCBgsBAQMJj2WCRgEB
IronPort-PHdr: A9a23:LJgA1xyFb0Y22RfXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv
IronPort-Data: A9a23:N2hQ+ayv1dDNfZcGhgx6t+fOxirEfRIJ4+MujC+fZmUNrF6WrkUEy 2dOXD/Xa/2DYzPye94jao3n8ExU656Hmt5kHARs+1hgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4wUNdokb0/n9BCJC5xZVH/fzOFuWU5NLsYHgrHFY9EXh50nqPpsZg6mJWqYnha++yk YuaT/33YDdJDBYtbwr4Q4rawP9elKyaVAEw5zTSVtgX1LPqrET5ObpETU2Hw9QUdaEPdgKyb 76rILhUZQo19T91Yj+uuu6TnkHn3tc+MCDW4ke6VZROjTBgiiFv2/w3LsBNVm14igiClshvm Ixk4MnYpQcBZsUgmcwUVx1eVip5J6ADpPnMIGO0toqYyEiun3nEmqo1Shpoe9RDvL8sXgmi9 tRAQNwJRhWKgeG/xbOgYuJtnc8kasLsOevzv1k/nGyEUKx9Gcirr6Pi3PIB0xk8neB3HPP8X /gwazssNBLwSkgaUrsQIMtuwLj37pXlSBVDrFOJpq0o+C7SwRB/+LfoOdvRPNeNQK19lEuDv UrH8nj3RBYAO7S3wzee6TenhubOhzjTWY8OGvu/7PECqFGJz2IPTRwbSVX+q/SikQuzRcpZb k0b/zJrqKw+sVSxScnsdxy1vHDCuQQTM/JRHvY1wACA1qSS5ByWbkANVDNdYdov8s47WTIC2 VqAntevDjtq2IB5UlqU8rOS6Di1IyVQcSkJZDQPSk0O5NyLTJwPYgznbPpuTafvgsfPSA7a7 DG3pyEmmeVKpJtev0mkxmzvjzWpr5nPawc64ATLQ26ohj+Vgqb4POREDnCGsZ59wJalokqp5 yNdwpfAhAwaJdTcynLSEbxl8KSBvq7dWAAwl2KDCHXIG96F0nqncIY4DNpWexoxa51sldMEn CbuVe557ZtXOj6harV6Jt73AMUxxq+mHtPgPhw1UjasSsUqHONk1HgzDaJ144wLuBN0+U3YE czCGftA9V5AVcxaIMOeHo/xK4MDyCEk3n/0Tpvm1Rmh2rf2TCfLEuhdYATSNrxisPzsTODpH zB3apXiJ/J3Db2WX8Ur2dN7wa0idCJiXsmm96S7iMbafFs/cI3eNxMh6epxJ9M690ikvuzJ5 Xq6ElRJ00bygGavFOl5Qi4LVV8bZr4m9ShTFXV1ZT6AgiF/Ca7yvfx3X8ZmItEPqrc5pdYqF KZtRil1KqkWItgx029FPceVQU0LXEnDuD9iyAL5OmViJMA5GFSSkjImFyO2nBQz4uOMnZNWi 9WdOsnzGPLvmywK4B7qVc+S
IronPort-HdrOrdr: A9a23:pQ83iaEQIiaJcGktpLqFRJHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhc4tKOTOHhILGFvAY0WKP+UyEJ8S6zJ8g6U 4CSdk+NDSTNykBsS+S2mDReLxMrKjlgcKVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYqILSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzR/Bky/JlaAkEuDzYILiJaIfy+wzdZ9vfrmrCpe O85ivI+f4Dsk85MFvF+ScFkDOQoQrGo0WSuWNwx0GT+vAQgFkBepd8bUUzSGqC16NohqAO7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbWIyUs4bkWUkxjIeLH7AJlOM1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZ TaSVtd8XU/fkr/YPf+lKGjMiq9CVlVcQ6dv/221qIJzIEUHoCbQxFrYGpe5/ednw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.87,241,1631577600"; d="scan'208,217";a="795552300"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Nov 2021 20:11:48 +0000
Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 1AHKBlf9027857 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 17 Nov 2021 20:11:47 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 17 Nov 2021 14:11:47 -0600
Received: from xfe-rtp-002.cisco.com (64.101.210.232) 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.15; Wed, 17 Nov 2021 14:11:46 -0600
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 17 Nov 2021 15:11:46 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=icJfrZJkWCTZiyD08XJB78PtqIjxHleZRq4NrC7tMKBU9SphQbqiG+F776BCSEp+BMcM1IH7VFnOZ58uSXCijjrAj4JDXTArhPYM2iFUdLniOAktGOO+tjyGfxMrJaFwNnNrj0Cks4nBEYVC1sWSmX7TonCOL8nOQgTcx3eZnAYXodW5OJQbUuqmChALvSOSDa1XwdRUIATCY3pi44WLRlALLE11SFsxPnxXgw+WYMAArJgAdWWwnpnNFkUxmQnfHwMS/FIAzv0+Rb9pWqkUImMIViUymcZNXEb5SxyoyKYaOHqOlPXjUZjd/DzR2l5MSrLoBApOmzdl4jyiEe5Eww==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=G9RVROuaguuGobPAEgRECdsXlcEzGgT3DoinYzF0zWQ=; b=T4ASbDFmAuYx1jQIHvuWjidEH6gFzJ1yNB2bbIDsjlTfp/XWuRwpqNSULlsHbuYr0KiN22KiVbeUE7AMOdMLlHgQ9JIDjYcYi72gHmhIMD9E6dttsoleX7Ym/0if5odOqCWg1FkU0pG+nYCQCOqlBh3+7wPvNvJS+y3Zq7wtZfFobe/ry8d8g/qeWnL3hNMQ7nPp5LMDkOyq+fEX0Ypc+3UFUoZvQj28C8Jxf/vDCRBtdK0vcMRA3NRTjUiFKycypYSm5O971WiBAODZPIuDdmt0HEASJVjLtfZ54ZO6k5c4Fq4Ia7iLdg40Gc+x7W83PGPQdxo8kIsHCUjIk89ukw==
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=G9RVROuaguuGobPAEgRECdsXlcEzGgT3DoinYzF0zWQ=; b=oF3uS8DtZfW+o2WuSrbFHUIH+bTWmNmSEGUsXRBMw7+nFp+TkvheySJlBiylzqKcVeZ0NzwEYjIyyY0qt8V58ZwOLB8l2PFLhwzkBJhxy6pqnMAaUd8rxzduxwOa3p02tQ+1cXeFe6VcojnLhG/Ba8wX30K2EY5roXbs4CN2RHM=
Received: from BYAPR11MB2725.namprd11.prod.outlook.com (2603:10b6:a02:c5::25) by BYAPR11MB3351.namprd11.prod.outlook.com (2603:10b6:a03:7c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.27; Wed, 17 Nov 2021 20:11:38 +0000
Received: from BYAPR11MB2725.namprd11.prod.outlook.com ([fe80::fc33:27d4:8b6e:888c]) by BYAPR11MB2725.namprd11.prod.outlook.com ([fe80::fc33:27d4:8b6e:888c%5]) with mapi id 15.20.4713.021; Wed, 17 Nov 2021 20:11:38 +0000
From: "Mankamana Mishra (mankamis)" <mankamis@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org" <draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "slitkows.ietf@gmail.com" <slitkows.ietf@gmail.com>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
Thread-Index: AQHXy1djK7Tq53q98Em/RgkiMA4apKwIRoet
Date: Wed, 17 Nov 2021 20:11:38 +0000
Message-ID: <BYAPR11MB272513BFE26ECBA8518153C3DF9A9@BYAPR11MB2725.namprd11.prod.outlook.com>
References: <163535541146.31356.5788998139231162845@ietfa.amsl.com>
In-Reply-To: <163535541146.31356.5788998139231162845@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 297eace6-7eff-4ef0-b2e2-08d9aa06767f
x-ms-traffictypediagnostic: BYAPR11MB3351:
x-microsoft-antispam-prvs: <BYAPR11MB335151C56375B671DE41A2E5DF9A9@BYAPR11MB3351.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 6Obd8Jv6INHH/I830Ohn2bUzMLWurmuGvu7ds8P0c+n8qoqYRzywm8Mm3lv5Vemb+pu/Ae/8NhW5sei2MgCuzJZ7fd+WgRaTF0IaUDI5NtkzxPMpsXliYXl+opEgpQcxYKov2BXL7SnMOI3oXgICaZam4HMex/K94ePlXZLx5HKMNLv9WK5ImbYz8H+dfqKBcjccnPxVdtQnjQodq9K6cyLCONXt1bNPePxfYc0Fub/EMd0uWT4aLJkHxrYCbFxpz3IA/LZrnOzsVnlFYOJKK/YGuUaa7jQPgdg9MLl/Z9jDCtUvaoLF/g/ZljgTr6g1WaKnsOkNm7cWnFS1VNjN+RQRlHveEX4THxmvvdg2le2YM37olDbG0z/XWmyVajot6Sa1+NZ1zs2aE029Exf5T8NWQxfcGmD3qnPb/tvU3kWAmA05iXGMUNK7kKBPxS5TApe5fg4jnSFrKvLpj3y+C9gVE2pq6iBv6fZaizi4nn2WjBnxQYTHh9AsuhGAEKC7wZnIX8/sYqpjgKFThKBkhrwJp28CcZ3WW4KpPTJ4Rbwfcv5ZOw1OsZ1Txf59ekA7ItqHNM4t7yYNNjukFDGvLBwD4roVViuuni5HRHlfEeZac4/1/eJKcJW7ylTdkctyFvUpq3zBf8u0ArXh+Uzg5zCrgPgbwEwrrMdm5U96+ohCl+ZzyFmRcthStq7DhWtwYz3qZeL65H7mQhojdhSbhPYMuYKzE0Oss1xTst8twcCFT2IHlxdepDqmHf1E7ipZUBCLzI7fXNJQDta/7JkVfjVkM7LxRDksbYY1+TqIMrlPkDpifdZQwEGcTGESTDrnmB6VKBwC8fQ3rRSATZOdDw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2725.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(122000001)(8936002)(30864003)(26005)(66446008)(186003)(8676002)(55016002)(66556008)(966005)(53546011)(52536014)(66946007)(6506007)(71200400001)(66476007)(33656002)(64756008)(2906002)(76116006)(66574015)(4326008)(38100700002)(86362001)(508600001)(9686003)(5660300002)(9326002)(38070700005)(110136005)(7696005)(166002)(54906003)(316002)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: x7a6sekv8rwoAp8YbOCcP6wfIWrjhd9RwsnuOw8C9/8kOcOGOXLA2yo7hFszmjhXgJs9L/wffp0UMn1iF22mmePde8ZmscW1yp9eeyyFyUrsuQUwPTkYjbMc1CVQZ9Ma2r1OaaFru9UAxzfUCc/g4lLR6jXWthZ2BhgFqxlqo3PTgXHUah8iK5cP3UmwHbVwTHOz8cXkJQYxoiNXr0TFEkXxOITzzTn6AzfhO9sFGzFkD6mQIboTyE+R8x1vu4s5/SpffoA04DIpnPH0jq+LxuNJwBx4e3aPPTRzbpw3rUb7fQu6O5pXb+MTwdKiENjiBWGfoUKMP2IBYH9R0/3yKVCr9aETbvtEmakVmiDMP9vquYdjC5XyiqhkUbcX4ALWOccIqaDT64wEdrqEs/+6oASOLovdmwN6usqugupCAdeX1fPBbXM6BfW4CkFManlaOWja075PfqVkyjXiHYdSMlyiW3FGr5mxJXNPOYUGbHm+kR1iBBrXOeuDAxLDmy8rddXOnArXOhWVrnyHWBbQL6waVbWY1XmjqW/VMOU+mJNWprGLeX2gvkhDL3MkGDii6C2updLy4MtxRFxErY0c4AgMB5vMUyKFXn4yPWdUv8gaVDRq0+F3LzKxLKYdF2a5BoNjln7kyde1u+K6boZloGXiLWUlH9wVnPd/1ANg/mQ5hm4KDpyMzE64As5CzTakTh7WM+sxoZZdq2aRJgvKT6v3rLyUWHXWiIBUiJG67OwThjvBvZhegAxBWVeQIr0Ou906quNSubl7mhadZZE9qYfWs8ubrtNHPY8nIT+hNw29zWrImgDdZurgoL5AX+ixopF3JSDvOLqqQvYpSrcYaTZ9XCkBqenHY8GUjONeyDBWjb2LfgLsCCbz5w83ApuoJKmuAPJBJcKsRB1IQ59DJfKvVoIWupuedG38u+FchJd3OhQ8LubLwDVAVATnKnjbl5UCM0I/bgdbIr1OKMNGh6Np8fO4IJSyMvWOrcfVjzAOPdLaSYG7+M19uQoaxw6YQQDLqpIM1X6XZcmPUbTmiBQU/yCN0hWJaBjs2WO8HXOEH2Ky2esfilhD+bToxfiJRK5apx86crNs2Kq+93/PpquikEaskQC7qHRteGhASMbQs2xKWBUjUBWkHbuy+LFJ1LJW4yo5oGaVH5sC5kK8LyoOsQTzfJnUwsIjU+DS83UErDRGO+GRqWTNGHSKWWolnCzEMLGO4824QOmKxbjN2bTu8DGBtRH/dBhhITfELHHWxrax7xQe5rLg4D9KVnMEehw0bLcKNLF+z2u2flnZkmg+RFyHw2Lz/S45yRH381LhDUDHippjJm5voh+L+ehRWDvOBIxcTLx59YWI6r231nKYIso3arR4JxBFwHxprZdt+KeRU5p5blddFVuOFBO+ZoHoyF0sTlVxMxcaVMXI3WvXQcajcKKrQs3akhjMrwiTkj0tLV1bf2FTsdBXNVbniUPhkpVPZDuAaAF6kopwQri+0DpN5qzNjstpasThZCTiEBFglTXQ55cj2X3BsNE4Faz16CCXiFBaxr4gmciAcddf9cUpjxuJg0GOcVYFE2opTE+F7sCExp1d7pFmnkg3Z4UNgE4oxMV8P2GUcFytbGuMraxhK2/3eMNrmFsHQ40Vryottz8vO8ekbOT8lLpH
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB272513BFE26ECBA8518153C3DF9A9BYAPR11MB2725namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2725.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 297eace6-7eff-4ef0-b2e2-08d9aa06767f
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2021 20:11:38.2572 (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: qTjvgQ2bIApcv7IRVXK6psjcpDhN0kXQkjhpPECAvW8pozbkVbAjCDHOmTNODEn/THi+kuxYZUMs8fFHsLkoLA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3351
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/fm8oazvKKOaSa4z1OXuMI1Q3dmY>
Subject: Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 20:11:54 -0000
Hi Alvaro, Thanks for detail comment. Please find inline response. From: Alvaro Retana via Datatracker <noreply@ietf.org> Date: Wednesday, October 27, 2021 at 10:23 AM To: The IESG <iesg@ietf.org> Cc: draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org <draft-ietf-bess-evpn-igmp-mld-proxy@ietf.org>, bess-chairs@ietf.org <bess-chairs@ietf.org>, bess@ietf.org <bess@ietf.org>, slitkows.ietf@gmail.com <slitkows.ietf@gmail.com> Subject: Alvaro Retana's Discuss on draft-ietf-bess-evpn-igmp-mld-proxy-14: (with DISCUSS and COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-bess-evpn-igmp-mld-proxy-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-igmp-mld-proxy/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- First of all, I am surprised that a document related to IGMP/MLD was not sent to the pim WG for review. I can't find any mention of this draft in the pim WG's archive. Mankamana: As in contributor to this document, all the procedures are very much limited to BGP overlay signaling. Not sure which aspect would be reviewed by PIM WG. This draft does not change any behavior of PIM or IGMP . §11 says this: This document does not provide any detail about IGMPv1 processing. Multicast working group are in process of deprecating uses of IGMPv1. Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and above for IPv6. IGMP V1 routes MUST be considered as invalid and the PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606]. Initial version of document did mention use of IGMPv1 and flag had provision to support IGMPv1. There may be an implementation which is deployed as initial version of document, to interop flag has not been changed. Note that the "Multicast working group" mentioned above is in fact the pim WG. There's no current WG to deprecate IGMPv1, but draft-ietf-pim-3376bis was recently adopted with the intent to progress IGMPv3 to Internet Standard. This text is from draft-ietf-pim-3376bis (it is the same text as in rfc3376): IGMPv3 is backward compatible with previous versions of the IGMP protocol. In order to remain backward compatible with older IGMP systems, IGMPv3 multicast routers MUST also implement versions 1 and 2 of the protocol (see section Section 7). (Section 7/draft-ietf-pim-3376bis talks about interoperability with older versions.) All this is to say that requiring that IGMPv1 not be used contradicts the IGMPv3 specification, which requires the support. The interoperation between the different versions is already considered in rfc3376, so the extra complexity added to this document (tracking the versions in the BGP updates) is not needed from the router side. I am balloting DISCUSS because this document is not in line with other consensus documents (specifically the IGMP specification). To clear, I will want the document reviewed by the pim WG. Mankamana : Do you expect it to be reviewed by PIM WG or we should remove section talking about use of V1 ? Based on current work in PIM WG, our understanding is that “v1 will become deprecated, v2 will still be proposed standard, and v3 will become internet standard.” ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) The terminology section should include IGMP/MLD-related terminology or at least a pointer to the relevant RFCs. Also, the messages are called Membership Reports, and not "Join" or "IGMP Reports". Similar comment related to "IGMP Queries" and "Membership Requests" (should be Membership Query). [I will not make other comments below about this same point.] Mankamana : will change IGMP join to Membership Request (2) [Line numbers from idnits.] 260 1. When the first hop PE receives several IGMP Membership Reports 261 (Joins), belonging to the same IGMP version, from different 262 attached hosts for the same (*,G) or (S,G), it SHOULD send a 263 single BGP message corresponding to the very first IGMP 264 Membership Request (BGP update as soon as possible) for that 265 (*,G) or (S,G). This is because BGP is a stateful protocol and 266 no further transmission of the same report is needed. If the The behavior in this rule is not required. Under what circumstances is it ok for the PE to not wait for several Membership Reports from multiple hosts before sending a BGP message? Waiting for multiple messages can clearly result in a delay for an interested host in receiving the multicast service. Note that rfc3376 says that "Multicast routers need to know only that *at least one* system on an attached network is interested..." Mankamana : it SHOULD send a 263 single BGP message corresponding to the very first IGMP 264 Membership Request (BGP update as soon as possible) for that does this not mean, BGP update should be sent ASAP. It does not state to wait for many ? (3) 269 (v2 or v3) set. In case of IGMPv3, the exclude flag MUST also be 270 set to indicate that no source IP address must be excluded 271 (include all sources "*"). If the IGMP Join is for (S,G), then 272 besides setting multicast group address along with the version 273 flag v3, the source IP address and the IE flag MUST be set. It "the exclude flag MUST also be set" I think you meant to reference the Exclude Group and the IE field in the flags. Note that the second part ("IE flag MUST be set") also refers to the same field, but for a different condition. Please be consistent and call things (the IE field, in this case) by a single name. The definitions in §9.* are not consistent either. Mankamana : will IE (Include or Exclude) in terminology be enough ? First part of statement talks about (*,G) join where only Exclude flag would be set. Where for (S,G) Include or Exclude either can be set. (4) 277 2. When the first hop PE receives an IGMPv3 Join for (S,G) on a 278 given BD, it SHOULD advertise the corresponding EVPN Selective 279 Multicast Ethernet Tag (SMET) route regardless of whether the 280 source (S) is attached to itself or not in order to facilitate 281 the source move in the future. When is it ok for the SMET route not to be advertised? IOW, why is it a recommendation and not a requirement? Mankamana : changing SHOULD to MUST ? (5) 283 3. When the first hop PE receives an IGMP version-X Join first for 284 (*,G) and then later it receives an IGMP version-Y Join for the 285 same (*,G), then it MUST re-advertise the same EVPN SMET route 286 with flag for version-Y set in addition to any previously-set 287 version flag(s). In other words, the first hop PE MUST NOT 288 withdraw the EVPN route before sending the new route because the 289 flag field is not part of BGP route key processing. The requirement (MUST) to re-advertise the same SMET route assumes that there was an advertisement done already, but rule 2 doesn’t require that. Mankamana : Changing previous one to MUST should fix this comment too. (6) 291 4. When the first hop PE receives an IGMP version-X Join first for 292 (*,G) and then later it receives an IGMPv3 Join for the same 293 multicast group address but for a specific source address S, then 294 the PE MUST advertise a new EVPN SMET route with v3 flag set (and 295 v2 reset). The IE flag also need to be set accordingly. Since 296 source IP address is used as part of BGP route key processing it 297 is considered as a new BGP route advertisement. When different 298 version of IGMP join are received, final state MUST be as per 299 section 5.1 of [RFC3376]. At the end of route processing local 300 and remote group record state MUST be as per section 5.1 of 301 [RFC3376]. Receiving an IGMPv3 Membership Report for the first time, as described here, is equivalent to the case in rule 2, However, the normative language is different: sending an SMET route is required here, but only recommended in rule 2. I fail to see why the conditions are different. Also, this rule mentions that the “ IE flag also need[s] to be set accordingly” while rule 1 requires a specific setting. This section is talking about the actions of a PE when it receives IGMP messages — this is what rfc3376 refers to as a multicast router. §5.1/rfc3376 refers to the host function (group members). Both statements (which seems redundant to me) requiring compliance with rfc3376 are misplaced. Mankamana : Sending you diff soon for your review. BTW, these are the only references (in the specification part of the text) to rfc3376. Given that this document is about IGMP/MLD Proxy, there should be other references that make clear the normative relationship. The same comment applies to the other versions of IGMP mentioned as well as MLD. Mankamana : Will add reference to IGMP and MLD RFC (7) §4.1.1: The set of rules in this section (IGMP/MLD Membership Report Advertisement in BGP) is preceded with: 256 When a PE wants to advertise an IGMP Membership Report (Join) using 257 the BGP EVPN route, it follows the following rules (BGP encoding 258 stated in Section 9): But rules 5-7 are about the actions related to the SMET route being received, not advertising it. Perhaps divide the list of rules so that it is clear when they apply. Mankamana : making it two section ? one who advertising the route and other for who receiving it ? (8) §4.1.1: Rule 7 talks about listening to PIM Hellos. Please add a Normative reference to rfc7761. Mankamana : Added (9) §4.1.2: Rules 2-3 are about the actions after the SMET route is received, which doesn't match with the preface to the rules. Perhaps divide the list of rules... Mankamana : making some changes and sending new text soon. (10) 1269 IGMP MAY be configured with immediate leave option. This allows the 1270 device to remove the group entry from the multicast routing table 1271 immediately upon receiving a IGMP leave message for (x,G). In case 1272 of all active multi-homing while synchronizing the IGMP Leave state 1273 to redundancy peers, Maximum Response Time MAY be filled in as Zero. 1274 Implementations SHOULD have identical configuration across multi- 1275 homed peers. In case IGMP Leave Synch route is received with Maximum 1276 Response Time Zero, irrespective of local IGMP configuration it MAY 1277 be processed as an immediate leave. By "immediate leave" I assume you're referring to "low leave latency" (rfc2236/rfc3376), is that right? There is no "immediate leave" mentioned in whose documents. "IGMP MAY be configured with immediate leave option." This "MAY" seems to just be stating a fact. s/MAY/may When is it ok for implementations to not have the same configuration? IOW, why is that a recommendation and not a requirement? Mankamana: Yes immediate leave is “low leave latency”. Since its optional functionality, its not hard requirement. An implementation may or may not support this functionality.
- [bess] Alvaro Retana's Discuss on draft-ietf-bess… Alvaro Retana via Datatracker
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Mankamana Mishra (mankamis)
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Mankamana Mishra (mankamis)
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Mankamana Mishra (mankamis)
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Mankamana Mishra (mankamis)
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Alvaro Retana
- Re: [bess] Alvaro Retana's Discuss on draft-ietf-… Mankamana Mishra (mankamis)