Re: [bess] Genart last call review of draft-ietf-bess-evpn-optimized-ir-09

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

Hi Gyan,

Thanks.

1) About MPLS being out of scope:
I added the following text in the introduction – while AR is for IP tunnels only, PFL can be used for MPLS too. Hope it helps:

This document describes a solution that makes use of two IR
   optimizations:

   1.  Assisted-Replication (AR)

   2.  Pruned-Flood-Lists (PFL)

   Both optimizations may be used together or independently so that the
   performance and efficiency of the network to transport multicast can
   be improved.  Both solutions require some extensions to the BGP
   attributes used in [RFC7432], and they are described in Section 4.
   **The AR solution described in this document is focused on NVO networks
   (hence it uses IP tunnels) and MPLS transport networks are out of
   scope.  The PFL solution MAY be used in NVO and MPLS transport
   networks.**

2) About adding RFC6513/6514/7117 as informative references:
- RFC6514 is already added as reference due to the L flag
- About the others, I see your point, however I still think it would be confusing to add references to 7117 and 6513: IR is defined in RFC7432/8365. This document is an extension of those two, so if we refer to RFC6513/7117 the reader might be thinking we are doing something different than what RFC7432/8365 say. So I would prefer not to add them.

3) About the IR-IP and AR-IP in the terminology section, I extended the text, hope it helps:

OLD:
   -  AR-IP: IP address owned by the AR-REPLICATOR and used to
      differentiate the ingress traffic that must follow the AR
      procedures.

   -  IR-IP: IP address used for Ingress Replication as in [RFC7432].

NEW:
   -  AR-IP: IP address owned by the AR-REPLICATOR and used to
      differentiate the ingress traffic that must follow the AR
      procedures.  The AR-IP is also used in the Tunnel Identifier and
      Next-Hop fields of the Replicator-AR route.

   -  IR-IP: local IP address of an NVE/PE that is used for the Ingress
      Replication signaling and procedures in [RFC7432].  Encapsulated
      ingress traffic with outer destination IP matching the IR-IP will
      follow the Ingress Replication procedures and not the AR
      procedures.  The IR-IP is also used in the Tunnel Identifier and
      Next-hop fields of the Regular-IR route.

3) about being specific with the type, as you requested, I made this change:

OLD:
   Each AR-enabled node MUST understand and process the AR type field in
   the PTA (Flags field) of the routes, and MUST signal the
   corresponding type (1 or 2) according to its
   administrative choice.

NEW:
   Each AR-enabled node MUST understand and process the AR type field in
   the PTA (Flags field) of the routes, and MUST signal the
   corresponding type (AR-REPLICATOR or AR-LEAF type) according to its
   administrative choice.

4) finally about this:
Do you plan to have a future draft that  adds this EVPN IR optimization to MPLS underlay?

As discussed, I clarified that PFL MAY be used for MPLS underlay. As for AR, as already mentioned, the agreement with the authors of draft-ietf-bess-evpn-virtual-hub-00<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00> is that the virtual-hub draft addresses AR for MPLS.

Thank you.
Jorge


From: Gyan Mishra <[e-mail]>
Date: Thursday, October 7, 2021 at 7:58 PM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Genart last call review of draft-ietf-bess-evpn-optimized-ir-09
Hi Jose

You are most welcome!

The overall main point I wanted to make is as follows:

As RFC 7432 BGP MPLS EVPN, and RFC 8365 NVO were designed to support both IP and MPLS underlay.  However, for IP underlay scenario both Core or DC with NVO3 you don’t have PTA PMSI Tunnel encapsulation attribute for all tunnel types except IR as all other PTA tunnels type are MPLS based.   Also EVPN per RFC 7432 supports all PTAs as it supports both IP and MPLS underlay, all the PTAs defined in RFC 6514 are supported. Also even though EVPN per RFC 7432 only supports only inclusive trees prior to this draft and BUM procedures update draft and proxy draft it does still support all PTAs defined in RFC 6514.  Since RFC 7432 supports MPLS underlay and all PTA types my recommendation is to explicitly state that MPLS underlay is not supported and out of scope for this draft as it’s not clear to the reader.

It maybe worthwhile to mention that although MPLS is out of scope for this draft that this drafts IR optimization could work for MPLS underlay.

I agree that RFC 7432 does reference RFC 6514 in section 11.2 so RFC 6514 does not need to mentioned as normative.  However since EVPN does used MVPN style procedures and route types concept, separation of control and from data plane on RR not just for multicast tree instantiation my recommendation is to add both RFC 6513 and RFC 6514 as informative references.

As far as the IR-IP and AR-IP in terminology section I understand the the additional process is defined in verbiage so need to clear up in the terminology section, however the additional behavior is setting of the next hop is to originator router IP address is defined in RFC 6514 and is standard MVPN instantiation of PTA tunnel.  I don’t think you need to specify that the next hop is being set as that is standard processing procedure for PTA tunnels per RFC 6514, but only if you reference RFC 6514 section 5 IR, as at least informative, however if you do decide to keep the text I would change the SHOULD to a MUST.

