SRv6 and MPLS interworking

The procedures in this section are illustrated using the reference multi-domain network topology and its description . Following is assumed of data plane support at various nodes: Nodes 2,3,5,6,8,9 are provider(P) nodes that need to support single data plane type. Nodes 1 and 10 are PEs. They support single data plane type in overlay and underlay. Nodes 4 and 7 are border nodes that support both the SRv6 and MPLS data plane. A VPN route is advertised via service RRs (S-RR) from an egress PE(node 10) to an ingress PE (node 1). For illustrations, the SRGB range starts from 16000 and prefix SID of a node is 16000 plus node number

As described in , transport IW requires: For 6oM, tunnel traffic destined to SRv6 Service SID of egress PE over MPLS C domain. For Mo6, tunnel MPLS encapsulated traffic destined to Loopback address of egress PE over SRv6 C domain. This draft enhances two well-known solutions to achieve above: An SR-PCE multi-domain On Demand Next-hop (ODN) SR policy that stitches end to end path across different data plane domains using interconnecting binding SIDs. These procedures can be used when overlay prefixes are signaled with a color extended community . BGP Inter-Domain routing procedures that advertise and propagate PE locator or Loopback address across domains. During propagation, domain border node set nexthop to self that result in allocation of label or SRv6 SID depending on dataplane type of the domain where prefix is propagated. These procedure can provide both best effort or intent aware end to end path.

This procedure provides a best-effort path as well as a path that satisfies the intent (e.g. low latency), across multiple domains. Service routes (VPN/EVPN) are received on ingress PE with color extended community from egress PE. A Color is a 32-bit numerical value that associates an SR Policy with an intent . Ingress PE does not know how to compute the traffic engineered path through the multi-domain network to egress PE and requests SR-PCE for it. The SR-PCE is aware of interworking requirement at border nodes as it is fed with BGP-LS topological information from each domain. It programs intermediate domain data plane specific policy on border nodes for the given intent and represents it in end-to-end path SID list on ingress PE leveraging . Below sections describe 6oM and Mo6 IW with SR-PCE

Service prefix (e.g. VPN or EVPN) is received on head-end (node 1) with color extended community (C1) from egress PE (node 10) with SRv6 service SID. The PCE computes (C1,10) path via node 2, 5 and 8. For interworking function, it programs an SR policy at border node 4 with segment list node 5 and 7 bounded to an End.BM BSID (For example, SR-PCE creates an SR-MPLS policy (C1,7) at node 4 with segments <16005,16007>. This policy is bound to End.BM behavior with SRv6 BSID as B:4:BM-C1-7::). SR-PCE responds back to node 1 with SRv6 segments of requested SLA including End.BM at node 4 to traverse SR-MPLS-IPv4 C domain. The data plane operations for the above-mentioned interworking example are: Node 1 performs SRv6 operation H.Encaps.Red with VPN service SID and SRv6 Policy (C1,10): Packet leaving node 1 IPv6 ((A:1::, B:2:E::) (B:10:DT4::, B:8:E::, B:4:BM-C1-7:: ; SL=3)) Node 2 performs SRv6 End behavior on B:2:E:: SRv6 SID present in the DA Packet leaving node 2 IPv6 ((A:1::, B:4:BM-C1-7::) (B:10:DT4::, B:8:E::, B:4:BM-C1-7:: ; SL=2)) Node 4(border node) performs End.BM behavior on B:4:BM-C1-7:: SRv6 SID present in the DA Packet leaving node 4 MPLS (16005,16007, IPv6 Explicit NULL)((A:1::, B:8:E::) (B:10:DT4::, B:8:E::, B:4:BM-C1-7-:: ; SL=1)). Node 5 performs PHP pn 16007 Node 7 performs native IPv6 lookup after IPv6 explicit NULL processing Packet leaving node 7 IPv6 ((A:1::, B:8:E::) (B:10:DT4::, B:8:E::, B:4:BM-C1-7:: ; SL=1)) Node 8 performs End(PSP) behavior B:8:E:: SRv6 SID present in the DA Packet leaving node 8 IPv6 ((A:1::, B:10:DT4::)) Node 10 performs End.DT4 behavior on B:10:DT4:: SRv6 SID present in the DA i.e. it looks up inner IP destination in the VRF corresponding to B:10:DT4:: SID and forwards traffic to CE accordingly.

