Re: [RTG-DIR] Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 28 November 2022 14:09 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3094C1522BC; Mon, 28 Nov 2022 06:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=MtFWVSCZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=bYB7FiGP
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRevEafWk5m2; Mon, 28 Nov 2022 06:09:02 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 3266CC14F730; Mon, 28 Nov 2022 06:09:01 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2ARNnxkX019417; Mon, 28 Nov 2022 06:08:57 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=umzf7CN/FG3Nu18exgMR5oKZB8OJ1GM+zuQZiDhro+s=; b=MtFWVSCZgsSF/ejlKhRp5Erldml+2sYMbi/YH+Pq7fsaK7Fo9xQBri9PBC+ux4wKsljn ezoSr9rkzecehNOUn3mIcKlY6WzUPj8dcf1Jtp/5zK2gVK8mEdNe++w+tbGKtbxmmXAh r2fQA7xhMSBTjmiih1tV+Dpt0eU+F20/kM38xi9JgbZV1TN9h6mMrf9mVkXYuCAwx7zH psFPoHFNW5QkC/ZXvGnMbTfHkdAZS+DvV+OhuJJIBSsMwwN3TUYY1V1YVr5JXf9Q4C7W YrtekLNpmZ2CXvAdbi0xpgoE3IlKwMwwLri7qCZM9EtHJBJ+yz0x1tSLoP/dxokL3Q3X dw==
Received: from na01-obe.outbound.protection.outlook.com (mail-westus2azlp17010006.outbound.protection.outlook.com [40.93.10.6]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3m3hknteuu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Nov 2022 06:08:57 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gyHdnAYJSy4JOSVYgUYwaUceMTKo6vd5pC82Ej5w/UHT1kUgE+UroheRCQAYZ5l4WCuDvansnoNivE6JJoQT2Z7gdnfROljcA+sZo5vasx7jOL4GoyurZucNGfAPKIsBsM48T0lnUT1D6tsi2yLzbXjt/3bWV8Pa1OejxlNEKaQdZevDrxugXwufQI77hkc0J14VBJtrBvXEXDWWAVxnklISEZggZeGhhBYqCqcUWHS0UBYblmueC4lejQeTeE+X3iFwXPVO3BvAQmu8sVdR51Juo3oV2nBt8J4psXJWNLNarLrUeax7TbeZHZlW4I8gCXu49BZGSry8JsMbsc74bw==
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=umzf7CN/FG3Nu18exgMR5oKZB8OJ1GM+zuQZiDhro+s=; b=FH8uVwMvDl0Z7NW7JGR1JAhYN6FSakRlq3AA/3ZMWRROTfq0/optxQnuknISUH2QyAgCmumFK+loKFz5i6svb/xltB3bc+TJuZuxqPM1DEG16TZI9VsuaLKhgtpJ3HsVetM+oBBM45Cf9QflEZnxro4FMcYQ9kdeeqkM+sOkASxtCjFKvhCm9QR4Ti08Bmtrvv7bZzYJ8zj0e6Jv58Ef17jxghmBbndMD/4dngYhKQ/yNGoS/m3bVckr1CaNpeD417MbrvIeATPEYn6iivyM2GQlwfUGdrqyCiIxifwGAwkVx5tJtSkcicJU4I9EN41Xatc6sBBs2fELyoV6jcsTUA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=umzf7CN/FG3Nu18exgMR5oKZB8OJ1GM+zuQZiDhro+s=; b=bYB7FiGPMIbt1QKKByJOoKGbtGC7lImCmVyN1dplfdnkI/tX1t47D1/pgcAZXunwck9V3GHvozu0KyE5OTPxJNDo2peCj6Nsd7a7W/GEpY8cIvg/ObWa7Uz6ufuMB31XlQa9jG7mDHOUQbPxrh7lGgETHfeM0AHbNQSVq93nkvU=
Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by PH0PR05MB7703.namprd05.prod.outlook.com (2603:10b6:510:21::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5857.18; Mon, 28 Nov 2022 14:08:54 +0000
Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::fadb:2b5:e851:6183]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::fadb:2b5:e851:6183%7]) with mapi id 15.20.5857.022; Mon, 28 Nov 2022 14:08:54 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-bess-evpn-irb-mcast@ietf.org" <draft-ietf-bess-evpn-irb-mcast@ietf.org>, Routing ADs <rtg-ads@ietf.org>
CC: Routing Directorate <rtg-dir@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt
Thread-Index: AQHY+SL5D4NH+5byCUu+rKjPwM7Qa65JyBEQ
Date: Mon, 28 Nov 2022 14:08:53 +0000
Message-ID: <BL0PR05MB5652FD78FECE3CB405244A18D4139@BL0PR05MB5652.namprd05.prod.outlook.com>
References: <D6B966AD-F779-4C7F-BD31-2FD7A715147C@cisco.com>
In-Reply-To: <D6B966AD-F779-4C7F-BD31-2FD7A715147C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-11-28T14:08:52Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=e2038cb3-4a17-4056-9ea9-0fc9641ca5d1; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BL0PR05MB5652:EE_|PH0PR05MB7703:EE_
x-ms-office365-filtering-correlation-id: ca58b626-0a67-417b-b248-08dad14a153b
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gGqN/ujT7JHUEx76asmQEw58FQTAsXvYICPFt677L2f32DzfArSUHNkJwCr0GngcCBsEglhOx6FjVgsW5R9kWnndvZwm+vj7rPh5UK028wg7QI06Fa3yEDmW705LPtCXGHV63xzwJssUieGmeBwwORWcB/kFHrkoRj9ToOktLIS3wi48WharF37NM17fPYo6BFVM/9z4kD0nbC/MWa51e8Hrr1Or6jlwIjxpTgZbJVCBZWdYxu3ZVJNiWCQhIti+HbsVXYdamm/qKox628dg33ouw0S1mjhh9sc1olL+FuP1rtSsBOD2KVM49K9RmYJBNvShxNfmHjcsZGEZOkHuvIS+T7BBx8t5QHtDLvnPKomXgmLIBE54jpJCYhT2cn+MI9Npdn2CrH0kv/C3DZrTELtUn6cUx5d9O8Q/EQ1shBMLjeex91et5XTo4Cw/AR/VpkzQvIYwz/baDy4jQAPVFlfaRUWqzK73TwKt67hVXmrim1ELWjBE2A6lDfuOfzL4b0cusUnVTMi5t/J6elDTwnlxLWiHPY/ACp6++sEp+aPgaHVt6KZOyEQLGM237h0fPak2pynOEMitoVfrqDwaTSlJ+4N2Tya+dr4/RxiqbvlIiBjDvXmMK/XcU+A4Nr8/eGqmpZYafNTzinSOER9GCfYAbGHQ4QH58qPycAQE1DHg1pou8HXMdRKaq7LpZ5U1M2hblyNg8VGXw5iEH70JMt/2OG6UA6B/sL7d0Tb62HP0OBPfv5L1dOnzYVPVDGL9PclHeT/yh6zvjxOLInv79w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(376002)(396003)(346002)(136003)(366004)(39860400002)(451199015)(5660300002)(33656002)(55016003)(9686003)(54906003)(26005)(316002)(9326002)(110136005)(52536014)(41300700001)(186003)(8676002)(66946007)(66476007)(66556008)(76116006)(66446008)(4326008)(64756008)(122000001)(38070700005)(38100700002)(166002)(8936002)(2906002)(83380400001)(86362001)(6506007)(966005)(7696005)(71200400001)(478600001)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: MdE3BAUxZvmiXoN/KrrIA0DQ1J2gIQv2aGN1GVSp+o6VaHsSv51N6Jjl6nD+F5FHII4DhdOFYgaJGFs6IiH/fLw5ovmUsmfqCcdfiG21GOVDnDvVcdsusCsKkKSEoqhodIk6ckX/D0TLe24nR/lwcosMZd7V0jUAZ2zMxaMnA/wHfnlTXb9vxw6m94/GJFG6l27gAhHepn+dw1HjB3rhTfRpMd+q5ob/M7l2C5Fl2fZgp1WKW2XgnSoQMBXp36hQfhfO7kCk7YnwOog9Jc1+ncRpUQ3fh7JSOkIeGFNE0hJGJ5+vSgr/ajvN1B/CMpXEEyV+HgeTNhNrC5s1emUP83FcP0j9pCvRTrWo13O/NbSiv1ex/uxaDXzGL1IUpBKNrPzRSA4fEAn2PY2XC1FSKM5SbZvvgIVBbDpUUfq55xFIxcYoJSteu/vlzOo5AiAN5wl3QYZM8m2Lix8ybdZU35O69ZiVPZYACgRD8NG0l3cwr4eDLiLmNLJK+I77/GpX2WoyLUCyjksBa8YIpugr7KE9+JXEjB50EiMFakAJYohDl1BK4hooM8eEgIJ90IpT81bsA0a065WoofSEsvX5B2J2TKCwtCCP2Pm8VFIqraAqvfqD0jFCCdbp4UJZP0/ucoyOwcdvc/3OqVybPUgybQab3dWv9qHka/2H1NUcgmtYBuusRzGXUaWS2sv1ei94PhpDClCFkk7WdP0cybPrjYb6qVeKXAbDQdmr7wg16TRZmpBCry549+hMMbtJ2E/MplaJxenyq+ArQvnpEJBn5djWBcnVnBaimRWuGBZYAGrurZnBwCbFyr5iuiD3Bz5Gn8LCFWo9gtYT8SOtqTcRJAREhGn2oesF6bP5v6wAxCZV6vpH/pUOskH+HW3eUpm2iZ0dMyya/WXPY0cRoQ4XWtMXmAHWKcDNYPBGaIq6axr4gjreVQo5YwY+SAueaDeyMr1N/ivPYQlufXe6KKdXX4ur01h3RhV9xeiC1zleXcOcoKIOSotxyHZ56z/lzRPhs3t77ovAa1mMDHldEJ6pX4H5x8kctaG2VizCwSjp22Z6BDDyo/FmYFOseQ4xcNcleDnrr+JSGsDRuVV6JKgyBLhma2EbeOXI1tb9CyTvzGrP6guNZpwGiPe6t3BdDqpfWzvuxOQjK6Gq8M7tbGDbrHKpiA2L9Byh/QVg6KOXNlyCwOrH72676PucTM7740tdCac/DU5jvaEHoNHehAXErwoD3OKtgmtrsf7itVS2NEfPoRLgnepkmmdDVRZW1fLWxD2udOjlrHYI5IYJJj4ZekY3BdyRigrKoG024YKQulTndcOKGYGl/WZz+ej8ShhreXyvXzKk7M7MLITUyCGrmftInyQppo1t64EX974Mfy9O+0QlMP5wSeimaDSokusFSsXuzZJ2NG3UKD6BiAZ4BZq9C1VJDaMKwQcAvJDJfgzdxIGxthz7oqeyW/AEx8LiQYx0jeX2ViQzcIQWlHkAcM62S2wGLkBSK9Lvc1Zi5wi2q8H9fErO84qHa9qVErn966o2d4+olYv96wDjsUqYd+7RzudJ30x0Rfram9+zwNcY2999f/ZRMYGg7Z2i8Xvm
Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5652FD78FECE3CB405244A18D4139BL0PR05MB5652namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ca58b626-0a67-417b-b248-08dad14a153b
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2022 14:08:54.0209 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bn0+kHegX4gcPPfPVPJJ5NiIb89O2KNNXZe9RIqnP2ZZG1snV9CTBno+YitnHx+4swUs8pdODhzD9yZQPGIsFg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7703
X-Proofpoint-ORIG-GUID: ZPCJ44ED4wXFnNlKFBbbCdHUP8mLMbuW
X-Proofpoint-GUID: ZPCJ44ED4wXFnNlKFBbbCdHUP8mLMbuW
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_11,2022-11-28_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 clxscore=1031 priorityscore=1501 lowpriorityscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280107
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/TjPPKGYiiTGu6snVvIRlFCk1dnQ>
Subject: Re: [RTG-DIR] Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Nov 2022 14:09:07 -0000

