SRv6 inter-domain mapping SIDs

Segment Routing (SR) allows source nodes to steer packets through SR paths. It can be implemented over IPv6 or MPLS . When SR is implemented over IPv6, it is called SRv6. This document describes three new SRv6 end-point behaviors, called END.REPLACE, END.REPLACEB6 and END.DB6. These behaviors are used to build paths across SRv6 domains. They also facilitate end-to-end SRv6 intent-based path stitching.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This use-case is mentioned in Section 4.1.1 of .

depicts three ASes (AS1, AS2 and AS3). All the three domains deploy SRv6. Inter-provider Option C connectivity is maintained from PE1 to PE2.

The above diagram shows two different SRv6 IGP domains. Services are running between PE1 and PE2 in option B style. The requirement here is to avoid service route lookup on ABR1 and ABR2 to provide option B style end to end connectivity

The END.REPLACE behavior is applicable in the Multiple ASes Connected With E-BGP use-case. The End.REPLACE SID cannot be the last segment in SRH or SR Policy. Any SID instance of this behavior is associated with a set, J, of one or more L3 adjacencies of immediate BGP neighbors When Node N receives a packet destined to S and S is a locally instantiated End.REPLACE SID, Node N executes the following procedure:

The END.REPLACEB6 behavior is applicable in the Multiple ASes Connected With E-BGP use-case. The End.REPLACEB6 SID cannot be the last segment in a SRH or SR Policy. Node N is configured with an IPv6 address T (e.g., assigned to its loopback). When Node N receives a packet destined to S and S is a locally instantiated End.REPLACEB6 SID, Node N executes the following procedure:

For the use-case mentioned under END.DB6 SID is applicable. The End.DB6 SID MUST be the last segment in SRH or SR Policy. Node N is configured with an IPv6 address T (e.g., assigned to its loopback). When Node N receives a packet destined to S and S is a locally instantiated End.DB6 SID, Node N executes the following procedure:

Here we will describe the control plane and data plane procedures by taking examples. Node n has a classic IPv6 loopback address An::1/128. One of the SID at node n with locator block B and function F is represented by B:n:F::sid_num. A SID list is represented as

]]> where S1 is the first SID to visit, S2 is the second SID to visit and S3 is the last SID to visit along the SR path.

Here we will discuss the use-case mentioned under

Node [1] acts as ingress PE and Node [16] acts as egress PE. Nodes [2], [3], [8], [9], [14] and [15] are P routers. Nodes [4], [5], [6], [7], [10], [11], [12] and [13] are ASBR routers. A VPN route is advertised via service RRs between an egress PE(node 16) and an ingress PE (node 1). The example below shows IBGP-CT connection between border routers in each domain and single hop EBGP-CT for inter-domain connections. However the forwarding procedure for the sids remains the same irrespective of the the various inter-domain protocol extensions used to advertise the sids. AS1, AS2 and AS3 has SRTE policy for the required intent paths.

H.Encaps.red with SRH, SRH NextHeader=IPv4 where the first sid B:2:END::1 belongs to the SR-policy in AS1. @2: IPv6 Table: B:2:END::1 => Update DA with B:4:REPLACE::1, decrement SL and forward towards the ASBR [4]. @4: IPv6 Table: B:4:REPLACE::1 => Update DA with B:6:REPLACEB6::1 and forward on the interface/interfaces identified by the ebgp neigbhor; the SL remains at 1. @6: IPv6 Table: B:6:REPLACEB6::1 => Update DA with B:10:REPLACE::1 AND do a fresh H.Encaps.red with SRH where the new SRH SIDs belong to SR policy in AS2. @8: IPv6 Table: B:8:END::1 => Update outer IPv6 packet DA with B:10:END::1 and forward towards ASBR [10] @10: IPv6 table: B:10:END::1 => Decap Outer IPv6 header and lookup next IPv6 DA B:10:REPLACE::1 => Update DA to B:12:End.B6.Encaps::1 and forward on the interface/interfaces identified by the ebgp neigbour. SL remains at 1. @12: IPv6 Table B:12:End.B6.Encaps::1 => Update DA with Next Segment in SRH(B:16:DT4::1) and do a fresh H.Encaps.red with SRH, where the new SIDs belong to the SR policy in AS3. @15: IPv6 Table B:15:END::1 => Update outer IPv6 packet DA with B:16:END::1 and forward towards [16]. @16: IPv6 Table B:16:END::1 => Decap the outer header and lookup the inner DA which results in B:16:DT4::1 lookup. DT4 lookup results in Decap and inner IPv4 packet DA lookup in the corresponding VRF. Note: At [1] we have optimized the solution by single Encapsulation with a SRH header.This can be supported by Most of the ASICS. Here we can even use two encapsulation, this mechanism will also work. ]]>

Here we will discuss the use-case mentioned under

Nodes [1] and [7] are PE routers. Node [4] is an option B style configured ABR/RR.

H.Encaps.red with SRH, SRH NextHeader=IPv4 where the first sid belongs to the SR-policy in AS1 @4: IPv6 Table: B:4:DB6::1 => Decapsulate the incoming IPv6 header and H.Encaps @7: IPv6 Table: B:7:DT4::1 => Decapsulate the header and lookup the inner IPv4 packet DA in the VRF ]]>

This document requires no IANA action. The authors will request an early allocation from the "SRv6 Endpoint Behaviors" sub-registry of the "Segment Routing Parameters" registry.

Because SR inter-working requires co-operation between inter-working domains, this document introduces no security consideration beyond those addressed in , and .

Thanks to Ram Santhanakrishnan, Srihari Sangli, Rajendra Prasad Bollam and Kiran Kushalad for their valuable comments.