Hi Mike, Thanks for the email and your presentation in SRv6OPS.
From the perspective of BESS, I understand that Section 4.4 (Interworking) intentionally focuses on transport and service interworking as described in SPRING, in particular [I-D.ietf-spring-srv6-mpls-interworking] (6oM/Mo6 and 6toM/Mto6). That framing is appropriate for the SPRING-centric path. But, from an operator and implementation perspective, however, a significant number of brownfield migrations are driven by service-layer gateways being able to provide interworking among MPLS, SR-MPLS, VXLAN, SRv6. These Service Gateways terminate one service encapsulation and re-originate into another. The interconnect domains may use different transports (MPLS, VXLAN/NVO, SRv6), and preserve multi-homing, loop-prevention and other properties across the gateways. BESS has documented a substantial body of work in this area. It would strengthen the Interworking section if the draft briefly acknowledged that service-layer gateway model as complementary to the SPRING mechanisms already cited, and pointed readers to at least: 1. [RFC9014] -> Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks (EVPN Domain Gateways and Interconnect Ethernet Segment (I-ES) procedures for interconnecting EVPN domains / overlays with WAN technologies.) 1. [I-D.ietf-bess-evpn-ipvpn-interworking] —> EVPN Interworking with IPVPN/EVPN (Interworking / Gateway / Composite PE model for Layer-3 VPNs that use IPVPN or EVPN), including Domain Path (D-PATH) for loop prevention. 2. [I-D.ietf-bess-evpn-vpws-gateway] — Ethernet VPN Virtual Private Wire Services Gateway Solution (Extends the Domain Gateway / I-ES approach to EVPN-VPWS across domains with different encapsulations, including SRv6.) A short subsection under 4.4 (or an informative paragraph, references) could be enough, for example, noting that operators migrating EVPN/IPVPN services to SRv6 may use Domain/Service Gateways per the above, in addition to SPRING SRv6/MPLS interworking for transport and SID/label stitching. That would help readers significantly. Looking forward to discussing in BESS. Thanks, Jorge From: Mike McBride <[email protected]> Date: Friday, July 10, 2026 at 4:43 PM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [bess] vxlan to srv6 migration sanity check CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi bess, I'm one of the authors of https://datatracker.ietf.org/doc/draft-ietf-srv6ops-srv6-deployment/, which describes deployment and migration options for networks evolving toward srv6. Section 4.3.1 covers vxlan to srv6 migration and we were asked to request a look from bess on that section. Are the control plane, etc assumptions correct or need clarification? thanks, mike
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