Hi Acee,

Thanks a lot for your thorough review and comments. I have posted -08 revision to address most of your comments: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-mcast-08.txt.

Please see zzh> below.



Juniper Business Use Only
From: Acee Lindem (acee) <acee@cisco.com>
Sent: Tuesday, November 15, 2022 1:49 PM
To: draft-ietf-bess-evpn-irb-mcast@ietf.org; Routing ADs <rtg-ads@ietf.org>
Cc: Routing Directorate <rtg-dir@ietf.org>; bess@ietf.org
Subject: Routing Directorate Last Call Review for draft-ietf-bess-evpn-irb-mcast-07.txt

[External Email. Be cautious of content]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see ​

  http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Early Review/Last Call  comments that you receive, and strive to
resolve them through discussion or by updating the draft.

Document: draft-ietf-bess-evpn-irb-mcast-07.txt
Reviewer: Acee Lindem
Review Date: Nov 15th, 2022
IETF LC End Date: Nov 7, 2022
Intended Status: Standards Track

Summary: I have some minor concerns about this document that I think should be resolved before publication.

Comments:

The draft is readable per se but the subject matter, Optimized Inter-Subnet Multicast,
is quite complex. The draft covers the mechanisms and procedures for multicast
advertisement and forwarding between tenant-BDs. Additionally, a single line in the
abstract includes procedures to accommodate multicast traffic external to the tenant
domain results in very dense specification of various interworking with other multicast
domains. These interworking scenarios build on the OISM gateway functionality specified
early in the document. The cascaded complexity probably explains the number of directorate
members who declined the review request. Given the complexity, this is a document that
could really benefit from implementation experience.

