Hi Ran, Thank you so much for reviewing the draft and sharing comments. Really appreciate that. Please see the response below. I have also published a new draft addressing comments as mentioned below.
Thanks, Kesavan From: Ran Chen via Datatracker <[email protected]> Date: Wednesday, October 15, 2025 at 3:20 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: draft-ietf-bess-evpn-mvpn-seamless-interop-09 early Opsdir review Document: draft-ietf-bess-evpn-mvpn-seamless-interop Title: Seamless Multicast Interoperability between EVPN and MVPN PEs Reviewer: Ran Chen Review result: Has Issues # OPSDIR Early Review of draft-ietf-bess-evpn-mvpn-seamless-interop-09 I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. The document is well-written. The motivation is clear. The document does not include a dedicated Operational Considerations section. Please consider adding one —draft-opsarea-rfc5706bis provides some useful information. >>> I have added a new operational consideration section in the draft. ## Minor Section 8.2 and Section 9. As the current text primarily focuses on MPLS and VXLAN, I propose the inclusion of SRv6 (Segment Routing over IPv6) encapsulation to enhance the future applicability and completeness of the solution Section 8.2 Suggestion: Please introduce a dedicated subsection to cover SRv6 encapsulation. Section 9 Suggestion: Following the discussion of the MPLS/VXLAN inter-connect, please add a discussion of the SRv6/VXLAN scenario. >> Thanks for the comment. Multicast handling in SRv6 itself is a separate >> area of interest. If required, a new draft can be introduced for SRv6 >> handling in future. ( BTW, ‘draft-ietf-bess-mvpn-evpn-sr-p2mp’ currently >> captures EVPN/MVPN interaction with SRv6 ) ## Nits 1.Please ensure the term "VxLAN" is consistently capitalized as VXLAN throughout the document to comply with the spelling used in RFC 7348. 2.Please perform a global check to remove unnecessary white spaces that appear throughout the document. -s/( Since EVPN PE/( Since EVPN PE (Remove extra spaces before 'Since') -s/( PE's loopback address/( PE's loopback address (Remove extra spaces before 'PE's') -s/( Refer Section 13)/ (Refer Section 13) (Remove extra spaces before 'Refer') 3.Terminology Section： Please add the full definition for IRB to the Terminology section, referencing RFC9135. IRB: Integrated Routing and Bridging interface. It connects an IP-VRF to a BD (or subnet). -s/NVE: Network Virtualization Endpoint/NVE: Network Virtualization Edge（Consistent with RFC8365 and RFC9135） -s/PE: Provider Edge device/ PE: Provider Edge -s/VNI: Virtual Network Identifier (for VXLAN)/ VNI: VXLAN Network Identifier（Consistent with RFC8365） -s/VXLAN: Virtual Extensible LAN/ VXLAN: Virtual eXtensible LAN（Consistent with RFC7348） 4. -s/I.e,/i.e., -s/External source and receivers/External Source and Receivers -s/IRB multicast in seamless interop mode/IRB Multicast in Seamless Interoperability Mode -s/ Setup of overlay multicast delivery/ Setup of Overlay Multicast delivery -s/Handling of different encapsulations/ Handling of Different Encapsulations -s/Data plane interconnect/Data Plane Interconnect -s/Control plane inter-connect/Control Plane Interconnect -s/Connecting external Multicast networks/Connecting External Multicast Networks -s/multihoming of IP multicast sources and receivers/ Multihoming of IP multicast sources and receivers -s/an temporary/a temporary -s/specificied/specified 5. Section 6.1 OLD： As described in Section 5.4.2, when a multicast source is sitting behind an All-Active ES, then an intra-subnet multicast tunnel is needed among the multihoming EVPN PEs for that ES to carry multicast flow received by one of the multihoming PEs to the other PEs in that ES. We refer to this multicast tunnel as an Intra-ES subnet tunnel. NEW： As described in Section 5.4.2, when a multicast source is sitting behind an All-Active ES, then an intra-subnet multicast tunnel is needed among the multihoming EVPN PEs for that ES to carry multicast flow received by one of the multihoming PEs to the other PEs in that ES. This multicast tunnel is referred to as an Intra-ES subnet tunnel. Section 9: This section describes the inter-operation between MVPN PEs in WAN using MPLS encapsulation with EVPN PEs in a DC network using VxLAN encapsulation. Since the tunnel encapsulation between these networks are different, we must have at least one gateway in between. NEW: This section describes the inter-operation between MVPN PEs in WAN using MPLS encapsulation with EVPN PEs in a DC network using VXLAN encapsulation. Since the tunnel encapsulation between these networks are different, it must have at least one gateway in between 6. Please review the references sections. If all referenced documents are normative, please delete Section 16.2 " Informative References " as it is redundant. >>> Thank you for capturing this. I have addressed all comments ( 1 to 6) >>> mentioned above. In addition to this, I also found a few minor nit issues >>> and have corrected them as well. Thanks! Ran
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
