[Gen-art] Genart early review of draft-ietf-bess-evpn-mvpn-seamless-interop-06

[Susan Hares via Datatracker <[e-mail]>]

Reviewer: Susan Hares
Review result: Almost Ready

GEN-ART review

Status: Almost ready

Summary Comment:
==========
Multicast distribution can aid the network, so it is important to have a solid
standard.

Wow! This is an amazing amount of work to combine EVPN and MVPN.
I went between RFC6513, RFC6514, RFC7432, and RFC8542. You caught many of the
issues between the EVPN-MVPN.

I'm hopeful this will help catch a few additional issues.

Sue
============================

Status Early Review: On the right track,
 6 technical issues, editorial issues

===============
Summary of Technical issues:

1. Technical issue #1:  Section 5.3 - refers to section 8 and 9
How you do you restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)?

The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5  Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF,  then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.

Level: IDR chairs indicate this ia well-known issue, and can be noted in
manageability. Issue: No manageability section.

2. VXLAN tunnels under the MVPN network (Section 8.2.2)
Question: How does the network limit the reach of these tunnels to keep the
EVPN and MVPN?

level: Security/managemeability issue

3. Section 8.2.3 - It is unclear what tunnel types that this RFC draft supports.
Does it support VXLAN plus NVGRE (type = 9) , GRE (type = 2), GENEVE or GPE (?).
Are you supporting any other tunnel types for encapsulation?

Level: Clarity of what is supported in draft

4.      Section 9 – MVPN VPN overlay tunnel over DC network is terminated on
IP-VRF (rather than MAC-VRF/BTs).

Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the EVPN-MVPN network? 4a) Does this functioning require MPLS
forwarding of traffic in EVPN--MVPN network? 4b) How is this BUM (Broadcast,
Unknown Unicast, and Multicast traffic) handled in the MVPN/EVPN gateway
    (section 6.3) for three types of tunnels?

5. TTL decrement - the IDR chairs do not think this is a problem.

6. The Security section does not seem to cover all the security and
mangeability issue for the EVPN-MVPN?
==================================================

Full Description of 6 Technical issues
============================

Level: Split-horizon + effective split horizon (RFC8584)

===============
Explanation of technical comments:

General overview:
The procedures in this draft are an extension of RFC6513 and RFC6514.
Figure 1-2 shows two ways to EVPN and MVPN in seamless operation.

Figure 1:
EVPN glued to MVPN via IP VRFs

                        EVPN PE1
                     +------------+
           Src1 +----|(MAC-VRF1)  |                   MVPN PE3
          Rcvr1 +----|      \     |    +---------+   +--------+
                     |    (IP-VRF)|----|         |---|(IP-VRF)|--- Rcvr5
                     |      /     |    |         |   +--------+
           Rcvr2 +---|(MAC-VRF2)  |    |         |
                     +------------+    |         |
                                       |  MPLS/  |
                        EVPN PE2       |  IP     |
                     +------------+    |         |
           Rcvr3 +---|(MAC-VRF1)  |    |         |    MVPN PE4
                     |       \    |    |         |   +--------+
                     |    (IP-VRF)|----|         |---|(IP-VRF)|--- Rcvr6
                     |       /    |    +---------+   +--------+
           Rcvr4 +---|(MAC-VRF3)  |
                     +------------+

                   Figure 1:  MVPN PEs Seamless Interop

Figure 2:
EVPN as MVPN PEs

                       EVPN PE1
                     +------------+
           Src1 +----|(MAC-VRF1)  |
                     |     \      |
          Rcvr1 +----|  +--------+|    +---------+   +--------+
                     |  |MVPN PE1||----|         |---|MVPN PE3|--- Rcvr5
                     |  +--------+|    |         |   +--------+
                     |      /     |    |         |
           Rcvr2 +---|(MAC-VRF2)  |    |         |
                     +------------+    |         |
                                       |  MPLS/  |
                        EVPN PE2       |  IP     |
                     +------------+    |         |
           Rcvr3 +---|(MAC-VRF1)  |    |         |
                     |       \    |    |         |
                     |  +--------+|    |         |   +--------+
                     |  |MVPN PE2||----|         |---|MVPN PE4|--- Rcvr6
                     |  +--------+|    |         |   +--------+
                     |       /    |    +---------+
           Rcvr4 +---|(MAC-VRF3)  |
                     +------------+

                       Figure 2: EVPN PEs as MVPN PEs

