Segment Routing based Network Resource Partition (NRP) for Enhanced VPN

2.1. SR-MPLS based NRP

This section describes a mechanism of allocating resource-aware SIDs to SR-MPLS based NRPs.¶

For an IGP link, multiple resource-aware adj-SIDs are allocated, each of which is associated with an NRP that the link participates in, and represents those link resources that are allocated to the NRP. For an IGP node, multiple resource-aware prefix-SIDs are allocated, each of which is associated with an NRP which the node participates in, and identifies the set of network resources allocated to the NRP on network nodes which participate in the NRP. These set of resources will be used by the network nodes to process packets which have the resource-aware SIDs as the active segment.¶

In the case of multi-domain NRPs, on an inter-domain link, multiple resource-aware BGP peering SIDs [RFC9086] are allocated, each of which is associated with an NRP which spans multiple domains, and represents a subset of resources allocated on the inter-domain link.¶

2.2. SRv6 based NRP

This section describes a mechanism of allocating resource-aware SRv6 Locators and resource-aware SRv6 SIDs to SRv6 based NRPs.¶

An resource-aware SRv6 Locator is allocated on each network node for each NRP in which the node participates. This Locator (the NRP-specific Locator) identifies the set of network resources allocated to the NRP on the network nodes which participate in the NRP. The resource-aware SRv6 SIDs associated with an NRP are allocated from the SID space using the NRP-specific resource-aware Locator as the covering prefix. These SRv6 SIDs can be used to indicate SRv6 functions in an NRP, and can identify the set of resources used by network nodes for executing the function.¶

2.3. NRP Identification

In a simple case, each NRP can be mapped to a unique topology or algorithm. Then the NRPs can be distinguished by the topology ID or algorithm ID in the control plane, and the resource-aware SIDs associated with an NRP can be identified using the <topology, algorithm> tuple as described in [RFC8402]. In this case, the number of NRPs supported in a network relies on the number of topologies or algorithms supported in the network.¶

In a more complicated case, multiple NRPs may be associated with the same <topology, algorithm> tuple, while each is allocated a separate set of network resources. Then a new NRP identifier (NRP ID) in the control plane is needed. The resource-aware SIDs of different NRPs are associated with different NRP IDs in the control plane.¶

In both cases, in the data plane, the resource-aware SIDs are used to distinguish packets of different NRPs, and are also used to determine the forwarding instructions and the set of network resources used for the packet processing action.¶

2.4. Scalability Considerations

Since multiple NRPs can be created in a network, and each NRP is allocated with a group of resource-aware SIDs, the mechanism of SR based NRPs increases the number of SIDs and SRv6 Locators needed in a network. There may be some concerns, especially about the SR-MPLS prefix-SIDs, which are allocated from the Segment Routing Global Block (SRGB), that the SRGB will be used up. The amount of network state will also increase accordingly. However, based on the SR paradigm, resource-aware SIDs and the associated network state are allocated and maintained per NRP, thus per-path network state is avoided in the SR network. In the control plane, the amount of information to be distributed in the distributed protocols (e.g., IGP) for different NRPs may become a concern. The scalability of resource-aware SID based NRPs are further analysed in [I-D.ietf-teas-nrp-scalability].¶

3.1. NRP Topology and Resource Planning

A centralized network controller can be responsible for the planning of an NRP to meet the received service request. The controller needs to collect the information on network connectivity, network resources, network performance and any other relevant network states from the underlay network. This can be done using either IGP TE extensions such as [RFC5305] [RFC3630] [RFC7471] [RFC8570], and/or BGP-LS [RFC7752] [RFC8571], or any other form of control plane signaling.¶

Based on the information collected from the underlay network, the controller obtains the underlay network topology and the information about the allocated and available network resources. When a service request is received, the controller determines the subset of the network topology, and the subset of resources needed on each network segment (e.g., links and nodes) in the sub-topology to meet the service requirements, whilst maintaining the needs of the existing services that are using the same network. The subset of the network topology and network resources will be used to constitute an NRP, which will be used as the virtual underlay network of the requested service.¶

