draft-ietf-spring-resource-aware-segments-00.txt   draft-ietf-spring-resource-aware-segments-01.txt 
SPRING Working Group J. Dong SPRING Working Group J. Dong
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track S. Bryant Intended status: Standards Track S. Bryant
Expires: January 31, 2021 Futurewei Technologies Expires: July 22, 2021 Futurewei Technologies
T. Miyasaka T. Miyasaka
KDDI Corporation KDDI Corporation
Y. Zhu Y. Zhu
China Telecom China Telecom
F. Qin F. Qin
Z. Li Z. Li
China Mobile China Mobile
F. Clad F. Clad
Cisco Systems Cisco Systems
July 30, 2020 January 18, 2021
Introducing Resource Awareness to SR Segments Introducing Resource Awareness to SR Segments
draft-ietf-spring-resource-aware-segments-00 draft-ietf-spring-resource-aware-segments-01
Abstract Abstract
This document describes the mechanism to associate network resource This document describes the mechanism to associate network resource
attributes to Segment Routing Identifiers (SIDs). Such SIDs are attributes to Segment Routing Identifiers (SIDs). Such SIDs are
referred to as resource-aware SIDs in this document. The resource- referred to as resource-aware SIDs in this document. The resource-
aware SIDs retain their original forwarding semantics, but with the aware SIDs retain their original forwarding semantics, but with the
additional semantics to identify the set of network resources additional semantics to identify the set of network resources
available for the packet processing action. The resource-aware SIDs available for the packet processing action. The resource-aware SIDs
can therefore be used to build SR paths or virtual networks with a can therefore be used to build SR paths or virtual networks with a
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2021. This Internet-Draft will expire on July 22, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Segments with Resource Awareness . . . . . . . . . . . . . . 3 2. Segments with Resource Awareness . . . . . . . . . . . . . . 3
2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Control Plane Considerations . . . . . . . . . . . . . . . . 6 3. Control Plane Considerations . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets Segment Routing (SR) [RFC8402] specifies a mechanism to steer packets
through an ordered list of segments. A segment is referred to by its through an ordered list of segments. A segment is referred to by its
Segment Identifier (SID). With SR, explicit source routing can be Segment Identifier (SID). With SR, explicit source routing can be
achieved without introducing per-path state into the network. achieved without introducing per-path state into the network.
Compared with RSVP-TE [RFC3209], currently SR does not have the Compared with RSVP-TE [RFC3209], currently SR does not have the
capability of reserving network resources or identifying a set of capability of reserving network resources or identifying a set of
network resources reserved for individual services or customers. network resources reserved for individual services or customers.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
require a set of dedicated network resources to be allocated in the require a set of dedicated network resources to be allocated in the
network to achieve resource isolation from other customers/services network to achieve resource isolation from other customers/services
in the same network. Also note the number of such customers or in the same network. Also note the number of such customers or
services can be larger than the number of traffic classes available services can be larger than the number of traffic classes available
with DiffServ QoS. with DiffServ QoS.
This document extends the SR paradigm without the need of defining This document extends the SR paradigm without the need of defining
new SID types by associating SIDs with network resource attributes. new SID types by associating SIDs with network resource attributes.
These resource-aware SIDs retain their original functionality, with These resource-aware SIDs retain their original functionality, with
the additional semantics of identifying the set of network resources the additional semantics of identifying the set of network resources
available for the packet processing action. On a particular network available for the packet processing action. One typical type of the
segment, multiple resource-aware SIDs can be allocated, each of which network resource is bandwidth, but it is also possible to associate
represents a subset of network resources allocated to meet the SR SIDs with other types of resources (e.g., processing or storage
requirement of individual customers or services. The allocation of resources). On a particular network segment, multiple resource-aware
network resources on a network segment can be done via a controller SIDs can be allocated, each of which represents a subset of network
or via local configuration, then each set of resource is associated resources allocated in the network to meet the requirement of
with a resource-aware SID. These resource-aware SIDs can be used to individual customers or services. The allocation of network
build SR paths with a set of reserved network resources, which can be resources on network segments can be done either via local
used in network scenarios which require to allocate a set of network configuration or via a centralized controller. Other approaches are
resources for the processing of groups of service traffic. The possible such as use of a control protocol signaling, but they are
resource-aware SIDs can also be used to build SR based virtual for further study. Each set of network resources can be associated
networks with the required network topology and resource attributes. with one or multiple resource-aware SIDs. These resource-aware SIDs
The proposed mechanism is applicable to SR with both MPLS data plane can be used to build SR paths with a set of reserved network
(SR-MPLS) and IPv6 data plane (SRv6). resources, which can be used to carry service traffic which requires
dedicated network resources. The resource-aware SIDs can also be
used to build SR based virtual networks with the required network
topology and resource attributes. The proposed mechanism is
applicable to SR with both MPLS data plane (SR-MPLS) and IPv6 data
plane (SRv6).
2. Segments with Resource Awareness 2. Segments with Resource Awareness
In segment routing architecture [RFC8402], several types of segments In segment routing architecture [RFC8402], several types of segments
are defined to represent either topological or service instructions. are defined to represent either topological or service instructions.
A topological segment can be a node segment or an adjacency segment. A topological segment can be a node segment or an adjacency segment.
A service segment may be associated with specific service functions A service segment may be associated with specific service functions
for service chaining purposes. This document introduces additional for service chaining purpose. This document introduces additional
resource semantics to these existing types of SIDs, so that the SIDs resource semantics to these existing types of SIDs, so that the SIDs
can be used to identify the topology or service functions, and the can be used to identify the topology or service functions, and also
set of network resources allocated on the network segments for packet the set of network resources allocated on the network segments for
processing. packet processing.
This section describes the mechanisms of using SR SIDs to identify This section describes the mechanisms of using SR SIDs to identify
the additional resource information of SR paths or virtual networks the additional resource information associated with SR paths or
with the two SR data plane instantiations: SR-MPLS and SRv6. The virtual networks based on the two SR data plane instantiations: SR-
mechanisms to identify the forwarding path or network topology with a MPLS and SRv6. The mechanisms to identify the forwarding path or
SID as defined in [RFC8402] are unchanged, and the control plane can network topology with SIDs as defined in [RFC8402] can be reused, and
be based on [RFC4915], [RFC5120] and [I-D.ietf-lsr-flex-algo]. the control plane can be based on [RFC4915], [RFC5120] and
[I-D.ietf-lsr-flex-algo].
2.1. SR-MPLS 2.1. SR-MPLS
As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an As specified in [RFC8402], an IGP Adjacency Segment (Adj-SID) is an
IGP-segment attached to a unidirectional adjacency or a set of SR segment attached to a unidirectional adjacency or a set of
unidirectional adjacencies. An IGP Prefix segment is an IGP segment unidirectional adjacencies. An IGP Prefix Segment (Prefix-SID) is an
representing an IGP prefix, and IGP node segment is an IGP-Prefix SR segment attached to an IGP prefix, which identifies an instruction
segment that identifies a specific router (e.g., a loopback). As to forward the packet along the path computed using the routing
described in [I-D.ietf-spring-segment-routing-central-epe] and 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 [I-D.ietf-spring-segment-routing-central-epe] and
[I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as [I-D.ietf-idr-bgpls-segment-routing-epe], BGP PeerAdj SID is used as
an instruction to steer over a specific local interface towards a an instruction to steer over a local interface towards a specific
specific peer node in a peering Autonomous System (AS). These types peer node in a peering Autonomous System (AS). These types of SIDs
of SIDs can be extended to represent both topological elements and can be extended to represent both topological instructions and the
the resources allocated on a network segment. The MPLS instantiation set of network resources allocated for packet processing following
of Segment Routing is specified in [RFC8660]. the instruction. The MPLS instantiation of Segment Routing is
specified in [RFC8660].
For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of For one IGP link, multiple resource-aware Adj-SIDs SHOULD be
which is associated with a network topology the link participates, allocated, each of which is associated with a subset of the link
and MAY represent a subset of link resources. Several approaches can resources allocated on the link, e.g. the link bandwidth. For one
be used to partition the link resource, such as [FLEXE], Layer-2 inter-domain link, multiple BGP PeerAdj SIDs SHOULD be allocated,
logical sub-interfaces, dedicated queues, etc. The detailed each of which is associated with a subset of the link resources
mechanism of resource partitioning is out of scope of this document. 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 that this per-segment resource
allocation complies to the SR paradigm, which avoids introducing per-
path state into the network. Several approaches can be used to
partition the link resource, such as [FLEXE], Layer-2 logical sub-
interfaces, dedicated queues, etc. The detailed mechanism of link
resource partitioning is out of scope of this document.
Similarly, for one IGP node, multiple prefix-SIDs SHOULD be For one IGP prefix, multiple resource-aware prefix-SIDs SHOULD be
allocated, each of which is associated with a network topology the allocated. A resource-aware prefix SID is associated with a network
node participates, and MAY represent a subset of the node resource topology and/or algorithm in which the attached node participates,
(e.g. the processing resources). For one inter-domain link, multiple and in addition, each resource-aware prefix-SID is associated with a
BGP PeerAdj SIDs SHOULD be allocated, each of which is associated set of local resources (e.g. bandwidth, processing and storage
with a specific network topology, which spans multiple domains, and resources) on each node participating in the same topology and/or
MAY represent a subset of link resource allocated on the inter-domain algorithm. Such set of network resources are used for forwarding the
link. Note that this per-segment resource allocation complies to the packets with this resource-aware prefix-SID, along the path computed
SR paradigm, which avoids introducing per-path state into the with the associated topology and/or algorithm.
network.
A group of resource-aware SIDs associated with the same network Although each resource-aware prefix-SID can be associated with a set
topology can be used to construct the SR paths (either strict or of dedicated resources, this implies additional overhead with per-
loose) to steer traffic within the topology. Each SID in the SID- prefix resource reservation in both control plane signaling and data
list of the SR path MAY represent the set of network resources plane states, and it is likely some resources will be wasted with
reserved on the corresponding network segment. per-prefix resource allocation along all the possible paths. Thus it
is RECOMMENDED that a group of resource-aware prefix-SIDs be
associated with an aggregated set of network resources in the
network. This helps to reduce the dynamics in resource allocation,
so that the resource can be allocated based on network planning and
does not have to rely on dynamic signaling.
In data packet forwarding, the SIDs are used to identify the topology For one IGP prefix, each resource-aware prefix-SID can be associated
the packet belongs to, so that a topology specific next-hop can be with a unique <topology, algorithm> tuple, in this case different
determined. In addition, the adj-SIDs MAY also be used to steer <topology, algorithm> tuples can be used to distinguish the resource-
traffic of different services into different set of link resources. aware prefix-SIDs for the same prefix. In another case, for one IGP
The prefix-SIDs MAY be used to steer traffic of different services prefix, multiple resource-aware prefix-SIDs can be associated with
into different set of node resources. When a prefix-SID is used in the same <topology, algorithm> tuple, then an additional
the SID-list to build an SR loose path, the transit nodes can use the distinguisher needs to be introduced to distinguish different
prefix-SID to identify the network topology and the associated group resource-aware prefix-SIDs associated with the same topology and
of resource, and can process the packet using the local resources algorithm but different groups of network resources. More details
allocated to the corresponding resource group. Note in this case, it about the new distinguisher will be described in a future version.
is RECOMMENDED that Penultimate Hop Popping (PHP) [RFC3031] be
disabled, otherwise the inner service label SHOULD be used to infer A group of resource-aware SR-MPLS SIDs can be used to construct SID
the set of resources to be used on the egress node of the SR path. lists to steer the traffic along the explicit paths (either strict or
loose) and be processed using the set of network resources identified
by the SIDs.
In data packet forwarding, each resource-aware Adj-SID identifies
both the next-hop and the set of resources used for packet processing
on the outgoing interface. Each resource-aware Prefix-SID identifies
a path to the node which the prefix is attached to, and the set of
network resources used for packet forwarding on network nodes along
the path. The transit nodes determine the next-hop of the packet and
the set of associated local resources based on the resource-aware
prefix-SID, 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, or the inner service label is
used to infer the set of resources to be used for packet processing
on the egress node of the SR path.
This mechanism requires to allocate additional prefix-SIDs or adj- This mechanism requires to allocate additional prefix-SIDs or adj-
SIDs for network segments to identify different set of network SIDs for network segments to identify different set of network
resources. As the number of resource groups increases, the number of resources. As the number of resource groups increases, the number of
SIDs would increase accordingly, while it should be noted that there SIDs would increase accordingly, while it should be noted that there
is no per-path state introduced into the network. is no per-path state introduced into the network.
2.2. SRv6 2.2. SRv6
As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6 As specified in [I-D.ietf-spring-srv6-network-programming], an SRv6
Segment Identifier (SID) is a 128-bit value which consists of a Segment Identifier (SID) is a 128-bit value which consists of a
locator (LOC) and a function (FUNCT), optionally it may also contain locator (LOC) and a function (FUNCT), optionally it may also contain
additional arguments (ARG) immediately after the FUNCT. The LOC of additional arguments (ARG) immediately after the FUNCT. The Locator
the SID is routable and leads to the node which instantiates that part of the SID is routable and leads to the node which instantiates
SID, which means the LOC can be parsed by all nodes in the network. that SID, which means the Locator can be parsed by all nodes in the
The FUNCT part of the SID is an opaque identification of a local network. The FUNCT part of the SID is an opaque identification of a
function bound to the SID, which means the FUNCT and ARG parts can local function bound to the SID, and the ARG bits of the SID can be
only be parsed by the node which instantiates that SID. used to encode additional information for the processing of the
behavoir bound to the SID. The FUNCT and ARG parts can only be
parsed by the node which instantiates the SRv6 SID.
Taking the above into consideration, for a network node, multiple For one SRv6 node, multiple resource-aware SRv6 LOCs SHOULD be
SRv6 LOCs SHOULD be allocated, each of which is associated with a allocated. A resource-aware LOC is associated with a network
network topology, and MAY represent a subset of the network resources topology and/or algorithm in which the node participates, and in
associated with a virtual network. The SRv6 SIDs of a particular addition, a resource-aware LOC is associated with a set of local
virtual network SHOULD be allocated from the SID space using the resources (e.g. bandwidth, processing and storage resources) on each
resource-aware LOC as the prefix. These SRv6 SIDs can be used to node participating in the same topology and/or algorithm. Such set
represent virtual network specific local functions. of network resources are used to forward the packets with SIDs which
has the resource-aware LOC as its prefix, along the path computed
with the associated topology and/or algorithm. Similar to the
resource-aware prefix-SIDs in SR-MPLS, the network resources used for
the forwarding instruction of a group of LOCs can be aggregated, this
helps to reduce the dynamics of resource allocation, so that the
resource can be allocated based on network planning and does not have
to rely on dynamic signaling.
A group of SRv6 SIDs associated with the same network topology can be For one IGP link, the resource-aware SRv6 End.X SIDs are used to
used to construct the SR paths (either strict or loose) to steer the identify different set of link resources allocated. Each resource-
traffic of particular service within the topology. Each SID in the aware End.X SID SHOULD use a resource-aware LOC as its prefix. SRv6
SID-list of the SR path MAY also represent the set of network SIDs for other types of functions MAY also be assigned as resource-
resources on the corresponding network segment. aware SIDs, which can identify the set of network resources allocated
by the node for executing the function.
In data packet forwarding, the LOC part of SRv6 SID is used by A group of resource-aware SRv6 SIDs can be used to construct SID
transit nodes to identify the topology the packet belongs to, so that lists to steer the traffic along the explicit paths (either strict or
a topology specific next-hop can be determined. The LOC MAY also be loose) and be processed using the set of network resources identified
used to indicate the set of local network resources on the transit by the SRv6 SIDs and Locators.
nodes to be used for the forwarding of the received packet. The SRv6
segment endpoint nodes use the SRv6 SID to identify the topology the In data packet forwarding, each resource-aware End.X SID identifies
packet belongs to, and the particular local function to perform on both the next-hop and the set of resources used for packet processing
the received packet. The local SRv6 SID MAY also be used to identify on the outgoing interface. Each resource-aware Locator identifies
the set of network resource to be used for executing the local the path to the node which the LOC is assigned to, and the set of
function. network resources used for packet forwarding on network nodes along
the path. The transit nodes determine the next-hop of the packet and
the set of associated local resources based on the resource-aware
Locator, then forward the packet to the next-hop using the set of
local resources.
This mechanism requires to allocate additional SRv6 Locators and SIDs This mechanism requires to allocate additional SRv6 Locators and SIDs
for network segments to identify different set of network resources. for network segments to identify different set of network resources.
As the number of resource groups increases, the number of Locators As the number of resource groups increases, the number of SRv6
and SIDs would increase accordingly, while it should be noted that Locators and SIDs would increase accordingly, while it should be
there is no per-path state introduced into the network. noted that there is no per-path state introduced into the network.
3. Control Plane Considerations 3. Control Plane Considerations
The mechanism described in this document makes use of a centralized The mechanism described in this document makes use of a centralized
controller to collect the information about the network controller to collect the information about the network
(configuration, state, routing databases, etc.) as well as the (configuration, state, routing databases, etc.) as well as the
service information (traffic matrix, performance statistics, etc.) service information (traffic matrix, performance statistics, etc.)
for the planning of network resources based on service requirement. for the planning of network resources based on service requirement.
The controller is also responsible for the centralized computation Then the centralized controller instructs network nodes to allocate
and optimization of the SR paths with both the topology and network the network resources and associate the resources with resource-aware
resource constraints. The resource-aware SIDs can be either SIDs. The resource-aware SIDs can be either explicitly provisioned
explicitly provisioned by the controller, or dynamically allocated by by the controller, or dynamically allocated by network nodes then
network nodes then reported to the controller. The interaction reported to the controller. The controller is also responsible for
between the controller and the network nodes can be based on PCEP the centralized computation and optimization of the SR paths with the
[RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS [RFC7752]. In topology, algorithm and network resource constraints. The
some scenarios, extensions to some of these protocols is needed, interaction between the controller and the network nodes can be based
which are out of the scope of this document and will be specified in on PCEP [RFC5440], Netconf/YANG [RFC6241] [RFC7950] and BGP-LS
separate documents. In some cases, a centralized controller may not [RFC7752]. In some scenarios, extensions to some of these protocols
be used, but this would complicate the operations and planning is needed, which are out of the scope of this document and will be
therefore not suggested. specified in separate documents. In some cases, a centralized
controller may not be used, but this would complicate the operations
and planning therefore not suggested.
The distributed control plane is complementary to the centralized The distributed control plane is complementary to the centralized
controller. A distributed control plane can be used for the controller. A distributed control plane can be used for the
collection and distribution of the network topology and resource collection and distribution of the network topology and resource
information associated with SIDs among network nodes. Distributed information associated with SIDs among network nodes, then some of
route computation for services with topology and resource constraints the nodes can distribute the collected information to the centralized
may also be needed. The distributed control plane may be based on controller. Distributed route computation for services with topology
[RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo] or the combination of and resource constraints may also be needed. The distributed control
some of them with necessary extensions. The details are out of the plane may be based on [RFC4915], [RFC5120], [I-D.ietf-lsr-flex-algo]
scope of this document. or the combination of some of them with necessary extensions. The
details are out of the scope of this document.
4. IANA Considerations 4. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
5. Security Considerations 5. Security Considerations
skipping to change at page 8, line 31 skipping to change at page 9, line 44
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-lsr-flex-algo] [I-D.ietf-lsr-flex-algo]
Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and
A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex-
algo-08 (work in progress), July 2020. algo-13 (work in progress), October 2020.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
Afanasiev, "Segment Routing Centralized BGP Egress Peer Afanasiev, "Segment Routing Centralized BGP Egress Peer
Engineering", draft-ietf-spring-segment-routing-central- Engineering", draft-ietf-spring-segment-routing-central-
epe-10 (work in progress), December 2017. epe-10 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
P. Mattes, "Segment Routing Policy Architecture", draft- P. Mattes, "Segment Routing Policy Architecture", draft-
ietf-spring-segment-routing-policy-08 (work in progress), ietf-spring-segment-routing-policy-09 (work in progress),
July 2020. November 2020.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-16 (work in draft-ietf-spring-srv6-network-programming-28 (work in
progress), June 2020. progress), December 2020.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
 End of changes. 26 change blocks. 
136 lines changed or deleted 192 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/