MVPN passes NLRI with sub-route types 1-7 (RFC6514, setion 4).
AFI=1, SAFI=5 (MVPN),  AFI=1, SAFI=129 - VPN for MVPN
      + 0 - Reserved
      + 1 - Intra-AS I-PMSI A-D route;
      + 2 - Inter-AS I-PMSI A-D route;
      + 3 - S-PMSI A-D route;
      + 4 - Leaf A-D route;
      + 5 - Source Active A-D route.
      + 6 - Shared Tree Join route;
      + 7 - Source Tree Join route;

PMSI Tunnel attribute with the following tunnel types
      + 0 - No tunnel information present
      + 1 - RSVP-TE P2MP LSP
      + 2 - mLDP P2MP LSP
      + 3 - PIM-SSM Tree
      + 4 - PIM-SM Tree
      + 5 - BIDIR-PIM Tree
      + 6 - Ingress Replication
      + 7 - mLDP MP2MP LSP

PE Distinguisher Labels attribute.

RFC9012 (TEA) - prefers PMSI tunnels if both TEA and PMSI.
Extended Communities: Source AS and VRF-RT Import

EVPN document defines the following Route Types for AFI (RFC7432)
AFI = 25, SAFI: 70
      + 0 - Reserved
      + 1 - Ethernet Auto-Discovery (A-D) route
      + 2 - MAC/IP Advertisement route
      + 3 - Inclusive Multicast Ethernet Tag route
      + 4 - Ethernet Segment route

Extended Communities:
1) ESI Label Extended Community  [0x01]
2) ES-Import Targe Extended Community [0x02]
3) MAC Mobility [0x00]
4) Default Gateway Extended Community [Opague]

====================================================================
Technical issue scope:
Sections 5.3, 5.4, and 5.5 are the key issues in EVPN/MVPN interoperation.

Technical issue #1:  Section 5.3 - refers to section 8 and 9

Problem:

1.      Restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)

The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5  Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF,  then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.

Text + explanation behind the problem.
---------------------------------------
1. Section 5.3 paragraph 1

Text:
/  When an IP multicast source is attached to an EVPN PE, the unicast
   route for that IP multicast source needs to be advertised.

   [Case 1]
   When the source is attached to a Single-Active multi-homed Ethernet
   Segment (ES), then the EVPN DF PE is the PE that advertises a unicast
   route corresponding to the source IP address with VRF Route Import
   extended community which in turn is used as the Route Target for Join
   (S,G) messages sent toward the source PE by the remote PEs.  The EVPN
   PE advertises this unicast route using EVPN route type 2 and IPVPN
   unicast route along with VRF Route Import extended community.  EVPN
   route type 2 is advertised with the Route Targets corresponding to
   both IP-VRF and MAC-VRF/BT; whereas, the IPVPN unicast route is
   advertised with RT corresponding to the IP-VRF.  When unicast routes
   are advertised by MVPN PEs, they are advertised using IPVPN unicast
   route along with VRF Route Import extended community per [RFC6514].
/
   Example: Figure-1, src-1, EVPN DF = EVPN-PE1, PE1 announces
   src1 with VRF Route Import Ext-Com in two announcements
   EVPN (RFC7542, AFI=L2 (25), SAFI = 70), Route-type=2, Rt-Targets IP-VRF +
   MAC-VRF MVPN - IP-VPN (RFC6514/6513, AFI=1, SAFI=5) RT-target = IP VRF

    If single access, EVPN routes are added to
        figure 1 + 2 :  PE1 + PE2 MAC VRF + IP-VPN, PE3 + PE - IPVRN