Refer for Mo6 scenario. MPLS Service prefix (e.g. VPN or EVPN) is received on head-end(node 1) with color extended community(C1) from egress PE(node 10) and vpn label. The SR-PCE computes color-aware C1 path via node 2, 5 and 8. For interworking function, it programs a SRv6 policy bound to MPLS BSID at border node 4 with SRv6 segment list along the required color-aware path with last segment of behavior End.DTM46 (For example, SR-PCE create SRv6 policy (C1,7) at node 4 with segments <B:5:E::,B:7:DTM46::>. It is bound to MPLS BSID 24407). SR-PCE responds back to node 1 with MPLS segment list including MPLS BSID of SRv6 policy at node 4 to traverse SRv6 core domain. The data plan operations for the above-mentioned interworking example are: Node 1 performs MPLS label stack encapsulation with VPN label and SR-MPLS Policy (C1,10): Packet leaving node 1 towards 2 (Note: node 2's prefix SID is not pushed due to PHP): MPLS packet (16004,24407,16008,16010,vpn_label) Node 2 forwards traffic towards 4 (PHP of 16004) Packet leaving node 2 MPLS packet (24407,16008,16010,vpn_label) Node 4 steers MPLS traffic into SRv6 policy bound to MPLS BSID label 24407 Packet leaving node 4 IPv6(A:4::, B:5:E::) (B:7:DTM46:: ; SL=1)NH=137) MPLS((16008,16010,vpn_label) Node 7 performs DTM46 behavior on B:7:DTM46:: SRv6 SID present in the DA i.e. remove IPv6 header and lookup label 16008 in MPLS table. Packet leaving node 7 towards node 8(PHP of 16008) MPLS packet (16010,vpn_label) Node 8 forwards traffic to 10 (PHP of 16010) Packet leaving node 8 MPLS packet (vpn_label) Node 10 pops vpn_label, looks up inner IP destination in the VRF corresponding to the vpn_label and forwards to traffic to CE accordingly.

Procedures described below build upon BGP Label Unicast (BGP-LU) and that advertise transport reachability of PE loopback address or SRv6 locator across a multi-domain network. The procedures leverage existing SAFIs (for example, BGP-LU(AFI=1 or 2 and SAFI=4) and IPv6 (AFI=2,SAFI=1)). Setting nexthop to self on border node provide independence of intra domain tunnel technology in different domains. The sections below describe 6oM and Mo6 IW with BGP procedures for best effort paths to a locator or loopback prefix. The procedures are equally applicable to intent aware paths, i.e., locator assigned for a given intent, for instance from an IGP Flexible Algorithm. They are also applicable to intent-aware routes recursing over intent aware intra-domain paths.

Refer for 6oM scenario. SRv6 based L3/L2 BGP services are signaled with SRv6 Service SID allocated from egress PE locator prefix. Ingress PE learns the service routes and need to resolve SRv6 Service SID over egress PE locator or its summary. Below describes propagation of locator or its summary to create end to end underlay path. Egress border node learns LE domain PE locator through IGP and redistribute it in BGP. Alternatively, locator is advertised by egress PE in the BGP IPv6 Unicast (AFI value 2 and SAFI value 1) to border nodes. Egress border node uses 6PE procedure that results in advertisement of locator as BGP-LU route with locally allocated label or IPv6 Explicit NULL and nexthop set to itself to ingress border node. SR-MPLS-IPv4 builds MPLS LSP path in C domain from ingress to egress border node. Note: Egress border router may advertise summary prefix covering all PE locators in LE domain. Ingress border node advertise route of remote locator or its summary in LI domain. Below are the options to advertise route: BGP IPv6 SAFI (AFI=2 and SAFI=1) distribute the route with SRv6 transport SID of local End behavior in Prefix-SID attribute TLV type 5 . This option results in additional SRv6 encapsulation at ingress PE. BGP IPv6 SAFI (AFI=2 and SAFI=1) distribute the route to each of P and PE router through infrastructure route reflector. This option avoids additional SRv6 transport SID encapsulation at ingress PE and forwards traffic hop by hop in LI domain. Leak remote locators or their summary in LI IGP (Typically on transport ABR only infrastructure prefixes are present in BGP. If that is not the case, proper filters need to be configured for such leaking into IGP). Ingress PE learns remote locator or summary with or without SRv6 transport SID. When learnt with SRv6 transport SID, it builds the packet encapsulation that contains the SRv6 Service SID and SRv6 transport SID in the SID list. SRv6 transport SID tunnels traffic to ingress border node in LI domain (P routers like 2 and 3 does not need egress PE locator reachability). When learnt without SRv6 transport SID, the packet encapsulation contains the SRv6 Service SID as DA and forwarded hop by hop based on remote locator IPv6 prefix lookup in LI domain. Example to advertise node 10 locator to node 1 with SRv6 SID encapsulation:

<----------C----------><-----------LE----------> ]]> Routing @ node 10: SIS advertises locator B:B:10::/48 BGP (AFI=1,SAFI=128) originates a VPN route RD:V/v via B:B:10::1 with SRv6 Service SID B:B:10:DT4::. This route is advertised to service RR. Routing @ node 7: ISIS redistributes B:B:10::/48 into BGP BGP advertise B:B:10::/48 in (AFI=2,SAFI=4) among border routers with nexthop as node 7 and IPv6 Explicit Null label. Routing @ node 4: BGP learns B:B:10::/48 with next hop node 7 and outgoing label. BGP advertise B:B:10::/48 in (AFI=2,SAFI=1) with next as itself B:B:4::1 and Prefix-SID attribute tlv type 5 carrying local End behavior function B:B:4:END:: to node 1 Routing @ node 1: BGP learns B:B:10::/48 with nexthop node 4 and outgoing SRv6 SID B:B:4:END:: in Prefix-SID attribute TLV type 5 BGP learns service prefix RD:V/v, with SRv6 service SID B:B:10:DT4:: ISIS learns locator prefix B:B:4::/48 for node 4's SID reachability Forwarding state at different nodes:

H.Encaps.red with SRH (SL=1 and NH=IPv4) @1: IPv6 Table: B:B:4::/48 => forward via ISIS path to node 4 @4: IPv6 Table: B:B:4:END:: => PSP Processing (Update DA with B:B:10:DT4::, set IPv6.NH=IPv4, pop the SRH) @4: IPv6 Table: B:B:10::/48 => push MPLS label stack {16007, 2 (IPv6 Explicit NULL)} @7: MPLS label 2 => pop and lookup inner IPv6 DA @7: IPv6 Table B:B:10::/48 => forward via ISIS path to node 10 @10: IPv6 Table B:B:10:DT4:: => DT4 SID processing (pop the outer header and lookup the inner IPv4 DA in the VRF ]]>

Refer for Mo6 scenario. MPLS-based L3/L2 BGP service is signaled with IPv4 nexthop of egress PE through Service RRs. Ingress PE needs MPLS reachability for egress PE's IPv4 loopback address in the LE domain to transport services. Egress PE originate route to its loopback address in BGP-LU in LE domain. Egress border node sets nexthop to itself and signals MPLS-over-IP to ingress border node that results in tunneling of BGP-LU LSP across SRv6 C domain. There are existing BGP-LU label cross-connect on border nodes for each PE loopback address. The lookup at the ingress border node are based on BGP-LU label as usual Just the SR-MPLS IGP label to next hop is replaced by an SRv6 encapsulation with DA = SRv6 SID associated with DTM46 behavior of egress border node in C domain. Ingress border node forwarding performs RFC3107 label swap, followed by H.Encaps.M operation setting DA = SRv6 SID associated with DTM46 behavior. Existing BGP-LU updates between border nodes need to signal SRv6 SID associated with DTM46 behavior. BGP procedures to signal SRv6 SID is described in and outside the scope of this document. Below illustrate the example control plane and corresponding FIB state to achieve such tunneling: Control plane example Routing @10: SR ISIS originates IPv4 PE loopback with SR Node SID 16010 BGP AFI=1,SAFI=4 originates IPv4 loopback address with next hop node 10 and optionally label-index=10 in Label Index TLV of Prefix-SID attribute. BGP AFI=1,SAFI=128 originates a VPN route RD:V/v via next hop node 10. This route is advertised to service RR. Routing @ 7: ISIS IPv6 advertise its locator B:B:7::/48 in C domain BGP learns node 10 IPv4 loopback address with label. It allocates local label (based on label-index, if present) and programs BGP-LU label swap to received label and deliver it to next hop. BGP AFI=1,SAFI=4 advertises loopback address of node 10 to node 4. NLRI label is set to local label and SRv6 SID B:B:7:DTM46:: is carried in SRv6 SID Information Sub-TLV of "SRv6 Transport" TLV in Prefix-Sid attribute. If received, Label-Index TLV of Prefix-SID attribute is also signaled. Routing @ 4: SR ISIS IPv4 originates its IPv4 loopback with prefix SID 16004 in LI domain. BGP learns node 10 IPv4 loopback address from node 7 with outgoing label. It allocates local label (based on label-index, if present) and programs label swap entry to be SRv6 tunnled to BGP nexthop by performing H.Encaps.M.red operation where IPv6 header is set to SRv6 SID B:B:7:DTM46:: (received in "SRv6 transport TLV" of Prefix-Sid attribute). BGP AFI=1,SAFI=4 advertise loopback address of node 10 to node 1 with locally allocated label and nexthop to self. This results in removal of SRv6 Transport TLV in Prefix-SID attribute. Routing @ 1: BGP learns IPv4 loopback address of node 10 from node 4 with outgoing label. It programs route to push outgoing label delivered to nexthop node 4. BGP AFI=1,SAFI=128 learns service prefix RD:V/v with service label via node 10 loopback address. Forwarding state at different nodes:

out label=vpn_label, next hop=IPv4 loopback of node 10 @1: IPv4 table: IPv4 loopback of node 10 => out label=16010, next hop=node4 @1: IPv4 table: IPv4 loopback of node 4 => out label=16004, next hop=interface to node 2 @4: MPLS Table: 16010 (BGP-LU) => out label=16010, H.Encaps.M.red with DA=B:B:7:DTM46:: @4: IPv6 table: B:B:7::/48 => next hop=interface to node 5 @7: SRv6 My SID table: B:B:7:DTM46:: => decaps IPv6 header and lookup top label. @7: MPLS table: 16010 (SR ISIS)=> out label=16010, next hop=interface to node 8 @10: MPLS table: vpn label => pop label and lookup the inner IPv4 DA in the VRF ]]> During migration, when MPLS data plane is still enabled in C domain, a SRv6 capable ABR an select relevant encapsulation and legacy ABR can continue MPLS encapsulation using label in NLRI. If domain border node is a pure transport node without any services, either End.DTM46 or End.DTM can be advertised and it is upto the implementation to choose. If domain border node does have global table IPv4 and IPv6 (), then it MUST advertise End.DTM46. END.DTM46 is a superset of END.DTM.

Procedures as defined in work for global table services (, ) over BGP-LU transport when service endpoint is beyond border node (example node 10). In scenarios where service endpoint is border node, additional SRv6 decapsulation behavior is required that performs service traffic IP destination lookup in global IPv4 or IPv6 table. In such deployment, border node advertise its existing IPv4 PE loopback address in BGP-LU as per where SRv6 SID is associated with End.DTM46 behavior instead of END.DTM.

As described in Service IW need BGP SRv6 based L2/L3 PE interworking with BGP MPLS based L2/L3 PE. There are a number of different ways of handling this scenario as detailed below.