3.2. NRP Network Resource and SID Allocation

According to the result of NRP planning, the network controller instructs the set of network nodes involved to join a specific NRP and allocate the required set of network resources for the NRP. This may be done with Netconf/YANG [RFC6241] [RFC7950] or with any other control or management plane mechanism with necessary extensions. Thus, the controller not only allocates the resources to the newly computed NRP, but also keeps track of the remaining available resources in order to cope with subsequent NRP requests.¶

On each network node involved in the NRP, a set of network resources (e.g., link bandwidth) is allocated to the NRP. Such set of network resources can be dedicated for the processing of traffic in that NRP, and may not be used for traffic in other NRPs. Note it is also possible that a group of NRPs may share a set of network resources on some network segments. A group of resource-aware SIDs, such as prefix-SIDs and adj-SIDs are allocated to identify both the network segments and the set of resources allocated on the network segments for the NRP. Such group of resource-aware SIDs, e.g., prefix-SIDs and adj-SIDs are used as the data plane identifiers of the nodes and links in the NRP.¶

In the underlying forwarding plane, there can be multiple ways of allocating a subset of network resources to an NRP. The candidate data plane technologies to support resource partitioning or reservation can be found in [I-D.ietf-teas-enhanced-vpn]. The resource-aware SIDs are considered as abstract data plane identifiers in the network layer, which can be used with various network resource partitioning or reservation mechanisms in the underlying forwarding plane.¶

    Prefix-SIDs:                         Prefix-SIDs:
      r:101                               r:102
      g:201                               g:202
      b:301      r:1001:1G    r:1001:1G   b:302
         +-----+ g:2001:2G    g:2001:2G +-----+
         |  A  | b:3001:1G    b:3001:1G |  B  |
         |     +------------------------+     + r:1003:1G
         +--+--+                        +--+--+\g:2003:2G
   r:1002:1G|                     r:1002:1G|    \
   g:2002:2G|                     g:2002:2G|     \ r:1001:1G
   b:3002:3G|                     b:3002:2G|      \g:2001:2G
            |                              |       \ +-----+Prefix-SIDs:
            |                              |        \+  E  |   r:105
            |                              |        /+     |   g:205
   r:1001:1G|                     r:1002:1G|       / +-----+
   g:2001:2G|                     g:2002:2G|      /r:1002:1G
   b:3001:3G|                     b:3002:2G|     / g:2002:2G
         +--+--+                        +--+--+ /
         |     |                        |     |/r:1003:1G
         |  C  +------------------------+  D  + g:2003:2G
         +-----+ r:1002:1G    r:1001:1G +-----+
  Prefix-SIDs:   g:2002:1G    g:2001:1G   Prefix-SIDs:
      r:103      b:3002:2G    b:3001:2G     r:104
      g:203                                 g:204
      b:303                                 b:304

      Figure 1. SID and resource allocation for multiple NRPs

Figure 1 shows an example of providing multiple NRPs in an SR based network. The prefix-SIDs are labeled as such in the figure. All other SIDs in the figure are adj-SIDs. Note that the format of the SIDs in this figure is for illustration, both SR-MPLS and SRv6 can be used as the data plane. In this example, three NRPs: red (r) , green (g) and blue (b) are created to carry traffic of different customers or services. Both the red and green NRPs consist of nodes A, B, C, D, and E with all their interconnecting links, whilst the blue NRP only consists of nodes A, B, C and D with all their interconnecting links. Note that different NRPs may have a set of shared nodes and links, but with different set of resources. On each node, a resource-aware prefix-SID is allocated for each NRP it participates in. And on each link, a resource-aware adj-SID is allocated for each NRP it participates in.¶

