From nobody Wed Aug 2 04:09:45 2023 Return-Path: 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 A67FAC14CE4F; Wed, 2 Aug 2023 04:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=gmail.com 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 6sDk_E_jNghG; Wed, 2 Aug 2023 04:09:40 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E970C15106D; Wed, 2 Aug 2023 04:09:35 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id ada2fe7eead31-4476a2a5bc9so2171059137.2; Wed, 02 Aug 2023 04:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690974574; x=1691579374; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=kQf0+fAlOjh3rlBjFkjBQRNa4DBb/nio4tQkkcPxqvs=; b=EpCTjDgg31/WyUGnY/7Eo3jIN0JjXt0AaOxU2jLf/bJThXWOVVBaNnybTqn2EYjmiM dXtK2MX4R/vSX9FTqwTBmqw/F+cUL4XJdMP7yjs/bUPfejxy2lkjTOGdQA/LPbQHi7Dt h1XG9DKtZNy+/CbwuuMTfmsmNQ0/Wa0gpE8tydtRiVCUqPPGNcBM6mHkSGTpv9h+S/mX 1cEDNUlBdsayf5Gc+7VOZdO5qxhrMhlVGxgGt9hpTJvhMNTCGCIudfvDf5UuQx3lmmYo CtwTZG8boWYh7fw6aFXrkuu59IueH7GKM752uQ56MlKb5B0Mwa0MboxSguXqWiFR/Bfa i4AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690974574; x=1691579374; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kQf0+fAlOjh3rlBjFkjBQRNa4DBb/nio4tQkkcPxqvs=; b=PZNQgH68mwloqdpuIPKjJ5zfwXLBUZlGX4KrdpU9utV7rqriyCdgppOUAvQjKcXIvM exPvkTI5PwFdP7cQgiWn79JUBTgTtNVAs5j5AGvisgvzkOA0WUhi5LK7RkKuDo+N/mft NVAotks6Cm3Kg8lrTx8ZKRi31j3GpYWp4TBtQsyzCv6ltIPFRNIZNWyc8I4b6NPRnOsM mF5VcVG0CsznIZAeFzSQSf7p32Ji4UKdp/XyOGy4BYN8vWG9zhEPdg8kVqCRRbwYud86 IH2qrsFl+Zr5JDKJRsYsHN2JOoqwRIBucXalnLQdq/6AX+J0Rudw3NQbuKnKZyj5upuN ubYQ== X-Gm-Message-State: ABy/qLaGZ0ptYpbZb22HulISgrZ2SJFFql5+n0qdDpjyrj0jNiDNBM83 uUR+HNnGeKdp6/cAxVCb66tbAFW86Hg= X-Google-Smtp-Source: APBJJlF4OYC64EhZIZ+9uv/2WNVI2xuLaqcF1qRa2/pZgNTXxxwdDajhAMEpW23wnQvQTg9mqkbGiQ== X-Received: by 2002:a05:6102:3a57:b0:443:7935:6eb5 with SMTP id c23-20020a0561023a5700b0044379356eb5mr4430979vsu.15.1690974573537; Wed, 02 Aug 2023 04:09:33 -0700 (PDT) Received: from smtpclient.apple ([2605:a601:91bc:d800:49d3:4f2e:cb65:fd48]) by smtp.gmail.com with ESMTPSA id p4-20020a0c8c84000000b0063cfb3fbb7esm5408552qvb.16.2023.08.02.04.09.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2023 04:09:33 -0700 (PDT) From: Acee Lindem Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_79F6C49D-1B93-4858-8972-44816CC04C04" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Date: Wed, 2 Aug 2023 07:09:22 -0400 In-Reply-To: Cc: Routing ADs , "draft-ietf-bess-evpn-per-mcast-flow-df-election@ietf.org" , "bess@ietf.org" , Routing Directorate To: "Mankamana Mishra (mankamis)" References: <9C5FDE48-9B4B-4ADF-A67D-43E60EAB734E@gmail.com> X-Mailer: Apple Mail (2.3731.600.7) Archived-At: Subject: Re: [bess] Routing Directorate early review for draft-ietf-bess-evpn-per-mcast-flow-df-election-09 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2023 11:09:42 -0000 --Apple-Mail=_79F6C49D-1B93-4858-8972-44816CC04C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mankamana,=20 > On Aug 1, 2023, at 17:44, Mankamana Mishra (mankamis) = wrote: >=20 > Hi Acee,=20 > Thanks for reviewing and comment. While I make changes to existing = draft based on your comments, I had question on some of the comments > =20 > 1. Precisely explain the hashing algorithm in section 4.1 and 4.2. = As > written, they subject to multiple interpretations. Provide a = reference > to CRC_32() and expand acronyms on first use (e.g., MSB). >=20 > 2. In addition to explaining the hashing algorithm, the document = should > provide a discussion on why this hashing algorithm provides a = good > distribiution of flows. > =20 > https://datatracker.ietf.org/doc/html/rfc8584#section-3 defines most = of the base HRW draft and its benefit . Do you expect it to be repeated = in this draft too ? This draft does not change the base HRW algorithm = but adds flow information as also an input parameter to calculate the = weight ? You shouldn=E2=80=99t include a formula in a document where the elements = are not explained, acronyms are not expanded, and references are not = provided.=20 You could reference the RFC 8584 discussion of why the algorithm = provides a good distribution of traffic this reference should be = accompanied with text explaining how these benefits extend to individual = multicast flows. Thanks, Acee > =20 > Please let me know if you want only reference to be given or content = to be copied here ? > =20 > Mankamana=20 > =20 > From: Acee Lindem > Date: Friday, July 21, 2023 at 2:43 PM > To: Routing ADs , = draft-ietf-bess-evpn-per-mcast-flow-df-election@ietf.org = > Cc: bess@ietf.org , Routing Directorate = > Subject: Routing Directorate early review for = draft-ietf-bess-evpn-per-mcast-flow-df-election-09 >=20 > Hello, >=20 > 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: >=20 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >=20 > 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. >=20 > Document: draft-ietf-bess-evpn-per-mcast-flow-df-election-09 > Reviewer: Acee Lindem > Review Date: 07/20/2023 > IETF LC End Date: N/A > Intended Status: Standards Track >=20 > Summary: > This document describes a per-multicast-flow DF election mechanism > which support per multicast flow load-balancing of the EVPN ES > forwarding amongst PEs in a redundancy group. While the document = describes > a fairly straightforward function, it really needs some editing and = never > should have been adopted as a WG document in this condition. = Consequently, > I have entered a =E2=80=9CNot Ready=E2=80=9D disposition for the = review.=20 >=20 >=20 > Major Issues: > 1. Precisely explain the hashing algorithm in section 4.1 and 4.2. = As > written, they subject to multiple interpretations. Provide a = reference > to CRC_32() and expand acronyms on first use (e.g., MSB). >=20 > 2. In addition to explaining the hashing algorithm, the document = should > provide a discussion on why this hashing algorithm provides a = good > distribiution of flows. >=20 > 3. While this is a minor comment, it also pertains to the hashing > algorithm. To better distribute the flows, why not exclude the = current > BUM DF from the list of PEs from which to choose a per-flow DF?? >=20 >=20 > Minor Issues: >=20 > 1. Acronyms from RFC 7432 and RFC 8584 used without first expansion. > For example, none of the acronyms in the figures are defined. I'd > suggest adding a glossary with terms from other documents. > 2. The acronym "Es" is used for Ethernet Segment when ES is used in > other EVPN documents. > 3. Missing articles make the text unwieldy to read. > 4. Multiple problems with agreement of subject and verb. > 5. Define what is referred to by DFn. Presumably, this is the = selected > PE in the redundancy group. > 5. Number 5 in section 5 doesn't make sense as written. I was trying = to > fix it but it needs attention from the author. > 6. The abstract cannot include RFC references from the draft. = However, > the RFCs may be referenced without the braces. > 7. The security considerations for RFC 8584 are also applicable. = Additionally, > you that you are going to be asked for a discussion of how the = existing > security mechanisms apply to per-flow DF selection, so you might = as well > provide it now. >=20 >=20 > Nits: See diff below. >=20 > Thanks, > Acee >=20 >=20 > *** draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt.orig Wed = Jul 19 11:43:37 2023 > --- draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt Wed = Jul 19 12:21:57 2023 > *************** > *** 18,33 **** >=20 > Abstract >=20 > ! [RFC7432] describes mechanism to elect designated forwarder (DF) = at > the granularity of (ESI, EVI) which is per VLAN (or per group of > VLANs in case of VLAN bundle or VLAN-aware bundle service). = However, > the current level of granularity of per-VLAN is not adequate for = some > ! applications.[RFC8584] improves base line DF election by = introducing > ! HRW DF election. [RFC9251] introduces applicability of EVPN to > ! Multicast flows, routes to sync them and a default DF election. = This > ! document is an extension to HRW base draft [RFC8584] and further > enhances HRW algorithm for the Multicast flows to do DF election = at > ! the granularity of (ESI, VLAN, Mcast flow). >=20 > Status of This Memo >=20 > --- 18,33 ---- >=20 > Abstract >=20 > ! RFC7432 describes mechanism to elect a designated forwarder (DF) = at > the granularity of (ESI, EVI) which is per VLAN (or per group of > VLANs in case of VLAN bundle or VLAN-aware bundle service). = However, > the current level of granularity of per-VLAN is not adequate for = some > ! applications. RFC8584 improves the base DF election by = introducing > ! Highest Random Weigth (HRW) DF election. RFC9251 introduces = applicability of EVPN to > ! Multicast flows, routes to sync them, and a default DF election. = This > ! document is an extension to HRW base draft and further > enhances HRW algorithm for the Multicast flows to do DF election = at > ! the granularity of (ESI, VLAN, Multicast flow). >=20 > Status of This Memo >=20 > *************** > *** 91,104 **** > deployments as well as service provider access/aggregation = networks. > [RFC7432] defines the role of a designated forwarder as the node = in > the redundancy group that is responsible to forward Broadcast, > ! Unknown unicast, Multicast (BUM) traffic on that Ethernet Segment = (CE > ! device or network) in All-Active multi-homing. >=20 > The default DF election mechanism allows selecting a DF at the > granularity of (ES, VLAN) or (ES, VLAN bundle) for BUM traffic. > ! While [RFC8584] improve on the default DF election procedure, = some > service provider residential applications require a finer > ! granularity, where whole multicast flows are delivered on a = single > VLAN. >=20 >=20 > --- 91,104 ---- > deployments as well as service provider access/aggregation = networks. > [RFC7432] defines the role of a designated forwarder as the node = in > the redundancy group that is responsible to forward Broadcast, > ! Unknown unicast, Multicast (BUM) traffic on that Ethernet Segment > ! (Customer Edge (CE) device or network) in All-Active = multi-homing. >=20 > The default DF election mechanism allows selecting a DF at the > granularity of (ES, VLAN) or (ES, VLAN bundle) for BUM traffic. > ! While [RFC8584] improves on the default DF election procedure, = some > service provider residential applications require a finer > ! granularity, where specific multicast flows are delivered on a = single > VLAN. >=20 >=20 > *************** > *** 154,161 **** >=20 > Consider the above topology, which shows a typical residential > deployment scenario, where multiple receivers are behind an all- > ! active multihoming segments. All of the multicast traffic is > ! provisioned on EVI-1. Assume PE-2 get elected as DF. According = to > [RFC7432], PE-2 will be responsible for forwarding multicast = traffic > to that Ethernet segment. >=20 > --- 154,161 ---- >=20 > Consider the above topology, which shows a typical residential > deployment scenario, where multiple receivers are behind an all- > ! active multihoming segment. All of the multicast traffic is > ! provisioned on EVI-1. Assume PE-2 gets elected as DF. According = to > [RFC7432], PE-2 will be responsible for forwarding multicast = traffic > to that Ethernet segment. >=20 > *************** > *** 172,194 **** >=20 > * Forcing sole data plane forwarding responsibility on PE-2 is a > limitation in the current DF election mechanism. The topology = at > ! Figure 1 would always have only one of the PE to be elected as = DF > ! irrespective of which current DF election mechanism is in use > ! defined in [RFC7432] or [RFC8584]. >=20 > * The problem may also manifest itself in a different way. For > example, AC1 happens to use 80% of its available bandwidth to > forward unicast data. And now there is need to serve = multicast > ! receivers where it would require more than 20% of AC1 = bandwidth. > In this case, AC1 becomes oversubscribed and multicast traffic > drop would be observed even though there is already another = link > ! (AC2) present in network which can be used more efficiently = load > balance the multicast traffic. >=20 > ! In this document, we propose an extension to the HRW base draft = to > allow DF election at the granularity of (ESI, VLAN, Mcast flow) = which > ! would allow multicast flows to be better distributed among = redundancy > ! group PEs to share the load. >=20 > 2. Terminology >=20 > --- 172,194 ---- >=20 > * Forcing sole data plane forwarding responsibility on PE-2 is a > limitation in the current DF election mechanism. The topology = at > ! Figure 1 would always have only one of the PEs elected as DF > ! irrespective of which DF election mechanism (defined in = [RFC7432] > ! or [RFC8584]) is in use. >=20 > * The problem may also manifest itself in a different way. For > example, AC1 happens to use 80% of its available bandwidth to > forward unicast data. And now there is need to serve = multicast > ! receivers where it would require more than 20% of AC1's = bandwidth. > In this case, AC1 becomes oversubscribed and multicast traffic > drop would be observed even though there is already another = link > ! (AC2) present in network which can be used more efficiently to = load > balance the multicast traffic. >=20 > ! In this document, we define an extension to the HRW base = [RFC8584] to > allow DF election at the granularity of (ESI, VLAN, Mcast flow) = which > ! would allow multicast flows to be better distributed among PEs in = a > ! redundancy group to share the load. >=20 > 2. Terminology >=20 > *************** > *** 201,212 **** >=20 > 3. The DF Election Extended Community >=20 > ! [RFC8584] defines an extended community, which would be used for = PEs > in redundancy group to reach a consensus as to which DF election > procedure is desired. A PE can notify other participating PEs in > ! redundancy group about its willingness to support Per multicast = flow > base DF election capability by signaling a DF election extended > ! community along with Ethernet-Segment Route (Type-4). The = current > proposal extends the existing extended community defined in > [RFC8584]. This draft defines new a DF type. >=20 > --- 201,212 ---- >=20 > 3. The DF Election Extended Community >=20 > ! [RFC8584] defines an extended community, which is used by PEs > in redundancy group to reach a consensus as to which DF election > procedure is desired. A PE can notify other participating PEs in > ! the redundancy group as to its willingness to support = per-multicast-flow > base DF election capability by signaling a DF election extended > ! community along with an Ethernet-Segment Route (Type-4). The = current > proposal extends the existing extended community defined in > [RFC8584]. This draft defines new a DF type. >=20 > *************** > *** 229,254 **** > - Type 5: HRW base per (*,G) multicast flow DF election > (explained in this document) >=20 > ! * The [RFC8584] describes encoding of capabilities associated to = the > ! DF election algorithm using Bitmap field. When these = capabilities > bits are set along with the DF type-4 and type-5, they need to = be > ! interpreted in context of this new DF type-4 and type-5. For > example, consider a scenario where all PEs in the same = redundancy > ! group (same ES) can support both AC-DF, DF type-4 and DF = type-5 > and receive such indications from the other PEs in the ES. In > this scenario, if a VLAN is not active in a PE, then the DF > election procedure on all PEs in the ES should factor that in = and > ! exclude that PE in the DF election per multicast flow. >=20 > ! * A PE SHOULD attach the DF election Extended Community to ES = route > ! and Extended Community MUST be sent if the ES is locally > ! configured for DF type Per Multicast flow DF election. Only = one > ! DF Election Extended community can be sent along with an ES = route. >=20 > * When a PE receives the ES Routes from all the other PEs for = the > ES, it checks if all of other PEs have advertised their desire = to > ! proceed by Per multicast flow DF election. If all peering PEs > ! have done so, it performs DF election based on Per multicast = flow > procedure. But if: >=20 > - There is at least one PE which advertised route-4 ( AD per = ES > --- 229,254 ---- > - Type 5: HRW base per (*,G) multicast flow DF election > (explained in this document) >=20 > ! * [RFC8584] describes encoding of capabilities associated to the > ! DF election algorithm using a Bitmap field. When these = capabilities > bits are set along with the DF type-4 and type-5, they need to = be > ! interpreted in context of the DF type-4 and type-5. For > example, consider a scenario where all PEs in the same = redundancy > ! group (same ES) can support both AC-DF, DF type-4, and DF = type-5 > and receive such indications from the other PEs in the ES. In > this scenario, if a VLAN is not active in a PE, then the DF > election procedure on all PEs in the ES should factor that in = and > ! exclude that PE in the per-multicast-flow DF election. >=20 > ! * A PE SHOULD attach the DF election Extended Community to an ES = route > ! and the Extended Community MUST be sent if the ES is locally > ! configured for DF type Per-Multicast-flow DF election. Only = one > ! DF Election Extended community can be sent with an ES route. >=20 > * When a PE receives the ES Routes from all the other PEs for = the > ES, it checks if all of other PEs have advertised their desire = to > ! proceed with Per-multicast-flow DF election. If all peering = PEs > ! have done so, it performs DF election based on the = Per-multicast-flow > procedure. But if: >=20 > - There is at least one PE which advertised route-4 ( AD per = ES > *************** > *** 258,264 **** > - There is at least one PE signaling single active in the AD = per > ES route >=20 > ! it MUST be considered as an indication to support of only = Default > DF election [RFC7432] and DF election procedure in [RFC7432] = MUST > be used. >=20 > --- 258,264 ---- > - There is at least one PE signaling single active in the AD = per > ES route >=20 > ! it MUST be considered as an indication to support of only the = Default > DF election [RFC7432] and DF election procedure in [RFC7432] = MUST > be used. >=20 > *************** > *** 268,276 **** > repeat the description of HRW algorithm itself. >=20 > EVPN PE does the discovery of redundancy groups based on = [RFC7432]. > ! If redundancy group consists of N peering EVPN PE nodes, after = the > ! discovery all PEs build an unordered list of IP address of all = the > ! nodes in the redundancy group. The procedure defined in this = draft > does not require the list of PEs to be ordered. Address [i] = denotes > the IP address of the [i]th EVPN PE in redundancy group where (0 = < i > <=3D N ). > --- 268,276 ---- > repeat the description of HRW algorithm itself. >=20 > EVPN PE does the discovery of redundancy groups based on = [RFC7432]. > ! If a redundancy group consists of N peering EVPN PE nodes, after = the > ! discovery all PEs, build an unordered list of IP address of all = the > ! nodes in the redundancy group. The procedure defined in this = document > does not require the list of PEs to be ordered. Address [i] = denotes > the IP address of the [i]th EVPN PE in redundancy group where (0 = < i > <=3D N ). > *************** > *** 284,290 **** >=20 > 4.1. DF election for IGMP (S,G) membership request >=20 > ! The DF is the PE who has maximum weight for (S, G, V, Es) where >=20 > * S - Multicast Source >=20 > --- 284,290 ---- >=20 > 4.1. DF election for IGMP (S,G) membership request >=20 > ! The DF is the PE who has maximum weight for (S, G, V, ES) where >=20 > * S - Multicast Source >=20 > *************** > *** 292,309 **** >=20 > * V - VLAN ID. >=20 > ! * Es - Ethernet Segment Identifier >=20 > Address[i] is address of the ith PE. The PEs IP address length = does > not matter as only the lower-order 31 bits are modulo = significant. >=20 > 1. Weight >=20 > ! * The weight of PE(i) to (S,G,VLAN ID, Es) is calculated by > ! function, weight (S,G,V, Es, Address(i)), where (0 < i <=3D = N), > PE(i) is the PE at ordinal i. >=20 > ! * Weight (S,G,V, Es, Address(i)) =3D (1103515245. > ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) = (mod > 2^31) >=20 > --- 292,309 ---- >=20 > * V - VLAN ID. >=20 > ! * ES - Ethernet Segment Identifier >=20 > Address[i] is address of the ith PE. The PEs IP address length = does > not matter as only the lower-order 31 bits are modulo = significant. >=20 > 1. Weight >=20 > ! * The weight of PE(i) to (S,G,VLAN ID, ES) is calculated by > ! function, weight (S,G,V, ES, Address(i)), where (0 < i <=3D = N), > PE(i) is the PE at ordinal i. >=20 > ! * Weight (S,G,V, ES, Address(i)) =3D (1103515245. > ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) = (mod > 2^31) >=20 > *************** > *** 312,333 **** >=20 > 2. Digest >=20 > ! * D(S,G,V, Es) =3D CRC_32(S,G,V, Es) >=20 > ! * Here D(S,G,V,Es) is the 31-bit digest (CRC_32 and = discarding > ! the MSB) of the Source IP, Group IP, Vlan ID and Es. The = CRC > MUST proceed as if the architecture is in network byte = order > (big-endian). >=20 > 4.2. DF election for IGMP (*,G) membership request >=20 > ! The DF is the PE who has maximum weight for (G, V, Es) where >=20 > * G - Multicast Group >=20 > * V - VLAN ID. >=20 > ! * Es - Ethernet Segment Identifier >=20 >=20 >=20 > --- 312,333 ---- >=20 > 2. Digest >=20 > ! * D(S,G,V, ES) =3D CRC_32(S,G,V, ES) >=20 > ! * Here D(S,G,V,ES) is the 31-bit digest (CRC_32 and = discarding > ! the MSB) of the Source IP, Group IP, Vlan ID and ES. The = CRC > MUST proceed as if the architecture is in network byte = order > (big-endian). >=20 > 4.2. DF election for IGMP (*,G) membership request >=20 > ! The DF is the PE who has maximum weight for (G, V, ES) where >=20 > * G - Multicast Group >=20 > * V - VLAN ID. >=20 > ! * ES - Ethernet Segment Identifier >=20 >=20 >=20 > *************** > *** 343,353 **** >=20 > 1. Weight >=20 > ! * The weight of PE(i) to (G,VLAN ID, Es) is calculated by > ! function, weight (G,V, Es, Address(i)), where (0 < i <=3D = N), > PE(i) is the PE at ordinal i. >=20 > ! * Weight (G,V, Es, Address(i)) =3D (1103515245. > ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) = (mod > 2^31) >=20 > --- 343,353 ---- >=20 > 1. Weight >=20 > ! * The weight of PE(i) to (G,VLAN ID, ES) is calculated by > ! function, weight (G,V, ES, Address(i)), where (0 < i <=3D = N), > PE(i) is the PE at ordinal i. >=20 > ! * Weight (G,V, ES, Address(i)) =3D (1103515245. > ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) = (mod > 2^31) >=20 > *************** > *** 356,376 **** >=20 > 2. Digest >=20 > ! * D(G,V, Es) =3D CRC_32(G,V, Es) >=20 > ! * Here D(G,V,Es) is the 31-bit digest (CRC_32 and discarding = the > ! MSB) of the Group IP, Vlan ID and Es. The CRC MUST = proceed as > if the architecture is in network byte order (big-endian). >=20 > 4.3. Default DF election procedure >=20 > ! Per multicast DF election procedure would be applicable only when > ! host behind Attachment Circuit (of the Es) start sending IGMP > ! membership requests. Membership requests are synced using = procedure > ! defined in [RFC9251], and each of the PE in redundancy group can = use > ! per flow DF election and create DF state per multicast flow. The = HRW > DF election "Type 1" procedure defined in [RFC8584] MUST be used = for > ! the Es DF election and SHOULD be performed on Es even before = learning > multicast membership request state. This default election = procedure > MUST be used at port level but will be overwritten by Per flow DF > election as and when new membership request state are learnt. > --- 356,376 ---- >=20 > 2. Digest >=20 > ! * D(G,V, ES) =3D CRC_32(G,V, Es) >=20 > ! * Here D(G,V,ES) is the 31-bit digest (CRC_32 and discarding = the > ! MSB) of the Group IP, Vlan ID and ES. The CRC MUST = proceed as > if the architecture is in network byte order (big-endian). >=20 > 4.3. Default DF election procedure >=20 > ! Per-multicast-flow DF election procedure would be applicable only = when > ! host behind the Attachment Circuit (of the ES) starts sending = IGMP > ! membership requests. Membership requests are synced using the = procedure > ! defined in [RFC9251], and each of the PEs in a redundancy group = can use > ! per-multicast-flow DF election and create DF state per multicast = flow. The HRW > DF election "Type 1" procedure defined in [RFC8584] MUST be used = for > ! the ES DF election and SHOULD be performed on ES even before = learning > multicast membership request state. This default election = procedure > MUST be used at port level but will be overwritten by Per flow DF > election as and when new membership request state are learnt. > *************** > *** 394,400 **** > Internet-Draft Per multicast flow Designated Forwarder July = 2023 >=20 >=20 > ! Multicast Source > | > | > | > --- 394,400 ---- > Internet-Draft Per multicast flow Designated Forwarder July = 2023 >=20 >=20 > ! Multicast Source > | > | > | > *************** > *** 436,446 **** > Route. This draft does not change any of this procedure, it > still uses the procedure defined in [RFC7432]. >=20 > ! 2. Each of the PEs in redundancy group advertise Ethernet = segment > ! route with extended community indicating their ability to > ! participate in per multicast flow DF election procedure. = Since > ! Per multicast flow would not be applicable unless PE learns = about > ! membership request from receiver, there is a need to have the > default DF election among PEs in redundancy group for BUM >=20 >=20 > --- 436,446 ---- > Route. This draft does not change any of this procedure, it > still uses the procedure defined in [RFC7432]. >=20 > ! 2. Each of the PEs in the redundancy group advertise an Ethernet = segment > ! route with an extended community indicating their ability to > ! participate in per-multicast-flow DF election procedure. = Since > ! Per multicast flow would not be applicable unless the PE = learns about > ! muilticast membership from a receiver, there is a need to = have the > default DF election among PEs in redundancy group for BUM >=20 >=20 > *************** > *** 450,484 **** > Internet-Draft Per multicast flow Designated Forwarder July = 2023 >=20 >=20 > ! traffic. Until multicast membership state are learnt, we use = the > ! the DF election procedure in Section 4.3, namely HRW per = (v,Es) > as defined in [RFC8584] . >=20 > 3. When a receiver starts sending membership requests for = (s1,g1), > ! where s1 is multicast source address and g1 is multicast = group > address, CE-1 could hash membership request (IGMP join) to = any of > the PEs in redundancy group. Let's consider it is hashed to = PE- > 2. [RFC9251] defines a procedure to sync IGMP join state = among > ! redundancy group of PEs. Now each of the PE would have > ! information about membership request (s1,g1) and each of them = run > ! DF election procedure Section 4.1 to elect DF among = participating > ! PEs in redundancy group. Consider PE-2 gets elected as DF = for > ! multicast flow (s1,g1). >=20 > 1. PE-1 forwarding state would be nDF for flow (s1,g1) and = DF > for rest other BUM traffic. >=20 > ! 2. PE-2 forwarding state would be DF for flow (s1,g1) and = nDF > for rest other BUM traffic. >=20 > 3. PE-3 forwarding state would be nDF for flow (s1,g1) and = rest > other BUM traffic. >=20 > ! 4. As and when new multicast membership request comes, same > ! procedure as above would continue. >=20 > 5. If Section 3 has DF type 4, For membership request (S,G) it = MUST > ! use Section 4.1 to elect DF among participating PEs. And > membership request (*,G) MUST use Section 4.2 to elect DF = among > participating PEs. >=20 > --- 450,485 ---- > Internet-Draft Per multicast flow Designated Forwarder July = 2023 >=20 >=20 > ! traffic. Until multicast membership state is learnt, we use = the > ! the DF election procedure in Section 4.3, namely HRW per = (v,ES) > as defined in [RFC8584] . >=20 > 3. When a receiver starts sending membership requests for = (s1,g1), > ! where s1 is a multicast source address and g1 is a multicast = group > address, CE-1 could hash membership request (IGMP join) to = any of > the PEs in redundancy group. Let's consider it is hashed to = PE- > 2. [RFC9251] defines a procedure to sync IGMP join state = among > ! PEs in a redundancy group. Now each of the PE would have > ! information about the membership request (s1,g1) and each of = them would run > ! the DF election procedure (refer to Section 4.1)( to elect > ! a DF among participating PEs in the redundancy group. = Consider PE-2 > ! gets elected as DF for multicast flow (s1,g1). >=20 > 1. PE-1 forwarding state would be nDF for flow (s1,g1) and = DF > for rest other BUM traffic. >=20 > ! 2. PE-2 forwarding state would be the DF for flow (s1,g1) = and nDF > for rest other BUM traffic. >=20 > 3. PE-3 forwarding state would be nDF for flow (s1,g1) and = rest > other BUM traffic. >=20 > ! 4. When a new multicast membership request arrives, the same > ! procedure as above would used to selected a nDF for the > ! multicast flow. >=20 > 5. If Section 3 has DF type 4, For membership request (S,G) it = MUST > ! use Section 4.1 to elect a DF among participating PEs. And > membership request (*,G) MUST use Section 4.2 to elect DF = among > participating PEs. >=20 > *************** > *** 487,494 **** > There are multiple triggers which can cause DF re-election. Some = of > the triggers could be >=20 > ! 1. Local ES going down due to physical failure or configuration > ! change triggers DF re-election at peering PE. >=20 > 2. Detection of new PE through ES route. >=20 > --- 488,495 ---- > There are multiple triggers which can cause DF re-election. Some = of > the triggers could be >=20 > ! 1. Local ES going down due to physical failure or a = configuration > ! change that triggers DF re-election at peering PE. >=20 > 2. Detection of new PE through ES route. >=20 > *************** > *** 509,515 **** > 6. Local configuration change of DF election Type and peering PE > consensus on new DF Type >=20 > ! This document does not provide any new mechanism to handle DF re- > election procedure. It uses the existing mechanism defined in > [RFC7432]. Whenever either of the triggers occur, a DF = re-election > would be done. and all of the flows would be redistributed among > --- 510,516 ---- > 6. Local configuration change of DF election Type and peering PE > consensus on new DF Type >=20 > ! This document does not provide any new mechanisms to handle DF = re- > election procedure. It uses the existing mechanism defined in > [RFC7432]. Whenever either of the triggers occur, a DF = re-election > would be done. and all of the flows would be redistributed among >=20 --Apple-Mail=_79F6C49D-1B93-4858-8972-44816CC04C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mankamana, 