Basically when the PTA tunnel type IR is instantiated for X-PMSI P-TREE the tunnel has endpoints which is the originator IP is the tunnel identifier and other end of the tunnel egress leaf PE PMSI route sets next hop to the IR parent node root tunnel identifier.


         Originating Router's IP Address MUST be set to an IP address of

         the PE that should be common to all the EVIs on the PE (usually

         this is the PE's loopback address).  The Tunnel Identifier and

         Next-Hop SHOULD be set to the same IP address as the

         Originating Router's IP address when the NVE/PE originates the

         route.  The Next-Hop address is referred to as the AR-IP and

         SHOULD be different than the IR-IP for a given PE/NVE.

RFC 6514 section 5:


   When the Tunnel Type is set to Ingress Replication, the Tunnel

   Identifier carries the unicast tunnel endpoint IP address of the

   local PE that is to be this PE's receiving endpoint address for the

   tunnel.


Instead of  IR optimization using AR-Route / Leaf-AD could you have used SMET RT-6 introduced in the BUM procedures update.

Most all of the RT updates that went into BUM procedures draft came from RFC 7117 as stated in the BUM procedures drat.  Most importantly the optimization of building selective trees used by this draft are introduced in BUM procedures draft, basically the idea replicated from RFC 7117 S-PMSI RT-11 and Leaf-AD RT-11.  My thoughts as that being the case and IR optimization utilizes Leaf-AD it would be a good Idea to add informative references to RFC 7117.

Another reason why RFC 6514 should be added as normative reference is that in Section 4 middle of page 9 below verbiage is basically the standard process for Leaf-AD in response to S-PMSI / Inter-AS I-PMSI route with L bit set.


      o  The AR-LEAF constructs an IP-address-specific route-target as

         indicated in [I-D.ietf-bess-evpn-bum-procedure-updates<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-optimized-ir-09#ref-I-D.ietf-bess-evpn-bum-procedure-updates>], by

         placing the IP address carried in the Next-Hop field of the

         received Replicator-AR route in the Global Administrator field

         of the Community, with the Local Administrator field of this

         Community set to 0.  Note that the same IP-address-specific

         import route-target is auto-configured by the AR-REPLICATOR

         that sent the Replicator-AR, in order to control the acceptance

         of the Leaf A-D routes.



BUM procedures update does not describethis but it’s part of standard MVPN procedures RFC 6514 below:



9.2.3.4.1<https://datatracker.ietf.org/doc/html/rfc6514#section-9.2.3.4.1>.  Originating Leaf A-D Route into IBGP



   If the Leaf Information Required flag in the PMSI Tunnel attribute of

   the received Inter-AS I-PMSI A-D route is set to 1, then the PE/ASBR

   MUST originate a new Leaf A-D route as follows.



   + If the received Inter-AS I-PMSI A-D route carries the PMSI Tunnel

      attribute with the Tunnel Type set to Ingress Replication, then

      the Leaf A-D route MUST carry the PMSI Tunnel attribute with the

      Tunnel Type set to Ingress Replication.  The Tunnel Identifier

      MUST carry a routable address of the PE/ASBR.  The PMSI Tunnel

      attribute MUST carry a downstream-assigned MPLS label that is used

      to demultiplex the MVPN traffic received over a unicast tunnel by

      the PE/ASBR.



    + The PE/ASBR constructs an IP-based Route Target Extended Community

      by placing the IP address carried in the Next Hop of the received

      Inter-AS I-PMSI A-D route in the Global Administrator field of the

      Community, with the Local Administrator field of this Community

      set to 0 and setting the Extended Communities attribute of the

      Leaf A-D route to that Community.



Do you plan to have a future draft that  adds this EVPN IR optimization to MPLS underlay?

Responses in-line

Kind Regards

Gyan

On Wed, Oct 6, 2021 at 8:58 AM Rabadan, Jorge (Nokia - US/Mountain View) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Gyan,

Thank you very much for review the document!
I’m adding comments along your comments with [jorge].

Please check them out.

Thanks again,
Jorge

From: Gyan Mishra via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Saturday, October 2, 2021 at 8:09 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [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]>>
Subject: Genart last call review of draft-ietf-bess-evpn-optimized-ir-09
Reviewer: Gyan Mishra
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-optimized-ir-??
Reviewer: Gyan Mishra
Review Date: 2021-10-02
IETF LC End Date: 2021-09-07
IESG Telechat date: Not scheduled for a telechat

Summary:
I am the GEN-ART reviewer for this draft and am reviewing the draft as a BESS
WG member familiar with the EVPN technology and issues that exist with IR and
understand the need for the IR optimized solution for BUM replication.   This
draft clearly defines the problem to be solved with IR BUM replication & the
proposed EVPN Optimized IR Solution which is technically sound.  My comments,
considerations & recommendations are related re-writing of some of the
technical verbiage to help improve the draft. The draft is well written &
clearly describes the problem with EVPN IR PTA and how the Optimized IR
solution with AR replication RT-11 can be used to provide an optimized
Selective P-Tree so all PEs do not have to receive the BUM as exists today with
RT-3 I-PMSI. This draft provides a EVPN procedure optimization for IR PTA R-3
X-PMSI that utilizes a new RT-11 Leaf A-D  that was introduced in Jeffrey
Zhang’s EVPN BUM Procedure update “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” that utilizes the RFC 6513
Leaf-AD route to create a new Selective tree Leaf A-D Route for optimized EVPN
BUM procedures for inter-as segmentation for any PTA P-Tree being instantiated
including IR.
  Leaf Auto-Discovery (A-D) routes [RFC6513]: For explicit leaf
  tracking purpose.

Leaf A-D concept from RFC 6514 Leaf A-D route for Multicast in  VPLS RFC 7117
Section 8.3 bottom of page 33 &  optimized selective & inclusive P-Tree X-PMSI
tunnels with or without inter-as segmentation and “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” P-Tree Multicast both
specifications uses RFC 7524 Section 4 Inter-Area P2MP Segmented Next hop
extended community  (S-NH-EC) utilized for tunnel segmentation for seamless
MPLS MVPN Multicast setting of “Leaf information required” L  flag in PTA now
used in EVPN BUM procedures updates in draft “draft
draft-ietf-bess-evpn-bum-procedure-updates-10” Section 6.3 and now also used in
EVPN IR Optimizations draft for Assisted Replication function  in RT-11
(S-NH-EC) with caveat that S-NH-EC is not used is changed from RFC 7524 which
should be reflected in the verbiage.

RFC 7524 S-NH-EC Section 4
4.  Inter-Area P2MP Segmented Next-Hop Extended Community

   This document defines a new Transitive IPv4-Address-Specific Extended
   Community Sub-Type: "Inter-Area P2MP Next-Hop".  This document also
   defines a new BGP Transitive IPv6-Address-Specific Extended Community
   Sub-Type: "Inter-Area P2MP Next-Hop".

   A PE, an ABR, or an ASBR constructs the Inter-Area P2MP Segmented
   Next-Hop Extended Community as follows:

   -  The Global Administrator field MUST be set to an IP address of the
      PE, ABR, or ASBR that originates or advertises the route carrying
      the P2MP Next-Hop Extended Community.  For example this address
      may be the loopback address or the PE, ABR, or ASBR that
      advertises the route.

   -  The Local Administrator field MUST be set to 0.

      If the Global Administrator field is an IPv4 address, the
      IPv4-Address-Specific Extended Community is used; if the Global
      Administrator field is an IPv6 address, the IPv6-Address-Specific
      Extended Community is used.

      The detailed usage of these Extended Communities is described in
      the following sections.

Excerpt from RFC 7524 Section 6.3 also verbiage used in the BUM procedure
update Section 6.3 as well as this EVPN IR optimization draft Section 4 page 9:
6.3.  Use of S-NH-EC

   [RFC7524] specifies the use of S-NH-EC because it does not allow ABRs
   to change the BGP next hop when they re-advertise I/S-PMSI A-D routes
   to downstream areas.  That is only to be consistent with the MVPN
   Inter-AS I-PMSI A-D routes, whose next hop must not be changed when
   they're re-advertised by the segmenting ABRs for reasons specific to
   MVPN.  For EVPN, it is perfectly fine to change the next hop when
   RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S-
   NH-EC.  As a result, this document specifies that RBRs change the BGP
   next hop when they re-advertise I/S-PMSI A-D routes and do not use S-
   NH-EC.  If a downstream PE/RBR needs to originate Leaf A-D routes, it
   constructs an IP-based Route Target Extended Community by placing the
   IP address carried in the Next Hop of the received I/S-PMSI A-D route
   in the Global Administrator field of the Community, with the Local
   Administrator field of this Community set to 0 and setting the
   Extended Communities attribute of the Leaf A-D route to that
   Community.

RFC 7117 Excerpt Section 8.3 bottom:
       The PE constructs an IP-address-specific RT by placing the IP
       address carried in the Next Hop field of the received S-PMSI A-D
       route in the Global Administrator field of the Community, with
       the Local Administrator field of this Community set to 0 and
       setting the Extended Communities attribute of the leaf A-D route
       to that Community.

This draft EVPN IR Optimization Section 4 page 9
The AR-LEAF constructs an IP-address-specific route-target as
         indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by
         placing the IP address carried in the Next-Hop field of the
         received Replicator-AR route in the Global Administrator field
         of the Community, with the Local Administrator field of this
         Community set to 0.  Note that the same IP-address-specific
         import route-target is auto-configured by the AR-REPLICATOR
         that sent the Replicator-AR, in order to control the acceptance
         of the Leaf A-D routes.

RFC 6514 Leaf A-D route is being used for EVPN procedures  RT-11 to build the
selective tree optimization using a new Assisted Replication (AR) procedure
which is the EVPN IR optimization in this draft.

The confusing part about this draft is that it mentions NVO3 & MPLS PTA.  In
general, NVO3 overlay encapsulations are used in Data Centers with typically IP
based underlay, however MPLS EVPN procedures RFC 7432 applies to both DC or
Core any underlay IP, MPLS, SR underlay.  This draft as its written applies to
an NVO3 overlay IR procedure optimization utilized in a Data Centers, however
the Data Center underlay as well as Core can be MPLS or IP based and can both
have an NVO3 overlay, however the Data Center environment is generally where
NVO3 VTEP termination tunnel endpoints reside and the core carries the EVPN
control plane inter-DC.   RFC 7432 MPLS / IP EVPN supports both IP & MPLS
underlay with IP underlay supporting IR PTA only and MPLS underlay supporting
all PTAs for RT-3 I-PMSI inclusive tree.  Here are a few scenario for the
authors to think about and where the EVPN IR replication optimization solution
could be utilized.  The point I would like to make here is that for BUM the use
of Multicast P2MP mLDP or RSVP-TE PTA is always the most preferred method to
handle BUM for both Core or DC scenario and only certain scenario’s that exist
where multicast would not be preferred.  As the NVO3 & MPLS can be used in both
DC or Core scenario, I will mention both DC & Core scenario, as both pertains
to this draft.   If MPLS is used in the DC or Core then the DC or Core could be
“PIM” free & “BGP” free in the underlay and mLPD or RSVP-TE PTA options could
be utilized as the optimal BUM solution.  If MPLS is used in the DC or Core
then the DC or Core could be “BGP” free but PIM is enabled in the core for PIM
Rosen MDT RFC 6037.  In the above use cases the IR optimization would not
optimal or preferred solution.  Only if IP Is used in the DC or Core in which
case MVPN PTA options are not possible as MVPN is only utilized with MPLS
underlay & “PIM” is not desired in the underlay then this IR optimization could
be utilized.   However, in the use case where underlay is IP only and not MPLS
& “PIM” is not desired then this IR optimization would be the most desired
solution for BUM with the caveat in this case that as MVPN procedures RFC 6513
& 6514 is used with MPLS underlay for PTA in this case the only viable PTA
would be IR as all the other PTA have MPLS underlay dependency.  So in summary
if MPLS exists then there are a lot of viable X-PMSI PTA options for both DC &
Core for EVPN NVO3 BUM and IR would not be the desired, and only the unique
case for IP underlay when “PIM” is not desired. I believe IR optimization AR
replication solution can be used for MPLS underlay as well as there could be a
use case where even though other PTAs X-PMSI are available it is desired to use
IR as PTA’s that use MPLS based multicast is not desired and in those cases the
IR optimization could be for both DC or Core & could apply to Core “Non NVO3”
use case of EVPN PE-CE AC MLAG All Active Multi-home. This solution breaks up
the BUM 3 tuple “Broadcast, Unknown Unicast, Multicast” into BM
“Broadcast/Multicast” & keeps Unknown Unicast separated out treated the same as
known unicast. As MPLS EVPN has a ubiquitous framework & thus ubiquitous use
cases and can be used for DC or Core and any underlay IP, MPLS or SR where the
two primary use cases for EVPN are NVO3 encapsulation overlay for DC
multi-tenant environments and NG L2 VPN PE-CE L2 AC advancement addressing
VPLS/H-VPLS gaps that existed to NG MPLS L2 VPN “EVPN” E-LINE, E-LAN,E-TREE,
this IR optimization draft as well should apply to any EVPN use case and not
limited to NVO3. BUM & why to separate out BUM 3-tuple (Broadcast, Unknown
Unicast, Multicast) separate out Unknown Unicast BUM handling from Broadcast &
Multicast “BM” traffic.
[jorge] about this:
“I believe IR optimization AR
replication solution can be used for MPLS underlay as well as there could be a
use case where even though other PTAs X-PMSI are available it is desired to use
IR as PTA’s that use MPLS based multicast is not desired and in those cases the
IR optimization could be for both DC or Core & could apply to Core “Non NVO3””
Gyan> Agreed

The document is focused on NVO solutions, that is, IP-tunnels, because the AR-REPLICATOR relies on a lookup on the IP tunnel outer IPs. Here NVO assumes the same as in RFC8365, which is the reference for EVPN as a control plane for IP tunnels. The terminology in this document follows RFC8365, however let us know if something needs to be clarified. When there is an MPLS underlay, an assisted replication solution is possible based on other procedures that are out of scope, e.g., draft-ietf-bess-evpn-virtual-hub-00<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-virtual-hub-00> . We can state more clearly that MPLS underlay is out of scope if you think it is not clear?


With regards to the BUM Broadcast / Unkown Unicast -  With Proxy ARP/Proxy ND
what occurs is when the broadcast occurs as an ARP All Fs broadcast, the first
ARP packet goes out and the Type 2 change from unknown mac / ip to Mac when arp
request is sent and then when reply is received the MAC/IP state is created.
After that point no further ARPs are sent for the device.  Most implementations
have a ARP/ND refresh so to keep the MAC/IP state current and purge the old
entries save on MAC VRF URIB state tradeoff so there is constant ARP and is
does not necessarily stop even with Proxy ARP.  Trade off is maintain the
larger MAC VRF if the ARP/ND refresh did not occur which is worse that you
don’t want to hit the ceiling on the MAC VRF which is worse.  So the draft
states that Broadcast is greatly reduced by Proxy ARP / Proxy ND capability &
Unknown Unicast is greatly reduced by in virtualized NVO3 networks where MAC/IP
is learned in the control plane.  Even with Proxy ARP / ND ARP as stated above
the 1st ARP packet is sent as flood all FFs until the control plane MAC
learning generates the Type 2 MAC-IP route, however since most implementations
track the MAC-IP control plane state with refresh timer to age out and purge
old entries the all FF’s ARP broadcast ends up being sent more often then just
once due to the refresh timers to purge the MAC-IP VRF.  Unknown unicast is a
situation where the switch does not have the MAC address in its CAM table or in
the EVPN scenario the MAC/IP does not exist in leaf within the fabric.  In a L2
switch environment the Unknown unicast “out of sync” of Bridge tables can occur
when first hop routing protocol is salt/peppered even/odd such that only the
Active Router has the MAC and the Standby router does not.  With EVPN All
Active Multi-home MHD/MHN MLAG scenario of host endpoint connections both leafs
are active so there is never an out of sync situation where one leaf has the
MAC and the other leaf does not.  Also EVPN backup path aliasing uniform load
balancing over MLAG & local bias may take care of the Unknown Unicast making it
nill or very rare in a EVPN NVO3 environment.  BUM Broadcast ARP/ND traffic
would definitely exist even with Proxy ARP/ Proxy ND and it can be quite
substantial due to refresh/purge timers.

Is the reason for treating the Unknown Unicast differently broken out from “BM”
because none exists in a NVO3 environment?
[jorge] BM and unknown (U) have separate flags in the Pruned-Flood-List flags, indeed. Also BM and U are handled differently since we want Unknown and known to follow the same path to avoid reordering. As for the PFL flags, the thought was that BM are both multipoint traffic always and the way to handle flooding for both B and M (without snooping mcast protocols) is similar. Unknown traffic is handled differently, and flooding can be optimized in a typical use-case where we know some compute based NVEs are not interested in receiving unknown traffic, since they always advertise the local MACs in advance.

Gyan> Understood
With regards to EVPN IR optimization
for BUM traffic as this draft addresses BUM optimization when using IR, as
draft draft-ietf-bess-evpn-igmp-mld-proxy defines a new SMET A-D RT-6 route for
IR optimization for BUM which is equivalent to this drafts leaf-ad route but
unsolicited and untargeted.  This draft must mention normatively in the draft,
draft-ietf-bess-evpn-igmp-mld-proxy as an alternative solution for BUM IR
optimization and why this solution should be utilized for BUM IR optimization
over the SMET RT-6 style optimization.  Also how is this drafts RT-11 selective
trees AR replications solution interoperate with draft
draft-ietf-bess-evpn-igmp-mld-proxy SMET route.  Is that possible or do you
have to implement one or the other.
[jorge] This document is mostly about the Assisted Replication definition as a new Tree type (besides the PFL flags, which are independent). AR can be used for BUM, as explained in the document, but it can also be used for multicast when igmp/mld proxy is enabled in the EVPN BDs, or even in the case of Optimized Inter-Subnet Multicast (OISM) forwarding – draft-ietf-bess-evpn-irb-mcast. The latter clearly explains how AR is used in OISM.
Gyan> Understood. Agreed.  Is it worthwhile to maybe explain how this draft would work in conjunction with the two drafts you mentioned.  I see that OSIM mentions AR operation.  Good.  As this draft pre dates the other two I agree they should mention this draft.

Major issues:

None

Minor issues:

Abstract
OLD TXT
   Network Virtualization Overlay (NVO) networks using EVPN as control
   plane may use Ingress Replication (IR) or PIM (Protocol Independent
   Multicast) based trees to convey the overlay Broadcast, Unknown
   unicast and Multicast (BUM) traffic.  PIM provides an efficient
   solution to avoid sending multiple copies of the same packet over the
   same physical link, however it may not always be deployed in the NVO
   core network.  IR avoids the dependency on PIM in the NVO network
   core.  While IR provides a simple multicast transport, some NVO
   networks with demanding multicast applications require a more
   efficient solution without PIM in the core.  This document describes
   a solution to optimize the efficiency of IR in NVO networks.

NEW TXT
Network Virtualization Overlay (NVO) networks and BGP MPLS Based L2 VPN
E-LINE, E-LAN, E-TREE flavor Ethernet VPN’s in a Service Provider Core and Data
Center Networks using EVPN as control plane may use any available PMSI Tunnel
Attribute (PTA)such as Ingress Replication (IR) RFC 7988,PIM (Protocol
Independent Multicast)MDT SAFI RFC 6037, mLDP P2MP MP2MP RFC 6388 or RSVP-TE
P2MP RFC 4875 based P-Trees to replicate the overlay Broadcast, Unknown unicast
and Multicast (BUM) traffic.  Multicast based PTA tunnel types provides an
efficient solution to avoid sending multiple copies of the same packet over the
same physical link, however in a Data Center all the PTA tunnel types may not
be available with IP-Based underlay and native PIM is not desirable or with
MPLS-Based underlay with “BGP” and “PIM” free core where the operator is
migrating to Segment Routing and is in the process of eliminating LDP and
RSVP-TE P2MP PTA is not desirable.  In these use cases, the only option
available is to use IR.  While IR provides a simple multicast transport, in the
case of Service Provider Core migrating to Segment Routing or Data Center NVO
networks with IP-Based underlay with demanding multicast applications require a
more efficient solution than IR.  This document describes a solution to
optimize the efficiency of IR in a Service Provider Core in transition to
Segment Routing or Data Center NVO network with IP-Based underlay.
[jorge] As explained earlier, the document is really focused on EVPN with NVO tunnels, as per RFC8365. So no Segment Routing MPLS or no RSVP/LDP. And for an NVO solution using EVPN (RFC8365), there is only PIM trees (different flavors of PIM) or IR defined. This document extends the list to AR as well. But I don’t think we should add the MPLS underlay related text in the abstract. Based on this, please let us know if you still think we need to clarify the abstract.
Gyan> Understood.  Agreed as MPLS is out of scope.  I think that needs to be mentioned clearly.

Introduction
OLD TXT
   Ethernet Virtual Private Networks (EVPN) may be used as the control
   plane for a Network Virtualization Overlay (NVO) network.  Network
   Virtualization Edge (NVE) devices and Provider Edges (PEs) that are
   part of the same EVPN Instance (EVI) use Ingress Replication (IR) or
   PIM-based trees to transport the tenant's Broadcast, Unknown unicast
   and Multicast (BUM) traffic.  In NVO networks where PIM-based trees
   cannot be used, IR is the only option.  Examples of these situations
   are NVO networks where the core nodes don't support PIM or the
   network operator does not want to run PIM in the core.

   In some use-cases, the amount of replication for BUM (Broadcat, Unkown
   Unicast, Multicast) traffic is kept under control on the NVEs due to the
   following fairly common assumptions:

   a.  Broadcast is greatly reduced due to the proxy ARP (Address
       Resolution Protocol) and proxy ND (Neighbor Discovery)
       capabilities supported by EVPN on the NVEs.  Some NVEs can even
       provide Dynamic Host Configuration Protocol (DHCP) server
       functions for the attached Tenant Systems (TS) reducing the
       broadcast even further.

   b.  Unknown unicast traffic is greatly reduced in virtualized NVO
       networks where all the MAC and IP addresses are learned in the
       control plane.

   c.  Multicast applications are not used.

   If the above assumptions are true for a given NVO network, then IR
   provides a simple solution for multi-destination traffic.  However,
   the statement c) above is not always true and multicast applications
   are required in many use-cases.

   When the multicast sources are attached to NVEs residing in
   hypervisors or low-performance-replication TORs (Top Of Rack
   switches), the ingress replication of a large amount of multicast
   traffic to a significant number of remote NVEs/PEs can seriously
   degrade the performance of the NVE and impact the application.

NEW TXT
Service Provider Core and Data Center networks may use Ethernet Virtual Private
Networks (EVPN)as the control plane for an Network Virtualization Overlay (NVO)
network with IP-Based Underlay or BGP MPLS Based L2 VPN E-LINE, E-LAN, E-TREE
flavor Ethernet VPN’s Virtualization Edge (NVE) devices and Provider Edges
(PEs) that are part of the same EVPN Instance (EVI)can use Ingress Replication
(IR) or any available MPLS based PTA for P-Tree instantiation to transport the
tenant's Broadcast, Unknown unicast and Multicast (BUM) traffic.  In Service
Provider Core or Data Center NVO networks where MPLS based PTA’s are not
available such as a Service Provider core migrating to Segment Routing where
LDP is being eliminated and RSVP-TE P2MP is not desirable or Data Center
network with IP-Based Underlay and Native PIM is not desirable, IR is the only
option.  Examples of these situations are NVO networks where the core nodes
don't support MPLS based PTA with dependency on mLDP and both Native PIM and
RSVP-TE P2MP LSM is not desirable.

   In some use-cases, the amount of replication for BUM traffic is kept
   under control on the NVEs due to the following fairly common
   assumptions:

   a.  Broadcast is moderately reduced due to the proxy ARP (Address
       Resolution Protocol) and proxy ND (Neighbor Discovery)
       capabilities supported by EVPN on the NVEs with Selective IR
       tunnels optimization defined in draft
       draft-ietf-bess-evpn-igmp-mld-proxy.  Some NVEs can even
       provide Dynamic Host Configuration Protocol (DHCP) server
       functions for the attached Tenant Systems (TS) reducing the
       broadcast even further. During the Proxy ARP/ND process the first ARP
       packet is still send all F’s broadcast resulting in Type 2 change from
       Unknown Mac-IP route to MAC-IP route when ARP/ND request is sent and
       reply is received the MAC VRF MAC-IP state is created.  Proxy ARP/ND
       then suppresses or proxies all ARP/ND sent by the local hosts. However,
       due to ARP/ND refresh state requirements to keep the MAC-IP state
       current and purge the old entries save on MAC VRF URIB state as a
       tradeoff there maybe additional ARP/ND packets sent for each MAC VRF
       MAC-IP entry. The IGMP-MLD proxy Selective IR tunnel optimization draft
       improves the performance of IR using SMET route and maybe used in
       conjunction with this draft. Even though Proxy ARP/ND suppression
       techniques are utilized as the refresh/purge must be implemented to age
       old entries to control the MAC VRF size the broadcast traffic is only
       moderately reduced and thus RFC 7432 EVPN IR for BUM is not a viable
       solution without the IR optimization solution defined in this draft
       and/or draft-ietf-bess-evpn-igmp-mld-proxy.

***Please investigate if both EVPN IR optimizations can be used together and
what are all the caveats and if they cannot be used together and why**  The
main point here that should be mentioned is that Broadcast traffic is reduced
but there is still a considerable amount of broadcast traffic that needs to be
optimized

   b.  Unknown unicast traffic is eliminated in virtualized NVO
       networks due to all the MAC and IP addresses are learned in the
       control plane for All-Active Multi-home LAG scenario and reduced for
       Single-Active Multi-Home EVPN scenario. Unknown unicast is a situation
       where the packet has the IP and MAC, however the switch is missing the
       MAC entry which occurs due to Layer 2 switch BD table synchronization
       becomes unsynchronized due to salt and pepper of first hop router
       redundancy active router VLAN between L2 switches resulting in Unknown
       unicast.  In an EVPN scenario with All-Active-Multi-Home the MAC-IP
       remains synchronized with ESI auto discovery, however with
       Single-Active-Multi-Home the MAC-IP may not be synchronized resulting in
       Unknown unicast. As a result, there is minimal to none Unknown Unicast
       in a NVO network.

   c.  Multicast applications are not used.

   If the above assumptions are true for a given NVO network, then IR
   provides a simple solution for multi-destination traffic.  However,
   the statement c) above is not always true and multicast applications
   are required in many use-cases.

   When the multicast sources are attached to NVEs residing in
   hypervisors or low-performance-replication TORs (Top Of Rack
   switches), the ingress replication of a large amount of multicast
   traffic to a significant number of remote NVEs/PEs can seriously
   degrade the performance of the NVE and impact the application.