In Figure 1, the notation x:nnnn:y means that in NRP x, the adj-SID nnnn will steer the packet over a link which has bandwidth y reserved for that NRP. For example, r:1002:1G in link C->D says that the NRP red has a reserved bandwidth of 1Gb/s on link C->D, and will be used by packets arriving at node C with an adj-SID 1002 at the top of the label stack. Similarly, on each node, a resource-aware prefix-SID is allocated for each NRP it participates in. Each resource-aware adj-SID can be associated with a set of link resources (e.g., bandwidth) allocated to a specific NRP, so that different adj-SIDs can be used to steer traffic into different set of link resources for packet forwarding. A resource-aware prefix-SID in an NRP can be associated with the set of network resources allocated to this NRP on each involved network node and link. Thus, the prefix-SIDs can be used to build loose SR path within an NRP, and can be used by the transit nodes to steer traffic into the set of local network resources allocated to the NRP.¶

3.3. Construction of SR based NRPs

The network controller needs to obtain the information about all the NRPs in the network it oversees, including the resource-aware SIDs and the associated network resources and topology information. Based on this information, the controller can have a global view of the NRP topologies, network resources and the associated SIDs, so as to perform NRP-specific explicit path computation, taking both the topology and resource constraints of the NRPs into consideration, and use the resource-aware SIDs to build the SID list for the explicit SR path. The controller may also compute the shortest paths in the NRP based on the resource-aware prefix-SIDs.¶

The network nodes also need to obtain the information about the NRPs they participate in, including the resource-aware SIDs and the associated network resources and topology information. Based on the collected information, the network nodes which are the headend of a path can perform NRP-specific path computation, and build the SID list using the collected resource-aware adj-SIDs and prefix-SIDs. The network nodes also need to generate the forwarding entries for the resource-aware prefix-SIDs in each NRP they participates in, and associate these forwarding entries with the set of local network resources (e.g., bandwidth on the outgoing interface) allocated to the corresponding NRP.¶

Thus, after receiving the network controller's instruction about network resource and SID allocation, each network node needs to advertise the identifier of the NRPs it participates in, the group of resource-aware SIDs allocated to each NRP, and the resource attributes (e.g., bandwidth) associated with the resource-aware SIDs in the network. Each resource-aware adj-SID is advertised with the set of associated link resources, and each resource-aware prefix-SID is advertised with the identifier of the associated NRP, as all the prefix-SIDs in an NRP are associated with the same set of network resources allocated to the NRP. Note that, as described in section 2.3, in the control plane, NRPs can be identified either using existing identifiers, such as the MT-ID or Flex-Algo ID, or using a newly defined NRP ID.¶

The IGP mechanisms which reuse the existing IDs (such as Multi-Topology [RFC5120] or Flex-Algo [RFC9350]) as the identifier of NRPs, and distribute the resource-aware SIDs with the associated topology and resource information may be based on the mechanisms described in [I-D.ietf-lsr-isis-sr-vtn-mt] and [I-D.zhu-lsr-isis-sr-vtn-flexalgo] respectively. The corresponding BGP-LS mechanisms which can be used to distribute both the intra-domain NRP information and the inter-domain NRP-specific link information to the controller may be based on the mechanisms described in [I-D.ietf-idr-bgpls-sr-vtn-mt] and [I-D.zhu-idr-bgpls-sr-vtn-flexalgo] respectively. Note that with these mechanisms, the number of NRPs supported relies on the number of topologies or algorithms supported.¶

The IGP mechanisms described in [I-D.dong-lsr-sr-enhanced-vpn] introduce a new control plane identifier, so that multiple NRPs can be mapped to the same <topology, algorithm> tuple, while each NRP can have different resource attributes. This provides a mechanism which allows flexible combination of network topology and network resources attributes to build a large number of NRPs with a relatively small number of topologies or algorithms. The corresponding BGP-LS mechanisms which may be used to distribute the intra-domain NRP information and the inter-domain NRP-specific link information to the controller are described in [I-D.dong-idr-bgpls-sr-enhanced-vpn].¶

Figure 2 shows the three SR based NRPs created in the network in Figure 1.¶

      1001  1001                 2001  2001                 3001  3001
   101---------102            201---------202            301---------302
    |           | \1003        |           | \2003        |           |