On Aug 1, = 2023, at 17:44, Mankamana Mishra (mankamis) <mankamis@cisco.com> = wrote:

Hi Acee, 
Thanks for reviewing and comment.  While I make = changes to existing draft based on your comments,  I had question = on some of the comments
 
  1. Precisely = explain the hashing algorithm in section 4.1 and 4.2. = As
     written, they subject to multiple = interpretations. Provide a reference
     to = CRC_32() and expand acronyms on first use (e.g., MSB).

  2. = In addition to explaining the hashing algorithm, the document = should
     provide a discussion on why this = hashing algorithm provides a good
     = distribiution of flows.
 
https://datatracker.ietf.org/doc/html/rfc8584#section-3 defines most of the base = HRW draft and its benefit . Do you expect it to be repeated in this = draft too ? This draft does not change the base HRW algorithm but adds = flow information as also an input parameter to calculate the weight = ?

You shouldn=E2=80=99t = include a formula in a document where the elements are not explained, = acronyms are not expanded, and references are not = provided. 

You could reference the RFC = 8584 discussion of why the algorithm provides a good distribution of = traffic this reference should be accompanied with text explaining how = these benefits extend to individual multicast = flows.

Thanks,
Acee




 
Please let me know = if you want only reference to be given or content to be copied here = ?
 
