SPRING Working Group J. Dong
Internet-Draft Huawei Technologies
Intended status: Standards Track T. Miyasaka
Expires: 9 November 2025 KDDI Corporation
Y. Zhu
China Telecom
F. Qin
Z. Li
China Mobile
8 May 2025
Introducing Resource Awareness to SR Segments
draft-ietf-spring-resource-aware-segments-12
Abstract
This document describes the mechanism to allocate network resources
to one or a set of Segment Routing Identifiers (SIDs). Such SIDs are
referred to as resource-aware SIDs. The resource-aware SIDs retain
their original forwarding semantics, with the additional semantics to
identify the set of network resources available for the packet
processing and forwarding action. A list of resource-aware SIDs can
be used to allow an SR Policy to use a specific set of network
resources, and a group of resource-aware SIDs can be used to
represent a virtual network with a specific set of reserved network
resources. The proposed mechanism is applicable to both segment
routing with MPLS data plane (SR-MPLS) and segment routing with IPv6
data plane (SRv6).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 9 November 2025.
Dong, et al. Expires 9 November 2025 [Page 1]
Internet-Draft Resource-Aware SR Segments May 2025
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Segments with Resource Awareness . . . . . . . . . . . . . . 4
2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Control Plane Considerations . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
through an ordered list of segments. A segment is referred to by its
Segment Identifier (SID). With SR, explicit source routing can be
achieved without introducing per-path state into the network.
Compared with RSVP-TE [RFC3209], the base SR specifications do not
have the capability of reserving network resources or identifying a
set of network resources reserved for an individual or a group of
services or customers. Although a centralized controller can have a
global view of network state and can provision different services
using different SR paths, in data packet forwarding it still relies
on the DiffServ QoS mechanism [RFC2474] [RFC2475] to provide coarse-
grained traffic differentiation in the network. While such a
mechanism may be sufficient for some types of services, some
customers or services may require to have a set of dedicated network
resources allocated in the network to achieve resource isolation from
Dong, et al. Expires 9 November 2025 [Page 2]
Internet-Draft Resource-Aware SR Segments May 2025
other customers/services in the same network. Also note the number
of such customers or services could be larger than the number of
traffic classes available with DiffServ QoS.
Without needing to define new SID types, this document extends the SR
paradigm by associating SIDs with network resource attributes, so
that network resources can be allocated to one or a set of SIDs.
Such SIDs are referred to as resource-aware SIDs. These resource-
aware SIDs retain their original functionality, with the additional
semantics of identifying the set of network resources available for
the packet processing action. Typical types of network resources
include link bandwidth, buffers, and queues that are associated with
class of service, scheduling weights or time cycles, and it is also
possible to associate SR SIDs with other types of resources (e.g.,
the processing and storage resources). For a particular SR segment,
multiple resource-aware SIDs can be allocated, each of which
represents a subset of network resources allocated in the network to
meet the requirements of one or a group of customers or services.
Each subset of the network resources may be associated with one or
multiple resource-aware SIDs. The allocation of network resources to
segments can be done either via local configuration or via a
centralized controller. Other approaches are possible such as use of
a control plane signaling protocol, but they are out of the scope of
this document.
A list of resource-aware SIDs can be used to allow an SR Policy to
use a specific set of network resources. This can be useful for
service which requires dedicated network resources along the path.
In addition, a group of resource-aware SIDs can be used to represent
an SR-based virtual network (which can be Multi-Point-to-Point or
Multi-Point-to-Multi-Point) with the required network topology and
resource attributes. The resources associated with each segment of
the virtual network can be the same or different. The proposed
mechanism is applicable to SR with both MPLS data plane (SR-MPLS) and
IPv6 data plane (SRv6).
1.1. Requirements Language
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
BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Dong, et al. Expires 9 November 2025 [Page 3]
Internet-Draft Resource-Aware SR Segments May 2025
2. Segments with Resource Awareness
In Segment Routing architecture [RFC8402], several types of segments
are defined to represent either topological or service instructions.
A topological segment can be a node segment or an adjacency segment.
A service segment may be associated with specific service functions
for service chaining purpose. This document introduces additional
resource semantics to the existing types of SIDs. A resource-aware
SID retains its original functionality, with the additional semantics
of identifying a set of network resources allocated in the network
for the packet processing action. A resource-aware SID is considered
local resource-aware if the associated network resource is allocated
on a specific node in the network. A resource-aware SID is
considered global resource-aware if the associated network resource
is allocated on multiple nodes in the network. A local resource-
aware SIDs may be allocated with a dedicated set of network
resources, while for global resource-aware SIDs, a common set of
network resources may be allocated to a group of resource-aware SIDs.
This section describes the mechanisms of using resource-aware SR SIDs
to indicate the network resource information associated with the SR
paths or virtual networks based on the two SR data plane
instantiations: SR-MPLS and SRv6. The mechanisms to identify the
forwarding path or network topology with SIDs as defined in [RFC8402]
can be reused, and the control plane can be based on [RFC4915],
[RFC5120] and [RFC9350].
2.1. SR-MPLS
The MPLS instantiation of Segment Routing is specified in [RFC8660].
As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an
SR segment attached to a unidirectional adjacency or a set of
unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an
SR segment attached to an IGP prefix, which identifies an instruction
to forward the packet along the path computed using the routing
algorithm in the associated topology. An IGP node segment is an IGP-
Prefix segment that identifies a specific router (e.g., a loopback).
As described in [RFC9086] and [RFC9087], a BGP PeerAdj SID is used as
an instruction to steer over a local interface towards a specific
peer node in a peering Autonomous System (AS). These types of SIDs
can be extended to represent both the topological instructions and
the set of network resources allocated for packet processing
following the instruction.
Dong, et al. Expires 9 November 2025 [Page 4]
Internet-Draft Resource-Aware SR Segments May 2025
A resource-aware Adj-SID is a local resource-aware segment, it
represents a subset of the network resources (e.g., bandwidth, buffer
and queuing resources) on a given link, thus each resource-aware Adj-
SID is associated with a subset of the link's traffic engineering
(TE) capabilities and resources (known as TE attributes [RFC2702]).
For one IGP link, multiple resource-aware Adj-SIDs can be assigned,
each of which is associated with a subset of the link resources
allocated on the link. For one inter-domain link, multiple BGP
PeerAdj SIDs may be assigned, each of which is associated with a
subset of the link resources allocated on the inter-domain link. The
resource-aware Adj-SIDs may be associated with a specific network
topology and/or algorithm, so that it is used only for resource-aware
SR paths computed within the topology and/or algorithm.
Note this per-segment resource allocation complies with the SR
paradigm, which avoids introducing per-path state into the network.
Several approaches can be used to partition and reserve the link
resources, such as [FLEXE], logical sub-interfaces, dedicated queues,
etc. The detailed mechanism of link resource partitioning is out of
scope of this document.
A resource-aware prefix-SID is a global resource-aware segment, it is
associated with a network topology and/or algorithm which the
attached node participates in. In addition, a resource-aware prefix-
SID is allocated with a set of network resources (e.g., bandwidth,
buffer and queuing resources) on all the nodes and links
participating in the associated topology and/or algorithm. Such set
of network resources can be used for forwarding packets which are
encapsulated with this resource-aware prefix-SID along the paths
computed in the associated topology and/or algorithm.
Dong, et al. Expires 9 November 2025 [Page 5]
Internet-Draft Resource-Aware SR Segments May 2025
Although it is possible that each resource-aware prefix-SID is
allocated with a set of dedicated resources on every node and link in
the associated topology and/or algorithm, the overhead of per-prefix
resource reservation is usually considered unacceptable in both
control plane signaling and data plane states, and it is likely some
of the allocated resources will be wasted. A more practical resource
allocation approach is RECOMMENDED in this document, which is that a
common set of network resources is allocated by the network nodes and
links participating in the topology and/or algorithm, and this common
set of network resource is associated with a group of resource-aware
prefix-SIDs. Such a common set of network resources constitutes a
network resource group. For a given <topology, algorithm> tuple,
there can be one or multiple network resource groups. This way, a
group of resource-aware prefix-SIDs which are associated with the
same <topology, algorithm> tuple can share the set of network
resources in a resource group. The association between the SR SIDs
and a resource group can be provisioned using the management plane or
a control plane.
This helps to reduce the dynamics in per-prefix resource allocation
and adjustment, so that the network resource can be allocated based
on planning and does not have to rely on dynamic signaling. When the
set of nodes and links participate in a <topology, algorithm> tuple
changes, the set of network resources allocated on specific nodes and
links may need to be adjusted. This means that the resources
allocated to resource-aware Adj-SIDs on those links may have to be
adjusted and new TE attributes for the associated adj-SIDs re-
advertised.
For one IGP prefix, multiple resource-aware prefix-SIDs can be
allocated. Each resource-aware prefix-SID may be associated with a
unique <topology, algorithm> tuple, in this case different <topology,
algorithm> tuples can be used to distinguish the resource-aware
prefix-SIDs of the same prefix. In another case, for one IGP prefix,
multiple resource-aware prefix-SIDs may be associated with the same
<topology, algorithm> tuple but different resource groups, then an
additional control plane distinguisher needs to be introduced to
distinguish different resource-aware prefix-SIDs associated with the
same <topology, algorithm> but different resource groups.
A group of resource-aware Adj-SID and resource-aware Prefix-SIDs can
be used to construct the SID lists, which are used to steer the
traffic to be forwarded along the explicit paths (either strict or
loose) and processed using the set of network resources identified by
the resource-aware SIDs.
Dong, et al. Expires 9 November 2025 [Page 6]
Internet-Draft Resource-Aware SR Segments May 2025
In SR-MPLS packet forwarding, each resource-aware adj-SID identifies
both the next-hop of the node and the set of resources used for
packet processing on the outgoing interface. Each resource-aware
Prefix-SID identifies the path to the node which the prefix is
attached to, and the common set of network resources used for packet
forwarding on the transit nodes along the path. The transit nodes
use the resource-aware prefix-SIDs to determine the next-hop of the
packet and the set of associated local resources, then forward the
packet to the next-hop using the set of local resources.
When the set of network resources allocated on the egress node also
needs to be determined, it is RECOMMENDED that Penultimate Hop
Popping (PHP) [RFC3031] be disabled, otherwise the inner service
label needs to be used to infer the set of resources to be used for
packet processing on the egress node of the SR path.
This mechanism requires the allocation of additional prefix-SIDs or
adj-SIDs to identify different sets of network resources. As the
number of resource groups increases, the number of SIDs would
increase accordingly, while it should be noted that there is still no
per-path state introduced into the network.
2.2. SRv6
As specified in [RFC8986], an SRv6 Segment Identifier (SID) is a
128-bit value which consists of a locator (LOC) and a function
(FUNCT), optionally it may also contain additional arguments (ARG)
immediately after the FUNCT. The Locator part of the SID is routable
and leads to the node which instantiates that SID, which means the
Locator can be parsed by all nodes in the network. The FUNCT part of
the SID is an opaque identification of a local function bound to the
SID, and the ARG part of the SID can be used to encode additional
information for the processing of the behavior bound to the SID.
Thus the FUNCT and ARG parts can only be parsed by the node which
instantiates the SRv6 SID.
The approach of introducing resource-awareness to SRv6 is by making
the SRv6 Locators resource-aware. For one SRv6 node, multiple
resource-aware SRv6 Locators can be assigned. A resource-aware
Locator is associated with a network topology and/or algorithm in
which the node participates, and in addition, a resource-aware
Locator allocated with a set of network resources (e.g., bandwidth,
buffer, and queueing resources) on each node and the attached links
participating in the same topology and/or algorithm. Such a set of
network resources are used to forward the packets with SRv6 SIDs
which have the resource-aware Locator as its prefix, along the path
computed with the associated topology and/or algorithm. These SIDs
are called resource-aware SRv6 SIDs. Similar to the approach used
Dong, et al. Expires 9 November 2025 [Page 7]
Internet-Draft Resource-Aware SR Segments May 2025
with resource-aware prefix-SIDs in SR-MPLS, it is RECOMMENDED that a
common set of network resources are allocated by the network nodes
and links participating in a topology and/or algorithm, and this
resource group is associated with a group of resource-aware Locators
of the same topology and/or algorithm.
For one IGP link, multiple resource-aware SRv6 End.X SIDs can be
allocated to identify different set of link resources allocated on
the link. Each resource-aware End.X SID SHOULD use a resource-aware
locator as its prefix. SRv6 SIDs for other types of functions MAY
also be assigned as resource-aware SIDs, which can identify the set
of network resources allocated by the node for executing the
behavior.
A group of resource-aware SRv6 SIDs can be used to construct the SID
lists, which are used to steer the traffic to be forwarded along the
explicit paths (either strict or loose) and processed using the set
of network resources identified by the resource-aware SIDs and
Locators.
In SRv6 packet forwarding, the transit nodes uses the resource-aware
Locator of the SRv6 SID carried in the IPv6 destination address field
to determine the next-hop of the packet, and the associated set of
network resources, then the packet is forwarded to the next-hop using
the set of local resources in the resource group. On the segment
endpoint nodes, the resource-aware End.X SID identifies both the
next-hop and the set of resources used for packet processing on the
outgoing interface of the node which instantiates the SID.
This mechanism requires the allocation of additional SRv6 Locators
and SIDs to identify different set of network resources. As the
number of resource groups increases, the number of SRv6 Locators and
SIDs would increase accordingly, while it should be noted that there
is still no per-path state introduced into the network.
3. Control Plane Considerations
The mechanism described in this document makes use of a centralized
controller to collect the information about the network
(configuration, state, routing databases, etc.) as well as the
service information (traffic matrix, performance statistics, etc.)
for the planning of network resources based on the service
requirement. Then the centralized controller instructs the network
nodes to allocate the network resources and associate the resources
with resource-aware SIDs. The resource-aware SIDs can be either
explicitly provisioned by the controller, or dynamically allocated by
network nodes then reported to the controller. The controller is
also responsible for the centralized computation and optimization of
Dong, et al. Expires 9 November 2025 [Page 8]
Internet-Draft Resource-Aware SR Segments May 2025
the SR paths taking the topology, algorithm and network resource
constraints into consideration. The interaction between the
controller and the network nodes can be based on Netconf/YANG
[RFC6241] [RFC7950], BGP-LS [RFC9552], BGP SR Policy
[I-D.ietf-idr-sr-policy-safi] or PCEP [RFC5440]. In some scenarios,
extensions to some of these protocols are needed, which are out of
the scope of this document. In some cases, a centralized controller
may not be used, but this would complicate the operations and
planning therefore is not suggested.
On network nodes, the support for a resource group and the
information to associate packets with that resource group needs to be
advertised in the control plane, so that all the nodes have a
consistent view of the resource group. Given that resource
management is a central function, the knowledge of the exact
resources provided to a resource group needs to be known accurately
by the relevant central control components (e.g., PCE) and the
network nodes. This may be done by configuration, alternative
protocols, or by advertisements in the IGP for collection by BGP-LS.
If there are related link advertisements, then consistency MUST be
assured across that set of advertisements.
The distributed control plane is complementary to the centralized
controller. A distributed control plane can be used for the
collection and distribution of the network topology and resource
information associated with the resource-aware SIDs among network
nodes, then some of the nodes can distribute the collected
information to the centralized controller. To advertise the support
for a given resource group, a node needs to advertise the identifier
of the resource group, the associated topology and algorithm, the
resource-aware SIDs and potentially a set of TE attributes
representing the resources allocated to it. Distributed route
computation with topology, algorithm and/or resource constraints may
also be performed by network nodes. The distributed control plane
may be based on [RFC4915], [RFC5120], [RFC9350] with necessary
extensions.
When a network node is instructed to associate a SID with specific
resources, its actions will depend on the operational configuration
of the network. In some cases the association between SIDs and
resources is configured on the individual network nodes, and the
control plane (e.g. IGP) is used to distribute the SID information
and resource availability to the controller and the ingress nodes for
TE constraint-based path computation. In hybrid cases with SR and
other TE mechanisms co-existing in the network, the IGP
advertisements of available resources may need to be updated to
indicate that there has been a change to the available resources
resulting from the instantiation of a new resource-aware SID: such
Dong, et al. Expires 9 November 2025 [Page 9]
Internet-Draft Resource-Aware SR Segments May 2025
updates would be rate-limited in the normal way. In still other
cases the association between SIDs and network resources is known by
the central controller which is responsible for all TE management,
the distributed control plane does not need to take any additional
action.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The security considerations of segment routing in [RFC8402] [RFC8754]
are applicable to this document.
The resource-aware SIDs may be used for provisioning of SR paths or
virtual networks to carry traffic with specific SLA requirement (such
as latency). By disrupting the SLA of such traffic an attack can be
directly targeted at the customer application, or can be targeted at
the network operator by causing them to violate their SLA, triggering
commercial consequences. Dynamic attacks of this sort are not
something that networks have traditionally guarded against, and
networking techniques need to be developed to defend against this
type of attack. By rigorously policing ingress traffic and carefully
provisioning network resources provided to such services, this type
of attack can be prevented. However care needs to be taken when
providing shared resources, and when the network needs to be
reconfigured as part of ongoing maintenance or in response to a
failure.
The details of the underlay network MUST NOT be exposed to third
parties, to prevent attacks aimed at exploiting shared network
resources.
6. Contributors
Dong, et al. Expires 9 November 2025 [Page 10]
Internet-Draft Resource-Aware SR Segments May 2025
Stwart Bryant
Email: stewart.bryant@gmail.com
Francois Clad
Email: fclad@cisco.com
Zhenbin Li
Email: lizhenbin@huawei.com
Zhibo Hu
Email: huzhibo@huawei.com
Joel Halpern
Email: jmh@joelhalpern.com
7. Acknowledgements
The authors would like to thank Mach Chen, Stefano Previdi, Charlie
Perkins, Bruno Decraene, Loa Andersson, Alexander Vainshtein and John
Drake for the valuable discussion and suggestions to this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
Dong, et al. Expires 9 November 2025 [Page 11]
Internet-Draft Resource-Aware SR Segments May 2025
[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>.
8.2. Informative References
[FLEXE] "Flex Ethernet Implementation Agreement", March 2016,
<https://www.oiforum.com/wp-content/uploads/2019/01/OIF-
FLEXE-01.0.pdf>.
[I-D.ietf-idr-sr-policy-safi]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., and
D. Jain, "Advertising Segment Routing Policies in BGP",
Work in Progress, Internet-Draft, draft-ietf-idr-sr-
policy-safi-13, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-safi-13>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999,
<https://www.rfc-editor.org/info/rfc2702>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>.
Dong, et al. Expires 9 November 2025 [Page 12]
Internet-Draft Resource-Aware SR Segments May 2025
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[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>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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>.
[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>.
[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>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[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>.
Dong, et al. Expires 9 November 2025 [Page 13]
Internet-Draft Resource-Aware SR Segments May 2025
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Authors' Addresses
Jie Dong
Huawei Technologies
Email: jie.dong@huawei.com
Takuya Miyasaka
KDDI Corporation
Email: ta-miyasaka@kddi.com
Yongqing Zhu
China Telecom
Email: zhuyq8@chinatelecom.cn
Fengwei Qin
China Mobile
Email: qinfengwei@chinamobile.com
Zhenqiang Li
China Mobile
Email: li_zhenqiang@hotmail.com
Dong, et al. Expires 9 November 2025 [Page 14]