1002|       1002|  \ 1001  2002|       2002|  \ 2001  3002|       3002|
    |           |  105         |           |  205         |           |
1001|       1002|  / 1002  2001|       2002|  / 2002  3001|       3002|
    |           | / 1003       |           | / 2003       |           |
   103---------104            203---------204            303---------304
      1002  1001                 2002  2001                 3002  3001
       NRP Red                   NRP Green                   NRP Blue

         Figure 2. SR based NRPs with different groups of SIDs

For each SR based NRP, SR paths are computed within the NRP, taking the NRP topology and resources as constraints. The SR path can be an explicit path instantiated using SR policy [RFC9256], in which the SID-list is built only with the SIDs allocated to the NRP. The SR path can also be an IGP computed path associated with a prefix-SID or SRv6 End SID allocated by a node for the NRP, the IGP path computation is also based on the topology and/or algorithm constraints of the NRP. Different SR paths in the same NRP may use shared network resources when they use the same resource-aware SIDs allocated to the NRP, while SR paths in different NRPs use different set of network resources even when they traverse the same network links or nodes. These NRP-specific SR paths need to be installed in the corresponding forwarding tables.¶

For example, to create an explicit path A-B-D-E in NRP red in Figure 2, the SR SID-list encapsulated in the service packet would be (1001, 1002, 1003). For the same explicit path A-B-D-E in NRP green, the SR segment list would be (2001, 2002, 2003). In the case where we wish to construct a loose path A-D-E in NRP green, the packet should be encapsulated with the SR SID-list (201, 204, 205). At node A, the packet can be sent towards D via either node B or C using the network resources allocated by these nodes for NRP green. At node D, the packet is forwarded to E using the link and node resource allocated for NRP green. Similarly, a packet to be sent via loose path A-D-E in NRP red would be encapsulated with segment list (101, 104, 105). In the case where an IGP computed path can meet the service requirement, the packet can be simply encapsulated with the prefix-SID of the egress node E in the corresponding NRP.¶

3.4. Mapping Services to SR based NRP

Network services can be provisioned using SR based NRPs as the virtual underlay networks. For example, different services may be provisioned in different SR based NRPs, each of which would use the network resources allocated to the NRP, so that their data traffic will not interfere with each other. In another case, a group of services which have similar characteristics and requirements may be provisioned in the same NRP, in this case the network resources allocated to the NRP are only shared among this group of services, but will not be shared with other services in the network. The steering of service traffic to SR based NRPs can be based on either local policy or, for example, the mechanisms as defined in [RFC9256].¶

3.5. NRP Visibility to Customers

NRPs can be used by network operators to organize and split their network infrastructure into different virtual underlay networks for different customers or services. Some customers may also request different granularity of visibility into the NRP which is used to deliver the service. Depending on the requirement and the network operator's policy, NRPs may be exposed to the customer either as a virtual network with both the edge nodes and the intermediate nodes, as a set of paths with some of the transit nodes, or simply as a set of virtual connections between the endpoints without any transit node information. The visibility may be delivered through different mechanisms, such as IGPs (e.g., IS-IS, OSPF), BGP-LS or Netconf/YANG. On the other hand, a network operator may want to restrict the visibility of the underlay network information it delivers to the customer by either hiding the transit nodes between sites (and only delivering information about the endpoint connectivity), or by hiding some of the transit nodes (summarizing the path into fewer nodes). The information about NRPs which are not used by the customer should also be filtered. Mechanisms such as BGP-LS allow the flexibility of the advertisement of aggregated virtual network information and configurable filtering policies.¶

10.1. Normative References

[I-D.ietf-spring-resource-aware-segments]

Dong, J., Miyasaka, T., Zhu, Y., Qin, F., and Z. Li, "Introducing Resource Awareness to SR Segments", Work in Progress, Internet-Draft, draft-ietf-spring-resource-aware-segments-08, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-spring-resource-aware-segments-08>.

[I-D.ietf-teas-enhanced-vpn]

Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A Framework for NRP-based Enhanced Virtual Private Network", Work in Progress, Internet-Draft, draft-ietf-teas-enhanced-vpn-17, 25 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-enhanced-vpn-17>.