More text on Case 2a/
   When the source is attached to an All-Active multi-homed ES, then the
   PE that learns the source advertises the unicast route for that
   source using EVPN route type 2 and IPVPN unicast route along with VRF
   Route Import extended community.  EVPN route type 2 is advertised
   with the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
   whereas, the IPVPN unicast route is advertised with RT corresponding
   to the IP-VRF./

 Note: This is the same announcement as above.

 Case 2b (already have) / When the other multi-homing EVPN PEs for that ES
   receive this unicast EVPN route, they import the route and check to
   see if they have learned the route locally for that ES, if they have,
   then they do nothing.
   /

Case 2c  (don't have)
  /But if they have not, then they add the IP and
   MAC addresses to their IP-VRF and MAC-VRF/BT tables respectively with
   the local interface corresponding to that ES as the corresponding
   route adjacency.  Furthermore, these PEs advertise an IPVPN unicast
   route along with VRF Route Import extended community and Route Target
   corresponding to IP-VRF to other remote PEs for that MVPN.
   Therefore, the remote PEs learn the unicast route corresponding to
   the source from all multi-homing PEs associated with that All-Active
   ES even though one of the multi-homing PEs may only have directly
   learned the IP address of the source./

 Result:
   Same as above.
-----------------
Section 8
   Section 8 extends seamless interop procedures to EVPN only fabrics as
   an IRB solution for multicast.  L3VPN provisioning is not needed
   among EVPN PEs.  EVPN PEs only need to advertise unicast routes using
   EVPN route-type 2 or route-type 5 with VRF Route Import extended
   community and don't need to advertise IPVPN routes within EVPN only
   fabric.
----------------
Technical issues for section 8 implementing 5.3

 #1.    Restriction of importing the same type-5 Route to IPVPN VRF from
 multiple PEs (Section 8.1)

Problem: The same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF.

If type-5 Route is sent from different PEs with different VRFs, there is not a
problem. If type-5 Route is sent once from different PE with same VRF,  then
route selection policy should handle the resolution. If type-5 Route is sent
multiple times from different PEs with Same VRF, it can encounter the count to
infinity problem.

Keyur Comment: This problem is well-known issue, and can be noted in
manageability.

===========================================================================
#2.     VXLAN tunnels under the MVPN network (Section 8.2.2)

technology:
a) VXLAN tunnels (tunnel type = 8)
   1. set up tunnels
   2. Announce MVPN routes I-PMSI (Type 1 or 2) or S-PMSI (Type 3) +
     PMSI Tunnel Attribute + RFC9012 Ext-Com (Encapsulation) with tunnel type 8
     (barebones)
         + VRF Route Import Extended Community + SRC Extended Community
   3. Require Gateway EVPN and MVPN with complete termination of L2 and L3

Question: How does the network limit the reach of these tunnels
to keep the EVPN and MVPN?

The initial assumption for a walled garden with EVPN and MVPN
is that the "configuration that limits the reach of EVPN and MVPN."
However, the text indicates there is little EVPN configuration.

Reference text: /

8.2.2.  VxLAN Encapsulation

   In order to signal VXLAN, the corresponding BGP encapsulation
   extended community [RFC9012] SHOULD be appended to the MVPN I-PMSI
   and S-PMSI A-D routes.  The MPLS label in the PMSI Tunnel Attribute
   MUST be the Virtual Network Identifier (VNI) associated with the
   customer MVPN.  The supported PMSI tunnel types with VXLAN
   encapsulation are: PIM-SSM Tree, PIM-SM Tree, BIDIR-PIM Tree, Ingress
   Replication [RFC6514].  Further details are in [RFC8365].

   In this case, a gateway is needed for inter-operation between the
   EVPN MVPN-capable PEs and non-EVPN MVPN PEs.  The gateway should re-
   originate the control plane signaling with the relevant tunnel
   encapsulation on either side.  In the data plane, the gateway
   terminates the tunnels formed on either side and performs the
   relevant stitching/re- encapsulation on data packets.
 /

 ====================================================
# 3. What tunnel types does this EVPN-MVPN draft support besides VXLAN?

Problem: It is unclear what is the exact list of tunnel types that this RFC
draft supports. VXLAN, NVGRE (type = 9) , GRE (type = 2),  or GENEVE (? see
IANA). Are you supporting any other tunnel types for encapsulation? Would you
include SR-Policy with TEA attribute?

