Hi Stig, Thanks for reviewing the draft and valuable feedback. I have addressed comments and posted a new version. Please see the response below.
Thanks, Kesavan From: Stig Venaas via Datatracker <[email protected]> Date: Monday, September 29, 2025 at 3:40 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-bess-evpn-mvpn-seamless-interop-09 early Rtgdir review 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? >> 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"? >> it is a typo. Addressed it. ( Replaced 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"? >> Here, “more than one” is accurate one. It implies that it is possible for >> multiple PE to send MVPN join towards remote PE. 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? >> Corrected [ changed as “local interests” ] 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? >> Replaced the word “another OIF” as “an 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"? >> Addressed the comment 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? >> Sure, Modified the paragraph as follow. “It must be emphasized that this >> solution poses no restriction on the setup of the tenant BDs. The source PE and receiver PEs do not need to know/learn about the BD configuration on other PEs in the tenant IP-VRF” 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"? >> Addressed it. 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? >> if someone configures import RT due to whatever reason which is beyond the >> scope of current document, route will be imported. Hence “SHOULD” is used >> here. If required, we can change this. 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? >> changed “should be” as “is targeted”. (This is an existing MVPN procedures ) In 8.2.2: When the encapsulation mode is configured as the VXLAN, the Should it say "as VXLAN"? >> Changed as suggested 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? >> Changed as suggested Heading 12: TS RP options What is TS? >> “Tenant systems”. This is captured in the terminology section. Section 13 IANA Considerations: Maybe point out that references need to be updated when published? >> It is taken care Section 14 Security Considerations Are there no new considerations due to how the existing technologies are combined? >> This draft leverages procedure defined in RFC 6513 and RFC 6514. Hence all >> security consideration for these RFC applies here. I have added an >> operational consideration section in the new version, which discusses what >> needs to be considered for the seamless interop. 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. >> Removed the ASIC reference and changed the sentences “The procedure >> mentioned here leverages single forwarding lookup for bridging and routing >> (L2+L3) capability”
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