[RFC8402]

Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8660]

Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.

[RFC8754]

Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, <https://www.rfc-editor.org/info/rfc8754>.

[RFC8986]

Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, <https://www.rfc-editor.org/info/rfc8986>.

10.2. Informative References

[DetNet]

"DetNet WG", 2016, <https://datatracker.ietf.org/wg/detnet>.

[I-D.dong-idr-bgpls-sr-enhanced-vpn]

Dong, J., Hu, Z., Li, Z., Tang, X., and R. Pang, "BGP-LS Extensions for Scalable Segment Routing based Enhanced VPN", Work in Progress, Internet-Draft, draft-dong-idr-bgpls-sr-enhanced-vpn-05, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-dong-idr-bgpls-sr-enhanced-vpn-05>.

[I-D.dong-lsr-sr-enhanced-vpn]

Dong, J., Hu, Z., Li, Z., Tang, X., Pang, R., and S. Bryant, "IGP Extensions for Scalable Segment Routing based Virtual Transport Network (VTN)", Work in Progress, Internet-Draft, draft-dong-lsr-sr-enhanced-vpn-10, 23 October 2023, <https://datatracker.ietf.org/doc/html/draft-dong-lsr-sr-enhanced-vpn-10>.

[I-D.ietf-idr-bgpls-sr-vtn-mt]

Xie, C., Li, C., Dong, J., and Z. Li, "BGP-LS with Multi-topology for Segment Routing based Virtual Transport Networks", Work in Progress, Internet-Draft, draft-ietf-idr-bgpls-sr-vtn-mt-03, 10 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-sr-vtn-mt-03>.

[I-D.ietf-lsr-isis-sr-vtn-mt]

Xie, C., Ma, C., Dong, J., and Z. Li, "Applicability of IS-IS Multi-Topology (MT) for Segment Routing based Network Resource Partition (NRP)", Work in Progress, Internet-Draft, draft-ietf-lsr-isis-sr-vtn-mt-07, 23 January 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-sr-vtn-mt-07>.

[I-D.ietf-teas-ietf-network-slices]

Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-25, 14 September 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-25>.

[I-D.ietf-teas-nrp-scalability]

Dong, J., Li, Z., Gong, L., Yang, G., Mishra, G. S., and F. Qin, "Scalability Considerations for Network Resource Partition", Work in Progress, Internet-Draft, draft-ietf-teas-nrp-scalability-03, 21 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-nrp-scalability-03>.

[I-D.zhu-idr-bgpls-sr-vtn-flexalgo]

Zhu, Y., Dong, J., and Z. Hu, "BGP-LS with Flex-Algo for Segment Routing based Virtual Transport Networks", Work in Progress, Internet-Draft, draft-zhu-idr-bgpls-sr-vtn-flexalgo-01, 22 February 2021, <https://datatracker.ietf.org/doc/html/draft-zhu-idr-bgpls-sr-vtn-flexalgo-01>.

[I-D.zhu-lsr-isis-sr-vtn-flexalgo]

Zhu, Y., Dong, J., and Z. Hu, "Using Flex-Algo for Segment Routing (SR) based Virtual Transport Network (VTN)", Work in Progress, Internet-Draft, draft-zhu-lsr-isis-sr-vtn-flexalgo-06, 10 July 2023, <https://datatracker.ietf.org/doc/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-06>.

[RFC3630]

Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.

[RFC4915]

Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.

[RFC5120]

Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.

[RFC5305]

Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7471]

Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.

[RFC7752]

Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8570]

Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March 2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8571]

Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, March 2019, <https://www.rfc-editor.org/info/rfc8571>.

[RFC9086]

Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, <https://www.rfc-editor.org/info/rfc9086>.

[RFC9232]

Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, <https://www.rfc-editor.org/info/rfc9232>.

[RFC9256]

Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, <https://www.rfc-editor.org/info/rfc9256>.

[RFC9350]

Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, <https://www.rfc-editor.org/info/rfc9350>.