SRv6 and MPLS interworking

shows reference multi-domain network topology and its description. The procedure in this section are illustrated using the topology. Following is assumed for data plane support of various nodes: Nodes 2,3,5,6,8,9 are provider(P) routers which need to support single data plane type. 1 and 10 are PEs. They support single data plane type in overlay and underlay. Border routers 4 and 7 need to support both the SRv6 and SR-MPLS-IPv4 data plane. A VPN route is advertised via service RRs (S-RR) between an egress PE(node 10) and 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 label stack bound to IPv4 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 stitching end to end 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 advertising PE locator or IPv4 Loopback address for best effort or intent aware end to end connectivity.

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 its 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. It programs an SR policy at border node 4 with segment list node 5 and 7 bounded to an End.BM BSID . SR-PCE responds back to node 1 with SRv6 segments along required SLA including End.BM at node 4 to traverse SR-MPLS-IPv4 C domain. For example, SR-PCE create SR-MPLS policy (C1,7) at node 4 with segments <16005,16007>. It is bound to End.BM behavior with SRv6 BSID as B:4:BM-C1-7:: The data plane operations for the above-mentioned interworking example are: Node 1 performs SRv6 function 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 End function 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 rout4er) performs End.BM function Packet leaving node 4 MPLS (16005,16007,2)((A:1::, B:8:E::) (B:10::DT4, B:8:E::, B:4:BM-C1-7-:: ; SL=1)). Node 7 performs a native IPv6 lookup on due PHP behavior for 16007 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) function Packet leaving node 8 IPv6 ((A:1::, B:10::DT4)) Node 10 performs End.DT function and lookups IP in VRF and send traffic to CE.

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). The PCE computes color-aware C1 path via node 2, 5 and 8. It programs a SRv6 policy bound to MPLS BSID at border node 4 with SRv6 segment list along required color-aware path with last segment of behavior End.DTM . 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. For example, SR-PCE create SRv6 policy (C1,7) at node 4 with segments <B:5:E::,B:7:DTM::>. It is bound to MPLS BSID 24407. 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: PHP of node 2 prefix SID): 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 24407 Packet leaving node 4 IPv6(A:4::, B:5:E::) (B:7:DTM:: ; SL=1)NH=137) MPLS((16008,16010,vpn_label) Node 7 receive IPv6 packet with DA=B:7:DTM::. It performs DTM behavior to remove IPv6 header and perform 16008 lookup in MPLS table. Packet leaves node 7 towards node 8(PHP of 16008) MPLS packet (16010,vpn_label) Node 8 forwards traffic towards 10 (PHP of 16010) Packet leaving node 8 MPLS packet (vpn_label) Node 10 performs vpn_label lookup and send traffic to CE.

Procedures described below build upon BGP Label Unicast (BGP-LU) and to advertise transport reachability for PE IPv4 loopbacks or SRv6 locators across a multi-domain network. The procedures leverage existing SAFIs ( for example, BGP-LU(AFI=1 or 2 and SAFI=4) and IPv6 (SAFI=1,AFI=2)). Nexthop self on border routers 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-FlexAlgo. They are also applicable to color-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 and with no BGP Color Extended community. Ingress PE learns the service routes and need to resolve SRv6 Service SID over egress PE locator or its summary. Below describes propagation of locators or its summary to create end to end underlay path. Egress border router learns LE domain PE locators through IGP and redistribute in BGP. Alternatively, locator is originated by egress PE in the BGP IPv6 unicast address family (AFI=2,SAFI=1) to border nodes. Egress border router uses 6PE procedure and advertise these locator in BGP-LU [AFI=2,SAFI=4] with locally allocated label or IPv6 Explicit NULL to ingress border router with IPv4 next hop. Next hop has SR MPLS IPv4 LSP paths built in C domain. Note: Egress border router may advertise summary prefix covering all PE locators in LE domain. Ingress border router advertise these remote locators or its summary in LI domain. Options to advertise are: To ingress PE in BGP IPv6 address family (AFI=2,SAFI=1) with SRv6 transport SID of local End behavior in Prefix-SID attribute TLV type 5 . This option will result in additional SRv6 encapsulation at ingress PE. BGP hop by hop routing model to each of P and PE routers through infrastructure route reflector. This option will avoid additional SRv6 transport SID encapsulation. 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 learn remote locators or their summary with or without SRv6 SID encapsulation. When learnt with SRv6 SID, it builds the packet encapsulation that contains the SRv6 Service SID and SRv6 transport SID in the SID list and tunnels traffic to ingress border node in LI domain (P routers (node 2 and 3) does not need remote prefix). When learnt without SRv6 SID, the packet encapsulation contains the SRv6 Service SID and forwarded hop by hop based on remote locator IPv6 prefix lookup. Example to advertise node 10 locator to node 1 with SRv6 SID encapsulation:

<----------C----------><-----------LE----------> ]]> Routing Protocol(RP) @10: In ISIS advertise locator B:10::/48 BGP (AFI=1,SAFI=128) originates a VPN route RD:V/v via B:10::1 and Prefix-SID attribute B:10:DT4::. This route is advertised to service RR. RP @ 7: ISIS redistribute B:10::/48 into BGP BGP Originates B:10::/48 in (AFI=2,SAFI=4) with next hop node 7 and IPv6 Explicit Null label among border routers. RP @ 4: BGP learns B:10::/48 with next hop node 7 and outgoing label. BGP advertise B:10::/48 in (AFI=2,SAFI=1) with next hop B:4::1 and Prefix-SID attribute tlv type 5 carrying local End behavior function B:4:END:: to node 1 RP @ 1: BGP learns B:10::/48 via B:4::1 and Prefix-SID attribute TLV type 5 with SRv6 SID B:4:END:: BGP AFI=1,SAFI=128 learn service prefix RD:V/v, next hop B:10::1 and PrefixSID attribute TLV type 5 with SRv6 SID B:10:DT4 FIB state

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