Text:/

 8.2.3.  Other Encapsulation

   In order to signal a different tunneling encapsulation such as NVGRE,
   GPE, or GENEVE the corresponding BGP encapsulation extended community
   [RFC9012] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D
   routes.  If the Tunnel Type field in the encapsulation extended-
   community is set to a type that requires Virtual Network Identifier
   (VNI), e.g., VXLAN-GPE or NVGRE [RFC9012], then the MPLS label in the
   PMSI Tunnel Attribute MUST be the VNI associated with the customer
   MVPN.  Same as in the VXLAN case, a gateway is needed for inter-
   operation between the EVPN MVPN-capable PEs and non-EVPN MVPN PEs.
/
================================================

#4. Section 9 – MVPN VPN overlay tunnel over DC network is terminated on IP-VRF
(rather than MAC-VRF/BTs).

Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the entire EVPN-MVPN network and the gateway between EVPN-MVPN?

If so,
   a) Where are you limiting the EVPN-MVPN network to multicast forwarding via
   MPLS? b) What are all the gateway EVPN/MVPN interactions need to be handled?

draft section 5.4/
   Since the network of interest for seamless interoperability between
   EVPN and MVPN PEs is MPLS, the EVPN handling of BUM traffic for MPLS
   network needs to be considered.  EVPN [RFC7432] uses ESI MPLS label
   for split-horizon filtering of Broadcast/Unknown unicast/multicast
   (BUM) traffic from an All-Active multi-homing Ethernet Segment to
   ensure that BUM traffic doesn't get looped back to the same Ethernet
   Segment that it came from.  This split-horizon filtering mechanism
   applies as-is for multicast IRB scenarios because of using the intra-
   ES tunnel among multi-homing PEs.  Since the multicast traffic
   received from a TS source on an All-Active ES by a multi-homing PE is
   bridged to all other multi-homing PEs in that group, the standard
   EVPN split-horizon filtering described in [RFC7432] applies as-is.
/


Problem 2 - How is BUM traffic handled in the MVPN-EVPN gateway?

There are three types of tunnels listed in section 6
1) intra-ES tunnel - for multihoming of ES traffic -
L2 forwarded among PEs on the same subnet.

2) intra-subnet BUM tunnel - for BUM traffic on a
given subnet (section 6.2) set-up by IMET per RFC7432
(IMET defined in section 7.3, procedures in 11, 12, and 16).

3) Inter-Subnet for IP multicast tunnel - L3 traffic using
 a) I-PMSI A-D Route (RFC6514, sections 4.1 + 9.2) for default underlay tunnel
 route, b) S-PMSI A-D Route (RFC6514, sections 4.2 + 9.1) for customer flow
 specific underlay tunnels,

All-Active multi-homing PE uses two tunnels:
1) intra-ES tunnel among multi-homing PEs (L2 + L3)
2) IMET tunnel for the Link-local multicast BUM part of the intra-ES network,
and

Section 6.3, does not seem to discuss how the L3 Multicast

It would be good to discuss scaling in a manageability section
about inclusive overlay trees versus tenant IP-VRF.

Section of text referenced in RFC7432
========================
RFC7432 section 8.3 Text: /
8.3.  Split Horizon

   Consider a CE that is multihomed to two or more PEs on an Ethernet
   segment ES1 operating in All-Active redundancy mode.  If the CE sends
   a broadcast, unknown unicast, or multicast (BUM) packet to one of the
   non-Designated Forwarder (non-DF) PEs, say PE1, then PE1 will forward
   that packet to all or a subset of the other PEs in that EVPN
   instance, including the DF PE for that Ethernet segment.  In this
   case, the DF PE to which the CE is multihomed MUST drop the packet
   and not forward back to the CE.  This filtering is referred to as
   "split-horizon filtering" in this document.

   When a set of PEs are operating in Single-Active redundancy mode, the
   use of this split-horizon filtering mechanism is highly recommended
   because it prevents transient loops at the time of failure or
   recovery that would impact the Ethernet segment -- e.g., when two PEs
   think that both are DFs for that segment before the DF election
   procedure settles down.

   In order to achieve this split-horizon function, every BUM packet
   originating from a non-DF PE is encapsulated with an MPLS label that
   identifies the Ethernet segment of origin (i.e., the segment from
   which the frame entered the EVPN network).  This label is referred to
   as the ESI label and MUST be distributed by all PEs when operating in
   All-Active redundancy mode using a set of Ethernet A-D per ES routes,
   per Section 8.2.1 above.  The ESI label SHOULD be distributed by all
   PEs when operating in Single-Active redundancy mode using a set of
   Ethernet A-D per ES routes.  These routes are imported by the PEs
   connected to the Ethernet segment and also by the PEs that have at
   least one EVPN instance in common with the Ethernet segment in the
   route.  As described in Section 8.1.1, the route MUST carry an ESI
   Label extended community with a valid ESI label.  The disposition PE
   relies on the value of the ESI label to determine whether or not a
   BUM frame is allowed to egress a specific Ethernet segment.