Mankamana 
 

From: Acee Lindem = <acee.ietf@gmail.com>
Date: Friday, July 21, 2023 = at 2:43 PM
To: Routing ADs = <rtg-ads@ietf.org>, = draft-ietf-bess-evpn-per-mcast-flow-df-election@ietf.org = <draft-ietf-bess-evpn-per-mcast-flow-df-election@ietf.org>
Cc:=  bess@ietf.org = <bess@ietf.org>, Routing Directorate = <rtg-dir@ietf.org>
Subject: Routing Directorate = early review for = draft-ietf-bess-evpn-per-mcast-flow-df-election-09

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-per-mcast-flow-df-election-09
Reviewer: Acee = Lindem
Review Date: 07/20/2023
IETF LC End Date: N/A
Intended = Status: Standards Track

Summary:
This document describes a = per-multicast-flow DF election mechanism
which support per multicast = flow load-balancing of the EVPN ES
forwarding amongst PEs in a = redundancy group. While the document describes
a fairly = straightforward function, it really needs some editing and = never
should have been adopted as a WG document in this condition. = Consequently,
I have entered a =E2=80=9CNot Ready=E2=80=9D = disposition for the review. 


Major = Issues:
  1. Precisely explain the hashing algorithm in section = 4.1 and 4.2. As
     written, they subject to = multiple interpretations. Provide a = reference
     to CRC_32() and expand acronyms on = first use (e.g., MSB).

  2. In addition to explaining the = hashing algorithm, the document should
     = provide a discussion on why this hashing algorithm provides a = good
     distribiution of flows.

 3. = While this is a minor comment, it also pertains to the = hashing
    algorithm. To better distribute the flows, = why not exclude the current
    BUM DF from the list = of PEs from which to choose a per-flow DF??