In Gateway Interworking role, node supports both BGP SRv6 based L2/L3 service and BGP MPLS based L2/L3 service for a given service instance (e.g. L3 VRF, EVPN EVI). In dataplane, it terminates service encapsulation of ingress PE and perform L2 MAC route or L3 IP destination lookup in service instance. Lookup provide egress PE service encapsulation that is used to send packet to egress PE. This is similar to inter-as option A that is implemented within a single node instead of implementing on two back2back ABRs/ASBRs nodes connected with VRF interface. A border router between SRv6 domain and SR-MPLS-IPv4 domain is suitable for a Gateway IW role. Transport reachability to SRv6 PE and gateway locators in SRv6 domain or MPLS LSP to PE/gateway IPv4 Loopbacks can be exchanged in IGP or through mechanism detailed in . Gateway exchange BGP L2/L3 service prefix with SRv6 based Service PEs via set of service RRs. This session will learn/advertise L3/L2 service prefixes with SRv6 service SID in prefix SID attribute. . Gateway exchanges BGP L2/L3 service prefix with MPLS based Service PEs via set of distinct service RRs. This session will learn/advertise L3/L2 service prefixes with service labels . L2/L3 prefix received from a domain is locally installed in service instance and re advertised to other domain with modified service encapsulation information. Prefix learned with SRv6 service SID from SRv6 PE is installed in service instance with instruction to perform H.Encaps.Red. It is advertised to MPLS service PE with service label. When gateway receives traffic with service label from MPLS service PE, it performs MAC/destination IP lookup in service instance. The lookup results in instruction to perform H.Encaps with DA being SRv6 Service SID learnt with prefix from SRv6 PE. Prefix learned with MPLS service label from MPLS service PE is installed in service instance with instruction to perform service label encapsulation and send to MPLS LSP towards the nexthop. It is advertised to SRv6 service PE with SRv6 service SID of behavior (e.g. DT4/DT6/DT2U) . When gateway receives traffic with SRv6 Service SID as DA of IPv6 header from SRv6 service PE, it performs inner destination lookup in service instance after decaps of IPv6 header. The Lookup result in instruction to push service label and send it over MPLS LSP towards the nexthop.

L2/L3 lookup<->SRv6 SID | +----| | | | | | +-------------------------------------+ | | MPLS | | SRv6 | +-------------------+ +-------------------+ <------MPLS VPN-----> <------SRv6 VPN-----> ]]> Couple of border routers can act as gateway for redundancy. It can scale horizontally by distributing service instance among them.

This approach is similar to inter-AS option B procedures described in , except that service label cross-connect on border node is replaced with service label to SRv6 service SID (or vice versa) translation on the IW node. IW node does not require service instance such as VRF or EVI. IW node exchanges BGP L2/L3 service prefix with SRv6 based Service PEs through a set of service RRs. This BGP session will learn and advertise L3/L2 service prefixes with SRv6 SIDs in the prefix SID attribute . IW node exchanges BGP L2/L3 service prefix with MPLS based service PEs through set of distinct service RRs. This BGP session will learn and advertise L3/L2 service prefixes with service labels . IW node that sets nexthop to self, allocates SRv6 SID of DXM behavior variant based on service route AFI and SAFI i.e. End.DXM4 for IPv4 service prefix, End.DXM6 for IPv6 service prefix and End.DXM2 for layer 2 prefix learned from the MPLS PE. The FIB entry lookup on SRv6 local service SID provides service route outgoing service label and BGP nexthop (MPLS PE). The IW node then advertises the service route in the SRv6 domain with locally allocated SRv6 SID and its corresponding behavior. During packet forwarding, when an IPv6 packet arrives with the DA matching the locally allocated SRv6 SID, the node decapsulates the IPv6 header, pushes the outgoing service label, and delivers the packet to the BGP next-hop." IW node that sets nexthop to self, allocates local label for service route learnt from SRv6 PE attached with SRv6 SID in Prefix-SID attribute. FIB label entry lookup results in H.Encaps with SRv6 SID learned from SRv6 PE. IW node then advertises the service route to MPLS domain with locally allocated label. During packet forwarding, when an MPLS packet arrives with locally allocated label, the node pops the service label and performs H.Encaps.Red operation, setting DA as remote SRv6 SID and Upper-layer header based on behavior of SRv6 SID.

SRv6 SID | +----| | | VPN label, LSP PE1 <- SRv6 SID | | | +-------------------------------------+ | | MPLS | | SRv6 | +-------------------+ +-------------------+ <------MPLS VPN-----> <------SRv6 VPN-----> ]]> Certain L2 service specific information (eg. control word) translation is out of the scope of this document. It will be covered in separate document.