In the draft it should be mentioned the reason why BM (Broacast & Multicast)
are treated differently by this solution then Unknown Unicast.   My answer is
that the Unknown Unicast is minimal to none so does not need the optimization.
[jorge] after explaining that MPLS underlay is out of scope, please let us know if it is ok to keep the OLD text. About AR tunnels being used in igmp/mld proxy and OISM, yes, compatibility is perfectly okay, but since this document just defines the AR tree and predates draft-ietf-bess-evpn-igmp-mld-proxy and draft-ietf-bess-evpn-irb-mcast I don’t think this document needs to refer to the other two drafts, but rather the opposite.
Gyan> I am ok with keeping old txt

Terminology section:

OLD TXT
-  Regular-IR: Refers to Regular Ingress Replication, where the
      source NVE/PE sends a copy to each remote NVE/PE part of the BD.

-  IR-IP: IP address used for Ingress Replication as in [RFC7432].

-  AR-IP: IP address owned by the AR-REPLICATOR and used to
      differentiate the ingress traffic that must follow the AR
      procedures.

New TXT
-  Regular-IR: an EVPN RT-3 ( Route Type 3) Regular Ingress Replication, where
the source NVE/PE sends a copy to each remote NVE/PE part of the BD.

-  IR-IP: PTA Tunnel endpoint identifier which carries the unicast tunnel
endpoint (Loopback) IP address of the Non-AR-Replicator local PE used for
Ingress Replication as defined in RFC 6514.
[jorge] The document uses the IR-IP as just an IP address, that can be used in the PTA tunnel identifier but also in the route’s next-hop and originating IP, also the outer IP DA of the packets is compared against this IP. So I don’t think the above is correct. I prefer to keep the current definition and then have the text explaining how to use the IR-IP.
Gyan> please see responses  at beginning of this email.