Minor = Issues:

  1. Acronyms from RFC 7432 and RFC 8584 used = without first expansion.
     For example, none = of the acronyms in the figures are defined. = I'd
     suggest adding a glossary with terms = from other documents.
  2. The acronym "Es" is used for Ethernet = Segment when ES is used in
     other EVPN = documents.
  3. Missing articles make the text unwieldy to = read.
  4. Multiple problems with agreement of subject and = verb.
  5. Define what is referred to by DFn. Presumably, this = is the selected
     PE in the redundancy = group.
  5. Number 5 in section 5 doesn't make sense as written. = I was trying to
     fix it but it needs = attention from the author.
  6. The abstract cannot include RFC = references from the draft. However,
     the RFCs = may be referenced without the braces.
  7. The security = considerations for RFC 8584 are also applicable. = Additionally,
     you that you are going to be = asked for a discussion of how the existing
     = security mechanisms apply to per-flow DF selection, so you might as = well
     provide it now.


Nits: See = diff below.

Thanks,
Acee


*** = draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt.orig Wed Jul 19 = 11:43:37 2023
--- = draft-ietf-bess-evpn-per-mcast-flow-df-election-09.txt   &n= bsp;  Wed Jul 19 12:21:57 2023
***************
*** 18,33 = ****

  Abstract

