Subject: Re: [bess] John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT)

From: John Scudder <[email-masked]>
Date: Fri, 7 Jan 2022 19:08:12 +0000

Hi Jorge and all,

On Nov 17, 2021, at 4:12 AM, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>> 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.

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).

    -  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.
+
          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

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Tue, 25 Jan 2022 13:01:10 +0000

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 <[email-masked]>
Date: Friday, January 7, 2022 at 11:09 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT)
Hi Jorge and all,

Hi John,

Thanks again.

Thanks,
Jorge

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

 Abstract

@@ -268,7 +268,7 @@
[jorge] I *guess* you meant section 4? That’s what I added in version 12.

@@ -643,7 +647,7 @@

[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.

@@ -1650,7 +1673,7 @@

---

From: John Scudder <[email-masked]>
Date: Tue, 25 Jan 2022 16:31:45 +0000

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) <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Sorry for the delay.

Thank you John.
Jorge

From: John Scudder <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 7, 2022 at 11:09 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT)
Hi Jorge and all,

Hi John,

Thanks again.

Thanks,
Jorge

Regards,

—John

 Abstract

@@ -268,7 +268,7 @@

@@ -643,7 +647,7 @@

@@ -1650,7 +1673,7 @@

---

From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <[email-masked]>
Date: Tue, 25 Jan 2022 16:34:05 +0000

Thank you John.
Jorge

From: John Scudder <[email-masked]>
Date: Tuesday, January 25, 2022 at 8:32 AM
To: Rabadan, Jorge (Nokia - US/Sunnyvale) <[email-masked]>
Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Bocci, Matthew (Nokia - GB) <[email-masked]>
Subject: Re: John Scudder's Discuss on draft-ietf-bess-evpn-optimized-ir-09: (with DISCUSS and COMMENT)
Thanks, Jorge.

Regards,

—John

Hi John,

Sorry for the delay.

Thank you John.
Jorge

Hi John,

Thanks again.

Thanks,
Jorge

Regards,

—John

 Abstract

@@ -268,7 +268,7 @@

@@ -643,7 +647,7 @@

@@ -1650,7 +1673,7 @@