-  AR-IP: PTA Tunnel endpoint identifier which carries the unicast tunnel
endpoint (loopback) IP address of the AR-REPLICATOR local PE as defined in RFC
6514 and used to differentiate the ingress traffic that must follow the AR
procedures.
[jorge] similar to the IR-IP comment.. AR-IP is an IP address of the replicator, the text later explains how to use it (not only in the PTA).
Gyan> Please see response  at beginning of this email

Updated the reference to what the AR-IP & IR-IP is basically is the PMSI Tunnel
attribute PTA termination endpoint ID, AR-IP for the AR node & IR-IP for Non-AR
node.
[jorge] AR-IP and IR-IP are not limited to the PTA, please see above.
Gyan> Understood

RFC 7432 section 11.2  references RFC 6514 PMSI tunnel attribute must contain
the identity of the tree RFC 7432 Section 11.2 11.2.  P-Tunnel Identification

   In order to identify the P-tunnel used for sending broadcast, unknown
   unicast, or multicast traffic, the Inclusive Multicast Ethernet Tag
   route MUST carry a Provider Multicast Service Interface (PMSI) Tunnel
   attribute as specified in [RFC6514].

   + If the PE that originates the advertisement uses ingress
     replication for the P-tunnel for EVPN, the route MUST include the
     PMSI Tunnel attribute with the Tunnel Type set to Ingress
     Replication and the Tunnel Identifier set to a routable address of
     the PE.