!    [RFC7432] = describes mechanism to elect designated forwarder (DF) = at
     the granularity of (ESI, EVI) which is = per VLAN (or per group of
     VLANs in case of = VLAN bundle or VLAN-aware bundle service).  = However,
     the current level of granularity of = per-VLAN is not adequate for some
!    = applications.[RFC8584] improves base line DF election by = introducing
!    HRW DF election.  [RFC9251] = introduces applicability of EVPN to
!    Multicast = flows, routes to sync them and a default DF election.  = This
!    document is an extension to HRW base draft = [RFC8584] and further
     enhances HRW algorithm = for the Multicast flows to do DF election at
!    the = granularity of (ESI, VLAN, Mcast flow).

  Status of This = Memo

--- 18,33 ----

  = Abstract

!    RFC7432 describes mechanism to elect = a designated forwarder (DF) at
     the = granularity of (ESI, EVI) which is per VLAN (or per group = of
     VLANs in case of VLAN bundle or = VLAN-aware bundle service).  However,
     = the current level of granularity of per-VLAN is not adequate for = some
!    applications. RFC8584 improves the base DF = election by introducing
!    Highest Random Weigth = (HRW) DF election.  RFC9251 introduces applicability of EVPN = to
!    Multicast flows, routes to sync them, and a = default DF election.  This
!    document is an = extension to HRW base draft and further
     = enhances HRW algorithm for the Multicast flows to do DF election = at
!    the granularity of (ESI, VLAN, Multicast = flow).

  Status of This Memo

