Hi Mike For section 4.3.1 VXLAN to SRv6 migration I can help with updating that section from experience in that area.
In some cases the vxlan hardware may not support SRv6 and so requires a all new fresh build In that case or greenfield build of SRv6 fabric and then swinging the edge vxlan leafs converting to TOR and then swinging the host connections off the TOR to the SRv6 leafs. In your migration scenario you have it correctly describing a valid brownfield case where the hardware supports both SRv6 and vxlan. The migration philosophy is very similar to dual plane MPLS and SRv6 migration. As long as the control plane is the same as is with your case EVPN E-LAN with DAG distributed Anycast Gateway no service IW translation gateway is needed which is the case for VXLAN and SRv6. First the fabric must be dual stacked identical to what is done with MPLS to SRv6 dual plane migration. Since NVO VXLAN has an IP underlay the underlay nodes remain IPv4 OSPFv2 plane and IPv6 plane is ISIS with SRv6 locator config built out and each leaf of border leaf becomes BGP EVPN dual attached with vxlan v4 plane peer and SRv6 v6 plane peer. BGP path attributes local pref can be used to prefer the v6 plane and traffic can be shifted seamlessly from v4 vxlan plane to b6 srv6 plane. That pretty much covers VXLAN to SRv6 and as it’s all EVPN E-LAN with anycast gateway the RFC 8365 and RFC 7432bis are all the same and no interworking GWs are needed. So that is all pretty straightforward. We do need to add sections on DC DCI to WAN edge core network scenarios which is what Jorge has mentioned which are crucial. In our draft we should create a section relating to service interworking where translation gateway reoriginates on the data plane inter domain handoff from safi x to safi y. https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-18 Also the RFC 9014 use cases go over all the permutations of wan edge scenarios going from vxlan in dc to MPLS wan edge and how to service level IW extend L2 inter domain. SRv6 to MPLS IW is also critical for transport and service interworking and I can help out with that section as well. https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-mpls-interworking-02 I can help out with those additional sections as well. Thanks Gyan On Wed, Jul 22, 2026 at 2:41 PM Jorge Rabadan (Nokia) < [email protected]> wrote: > 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.) > > > > 2. [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. > > 3. [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]