RFC 6514 Section 5
   When the Tunnel Type is set to Ingress Replication, the Tunnel
   Identifier carries the unicast tunnel endpoint IP address of the
   local PE that is to be this PE's receiving endpoint address for the
   tunnel.

Section 3 Solution Requirements

OLD TXT
   a.  It provides an IR optimization for BM (Broadcast and Multicast)
       traffic without the need for PIM, while preserving the packet
       order for unicast applications, i.e., known and unknown unicast
       traffic should follow the same path.  This optimization is
       required in low-performance NVEs.

NEW TXT
   a.  It provides an IR optimization for BM (Broadcast and Multicast)
       traffic without the need for PTA’s with MPLS or PIM based dependencies,
       while preserving the packet order for unicast applications, i.e., known
       and unknown unicast traffic should follow the same path.  This
       optimization is required in low-performance NVEs.
[jorge] similar comment as earlier about MPLS trees, they are out of scope of the document.
Gyan> Understood

How is IR optimization preserving unicast ordering ?
Normal Unicast traffic is not BUM and thus would not use EVPN IR optimization
AR mechanism.
[jorge] the solution uses AR for BM and unknown/known unicast follow regular ingress replication, that’s how they can follow the same path. This is the relevant text, let us know if it requires clarification:
Gyan> I see maybe if you can clarify a bit more how unknown Unicast which is all Fs flooded in L2 environment so unknown and known Unicast flow is completely different and how and why the two have the same treatment.  Is it because their is minimal to none unknown in NVO environment is my guess.
This solution recommends the replication of BM through the
   AR-REPLICATOR node, whereas unknown/known unicast will be delivered
   directly from the source node to the destination node without being
   replicated by any intermediate node.  Unknown unicast SHALL follow
   the same path as known unicast traffic in order to avoid packet
   reordering for unicast applications and simplify the control and data
   plane procedures.


