Document: draft-ietf-bess-evpn-mvpn-seamless-interop Title: Seamless Multicast Interoperability between EVPN and MVPN PEs Reviewer: Stig Venaas Review result: Has Issues
I found the document well written and no serious issues. There are however a few minor issues that I think should be resolved before it is submitted to the IESG. I see revision 06 was reviewed previously, please check that all those comments are addressed. review-ietf-bess-evpn-mvpn-seamless-interop-06-rtgdir-early-boucadair-2023-11-29-00 There are a few sentences that are hard to parse. In section 5.2: sending these messages over MPLS/IP core. A tenant virtual/physical router (e.g., CE) attached to an EVPN PE becomes a multicast routing the adjacency of that PE. Furthermore, the PE uses MVPN BGP protocol I don't understand the sentence ending with "the adjacency of that PE". Should simply "the" be removed? In section 5.3: attached behind EVPN PEs. All VPN-IP routes SHOULD be summarized while adverting to MVPN PEs. Replace "adverting" with "advertising"? In 6.1: In case of a TS, receiver sits behind an All-Active Multihoming ES and a TS source sits behind an inter-subnet tunnel (with respect to the multihomed PE), it is possible that more than one multihomed PEs sends MVPN join toward remote PE based on incoming join on their Replace "more than one" with "more than one of the"? In 6.4: Here, IGMP/MLD states are terminated at IRB interfaces, and local interest are expressed in the context of IP-VRF to remote PEs. s/are/is? In 7.2: Rcvr2 in Figure 1 is connected to PE1 in MAC-VRF2 and hence PE1 will record its membership in MAC-VRF2. Since MAC-VRF2 is enabled with IRB, gets added as another OIF to the routing entry formed for (C-S, C-G). What is it that gets added as another OIF? In 7.2: another OIF 'MAC-VRF2' to its existing routing entry. But there is no change in control plane states since it is already sent MVPN route and no further signaling is required. Traffic received by the tenant Replace "it is already" with "it has already"? In 8.1: It must be emphasized that this solution poses no restriction on the setup of the tenant BDs and that neither the source PE, nor the receiver PEs do not need to know/learn about the BD configuration on other PEs in the tenant IP-VRF ( Since EVPN PE is modeled as MVPN PE, source and receivers are announced to remote PE in the context of tenant IP-VRF(MVPN) as opposed to BD context). The Reverse Path This is hard to read with the double negative. Can "do not" be removed? In 8.1: EVPN PE MUST have Route Target Extended Community to import/export MVPN routes. In a data center environment, it is desirable to have this RT is configured using an auto-generated method rather than a static configuration. Replace "RT is" with "RT"? In 8.1: be appended as an export route-target extended community. The PE which has advertised the unicast route with VRI, will import the incoming MCAST-VPN NLRI in the IP-VRF with the same import route- target extended-community and other PEs SHOULD ignore it. Following Why is this a SHOULD and not a MUST? What are the conditions where it makes sense not to ignore it? In 8.1: If the multicast source is unknown (overlay ASM mode), the MCAST-VPN route type 6 (C-*,C-G) join SHOULD be targeted towards the designated overlay Rendezvous Point (RP) by appending the received RP VRI as an export route-target extended community. Every PE which detects a a Also here, why is it a SHOULD and not a MUST. When does it make sense not to do it? In 8.2.2: When the encapsulation mode is configured as the VXLAN, the Should it say "as VXLAN"? In 8.2.2: 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 Upper case SHOULD? Heading 12: TS RP options What is TS? Section 13 IANA Considerations: Maybe point out that references need to be updated when published? Section 14 Security Considerations Are there no new considerations due to how the existing technologies are combined? In A.3: Recent ASIC supports single lookup forwarding for bridging and routing (L2+L3). The procedure mentioned here leverages this ASIC capability. "Recent" may not age well. This document may be read years after publication. It might also become multiple ASICs. I also find it a bit odd to mention ASIC support. Maybe it makes more sense with ASIC support, but couldn't it be done anyway? That's all my issues. _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
