Thanks, Jorge. - I’m not sure what I was thinking about with my reference to §8, your reference to §4 does indeed seem like the right one. - The text about BD label is clear now.
Regards, —John On Jan 25, 2022, at 8:01 AM, Rabadan, Jorge (Nokia - US/Sunnyvale) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote: Hi John, Sorry for the delay. I agree the document improved significantly and your thorough review and great points had a lot to do with it. So thank you very much on behalf of the authors. Just published version 12 which addresses your comments. I’m adding my comments below in-line with [jorge]. Thank you John. Jorge From: John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Date: Friday, January 7, 2022 at 11:09 AM To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>, draft-ietf-bess-evpn-optimized...@ietf.org<mailto:draft-ietf-bess-evpn-optimized...@ietf.org> <draft-ietf-bess-evpn-optimized...@ietf.org<mailto:draft-ietf-bess-evpn-optimized...@ietf.org>>, bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> <bess-cha...@ietf.org<mailto:bess-cha...@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, Bocci, Matthew (Nokia - GB) <matthew.bo...@nokia.com<mailto:matthew.bo...@nokia.com>> Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT) Hi Jorge and all, On Nov 17, 2021, at 4:12 AM, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> wrote: Hi John, Thanks again. We just published version 11, addressing some other reviews. Let us know if you have any other comments. Thanks, Jorge I do have just a few more comments that I came up with while reviewing your update. By the way, thanks again for the update, it was not a small piece of work. I do think it made the document meaningfully more usable, I appreciate your effort. Below are my additional comments. All of these are proofreading or nits, except for the comment about the definition of “BD label” which is slightly more consequential. [jorge] thanks again John. We took them all, I’m only adding comments to those that needed explanation. Please see in-line. Regards, —John --- draft-ietf-bess-evpn-optimized-ir-11.txt 2022-01-07 14:00:37.000000000 -0500 +++ draft-ietf-bess-evpn-optimized-ir-11-jgs-markup.txt 2022-01-07 13:58:18.000000000 -0500 @@ -19,7 +19,7 @@ Abstract - Network Virtualization Overlay networks using Ethernet VPN (EVPN) as + Network Virtualization Overlay networks using Ethernet VPN (EVPN) as their control plane may use Ingress Replication or PIM (Protocol Independent Multicast)-based trees to convey the overlay Broadcast, Unknown unicast and Multicast (BUM) traffic. PIM provides an @@ -105,7 +105,7 @@ Ethernet Virtual Private Networks (EVPN) may be used as the control plane for a Network Virtualization Overlay network [RFC8365]. - Network Virtualization Edge (NVE) and Provider Edges (PE) devices + Network Virtualization Edge (NVE) and Provider Edge (PE) devices @@ -268,7 +268,7 @@ Pruned-Flood-Lists is a method for the ingress NVE/PE to prune or remove certain destination NVEs/PEs from a flood-list, depending on the interest of those NVEs/PEs in receiving Broadcast, Multicast or - Unknown unicast. As specfied in [RFC8365], an NVE/PE builds a flood- + Unknown unicast. As specified in [RFC8365], an NVE/PE builds a flood- list for BUM traffic based on the Next-Hops of the received EVPN Inclusive Multicast Ethernet Tag routes for the Broadcast Domain. While [RFC8365] states that the flood-list is used for all BUM @@ -421,6 +421,10 @@ - Replicator-AR route: an EVPN Inclusive Multicast Ethernet Tag route that is advertised by an AR-REPLICATOR to signal its capabilities. + +I had noted earlier that a reference to Section 8 would have been useful +in the above, I suppose it still might (although I'm OK with there not +being one). [jorge] I *guess* you meant section 4? That’s what I added in version 12. - TOR: Top Of Rack switch. @@ -643,7 +647,7 @@ AR-IP, but will forward in Ingress Replication forwarding mode if the outer IP DA matches its IR-IP. - In addition, this document also uses the Leaf Auto-Discovery route + In addition, this document also uses the Leaf Auto-Discovery (Leaf A-D) route defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the selective AR mode is used. An AR-LEAF MAY send a Leaf A-D route in response to reception of a Replicator-AR route whose L flag is set. @@ -694,7 +698,7 @@ Replication type) field in the PMSI Tunnel Attribute (Flags field) of the routes, and MUST signal the corresponding type (AR-REPLICATOR or AR-LEAF type) according to its administrative choice. An NVE/PE - following this specification is not expected to set the AR type field + following this specification is not expected to set the Assisted-Replication Type field to decimal 3 (which is a RESERVED value). If a route with the AR type field set to decimal 3 is received by an AR-REPLICATOR or AR- LEAF, the router will process the route as a Regular-IR route @@ -866,6 +870,23 @@ o If the encapsulation is MPLSoGRE or MPLSoUDP and the received BD label (or label that the AR-REPLICATOR advertised in the Replicator-AR route) is not the bottom of the stack, the AR- + +I had previously flagged "BD label" as needing a definition or reference. +I'm not sure if the thing in parentheses answers that request, or not? +Is the BD label *defined as* "the label that the AR-REPLICATOR advertised +in the Replicator-AR route"? If so, remove "or" and use "the" or "defined +as the". + +On the other hand, maybe you are saying there are two choices: +the BD label, *or* the other thing. In that case, (a) we still need a +definition of "BD label", (b) a bit of a rewrite is needed, as in +"... If the encapsulation is MPLSoGRE or MPLSoUDP and neither the +BD label nor the label that the AR-REPLICATOR advertised in the +Replicator-AR route is the bottom of the stack..." + +The same comment applies later in the document where you use "BD label" +again. [jorge] I added the term “BD label” in the terminology section and fixed the ‘or’ in the references. In those sentences, it refers to the label advertised by the AR-REPLICATOR in the Replicator-AR route. It was a good point, hopefully the changes in version 12 clarifies this. + REPLICATOR MUST copy the all the labels below the BD label and propagate them when forwarding the packet to the egress overlay tunnels. @@ -955,7 +976,7 @@ BD. This selection is a local decision and it does not have - to match other AR-LEAF's selections within the same BD. + to match other AR-LEAFs' selections within the same BD. o An AR-LEAF MAY select more than one AR-REPLICATOR and do either per-flow or per-BD load balancing. @@ -1105,12 +1126,12 @@ different. The Selective AR procedures create multiple AR-LEAF-sets in the EVPN - BD, and builds single-hop trees among AR-LEAFs of the same set (AR- + BD, and build single-hop trees among AR-LEAFs of the same set (AR- LEAF->AR-REPLICATOR->AR-LEAF), and two-hop trees among AR-LEAFs of different sets (AR-LEAF->AR-REPLICATOR->AR-REPLICATOR->AR-LEAF). Compared to the Selective solution, the Non-Selective AR method assumes that all the AR-LEAFs of the BD are in the same set and - always create two-hop trees among AR-LEAFs. While the Selective + always creates two-hop trees among AR-LEAFs. While the Selective solution is more efficient than the Non-Selective solution in multi- stage IP fabrics, the trade-off is additional signaling and an additional outer source IP address lookup. @@ -1273,6 +1294,8 @@ REPLICATOR advertised in the Replicator-AR route) is not the bottom of the stack, the AR-REPLICATOR MUST copy the rest of the labels when forwarding them to the egress overlay tunnels. + +See previous comment about "BD label". 6.2. Selective AR-LEAF Procedures @@ -1650,7 +1673,7 @@ traffic. Unicast traffic is not affected by Assisted-Replication (although Unknown unicast traffic is affected by the Pruned-Flood- Lists procedures). The forwarding of Broadcast and Multicast (BM) - traffic is modified; and BM traffic from the AR-LEAF nodes will be + traffic is modified, and BM traffic from the AR-LEAF nodes will be attracted by the existence of AR-REPLICATORs in the BD. An AR-LEAF will forward BM traffic to its selected AR-REPLICATOR, therefore an attack on the AR-REPLICATOR could impact the delivery of the BM
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