Section 4 – Type3 is being extended to support -optimized IR – new type 3 – so
that is part of capability exchange

4.  EVPN BGP Attributes for optimized-IR

   This solution extends the [RFC7432] Inclusive Multicast Ethernet Tag
   routes and attributes so that an NVE/PE can signal its optimized-IR
   capabilities.

7432 section 7.3
7.3.  Inclusive Multicast Ethernet Tag Route

   An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI
   consists of the following:

               +---------------------------------------+
               |  RD (8 octets)                        |
               +---------------------------------------+
               |  Ethernet Tag ID (4 octets)           |
               +---------------------------------------+
               |  IP Address Length (1 octet)          |
               +---------------------------------------+
               |  Originating Router's IP Address      |
               |          (4 or 16 octets)             |
               +---------------------------------------+

Please reference below with RFC 6514 Section 5

5.  PMSI Tunnel Attribute

   This document defines and uses a new BGP attribute called the
   "P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute".  This
   is an optional transitive BGP attribute.  The format of this
   attribute is defined as follows:

RFC 6514         BGP Encodings and Procedures for MVPNs    February 2012

      +---------------------------------+
      |  Flags (1 octet)                |
      +---------------------------------+
      |  Tunnel Type (1 octets)         |
      +---------------------------------+
      |  MPLS Label (3 octets)          |
      +---------------------------------+
      |  Tunnel Identifier (variable)   |
      +---------------------------------+
