(RFCs) SRv6 Locator and Locator-chunk Mechanism

[slankdev]

(RFC1) Locator and Locator-chunk Mechanism

A chunk is a unit of subset that logically divides a locator so that a portion of the locator is occupied by each protocol. For example, with the following configuration. There is a locator named loc1 and its prefix configure as 2001:db8:1:1::/64.

segment-routing
 srv6
  locators
   locator loc1
    prefix 2001:db8:1:1::/64
   !
  !
 !
!

Following figure shows overall object map.

Suppose that there are two protocol daemons that want to use Locator loc1. For example, bgpd and isisd. They need to allocate SIDs from 2001:db8:1:1::/64 of this locator so that they are not identical, and set the SRv6 function to be used by each routing protocol in ZEBRA_ROUTE_ADD.

How should we allocate SIDs from a single shared prefix 2001:db8:1:1::/64? There are several ways, such as (a) preparing a ZAPI of get new SID, or (b) preparing a ZAPI of get new Locator-chunk which is defining a prefix subset of locator. Since it is not efficient to perform Round Trip Communication of the ZAPI for each SID, we tried to allow each protocol to partially occupy the prefix of the locator. This method was designed based on a mechanism already implemented in FRRouting called label chunk.

Since ZAPI is serialized and executed in order, when Zebra receives a ZAPI call of ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK, it creates a locator-chunk in the context of the locator and sets a sub set prefix of the locator prefix. Following figure shows what I say.

You can check what kind of chunk is allocated for each locator as follows. In the following example, the locator loc1 has the prefix 2001:db8:1:1::/64, and there is one locator chunk. The chunk is stored in an array that can be referenced by chunks key, and there is one chunk for 2001:db8:1:1::/64. Furthermore, we can see that this chunk is occupied by bgpd.

ubuntu# sh segment-routing srv6 locator json
{
  "locators":[
    {
      "name":"loc1",
      "prefix":"2001:db8:1:1::\/64",
      "function_bits_length":0,
      "status_up":true,
      "chunks":[
        {
          "prefix":"2001:db8:1:1::\/64",
          "proto":"bgp"
        }
      ]
    }
  ]
}

In the initial locator chunk allocation mechanism as of PR5865, only one locator-chunk is allocated for each locator in order to simplify the implementation. Therefore, isisd and bgpd cannot share a single locator at this time, but we can achieve the original goal by simply modifying the locator allocation algorithm. This limitation was made to keep the PR simple and to simplify the review.

Bgpd receive the response of ZEBRA_SRV6_MANAGER_GET_LOCATOR_CHUNK api with allocated chunk information like following figure.

In this way, bgpd will be able to freely dispatch SIDs from 2001:db8:1:1::/64. If you are configuring SRv6 VPNv6 and there are two VRFs, two SRv6 functions will be configured as follows. In this case, GET_LOCATOR_CHUNK is issued to loc1, and bgpd allocates and sets the SID from the chunk it occupies.

ubuntu# sh ipv6 route 2001:db8:1:1::/64 longer-prefixes
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure
B>* 2001:db8:1:1::100/128 [20/0] is directly connected, vrf10, seg6local End.DT6 table 10, weight 1, 00:04:16
B>* 2001:db8:1:1::200/128 [20/0] is directly connected, vrf20, seg6local End.DT6 table 20, weight 1, 00:04:16

[slankdev]

This is merged #5865