Refer for Mo6 scenario. MPLS based L3/L2 BGP services are signaled with IPv4 next-hop of egress PE through Service RRs with no color extended community. Ingress PE need labelled reachability to remote PE IPv4 loopback address advertised as next hop with service routes. BGP-LU advertise IPv4 PE loopbacks. Next hop self is performed on the border routers. Following are options and protocol extensions to tunnel IPv4 PE loopback LSP through SRv6 C domain

Intuitive solution for an MPLS-minded operator Existing BGP-LU label cross-connect on border routers for each PE IPv4 loopback address. The lookups at the ingress border router are based on BGP-LU label as usual Just the SR-MPLS IGP label to next hop is replaced by an IPv6 tunnel with DA = SRv6 SID associated with DTM behavior in C domain. Ingress border router forwarding perform 3107 label swap and H.Encaps.M with DA = SRv6 SID associated with DTM behavior Similar to MPLS-over-IP Existing BGP-LU updates between border routers need to signal SRv6 SID associated with DTM behavior. proposes "SRv6 tunnel for label route" TLV of the BGP Prefix-SID Attribute to signal SRv6 SID to tunnel MPLS packet with label in NLRI at the top of its label stack through SRv6/IPv6 domain. Below describes the control plane and corresponding FIB state to achieve such tunneling: Control plane example Routing Protocol(RP) @10: ISIS originates its IPv4 PE loopback with Node SID 16010 BGP AFI=1,SAFI=4 originate 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 next hop node 10. This route is advertised to service RR. RP @ 7: ISIS v6, advertise locator B:7::/48 in C domain BGP learns node 10 IPv4 loopback address with outgoing label. It allocates local label (based on label index if present) and programs label swap to outgoing label and MPLS LSP to next hop. BGP AFI=1,SAFI=4 advertise IPv4 loopback address of node 10 to node 4. NLRI label is set to local label and SRv6 SID B:7:DTM:: carried in SRv6 SID Information Sub-TLV of "SRv6 tunnel for label route" TLV in Prefix-Sid attribute. If received, label index=10 in Label-Index TLV of Prefix-SID attribute is also signaled. RP @ 4: ISIS v4 originates its IPv4 loopback with prefix SID 16004 in LI domain. BGP learns node10 IPv4 loopback address from node 7 with outgoing label. It allocate local label (based on label index if present) and programs label swap and H.Encaps.M.red with IPv6 header destination address as SRv6 SID received in "SRv6 tunnel for label route" TLV of Prefix-Sid attribute i.e. B:7:DTM::. BGP AFI=1,SAFI=4 advertise IPv4 Loopback address of node 10 to node 1. NLRI label is set to local label and do not signal "SRv6 tunnel for label route" TLV in Prefix-SID attribute. RP @ 1: BGP learns IPv4 loopback address of node 10 from node 4 with outgoing label. It programs route to push outgoing label and MPLS LSP to next hop i.e. node 4 BGP AFI=1,SAFI=128 learn service prefix RD:V/v, next hop IPv4 loopback address of node 10 and service label. Forwarding state at different nodes:

out label=vpn_label, next hop=IPv4 address of node 10 @1: IPv4 table: IPv4 address of node 10 => out label=16010, next hop=node4 @1: IPv4 table: IPv4 address of node 4 => out label=16004, next hop=interface to reach 2 @4: MPLS Table: 16010 => out label=16010, H.Encaps.M.red with DA=B:7:DTM:: @4: IPv6 table: B:7::/48 => next hop=interface to reach 5 @7: SRv6 My SID table: B:7:DTM:: => decaps IPv6 header and lookup top label. @7: MPLS table: 16010 => out label=16010, next hop=interface to reach 8 @10: MPLS table: vpn label => pop label and lookup the inner IPv4 DA in the VRF ]]> During transition when MPLS data plane is still enabled in C domain, an ABR that does not understand "SRv6 tunnel for label route" TLV in BGP Prefix-SID Attribute or based on operator configured local policy can continue MPLS encapsulation using label in NLRI and LSP to next hop.

For each PE IPv4 loopback address, existing BGP-LU label cross-connect on area border router is replaced by label to SRv6 SID cross-connect or vice versa. In effect, it creates a translation between from 3107 label to SRv6 SID at ingress of SRv6 domain and SRv6 SID to 3107 label on egress. For each BGP-LU route (IPv4 loopback address of PE) received from LE domain on egress border router, allocate SRv6 SID of DPM behavior bound to the PE address. Lookup of SRv6 SID result in decapsulation of IPv6 header and push of BGP-LU outgoing label and MPLS LSP to next hop. Advertise BGP route to PE address with SRv6 SID to ingress border router. Ingress border router allocate local label and advertise to LI domain. The lookups at the ingress border router are based on BGP-LU label as usual. Lookup results SRv6 SID of DPM behavior signaled by egress border node. Decap BGP-LU label and perform H.Encaps.M with DA = SRv6 SID. Section 2.2 of describes how existing BGP advertisement can signal SRv6 SID associated with DPM behavior from egress to ingress border router.

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.

Gateway is IW role that which supports both BGP SRv6 based L2/L3 services and BGP MPLS based L2/L3 services for a service instance (e.g. L3 VRF, EVPN EVI). It terminates service encapsulation and perform L2/L3 destination lookup in service instance. This is similar to inter-as option A on the single node instead of back to back VRF interfaces between ABRs/ASBRs. A border router between SRv6 domain and SR-MPLS-IPv4 domain is suitable for Gateway 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 exchange 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. It is advertised to MPLS service PE with service label. When gateway receives traffic with service label from MPLS service PE, it perform destination lookup in service instance. Lookup result 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 to 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 perform destination lookup in service instance after decaps of IPv6 header. Lookup result in instruction to push service label and send it to 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 is similar to inter-as option B procedures described in just that service label cross-connect on border router is replaced with service label to SRv6 service SID or vice verse translation on IW node. IW node does not need service instance like VRF or EVI. IW node exchange BGP L2/L3 service prefix with SRv6 based Service PEs via set of service RRs. This BGP session will learn/advertise L3/L2 service prefixes with SRv6 service SID in prefix SID attribute . IW node exchange BGP L2/L3 service prefix with MPLS based service PEs via set of distinct service RRs. This BGP session will learn/advertise L3/L2 service prefixes with service labels . IW node allocates SRv6 SID of behavior End.DPM that result in pushing service label and MPLS label stack to service nexthop for BGP L2/L3 service learnt from MPLS PE. It advertises the service to SRv6 domain. IW node allocates service label that results in H.Encaps with IPv6 header DA set to SRv6 SID signaled in BGP L2/L3 service learnt from SRv6 PE. Advertises the service to MPLS domain with allocated service label.

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. It will be covered in separate document.