[jorge] are you suggesting this document should refer to RFC6514? This document is based on RFC7432 and RFC8365, both of which make use of the PTA in RFC6514, but that should have been already referenced in those… ?
Gyan> See responses at beginning of email

Section 4 top of page 8

As described in the summary section of the review, this section should
reference RFC 7524 Section 4 which is referenced by
“draft-ietf-bess-evpn-bum-procedure-updates” section 6.3 S-NH-EC and also
reference used by RFC 7117 Section 8.3 and in describe that in
“draft-ietf-bess-evpn-bum-procedure-updates” that for EVPN S-NH-EC in the
Leaf-AD routes is not necessary for the response to Replicator-AR route RT-3.
This should be included in the verbiage.
[jorge] hmm… is that necessary given that we already refer to I-D.ietf-bess-evpn-bum-procedure-updates?
Gyan> See responses at beginning of email

I updated some normative language – please check
OLD TXT
   In this document, the above RT-3 and PTA can be used in two different
   modes for the same BD:

   -  Regular-IR route: in this route, Originating Router's IP Address,
      Tunnel Type (0x06), MPLS Label and Tunnel Identifier MUST be used
      as described in [RFC7432] when Ingress Replication is in use.  The
      NVE/PE that advertises the route will set the Next-Hop to an IP
      address that we denominate IR-IP in this document.  When
      advertised by an AR-LEAF node, the Regular-IR route SHOULD be
      advertised with type T= AR-LEAF.

   -  Replicator-AR route: this route is used by the AR-REPLICATOR to
      advertise its AR capabilities, with the fields set as follows:

      o  Originating Router's IP Address MUST be set to an IP address of
         the PE that should be common to all the EVIs on the PE (usually
         this is the PE's loopback address).  The Tunnel Identifier and
         Next-Hop SHOULD be set to the same IP address as the
         Originating Router's IP address when the NVE/PE originates the
         route.  The Next-Hop address is referred to as the AR-IP and
         SHOULD be different than the IR-IP for a given PE/NVE.

      o  Tunnel Type = Assisted-Replication Tunnel.  Section 11 provides
         the allocated type value.

      o  T (AR role type) = 01 (AR-REPLICATOR).

      o  L (Leaf Information Required) = 0 (for non-selective AR) or 1
         (for selective AR).

   In addition, this document also uses the Leaf A-D route (RT-11)
   defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the
   selective AR mode is used.  The Leaf A-D route MAY be used by the AR-
   LEAF in response to a Replicator-AR route (with the L flag set) to
   advertise its desire to receive the BM traffic from a specific AR-
   REPLICATOR.  It is only used for selective AR and its fields are set
   as follows:

      o  Originating Router's IP Address is set to the advertising PE's
         IP address (same IP used by the AR-LEAF in regular-IR routes).
         The Next-Hop address is set to the IR-IP.

      o  Route Key is the "Route Type Specific" NLRI of the Replicator-
         AR route for which this Leaf A-D route is generated.

      o  The AR-LEAF constructs an IP-address-specific route-target as
         indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by
         placing the IP address carried in the Next-Hop field of the
         received Replicator-AR route in the Global Administrator field
         of the Community, with the Local Administrator field of this
         Community set to 0.  Note that the same IP-address-specific
         import route-target is auto-configured by the AR-REPLICATOR
         that sent the Replicator-AR, in order to control the acceptance
         of the Leaf A-D routes.

      o  The Leaf A-D route MUST include the PMSI Tunnel attribute with
         the Tunnel Type set to AR, type set to AR-LEAF and the Tunnel
         Identifier set to the IP of the advertising AR-LEAF.  The PMSI
         Tunnel attribute MUST carry a downstream-assigned MPLS label or
         VNI that is used by the AR-REPLICATOR to send traffic to the
         AR-LEAF.

   Each AR-enabled node MUST understand and process the AR type field in
   the PTA (Flags field) of the routes, and MUST signal the
   corresponding type (1 or 2) according to its administrative choice.

NEW TXT
When the PTA builds PMSI tunnel per RFC 6514 section I called the IR-IP changed
to PTA-ID to make it easier for the reader as the source / destination of the
PMSI tunnel termination endpoints is the PTA PMSI Tunnel Attribute Identifier.
[jorge] I don’t think we should change that since it changes the intended meaning.
Gyan> I am good with OLD TXT.  Please reference comments at beginning of email

**start of the new txt**
[jorge] please check out my comments and let us know what changes you would like to make based on them.

   In this document, the above RT-3 and PTA can be used in two different
   modes for the same BD:

   -  Regular-IR route: This route is the regular RT-3 I-PMSI

      Originating Router's Unicast IP Address called the IR-IP MUST be set to
      the PMSI Tunnel Identifier for the PTA Tunnel Type (0x06) used for IR as
      described in 6514 when Ingress Replication is used.  The NVE/PE that
      advertises the route will set the Next-Hop to the remote tunnel endpoint
      PMSI Tunnel Identifier IR-IP as defined in RFC 6514.  When advertised by
      an AR-LEAF node, the Regular-IR route MUST be advertised with type T=
      AR-LEAF.
[jorge] I don’t agree we should reference RFC6514, since this IR route is the same route defined in RFC7432, and we refer to RFC7432.
Gyan> See comments beginning of email

      o  Tunnel Type = Assisted-Replication Tunnel.  Section 11 provides
         the allocated type value.

      o  T (AR role type) = 10 (AR-LEAF).

      o  L (Leaf Information Required) = 0 (for non-selective AR=0) or
         (for selective AR=1).  Regular-IR route is only used only for Non
         Selective P-Tree.

   -  Replicator-AR route: This route is used by the AR-REPLICATOR to
      advertise its AR capabilities, with the fields set as follows:

      o Originating Router's Unicast IP Address called the AR-IP MUST be set to
      the PMSI Tunnel Identifier for the PTA Tunnel Type(0x06) which is the IP
      address of the PE that should be common to all the EVIs on the PE as
      defined in RFC 6514. The Tunnel Identifier and Next-Hop MUST be set to
      the same IP address as the Originating Router's IP address PTA Tunnel ID
      when the NVE/PE originates the route as described in RFC 6514.  The
      Next-Hop address of the Replicator-AR route as seen on the AR-LEAF is
      referred to as the AR-IP and MUST be unique and cannot be the same as the
      IR-IP for a given PE/NVE.

      o  Tunnel Type = Assisted-Replication Tunnel.  Section 11 provides
         the allocated type value.

      o  T (AR role type) = 01 (AR-REPLICATOR).

      o  L (Leaf Information Required) = 1 (for non-selective AR=0) or
         (for selective AR=1).  Replicator-AR route is only used for  Selective
         P-Tree.

   In addition, this document also uses the Leaf A-D route (RT-11)
   defined in [I-D.ietf-bess-evpn-bum-procedure-updates] in case the
   selective AR mode is used. Draft ietf-bess-evpn-bum-procedure-updates
   updates the EVPN BUM procedures for EVPN Multicast optimized selective trees
   used, introducing three new route types RT-9 Per Region I-PMSI A-D, RT-10
   S-PMSI A/D and RT-11 Leaf A-D utilized for Selective P-Tree PTA inter-as
   segmentation optimizations, and utilizes RFC 7117 concept of selective tree
   optimization procedure to signal leaf-ad route to instantiate inter-as
   P-Tree framework from Intra-AS and Inter-AS VPLS Multicast I/S-PMSI A/D &
   Leaf A-D solution which now is also leveraged by AR replicator for IR
   optimization utilizing RT-11 to build selective tree IR optimization for BUM
   traffic.  Section 6 of bess-evpn-bum-procedure-updates defines the RT-11
   Leaf-AD route selective tree optimization concept from RFC 7117 response to
   I-PMSI route, RFC 7524 Inter-Area P2MP Segmented Next Hop Extended Community
   S-NH-EC which is utilized for Inter-AS P2MP Segmented LSP stitching. RFC
   7524 Section 6 states that it requires the ABRs to keep the next hop
   unchanged for re-advertisement I/S PMSI A-D route which only needs to be
   consistent for MVPN Inter-AS I-PMSI A/D routes whose next hop MUST be
   unchanged. EVPN for inter-as readvertisement of I/S-PMSI A-D route the next
   hop can be changed and so does not need to rely on S-NH-EC.
[jorge] if we have a reference to I-D.ietf-bess-evpn-bum-procedure-updates, I don’t think we need references to RFC7524 or 7117. This documents follows the RT-11 use as defined in I-D.ietf-bess-evpn-bum-procedure-updates, with the specifics described in the document. Besides, as discussed, MPLS underlay is out of scope.
Gyan> I agree we don’t have to reference RFC 7524.  Please see responses beginning of email

   The Leaf A-D route MAY be used by the AR-LEAF in response to a
Replicator-AR route (with the L flag set) to advertise its desire to receive
the BM traffic from a specific AR-REPLICATOR.  It is only used for selective AR
and its fields are set as follows:

      o  Originating Router's IP Address is set to the advertising PE's
         IP address (same IP used by the AR-LEAF in regular-IR routes).
         The Next-Hop address is set to the IR-IP.

      o  Route Key is the "Route Type Specific" NLRI of the Replicator-
         AR route for which this Leaf A-D route is generated.

      o  The AR-LEAF constructs an IP-address-specific route-target as
         indicated in [I-D.ietf-bess-evpn-bum-procedure-updates], by
         placing the IP address carried in the Next-Hop field of the
         received Replicator-AR route in the Global Administrator field
         of the Community, with the Local Administrator field of this
         Community set to 0.  Note that the same IP-address-specific
         import route-target is auto-configured by the AR-REPLICATOR
         that sent the Replicator-AR, in order to control the acceptance
         of the Leaf A-D routes.

      o  The Leaf A-D route MUST include the PMSI Tunnel attribute with
         the Tunnel Type set to AR, type set to AR-LEAF and the Tunnel
         Identifier set to the IP of the advertising AR-LEAF.  The PMSI
         Tunnel attribute MUST carry a downstream-assigned MPLS label or
         VNI that is used by the AR-REPLICATOR to send traffic to the
         AR-LEAF.

   Each AR-enabled node MUST understand and process the AR type field in
   the PTA (Flags field) of the routes, and MUST signal the
   corresponding type (1 or 2) according to its administrative choice.

**There are a few different flags & new flags defined in the PTA  - please be
specific as to the type 1 & 2 flags**
[jorge] sure, we can do that in the next revision.


***Implementation considerations section – important and also details as to how
does the backwards compatibility work*** As RT-3 introduces a mode and RT-11 is
new in this draft what devices need to be upgraded and do all need to be
upgraded to support the solution? ***Implementation section of any vendor
implementations thus far please list** Also mention any issues found with any
implementations also any operators that have deployed the implementation.
[jorge] we can elaborate on this but the RNVE role is actually a non-upgraded node, so backwards compatibility is always present in the document. About implementations, there are two vendors with shipping code for this afaik. There was public interop testing at the EANTC 2020, and a public white paper exists with the details of the interop testing for AR. As this document is in Last Call and seeks publication, I fail to see how including details on interop testing between specific vendors help the document. That information will be outdated as more vendors implement it.. ?
Gyan> Agreed no need for interoperability testing but I think implementations would be good to include.

Nits/editorial comments:

Normative reference should be added per the re-written text provided in the
Minor issues section for the following:

 RFC 7524 Inter-AS P2MP Segmented LSP & RFC 7117 Multicast VPLS and draft
 draft-ietf-bess-evpn-igmp-mld-proxy, RFC 6388 mLDP, RFC 6037 MDT SAFI, RFC
 4875 P2MP TE
[jorge] I discussed, I don’t think we need to refer to the above due to the reasons stated.
Gyan> See comments at beginning of email. I still recommend that RFC 7117 be informative reference.

Informative reference to MVPN procedures RFC 6513 MVPN, RFC 7988 Ingress
Replication, RFC 7348 VXLAN, RFC 8926 GENEVE
[jorge] this document does not use any of the procedures in 6513 or 7988 as discussed. It uses some pieces in RFCs 7432, 8365 and the bum-procedures draft and those are referenced already. Also yes, we can add references to VXLAN and GENEVE, but there is no text in the document that refer to those two, so not sure why we would need references to 7348 or 8926 either?
Gyan> Agreed.  RFC 6514 and RFC 7117 are the only two additional references I would recommend.  As a lot of the basis and changes to EVPN procedures for multicast are from RFC 7117 I think it would be a good idea.

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347