***************
*** = 91,104 ****
     deployments as well as service = provider access/aggregation networks.
     = [RFC7432] defines the role of a designated forwarder as the node = in
     the redundancy group that is responsible = to forward Broadcast,
!    Unknown unicast, Multicast = (BUM) traffic on that Ethernet Segment (CE
!    device = or network) in All-Active multi-homing.

     = The default DF election mechanism allows selecting a DF at = the
     granularity of (ES, VLAN) or (ES, VLAN = bundle) for BUM traffic.
!    While [RFC8584] improve = on the default DF election procedure, some
     = service provider residential applications require a = finer
!    granularity, where whole multicast flows = are delivered on a single
     = VLAN.


--- 91,104 ----
     deployments = as well as service provider access/aggregation = networks.
     [RFC7432] defines the role of a = designated forwarder as the node in
     the = redundancy group that is responsible to forward = Broadcast,
!    Unknown unicast, Multicast (BUM) = traffic on that Ethernet Segment
!    (Customer Edge = (CE) device or network) in All-Active = multi-homing.

     The default DF election = mechanism allows selecting a DF at the
     = granularity of (ES, VLAN) or (ES, VLAN bundle) for BUM = traffic.
!    While [RFC8584] improves on the default = DF election procedure, some
     service provider = residential applications require a finer
!    = granularity, where specific multicast flows are delivered on a = single
     = VLAN.


***************
*** 154,161 = ****

     Consider the above topology, which = shows a typical residential
     deployment = scenario, where multiple receivers are behind an = all-
!    active multihoming segments.  All of = the multicast traffic is
!    provisioned on = EVI-1.  Assume PE-2 get elected as DF.  According = to
     [RFC7432], PE-2 will be responsible for = forwarding multicast traffic
     to that = Ethernet segment.

--- 154,161 = ----

     Consider the above topology, which = shows a typical residential
     deployment = scenario, where multiple receivers are behind an = all-
!    active multihoming segment.  All of the = multicast traffic is
!    provisioned on EVI-1.  = Assume PE-2 gets elected as DF.  According = to
     [RFC7432], PE-2 will be responsible for = forwarding multicast traffic
     to that = Ethernet segment.

***************
*** 172,194 = ****

     *  Forcing sole data plane = forwarding responsibility on PE-2 is = a
        limitation in the = current DF election mechanism.  The topology = at
!       Figure 1 would always have = only one of the PE to be elected as = DF
!       irrespective of which = current DF election mechanism is in = use
!       defined in [RFC7432] or = [RFC8584].

     *  The problem may also = manifest itself in a different way.  = For
        example, AC1 happens = to use 80% of its available bandwidth = to
        forward unicast = data.  And now there is need to serve = multicast
!       receivers where it = would require more than 20% of AC1 = bandwidth.
        In this case, = AC1 becomes oversubscribed and multicast = traffic
        drop would be = observed even though there is already another = link
!       (AC2) present in network = which can be used more efficiently = load
        balance the multicast = traffic.

!    In this document, we propose an = extension to the HRW base draft to
     allow DF = election at the granularity of (ESI, VLAN, Mcast flow) = which
!    would allow multicast flows to be better = distributed among redundancy
!    group PEs to share = the load.

  2.  Terminology

--- 172,194 = ----

     *  Forcing sole data plane = forwarding responsibility on PE-2 is = a
        limitation in the = current DF election mechanism.  The topology = at
!       Figure 1 would always have = only one of the PEs elected as = DF
!       irrespective of which DF = election mechanism (defined in = [RFC7432]
!       or [RFC8584]) is in = use.

     *  The problem may also = manifest itself in a different way.  = For
        example, AC1 happens = to use 80% of its available bandwidth = to
        forward unicast = data.  And now there is need to serve = multicast
!       receivers where it = would require more than 20% of AC1's = bandwidth.
        In this case, = AC1 becomes oversubscribed and multicast = traffic
        drop would be = observed even though there is already another = link
!       (AC2) present in network = which can be used more efficiently to = load
        balance the multicast = traffic.

!    In this document, we define an = extension to the HRW base [RFC8584] to
     allow = DF election at the granularity of (ESI, VLAN, Mcast flow) = which
!    would allow multicast flows to be better = distributed among PEs in a
!    redundancy group to = share the load.

  2.  = Terminology

***************
*** 201,212 ****

  = 3.  The DF Election Extended Community

!    = [RFC8584] defines an extended community, which would be used for = PEs
     in redundancy group to reach a consensus = as to which DF election
     procedure is = desired.  A PE can notify other participating PEs = in
!    redundancy group about its willingness to = support Per multicast flow
     base DF election = capability by signaling a DF election extended
!    = community along with Ethernet-Segment Route (Type-4).  The = current
     proposal extends the existing = extended community defined in
     = [RFC8584].  This draft defines new a DF type.

--- 201,212 = ----

  3.  The DF Election Extended = Community

!    [RFC8584] defines an extended = community, which is used by PEs
     in = redundancy group to reach a consensus as to which DF = election
     procedure is desired.  A PE = can notify other participating PEs in
!    the = redundancy group as to its willingness to support = per-multicast-flow
     base DF election = capability by signaling a DF election extended
!    = community along with an Ethernet-Segment Route (Type-4).  The = current
     proposal extends the existing = extended community defined in
     = [RFC8584].  This draft defines new a DF = type.

***************
*** 229,254 = ****
        -  Type 5: HRW = base per (*,G) multicast flow DF = election
           = (explained in this document)

!    *  The = [RFC8584] describes encoding of capabilities associated to = the
!       DF election algorithm using = Bitmap field.  When these = capabilities
        bits are set = along with the DF type-4 and type-5, they need to = be
!       interpreted in context of = this new DF type-4 and type-5.  = For
        example, consider a = scenario where all PEs in the same = redundancy
!       group (same ES) can = support both AC-DF, DF type-4 and DF = type-5
        and receive such = indications from the other PEs in the ES.  = In
        this scenario, if a = VLAN is not active in a PE, then the = DF
        election procedure on = all PEs in the ES should factor that in = and
!       exclude that PE in the DF = election per multicast flow.

!    *  A PE = SHOULD attach the DF election Extended Community to ES = route
!       and Extended Community = MUST be sent if the ES is = locally
!       configured for DF type = Per Multicast flow DF election.  Only = one
!       DF Election Extended = community can be sent along with an ES = route.

     *  When a PE receives the ES = Routes from all the other PEs for = the
        ES, it checks if all = of other PEs have advertised their desire = to