/

=============================
5.      The points out that inter-subnet will be L2-Switched not routed, so TTL
is decremented (see appendix A)

   The IDR Chairs thought the TTL decrement was a positive thing rather than a
   problem.

========================================
6. Technical - lack of in-depth manageability or security section on
combination.

6-a) How the walled garden for the EVPN/MVPN cloud is delineated?
What attacks can occur within the combined walled garden?

6-b) How does the text discuss the security issues regarding
DOS attacks due to overload with multicast technology?

Old text in draft /

14.  Security Considerations

   All the security considerations in [RFC7432], [RFC6513] and [RFC6514]
   apply directly to this document because this document leverages these
   RFCs control planes and their associated procedures.
/

Why I am concerned about these issues
==========================================

#6-a) How the walled garden for the EVPN/MVPN cloud is delineated?
What attacks can occur within the combined walled garden?

Texts from RFC6513, RFC6514, RFC7432 that cause me to wonder:

Text from RFC6513:/
   An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE
   control message that attempts to extend a P-tunnel from one SP's
   domain into another SP's domain.  This is perfectly valid if there is
   an agreement between the SPs to jointly provide an MVPN service.  In
   the absence of such an agreement, however, this could be an
   illegitimate attempt to intercept data packets.  By default, an ASBR
   MUST NOT allow P-tunnels to extend beyond AS boundaries.  However, it
   MUST be possible to configure an ASBR to allow this on a specified
   set of interfaces. /

Review comment:  Is this Extension abnormal for the EVPN-MVPN cloud?
How are tunnels restricted with RFC 9012 TEA?

Text from RFC6514:/

17.  Security Considerations

   The mechanisms described in this document could reuse the existing
   BGP security mechanisms [RFC4271] [RFC4272].  The security model and
   threats specific to Provider Provisioned VPNs, including L3VPNs, are
   discussed in [RFC4111].  [MVPN] discusses additional threats specific
   to the use of multicast in L3VPNs.  There is currently work in
   progress to improve the security of TCP authentication.  When the
   document is finalized as an RFC, the method defined in [RFC5925]
   SHOULD be used where authentication of BGP control packets is needed.

   A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI.

   If BGP is used as a CE-PE routing protocol, then when a PE receives a
   route from a CE, if this route carries the VRF Route Import Extended
   Community, the PE MUST remove this Community from the route before
   turning it into a VPN-IP route.  Routes that a PE advertises to a CE
   MUST NOT carry the VRF Route Import Extended Community.
/

Text from RFC7432 , Section 19 /
   Note that [RFC5925] will not help in keeping MPLS labels private --
   knowing the labels, one can eavesdrop on EVPN traffic.  Such
   eavesdropping additionally requires access to the data path within an
   SP network.  Users of VPN services are expected to take appropriate
   precautions (such as encryption) to protect the data exchanged over
   a VPN.

   One of the requirements for protecting the data plane is that the
   MPLS labels be accepted only from valid interfaces.  For a PE, valid
   interfaces comprise links from other routers in the PE's own AS.  For
   an ASBR, valid interfaces comprise links from other routers in the
   ASBR's own AS, and links from other ASBRs in ASes that have instances
   of a given EVPN.  It is especially important in the case of multi-AS
   EVPN instances that one accept EVPN packets only from valid
   interfaces.