Major Issues: None

Minor Issues:

   1. The concept of multicast packets and, in some cases, advertisements being sent
      "Up" or "Down" the IRB interface seemed confusing to me. I'd of thought the IRB
      interfaces would be described in terms of transmission or reception by the IRB
      L3 Routing instance. In any case, the usage must be described in the terminology
     section is not intuitive even though one can reverse engineer what is meant.

Zzh> An IRB interface connects a bridge domain (L2) to an IP routing instance (L3). Therefore, we use the up/down to indicate if traffic is up towards the L3 or down towards L2. I’ve added the following paragraph in section “1.1.2.  Inter-BD (Inter-Subnet) IP Traffic” where IRB interface was firs mentioned in the document:

                                           In this document, when traffic is routed out of an IRB interface,
                                           we say it is sent down the IRB interface to the BD that the IRB is
                                           for. In the other direction, traffic is sent up the IRB interface
                                           from the BD to the L3 routing instance.


   2. The Section 6 interworking scenarios could benefit from some ASCII art for
       visual reference of the various gateway and domain scenarios.

Zzh> I have added the following figure:



                     src1                       rcvr1
                     |                          |
                     R1           RP            R2

                               PIM/MVPN
                                domain
                    +---+                      +---+
               -----|GW1|----------------------|GW2|----
                    +---+                      +---+
                     | \ \                    / / |
                     |  \ \                  / /  |
                   BD1 BD2 SBD            SBD BD2 BD1

                              EVPN Domain

                           SBD            SBD
                          /                  \
                         /                    \
                    +---+                      +---+
                    |PE1|                      |PE2|
                    +---+                      +---+
                     | \                       / |
                    BD1 BD2                  BD2 BD1
                     |   |                    |  |
                    src2 rcvr2              src3 rcvr3

   3. Since this is Last Call review, it seems references to topics that may be
      covered in future revisions of the draft should be removed.

