Hi Ran & Mankamana, Thank you for comments related to SRv6. Currently, SRv6 specific drafts discuss multicast handling in SRv6 ( Ex: draft-ietf-bess-mvpn-evpn-sr-p2mp/draft-mankamana-pim-multicast-over-srv6/draft-xie-spring-srv6-multicast). Those are still evolving. We could consider a sperate document in future for handling inter subnet multicast routing if required/or this may be captured in one of the SRv6 related draft itself. Hope this is fine.
Thanks Kesavan From: Mankamana Mishra (mankamis) <[email protected]> Date: Friday, October 17, 2025 at 2:32 PM To: Ran Chen <[email protected]>, [email protected] <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: Re: draft-ietf-bess-evpn-mvpn-seamless-interop-09 early Opsdir review Hi Ran, Thanks for comment. Speaking as working group member, I believe it would be better to avoid including the SRv6 encapsulation details in this document at this stage. The SRv6 and multicast aspects are still under active development, and adding partial references here could lead to confusion rather than clarity. I would suggest that any SRv6-related content be introduced later through a future extension, if required. The multicast behavior where SRv6 is enabled for unicast is currently being defined in a PIM Working Group draft, which will take some time to mature. But I will leave the final decision to authors about it. Mankamana 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. ## 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. ## 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. Thanks! Ran
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
