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

["Rabadan, Jorge (Nokia - US/Sunnyvale)" <[e-mail]>]

Thank you John.
Jorge

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