Zzh> I fixed two such topics to say “may be specified in separate documents”.

   4. In section 4.1.1, why are ACs that are not using IGMP/MLD automatically
      added to the OIF list for all flows? I'd think an administrator would have to
      run IGMP/MLD on ACs on which multicast traffic is desired.

Zzh> For a L2 switch, by default multicast is handled as broadcast – flooded everywhere – unless IGMP/MLD snooping is used. I added “snooping” in the paragraph:

   An EVPN-PE may run IGMP/MLD snooping procedures on each of its ACs, in order
   to determine the set of flows of interest to each AC.


   5. In section 4.2, how can one lookup S in the MAC-VRF(s) of a tenant domain?
      S is the IP address of the source - not a MAC address. This needs to be clarified.

Zzh> EVPN does advertise IP address along with MAC address. It’s actually fine looking up either in the MAC VRF or IP VRF, so I removed the lookup details.

   6. In section 6.1.2.2.1, it seems a bit odd to have the MEG import and export
      unicast routes dependent on whether or not there are hosts in the EVPN
      transmitting multicast flows? What route should be exported – a host route
      to the source or the corresponding subnet route from the EVPN IP RIB? Why
      isn't the AC source route covered by a subnet route for the corresponding
      tenant BD?

Zzh> Because two MEGs can be attached to the same subnet, while a source S is only attached to single MEG (if the S is local to the MEG at all), we want the L3VPN egress PE to direct its (s,g) joins towards the MEG that has S locally attached. That’s why the MEG SHOULD advertise the host route when there is traffic (and withdraw after the traffic stops), in addition to the subnet route that both MEGs do advertise:


   As a result, if S is attached to a MEG, the L3VPN nodes will direct

   their MVPN C-multicast Join routes to that MEG.  …



   If S is not attached to a MEG, the L3VPN nodes will direct their

   C-multicast Join routes to whichever MEG appears to be on the best

   route to S's subnet.  Upon receiving the C-multicast Join, that MEG

   will originate an EVPN SMET route for (S,G).  As a result, the MEG

   will receive the (S,G) traffic at layer 2 via the OISM procedures.

   The (S,G) traffic will be sent up the appropriate IRB interface, and

   the layer 3 MVPN procedures will ensure that the traffic is delivered

   to the L3VPN nodes that have requested it.


   7. Section 6.2, I reworded some text that didn't parse at all. I rewrote as:

      Furthermore, even if a particular AC is part of that BD, the PE SHOULD NOT
      transmit an IGMP/MLD Join on that AC unless there is an external PIM route
      attached via that AC

zzh> Thanks! That’s what the original text tried to say. I also changed “route” to “router”.

Nits:

Zzh> I fixed the nits below. In particular, for nit #1 below I changed “about” to “for”.

   1. Saying a route is "about" a BD is awkward. Please use "pertains to" or
      "associated with".

   2. Avoid the usage of "we" and use the infinitive instead. For example,
      "It is RECOMMENDED", rather than "We RECOMMEND". I didn’t fix all these
      In the diff.

   3. Avoid putting extra parentheses around single references - I've fixed this
      in the diffs.

   4. The draft uses various terms for assuring reception of multicast
      traffic - "draw", "pull", and "must see".  I'd use "receive" consistently
      as in the diff.

   5. Use "sent on ..." rather than "sent out ...".

See attached RFC diff for more suggested editorial changes.

Zzh> Thanks! They show the extraordinary effort you’ve put in and I really appreciate it! I fixed most of them, though kept a few unchanged.
Zzh> For example, I did not change “pull” or “draw” to “receive”, because “pull/draw” refers to the fact that a PE advertises SMET routes to draw traffic. I see you later changed “pull” to “attract”. “pull” or “draw” seems to be more explicit?
Zzh> Thanks!
Zzh> Jeffrey

Thanks,
Acee