/


#6-b) How does the text discuss the security issues regarding
DOS attacks due to overload with multicast technology?

Text from RFC6513, Sction 13 /

   Many of the procedures in this document cause the SP network to
   create and maintain an amount of state that is proportional to
   customer multicast activity.  If the amount of customer multicast
   activity exceeds expectations, this can potentially cause P and PE
   routers to maintain an unexpectedly large amount of state, which may
   cause control and/or data plane overload.  To protect against this
   situation, an implementation should provide ways for the SP to bound
   the amount of state it devotes to the handling of customer multicast
   activity.

   In particular, an implementation SHOULD provide mechanisms that allow
   an SP to place limitations on the following:

     - total number of (C-*,C-G) and/or (C-S,C-G) states per VRF
     - total number of P-tunnels per VRF used for S-PMSIs
     - total number of P-tunnels traversing a given P router

   A PE implementation MAY also provide mechanisms that allow an SP to
   limit the rate of change of various MVPN-related states on PEs, as
   well as the rate at which MVPN-related control messages may be
   received by a PE from the CEs and/or sent from the PE to other PEs.

   An implementation that provides the procedures specified in Sections
   10.1 or 10.2 MUST provide the capability to impose an upper bound on
   the number of Source Active A-D routes generated and on how
   frequently they may be originated.  This MUST be provided on a per-
   PE, per-MVPN granularity.
/

Text from RFC6514, section 17  /
   It is important to protect the control plane resources within the PE
   to prevent any one VPN from hogging excessive resources.  This is the
   subject of the remainder of the Security Considerations section.

   When C-multicast routing information is exchanged among PEs using
   BGP, an implementation SHOULD provide the ability to rate limit BGP
   messages used for this exchange.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   An implementation SHOULD provide capabilities to impose an upper
   bound on the number of S-PMSI A-D routes, as well as on how
   frequently they may be originated.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   In conjunction with the procedures specified in Section 14, an
   implementation SHOULD provide capabilities to impose an upper bound
   on the number of Source Active A-D routes, as well as on how
   frequently they may be originated.  This SHOULD be provided on a per-
   PE, per-MVPN granularity.

   In conjunction with the procedures specified in Section 13 limiting
   the amount of (C-S,C-G) state would limit the amount of Source Active
   A-D route, as in the context of this section, Source Active A-D
   routes are created in response to Source Tree Join C-multicast
   routes, and Source Tree Join C-multicast routes are created as a
   result of creation of (C-S,C-G) state on PEs.  However, to provide an
   extra level of robustness in the context of these procedures, an
   implementation MAY provide capabilities to impose an upper bound on
   the number of Source Active A-D routes, as well as on how frequently
   they may be originated.  This MAY be provided on a per-PE, per-MVPN
   granularity.

   Section 16.1.1 describes optional procedures for dampening
   withdrawals of C-multicast routes.  It is RECOMMENDED that an
   implementation support such procedures.

   Section 16.1.1 describes optional procedures for dampening
   withdrawals of Leaf A-D routes.  It is RECOMMENDED that an
   implementation support such procedures.
/
Text from RFC7542 Section 19, /
   As mentioned in [RFC4761], there are two aspects to achieving data
   privacy and protecting against denial-of-service attacks in a VPN:
   securing the control plane and protecting the forwarding path.
   Compromise of the control plane could result in a PE sending customer
   data belonging to some EVPN to another EVPN, or black-holing EVPN
   customer data, or even sending it to an eavesdropper, none of which
   are acceptable from a data privacy point of view.  In addition,
   compromise of the control plane could provide opportunities for
   unauthorized EVPN data usage (e.g., exploiting traffic replication
   within a multicast tree to amplify a denial-of-service attack based
   on sending large amounts of traffic).

   [snip]

   It is also important to help limit malicious traffic into a network
   for an impostor MAC address.  The mechanism described in Section 15.1
   shows how duplicate MAC addresses can be detected and continuous
   false MAC mobility can be prevented.  The mechanism described in
   Section 15.2 shows how MAC addresses can be pinned to a given
   Ethernet segment, such that if they appear behind any other Ethernet
   segments, the traffic for those MAC addresses can be prevented from
   entering the EVPN network from the other Ethernet segments.
