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

[Gyan Mishra <[e-mail]>]

Hi Jorge,

On Fri, Oct 8, 2021 at 11:02 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[e-mail]> wrote:

> 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.***
>
>  Gyan> Excellent
>
> 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.
>
> Gyan> Understood.
>
> 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.
>
>  Gyan> Perfect!
>
> 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.
>
>  Gyan>  Very good.  As I am interested in AR use with MPLS I will review
> that draft as well.
>
    I am all set.  Thank you!

Kind Regards

Gyan

> 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]> 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]>
> *Date: *Saturday, October 2, 2021 at 8:09 PM
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [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://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*