!       proceed by Per multicast = flow DF election.  If all peering = PEs
!       have done so, it performs = DF election based on Per multicast = flow
        procedure.  But = if:

        -  There is = at least one PE which advertised route-4 ( AD per ES
--- 229,254 = ----
        -  Type 5: HRW = base per (*,G) multicast flow DF = election
           = (explained in this document)

!    *  = [RFC8584] describes encoding of capabilities associated to = the
!       DF election algorithm using = a Bitmap field.  When these = capabilities
        bits are set = along with the DF type-4 and type-5, they need to = be
!       interpreted in context of = the DF type-4 and type-5.  = For
        example, consider a = scenario where all PEs in the same = redundancy
!       group (same ES) can = support both AC-DF, DF type-4, and DF = type-5
        and receive such = indications from the other PEs in the ES.  = In
        this scenario, if a = VLAN is not active in a PE, then the = DF
        election procedure on = all PEs in the ES should factor that in = and
!       exclude that PE in the = per-multicast-flow DF election.

!    *  A PE = SHOULD attach the DF election Extended Community to an ES = route
!       and the Extended = Community MUST be sent if the ES is = locally
!       configured for DF type = Per-Multicast-flow DF election.  Only = one
!       DF Election Extended = community can be sent with an ES route.

     = *  When a PE receives the ES Routes from all the other PEs for = the
        ES, it checks if all = of other PEs have advertised their desire = to
!       proceed with = Per-multicast-flow DF election.  If all peering = PEs
!       have done so, it performs = DF election based on the = Per-multicast-flow
        = procedure.  But = if:

        -  There is = at least one PE which advertised route-4 ( AD per = ES
***************
*** 258,264 = ****
        -  There is at = least one PE signaling single active in the AD = per
           ES = route

!       it MUST be considered = as an indication to support of only = Default
        DF election = [RFC7432] and DF election procedure in [RFC7432] = MUST
        be used.

--- = 258,264 ----
        -  There = is at least one PE signaling single active in the AD = per
           ES = route

!       it MUST be considered = as an indication to support of only the = Default
        DF election = [RFC7432] and DF election procedure in [RFC7432] = MUST
        be = used.

***************
*** 268,276 = ****
     repeat the description of HRW algorithm = itself.

     EVPN PE does the discovery of = redundancy groups based on [RFC7432].
!    If = redundancy group consists of N peering EVPN PE nodes, after = the
!    discovery all PEs build an unordered list of = IP address of all the
!    nodes in the redundancy = group.  The procedure defined in this = draft
     does not require the list of PEs to be = ordered.  Address [i] denotes
     the IP = address of the [i]th EVPN PE in redundancy group where (0 < = i
     <=3D N ).
--- 268,276 = ----
     repeat the description of HRW algorithm = itself.

     EVPN PE does the discovery of = redundancy groups based on [RFC7432].
!    If a = redundancy group consists of N peering EVPN PE nodes, after = the
!    discovery all PEs, build an unordered list of = IP address of all the
!    nodes in the redundancy = group.  The procedure defined in this = document
     does not require the list of PEs to = be ordered.  Address [i] denotes
     the IP = address of the [i]th EVPN PE in redundancy group where (0 < = i
     <=3D N ).
***************
*** = 284,290 ****

  4.1.  DF election for IGMP (S,G) = membership request

!    The DF is the PE who has = maximum weight for (S, G, V, Es) where

     = *  S - Multicast Source

--- 284,290 ----

  = 4.1.  DF election for IGMP (S,G) membership = request

!    The DF is the PE who has maximum = weight for (S, G, V, ES) where

     *  S = - Multicast Source

***************
*** 292,309 = ****

     *  V - VLAN = ID.

!    *  Es - Ethernet Segment = Identifier

     Address[i] is address of the = ith PE.  The PEs IP address length does
     = not matter as only the lower-order 31 bits are modulo = significant.

     1.  = Weight

!        *  The = weight of PE(i) to (S,G,VLAN ID, Es) is calculated = by
!           = function, weight (S,G,V, Es, Address(i)), where (0 < i <=3D = N),
            = PE(i) is the PE at ordinal = i.

!        *  Weight = (S,G,V, Es, Address(i)) =3D = (1103515245.
         &nbs= p;  ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) = (mod
           = 2^31)

--- 292,309 ----

     *  V = - VLAN ID.

!    *  ES - Ethernet Segment = Identifier

     Address[i] is address of the = ith PE.  The PEs IP address length does
     = not matter as only the lower-order 31 bits are modulo = significant.

     1.  = Weight

!        *  The = weight of PE(i) to (S,G,VLAN ID, ES) is calculated = by
!           = function, weight (S,G,V, ES, Address(i)), where (0 < i <=3D = N),
            = PE(i) is the PE at ordinal = i.

!        *  Weight = (S,G,V, ES, Address(i)) =3D = (1103515245.
         &nbs= p;  ((1103515245.Address(i) + 12345) XOR D(S,G,V,ESI))+12345) = (mod
           = 2^31)

***************
*** 312,333 = ****

     2.  = Digest

!        *  = D(S,G,V, Es) =3D CRC_32(S,G,V, = Es)

!        *  Here = D(S,G,V,Es) is the 31-bit digest (CRC_32 and = discarding
!          = ; the MSB) of the Source IP, Group IP, Vlan ID and Es.  The = CRC
            = MUST proceed as if the architecture is in network byte = order
           = ; (big-endian).

  4.2.  DF election for IGMP (*,G) = membership request

!    The DF is the PE who has = maximum weight for (G, V, Es) where

     = *  G - Multicast Group

     *  V - = VLAN ID.

!    *  Es - Ethernet Segment = Identifier



--- 312,333 = ----

     2.  = Digest

!        *  = D(S,G,V, ES) =3D CRC_32(S,G,V, = ES)

!        *  Here = D(S,G,V,ES) is the 31-bit digest (CRC_32 and = discarding
!          = ; the MSB) of the Source IP, Group IP, Vlan ID and ES.  The = CRC
            = MUST proceed as if the architecture is in network byte = order
           = ; (big-endian).

  4.2.  DF election for IGMP (*,G) = membership request

!    The DF is the PE who has = maximum weight for (G, V, ES) where

     = *  G - Multicast Group

     *  V - = VLAN ID.

!    *  ES - Ethernet Segment = Identifier



***************
*** 343,353 = ****

     1.  = Weight

!        *  The = weight of PE(i) to (G,VLAN ID, Es) is calculated = by
!           = function, weight (G,V, Es, Address(i)), where (0 < i <=3D = N),
            = PE(i) is the PE at ordinal = i.

!        *  Weight = (G,V, Es, Address(i)) =3D = (1103515245.
         &nbs= p;  ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) = (mod
           = 2^31)

--- 343,353 ----

     1.  = Weight

!        *  The = weight of PE(i) to (G,VLAN ID, ES) is calculated = by
!           = function, weight (G,V, ES, Address(i)), where (0 < i <=3D = N),
            = PE(i) is the PE at ordinal = i.

!        *  Weight = (G,V, ES, Address(i)) =3D = (1103515245.
         &nbs= p;  ((1103515245.Address(i) + 12345) XOR D(G,V,ESI))+12345) = (mod
           = 2^31)

***************
*** 356,376 = ****

     2.  = Digest

!        *  D(G,V, = Es) =3D CRC_32(G,V, = Es)

!        *  Here = D(G,V,Es) is the 31-bit digest (CRC_32 and discarding = the
!           = MSB) of the Group IP, Vlan ID and Es.  The CRC MUST proceed = as
            = if the architecture is in network byte order (big-endian).

  = 4.3.  Default DF election procedure

!    Per = multicast DF election procedure would be applicable only = when
!    host behind Attachment Circuit (of the Es) = start sending IGMP
!    membership requests.  = Membership requests are synced using procedure
!    = defined in [RFC9251], and each of the PE in redundancy group can = use
!    per flow DF election and create DF state per = multicast flow.  The HRW
     DF election = "Type 1" procedure defined in [RFC8584] MUST be used = for
!    the Es DF election and SHOULD be performed on = Es even before learning
     multicast membership = request state.  This default election = procedure
     MUST be used at port level but = will be overwritten by Per flow DF
     election = as and when new membership request state are learnt.
--- 356,376 = ----

     2.  = Digest

!        *  D(G,V, = ES) =3D CRC_32(G,V, = Es)

!        *  Here = D(G,V,ES) is the 31-bit digest (CRC_32 and discarding = the
!           = MSB) of the Group IP, Vlan ID and ES.  The CRC MUST proceed = as
            = if the architecture is in network byte order (big-endian).

  = 4.3.  Default DF election procedure

!    = Per-multicast-flow DF election procedure would be applicable only = when
!    host behind the Attachment Circuit (of the = ES) starts sending IGMP
!    membership = requests.  Membership requests are synced using the = procedure
!    defined in [RFC9251], and each of the = PEs in a redundancy group can use
!    = per-multicast-flow DF election and create DF state per multicast = flow.  The HRW
     DF election "Type 1" = procedure defined in [RFC8584] MUST be used for
!    = the ES DF election and SHOULD be performed on ES even before = learning
     multicast membership request = state.  This default election procedure
     = MUST be used at port level but will be overwritten by Per flow = DF
     election as and when new membership = request state are learnt.
***************
*** 394,400 = ****
  Internet-Draft   Per multicast flow Designated = Forwarder       July = 2023


!         &nb= sp;            = ;            &= nbsp;   Multicast  = Source
          &nbs= p;            =             &n= bsp;           = |
           &nb= sp;            = ;            &= nbsp;          = |
           &nb= sp;            = ;            &= nbsp;          |
--- = 394,400 ----
  Internet-Draft   Per multicast flow = Designated Forwarder       July = 2023


!         &nb= sp;            = ;            &= nbsp;   Multicast = Source
          &nbs= p;            =             &n= bsp;           = |
           &nb= sp;            = ;            &= nbsp;          = |
           &nb= sp;            = ;            &= nbsp;          = |
***************
*** 436,446 = ****
         Route.  = This draft does not change any of this procedure, = it
         still uses the = procedure defined in [RFC7432].

!    2.  Each = of the PEs in redundancy group advertise Ethernet = segment
!        route with = extended community indicating their ability = to
!        participate in per = multicast flow DF election procedure.  = Since
!        Per multicast flow = would not be applicable unless PE learns = about
!        membership request = from receiver, there is a need to have = the
         default DF = election among PEs in redundancy group for BUM


--- 436,446 = ----
         Route.  = This draft does not change any of this procedure, = it
         still uses the = procedure defined in [RFC7432].

!    2.  Each = of the PEs in the redundancy group advertise an Ethernet = segment
!        route with an = extended community indicating their ability = to
!        participate in = per-multicast-flow DF election procedure.  = Since
!        Per multicast flow = would not be applicable unless the PE learns = about
!        muilticast = membership from a receiver, there is a need to have = the
         default DF = election among PEs in redundancy group for = BUM


***************
*** 450,484 ****
  = Internet-Draft   Per multicast flow Designated = Forwarder       July = 2023


!        = traffic.  Until multicast membership state are learnt, we use = the
!        the DF election = procedure in Section 4.3, namely HRW per = (v,Es)
         as defined in = [RFC8584] .

     3.  When a receiver = starts sending membership requests for = (s1,g1),
!        where s1 is = multicast source address and g1 is multicast = group
         address, CE-1 = could hash membership request (IGMP join) to any = of
         the PEs in = redundancy group.  Let's consider it is hashed to = PE-
         2.  = [RFC9251] defines a procedure to sync IGMP join state = among
!        redundancy group of = PEs.  Now each of the PE would = have
!        information about = membership request (s1,g1) and each of them = run
!        DF election procedure = Section 4.1 to elect DF among = participating
!        PEs in = redundancy group.  Consider PE-2 gets elected as DF = for
!        multicast flow = (s1,g1).

         = 1.  PE-1 forwarding state would be nDF for flow (s1,g1) and = DF
           &n= bsp; for rest other BUM = traffic.

!        2.  = PE-2 forwarding state would be DF for flow (s1,g1) and = nDF
           &= nbsp; for rest other BUM = traffic.

         = 3.  PE-3 forwarding state would be nDF for flow (s1,g1) and = rest
           =   other BUM traffic.

!    4.  As and = when new multicast membership request comes, = same
!        procedure as above = would continue.

     5.  If Section 3 = has DF type 4, For membership request (S,G) it = MUST
!        use Section 4.1 to = elect DF among participating PEs.  = And
         membership = request (*,G) MUST use Section 4.2 to elect DF = among
         participating = PEs.

--- 450,485 ----
  Internet-Draft   Per = multicast flow Designated Forwarder       = July 2023


!        = traffic.  Until multicast membership state is learnt, we use = the
!        the DF election = procedure in Section 4.3, namely HRW per = (v,ES)
         as defined in = [RFC8584] .

     3.  When a receiver = starts sending membership requests for = (s1,g1),
!        where s1 is a = multicast source address and g1 is a multicast = group
         address, CE-1 = could hash membership request (IGMP join) to any = of
         the PEs in = redundancy group.  Let's consider it is hashed to = PE-
         2.  = [RFC9251] defines a procedure to sync IGMP join state = among
!        PEs in a redundancy = group.  Now each of the PE would = have
!        information about = the membership request (s1,g1) and each of them would = run
!        the DF election = procedure (refer to Section 4.1)( to = elect
!        a DF among = participating  PEs in the redundancy group.  Consider = PE-2
!        gets elected as DF = for multicast flow = (s1,g1).

         = 1.  PE-1 forwarding state would be nDF for flow (s1,g1) and = DF
           &n= bsp; for rest other BUM = traffic.

!        2.  = PE-2 forwarding state would be the DF for flow (s1,g1) and = nDF
           &= nbsp; for rest other BUM = traffic.

         = 3.  PE-3 forwarding state would be nDF for flow (s1,g1) and = rest
           =   other BUM traffic.

!    4.  When a new = multicast membership request arrives, the = same
!        procedure as above = would used to selected a nDF for = the
!        multicast = flow.

     5.  If Section 3 has DF type = 4, For membership request (S,G) it = MUST
!        use Section 4.1 to = elect a DF among participating PEs.  = And
         membership = request (*,G) MUST use Section 4.2 to elect DF = among
         participating = PEs.

***************
*** 487,494 = ****
     There are multiple triggers which can = cause DF re-election.  Some of
     the = triggers could be

!    1.  Local ES going = down due to physical failure or = configuration
!        change = triggers DF re-election at peering PE.

     = 2.  Detection of new PE through ES route.

--- 488,495 = ----
     There are multiple triggers which can = cause DF re-election.  Some of
     the = triggers could be

!    1.  Local ES going = down due to physical failure or a = configuration
!        change that = triggers DF re-election at peering PE.

     = 2.  Detection of new PE through ES = route.

***************
*** 509,515 = ****
     6.  Local configuration change of = DF election Type and peering = PE
         consensus on new = DF Type

!    This document does not provide any = new mechanism to handle DF re-
     election = procedure.  It uses the existing mechanism defined = in
     [RFC7432].  Whenever either of the = triggers occur, a DF re-election
     would be = done. and all of the flows would be redistributed among
--- 510,516 = ----
     6.  Local configuration change of = DF election Type and peering = PE
         consensus on new = DF Type

!    This document does not provide any = new mechanisms to handle DF re-
     election = procedure.  It uses the existing mechanism defined = in
     [RFC7432].  Whenever either of the = triggers occur, a DF re-election
     would be = done. and all of the flows would be redistributed = among


= --Apple-Mail=_79F6C49D-1B93-4858-8972-44816CC04C04--