/

==============================================
End of Technical Comments

Editorial comments
=========================
1. Introduction, paragraph 2

Problem: Sentence Grammar - Capitalization of first word in sentence.

Old Text/
   - Lower Cost: gateway devices need to have very high scalability to
   handle VPN services for their DCs and as such need to handle large
   number of VPN instances (in tens or hundreds of thousands) and very
   large number of routes (e.g., in tens of millions).
  /

New Text/
   - Lower Cost: Gateway devices need to have very high scalability to
   handle VPN services for their DCs and as such need to handle large
   number of VPN instances (in tens or hundreds of thousands) and very
   large number of routes (e.g., in tens of millions).
  /

Old text:/
   - Optimum Forwarding: in a given Central Office(CO), both EVPN PEs
   and MVPN PEs can be connected to the same fabric/network (e.g., same
   IGP domain).
/
New text: /
   - Optimum Forwarding: In a given Central Office(CO), both EVPN PEs
   and MVPN PEs can be connected to the same fabric/network (e.g., same
   IGP domain).
/

2. Introduction paragraph 2, section starting with "Optimm Forwarding"

Issue: The use of terms "tromboned" or "tromboning" is term of art, but
the lack of a definition in the Terminology section makes it difficult for
starting to read.

Suggestion:

1) Add a definition on tromboned or Tromboning in the Terminology section.

3. Section 3, Terminology

3a) Please alphabetize the terms in this section.

3b) Use a consistent methodology for periods in this section.
I think you are consistent except for the following:
Old text/
         E: Provider Edge device.
/
New text:/
     PE: Provider Edge device.
/

3c) Please consider adding the following terms used in the document:

1) Aggregate Selective P-tunnels
2) Aggregate tunnel (Section 5, paragraph 4)
3) CO (section 4.1)
4) IMET (section 6.2)
5) ingress replication tunnels (section 4.1)
6) Intra subnet (section 4.2)
7) Inter subnet (section 4.
8) P2MP Tunnels (setion 4.10
9) Selective P-tunels

4) Section 5.1.1

Old text:/
   In order to enable seamless integration of EVPN and MVPN PEs, this
   document extends the concept of an emulated VLAN service for
   multicast IRB applications such that the intra-subnet IP multicast
   traffic can get treated the same as inter-subnet IP multicast traffic
   which means intra-subnet IP multicast traffic destined to remote PEs
   gets routed instead of being L2-switched - i.e., TTL value gets
   decremented and the Ethernet header of the L2 frame is de-capsulated
   and encapsulated at both ingress and egress PEs.
   /

 English problem-  This text uses "which means" and "- i.e."

 The abbreviation “i.e.” stands for id est, which is Latin for “that is".
 A main clause followed by two clauses "which means" ... "that is"
 makes the sentence confusing.

 It would be good to rewrite the sentece which takes up the whole paragraph.

 5) Section 5.2, Figure 2

 Old Text:/ Figure 1: & MVPN PEs Seamless Interop/
 New Text:/ Figure 1: MVPN PE Seamless Interop /

The content makes me wonder if the figure should be title something different. ;

6) Section 5.3

context: Sections 5.3, 5.4 and 5.5 contain key technology.

Problem: Section 5.3 is has many run-on sentences.
This level of run-on sentences may be due to multiple edits.
It would be good to suggest the authors try a fresh write of the
section.

One nit if they are rewriting:
Old text: /
   When the source is attached to an All-Active multi-homed ES, then the
   PE that learns the source advertises the unicast route for that
   source using EVPN route type 2 and IPVPN unicast route along with VRF
   Route Import extended community.
/

new text:/
   When the multicast source is attached to an All-Active multi-homed ES, then
   the PE that learns the multicast source advertises the unicast route for
   that source using EVPN route type 2 and IPVPN unicast route along with VRF
   Route Import extended community.
 /

 7) Section 6.1 - paragraph indenting is not consistent.