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.