< draft-ietf-spring-segment-routing-policy-07.txt   draft-ietf-spring-segment-routing-policy-08.txt >
SPRING Working Group C. Filsfils SPRING Working Group C. Filsfils
Internet-Draft S. Sivabalan, Ed. Internet-Draft K. Talaulikar, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: November 8, 2020 D. Voyer Expires: January 8, 2021 D. Voyer
Bell Canada Bell Canada
A. Bogdanov A. Bogdanov
Google, Inc. Google, Inc.
P. Mattes P. Mattes
Microsoft Microsoft
May 7, 2020 July 7, 2020
Segment Routing Policy Architecture Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-07.txt draft-ietf-spring-segment-routing-policy-08
Abstract Abstract
Segment Routing (SR) allows a headend node to steer a packet flow Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Intermediate per-flow states are eliminated thanks along any path. Intermediate per-flow states are eliminated thanks
to source routing. The headend node steers a flow into an SR Policy. to source routing. The headend node steers a flow into an SR Policy.
The header of a packet steered in an SR Policy is augmented with an The header of a packet steered in an SR Policy is augmented with an
ordered list of segments associated with that SR Policy. This ordered list of segments associated with that SR Policy. This
document details the concepts of SR Policy and steering into an SR document details the concepts of SR Policy and steering into an SR
Policy. Policy.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 8, 2020. This Internet-Draft will expire on January 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4
2.2. Candidate Path and Segment List . . . . . . . . . . . . . 4 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 4
2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 5 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 5
2.4. Originator of a Candidate Path . . . . . . . . . . . . . 5 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6
2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 6 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 6
2.6. Identification of a Candidate Path . . . . . . . . . . . 7 2.6. Identification of a Candidate Path . . . . . . . . . . . 7
2.7. Preference of a Candidate Path . . . . . . . . . . . . . 7 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 7
2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 7 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 7
2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 7
2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 9
2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 9
2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 9 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 9
2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Segment Routing Database . . . . . . . . . . . . . . . . . . 10 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 10
4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 14
5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 15 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 15
5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 15 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 15
5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 16 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 16
6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 17 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 17
6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 17 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 17
6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 22 skipping to change at page 3, line 18
9.2. Using an SR Policy to locally protect a link . . . . . . 27 9.2. Using an SR Policy to locally protect a link . . . . . . 27
9.3. Using a Candidate Path for Path Protection . . . . . . . 27 9.3. Using a Candidate Path for Path Protection . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11.1. Guidance for Designated Experts . . . . . . . . . . . . 29 11.1. Guidance for Designated Experts . . . . . . . . . . . . 29
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 31 14.1. Normative References . . . . . . . . . . . . . . . . . . 31
14.2. Informative References . . . . . . . . . . . . . . . . . 31 14.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Segment Routing (SR) allows a headend node to steer a packet flow Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Intermediate per-flow states are eliminated thanks along any path. Intermediate per-flow states are eliminated thanks
to source routing [RFC8402]. to source routing [RFC8402].
The headend node is said to steer a flow into an Segment Routing The headend node is said to steer a flow into an Segment Routing
Policy (SR Policy). Policy (SR Policy).
The header of a packet steered into an SR Policy is augmented with an The header of a packet steered into an SR Policy is augmented with an
ordered list of segments associated with that SR Policy. ordered list of segments associated with that SR Policy.
This document details the concepts of SR Policy and steering packets This document details the concepts of SR Policy and steering packets
into an SR Policy. These apply equally to the MPLS and SRv6 into an SR Policy. These apply equally to the MPLS and SRv6
instantiations of segment routing. instantiations of segment routing.
For reading simplicity, the illustrations are provided for the MPLS For reading simplicity, the illustrations are provided for the MPLS
instantiations. instantiations.
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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. SR Policy 2. SR Policy
An SR Policy is a framework that enables instantiation of an ordered An SR Policy is a framework that enables instantiation of an ordered
list of segments on a node for implementing a source routing policy list of segments on a node for implementing a source routing policy
with a specific intent for traffic steering from that node. with a specific intent for traffic steering from that node.
The Segment Routing architecture [RFC8402] specifies that any The Segment Routing architecture [RFC8402] specifies that any
instruction can be bound to a segment. Thus, an SR Policy can be instruction can be bound to a segment. Thus, an SR Policy can be
built using any type of Segment Identifier (SID) including those built using any type of Segment Identifier (SID) including those
associated with topological or service instructions. associated with topological or service instructions.
skipping to change at page 4, line 35 skipping to change at page 4, line 38
The color is a 32-bit numerical value that associates the SR Policy The color is a 32-bit numerical value that associates the SR Policy
with an intent (e.g. low-latency). with an intent (e.g. low-latency).
The endpoint and the color are used to automate the steering of The endpoint and the color are used to automate the steering of
service or transport routes on SR Policies (refer to Section 8). service or transport routes on SR Policies (refer to Section 8).
An implementation MAY allow assignment of a symbolic name comprising An implementation MAY allow assignment of a symbolic name comprising
of printable ASCII characters to an SR Policy to serve as a user- of printable ASCII characters to an SR Policy to serve as a user-
friendly attribute for debug and troubleshooting purposes. Such friendly attribute for debug and troubleshooting purposes. Such
symbolic names may identify an SR Policy when the naming scheme symbolic names may identify an SR Policy when the naming scheme
ensures uniqueness. ensures uniqueness. The SR Policy name may also be signaled along
with a candidate path of the SR Policy (refer Section 2.2). An SR
Policy may have multiple names associated with it in the scenario
where the headend receives different SR Policy names along with
candidate paths for the same SR Policy.
2.2. Candidate Path and Segment List 2.2. Candidate Path and Segment List
An SR Policy is associated with one or more candidate paths. A An SR Policy is associated with one or more candidate paths. A
candidate path is the unit for signaling of an SR Policy to a headend candidate path is the unit for signaling of an SR Policy to a headend
via protocols like Path Computation Element (PCE) Communication via protocols like Path Computation Element (PCE) Communication
Protocol (PCEP) [RFC8281] or BGP SR Policy Protocol (PCEP) [RFC8664] or BGP SR Policy
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy].
A Segment-List represents a specific source-routed path to send A Segment-List represents a specific source-routed path to send
traffic from the headend to the endpoint of the corresponding SR traffic from the headend to the endpoint of the corresponding SR
policy. policy.
A candidate path is either dynamic or explicit. A candidate path is either dynamic or explicit.
An explicit candidate path is expressed as a Segment-List or a set of An explicit candidate path is expressed as a Segment-List or a set of
Segment-Lists. Segment-Lists.
skipping to change at page 5, line 21 skipping to change at page 5, line 27
solves the optimization problem. solves the optimization problem.
If a candidate path is associated with a set of Segment-Lists, each If a candidate path is associated with a set of Segment-Lists, each
Segment-List is associated with a weight for weighted load balancing Segment-List is associated with a weight for weighted load balancing
(refer Section 2.11 for details). The default weight is 1. (refer Section 2.11 for details). The default weight is 1.
2.3. Protocol-Origin of a Candidate Path 2.3. Protocol-Origin of a Candidate Path
A headend may be informed about a candidate path for an SR Policy A headend may be informed about a candidate path for an SR Policy
<color, endpoint> by various means including: via configuration, PCEP <color, endpoint> by various means including: via configuration, PCEP
[RFC8281] or BGP [I-D.ietf-idr-segment-routing-te-policy]. [RFC8664] or BGP [I-D.ietf-idr-segment-routing-te-policy].
Protocol-Origin of a candidate path is an 8-bit value which Protocol-Origin of a candidate path is an 8-bit value which
identifies the component or protocol that originates or signals the identifies the component or protocol that originates or signals the
candidate path. candidate path.
The head-end assigns different Protocol-Origin Priority values to The head-end assigns different Protocol-Origin Priority values to
each Protocol-Origin. The Protocol-Origin Priority is used as a tie- each Protocol-Origin. The Protocol-Origin Priority is used as a tie-
breaker between candidate-paths of equal preference, as described in breaker between candidate-paths of equal preference, as described in
Section 2.9. The table below specifies the RECOMMENDED default Section 2.9. The table below specifies the RECOMMENDED default
values of Protocol-Origin Priority: values of Protocol-Origin Priority:
skipping to change at page 6, line 23 skipping to change at page 6, line 28
Section 2.9. Section 2.9.
When Protocol-Origin is Via Configuration, the ASN and node address When Protocol-Origin is Via Configuration, the ASN and node address
MAY be set to either the headend or the provisioning controller/node MAY be set to either the headend or the provisioning controller/node
ASN and address. Default value is 0 for both AS and node address. ASN and address. Default value is 0 for both AS and node address.
When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the When Protocol-Origin is PCEP, it is the IPv4 or IPv6 address of the
PCE and the AS number SHOULD be set to 0 by default when not PCE and the AS number SHOULD be set to 0 by default when not
available or known. available or known.
Protocol-Origin is BGP SR Policy, it is provided by the BGP component When Protocol-Origin is BGP SR Policy, the ASN and Node Address are
on the headend and is: provided by BGP (refer [I-D.ietf-idr-segment-routing-te-policy]) on
the headend.
o the BGP Router ID and ASN of the node/controller signalling the
candidate path when it has a BGP session to the headend, OR
o the BGP Router ID of the eBGP peer signalling the candidate path
along with ASN of origin when the signalling is done via one or
more intermediate eBGP routers, OR
o the BGP Originator ID [RFC4456] and the ASN of the node/controller
when the signalling is done via one or more route-reflectors over
iBGP session.
2.5. Discriminator of a Candidate Path 2.5. Discriminator of a Candidate Path
The Discriminator is a 32 bit value associated with a candidate path The Discriminator is a 32 bit value associated with a candidate path
that uniquely identifies it within the context of an SR Policy from a that uniquely identifies it within the context of an SR Policy from a
specific Protocol-Origin as specified below: specific Protocol-Origin as specified below:
When Protocol-Origin is Via Configuration, this is an When Protocol-Origin is Via Configuration, this is an
implementation's configuration model specific unique identifier for a implementation's configuration model specific unique identifier for a
candidate path. Default value is 0. candidate path. Default value is 0.
When PCEP is the Protocol-Origin, the method to uniquely identify When PCEP is the Protocol-Origin, the method to uniquely identify
signalled path will be specified in a future PCEP document. Default signalled path will be specified in a future PCEP document. Default
value is 0. value is 0.
When BGP SR Policy is the Protocol-Origin, it is the distinguisher When BGP SR Policy is the Protocol-Origin, it is the distinguisher
specified in Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]. (refer Section 2.1 of [I-D.ietf-idr-segment-routing-te-policy]).
Its application in the candidate path selection is described in Its application in the candidate path selection is described in
Section 2.9. Section 2.9.
2.6. Identification of a Candidate Path 2.6. Identification of a Candidate Path
A candidate path is identified in the context of a single SR Policy. A candidate path is identified in the context of a single SR Policy.
A candidate path is not shared across SR Policies. A candidate path is not shared across SR Policies.
skipping to change at page 10, line 9 skipping to change at page 9, line 50
same or different sources. A candidate path MAY be signaled with a same or different sources. A candidate path MAY be signaled with a
priority value. When an SR Policy has multiple candidate paths with priority value. When an SR Policy has multiple candidate paths with
distinct signaled non-default priority values, the SR Policy as a distinct signaled non-default priority values, the SR Policy as a
whole takes the lowest value (i.e. the highest priority) amongst whole takes the lowest value (i.e. the highest priority) amongst
these signaled priority values. these signaled priority values.
2.13. Summary 2.13. Summary
In summary, the information model is the following: In summary, the information model is the following:
SR policy POL1 <headend, color, endpoint> SR policy POL1 <headend = H1, color = 1, endpoint = E1>
Candidate-path CP1 <protocol-origin = 20, originator = Candidate-path CP1 <protocol-origin = 20, originator =
100:1.1.1.1, discriminator = 1> 100:1.1.1.1, discriminator = 1>
Preference 200 Preference 200
Weight W1, SID-List1 <SID11...SID1i> Weight W1, SID-List1 <SID11...SID1i>
Weight W2, SID-List2 <SID21...SID2j> Weight W2, SID-List2 <SID21...SID2j>
Candidate-path CP2 <protocol-origin = 20, originator = Candidate-path CP2 <protocol-origin = 20, originator =
100:2.2.2.2, discriminator = 2> 100:2.2.2.2, discriminator = 2>
Preference 100 Preference 100
Weight W3, SID-List3 <SID31...SID3i> Weight W3, SID-List3 <SID31...SID3i>
Weight W4, SID-List4 <SID41...SID4j> Weight W4, SID-List4 <SID41...SID4j>
The SR Policy POL1 is identified by the tuple <headend, color, The SR Policy POL1 is identified by the tuple <headend, color,
endpoint>. It has two candidate paths CP1 and CP2. Each is endpoint>. It has two candidate paths CP1 and CP2. Each is
identified by a tuple <protocol-origin, originator, discriminator>. identified by a tuple <protocol-origin, originator, discriminator>.
CP1 is the active candidate path (it is valid and it has the highest CP1 is the active candidate path (it is valid and it has the highest
preference). The two Segment-Lists of CP1 are installed as the preference). The two Segment-Lists of CP1 are installed as the
forwarding instantiation of SR policy Pol1. Traffic steered on Pol1 forwarding instantiation of SR policy POL1. Traffic steered on POL1
is flow-based hashed on Segment-List <SID11...SID1i> with a ratio is flow-based hashed on Segment-List <SID11...SID1i> with a ratio
W1/(W1+W2). W1/(W1+W2).
3. Segment Routing Database 3. Segment Routing Database
An SR headend maintains the Segment Routing Database (SR-DB). The An SR headend maintains the Segment Routing Database (SR-DB). The
SR-DB is a conceptual database to illustrate the various pieces of SR-DB is a conceptual database to illustrate the various pieces of
information and their sources that may help in SR Policy computation information and their sources that may help in SR Policy computation
and validation. There is no specific requirement for an and validation. There is no specific requirement for an
implementation to create a new database as such. implementation to create a new database as such.
An SR headend leverages the SR-DB to validate explicit candidate An SR headend leverages the SR-DB to validate explicit candidate
paths and compute dynamic candidate paths. paths and compute dynamic candidate paths.
The information in the SR-DB MAY include: The information in the SR-DB MAY include:
o IGP information (topology, IGP metrics based on ISIS [RFC1195] and o IGP information (topology, IGP metrics based on ISIS [RFC1195] and
OSPF [RFC2328] [RFC5340]) OSPF [RFC2328] [RFC5340])
o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj- o Segment Routing information (such as SRGB, SRLB, Prefix-SIDs, Adj-
SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402] SIDs, BGP Peering SID, SRv6 SIDs) [RFC8402]
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-spring-srv6-network-programming]
[I-D.filsfils-spring-srv6-network-programming]
o TE Link Attributes (such as TE metric, SRLG, attribute-flag, o TE Link Attributes (such as TE metric, SRLG, attribute-flag,
extended admin group) [RFC5305] [RFC3630]. extended admin group) [RFC5305] [RFC3630].
o Extended TE Link attributes (such as latency, loss) [RFC7810] o Extended TE Link attributes (such as latency, loss) [RFC8570]
[RFC7471] [RFC7471]
o Inter-AS Topology information o Inter-AS Topology information
[I-D.ietf-idr-bgpls-segment-routing-epe]. [I-D.ietf-idr-bgpls-segment-routing-epe].
The attached domain topology MAY be learned via IGP, BGP-LS or The attached domain topology MAY be learned via IGP, BGP-LS or
NETCONF. NETCONF.
A non-attached (remote) domain topology MAY be learned via BGP-LS or A non-attached (remote) domain topology MAY be learned via BGP-LS or
NETCONF. NETCONF.
In some use-cases, the SR-DB may only contain the attached domain In some use-cases, the SR-DB may only contain the attached domain
topology while in others, the SR-DB may contain the topology of topology while in others, the SR-DB may contain the topology of
multiple domains and in this case it is multi-domain capable. multiple domains and in this case it is multi-domain capable.
The SR-DB MAY also contain the SR Policies instantiated in the The SR-DB MAY also contain the SR Policies instantiated in the
network. This can be collected via BGP-LS network. This can be collected via BGP-LS
[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
[I-D.sivabalan-pce-binding-label-sid]. This information allows to [I-D.ietf-pce-binding-label-sid]. This information allows to build
build an end-to-end policy on the basis of intermediate SR policies an end-to-end policy on the basis of intermediate SR policies (see
(see Section 6 for further details). Section 6 for further details).
The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of The SR-DB MAY also contain the Maximum SID Depth (MSD) capability of
nodes in the topology. This can be collected via ISIS nodes in the topology. This can be collected via ISIS [RFC8491],
[I-D.ietf-isis-segment-routing-msd], OSPF OSPF [RFC8476], BGP-LS [I-D.ietf-idr-bgp-ls-segment-routing-msd] or
[I-D.ietf-ospf-segment-routing-msd], BGP-LS PCEP [RFC8664].
[I-D.ietf-idr-bgp-ls-segment-routing-msd] or PCEP
[I-D.ietf-pce-segment-routing].
The use of the SR-DB for computation and validation of SR Policies is The use of the SR-DB for computation and validation of SR Policies is
outside the scope of this document. Some implementation aspects outside the scope of this document. Some implementation aspects
related to this are covered in related to this are covered in
[I-D.filsfils-spring-sr-policy-considerations]. [I-D.filsfils-spring-sr-policy-considerations].
4. Segment Types 4. Segment Types
A Segment-List is an ordered set of segments represented as <S1, S2, A Segment-List is an ordered set of segments represented as <S1, S2,
... Sn> where S1 is the first segment. ... Sn> where S1 is the first segment.
skipping to change at page 12, line 9 skipping to change at page 11, line 47
A MPLS label corresponding to any of the segment types defined A MPLS label corresponding to any of the segment types defined
for SR-MPLS (as defined in [RFC8402] or other SR-MPLS for SR-MPLS (as defined in [RFC8402] or other SR-MPLS
specifications) can be used. Additionally, reserved labels specifications) can be used. Additionally, reserved labels
like explicit-null or in general any MPLS label may also be like explicit-null or in general any MPLS label may also be
used. E.g. this type can be used to specify a label used. E.g. this type can be used to specify a label
representation which maps to an optical transport path on a representation which maps to an optical transport path on a
packet transport node. This type does not require the headend packet transport node. This type does not require the headend
to perform SID resolution. to perform SID resolution.
Type B: SRv6 SID: Type B: SRv6 SID:
An IPv6 address corresponding to any of the segment types An IPv6 address corresponding to any of the SID behaviors for
defined for SRv6 (as defined in SRv6 (as defined in [I-D.ietf-spring-srv6-network-programming]
[I-D.filsfils-spring-srv6-network-programming] or other SRv6 or other SRv6 specifications) can be used. This type does not
specifications) can be used. This type does not require the require the headend to perform SID resolution.
headend to perform SID resolution.
Type C: IPv4 Prefix with optional SR Algorithm: Type C: IPv4 Prefix with optional SR Algorithm:
The headend is required to resolve the specified IPv4 Prefix The headend is required to resolve the specified IPv4 Prefix
Address to the SR-MPLS label corresponding to a Prefix SID Address to the SR-MPLS label corresponding to a Prefix SID
segment (as defined in [RFC8402]). The SR algorithm (refer to segment (as defined in [RFC8402]). The SR algorithm (refer to
Section 3.1.1 of [RFC8402]) to be used MAY also be provided. Section 3.1.1 of [RFC8402]) to be used MAY also be provided.
Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS: Type D: IPv6 Global Prefix with optional SR Algorithm for SR-MPLS:
In this case the headend is required to resolve the specified In this case the headend is required to resolve the specified
IPv6 Global Prefix Address to the SR-MPLS label corresponding IPv6 Global Prefix Address to the SR-MPLS label corresponding
to its Prefix SID segment (as defined in [RFC8402]). The SR to its Prefix SID segment (as defined in [RFC8402]). The SR
Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY Algorithm (refer to Section 3.1.1 of [RFC8402]) to be used MAY
also be provided. also be provided.
Type E: IPv4 Prefix with Local Interface ID: Type E: IPv4 Prefix with Local Interface ID:
This type allows identification of Adjacency SID (as defined in This type allows identification of Adjacency SID or BGP Peer
[RFC8402]) or BGP EPE Peering SID (as defined in Adjacency SID (as defined in [RFC8402]) label for point-to-
[I-D.ietf-idr-bgpls-segment-routing-epe]) label for point-to-
point links including IP unnumbered links. The headend is point links including IP unnumbered links. The headend is
required to resolve the specified IPv4 Prefix Address to the required to resolve the specified IPv4 Prefix Address to the
Node originating it and then use the Local Interface ID to Node originating it and then use the Local Interface ID to
identify the point-to-point link whose adjacency is being identify the point-to-point link whose adjacency is being
referred to. The Local Interface ID link descriptor follows referred to. The Local Interface ID link descriptor follows
semantics as specified in [RFC7752]. This type can also be semantics as specified in [RFC7752]. This type can also be
used to indicate indirection into a layer 2 interface (i.e. used to indicate indirection into a layer 2 interface (i.e.
without IP address) like a representation of an optical without IP address) like a representation of an optical
transport path or a layer 2 Ethernet port or circuit at the transport path or a layer 2 Ethernet port or circuit at the
specified node. specified node.
Type F: IPv4 Addresses for link endpoints as Local, Remote pair: Type F: IPv4 Addresses for link endpoints as Local, Remote pair:
This type allows identification of Adjacency SID (as defined in This type allows identification of Adjacency SID or BGP Peer
[RFC8402]) or BGP EPE Peering SID (as defined in Adjacency SID (as defined in [RFC8402]) label for links. The
[I-D.ietf-idr-bgpls-segment-routing-epe]) label for links. The
headend is required to resolve the specified IPv4 Local Address headend is required to resolve the specified IPv4 Local Address
to the Node originating it and then use the IPv4 Remote Address to the Node originating it and then use the IPv4 Remote Address
to identify the link adjacency being referred to. The Local to identify the link adjacency being referred to. The Local
and Remote Address pair link descriptors follows semantics as and Remote Address pair link descriptors follows semantics as
specified in [RFC7752]. specified in [RFC7752].
Type G: IPv6 Prefix and Interface ID for link endpoints as Local, Type G: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SR-MPLS: Remote pair for SR-MPLS:
This type allows identification of Adjacency SID (as defined in This type allows identification of Adjacency SID or BGP Peer
[RFC8402]) or BGP EPE Peering SID (as defined in Adjacency SID (as defined in [RFC8402]) label for links
[I-D.ietf-idr-bgpls-segment-routing-epe]) label for links
including those with only Link Local IPv6 addresses. The including those with only Link Local IPv6 addresses. The
headend is required to resolve the specified IPv6 Prefix headend is required to resolve the specified IPv6 Prefix
Address to the Node originating it and then use the Local Address to the Node originating it and then use the Local
Interface ID to identify the point-to-point link whose Interface ID to identify the point-to-point link whose
adjacency is being referred to. For other than point-to-point adjacency is being referred to. For other than point-to-point
links, additionally the specific adjacency over the link needs links, additionally the specific adjacency over the link needs
to be resolved using the Remote Prefix and Interface ID. The to be resolved using the Remote Prefix and Interface ID. The
Local and Remote pair of Prefix and Interface ID link Local and Remote pair of Prefix and Interface ID link
descriptor follows semantics as specified in [RFC7752]. This descriptor follows semantics as specified in [RFC7752]. This
type can also be used to indicate indirection into a layer 2 type can also be used to indicate indirection into a layer 2
interface (i.e. without IP address) like a representation of an interface (i.e. without IP address) like a representation of an
optical transport path or a layer 2 Ethernet port or circuit at optical transport path or a layer 2 Ethernet port or circuit at
the specified node. the specified node.
Type H: IPv6 Addresses for link endpoints as Local, Remote pair for Type H: IPv6 Addresses for link endpoints as Local, Remote pair for
SR-MPLS: SR-MPLS:
This type allows identification of Adjacency SID (as defined in This type allows identification of Adjacency SID or BGP Peer
[RFC8402]) or BGP EPE Peering SID (as defined in Adjacency SID (as defined in [RFC8402]) label for links with
[I-D.ietf-idr-bgpls-segment-routing-epe]) label for links with
Global IPv6 addresses. The headend is required to resolve the Global IPv6 addresses. The headend is required to resolve the
specified Local IPv6 Address to the Node originating it and specified Local IPv6 Address to the Node originating it and
then use the Remote IPv6 Address to identify the link adjacency then use the Remote IPv6 Address to identify the link adjacency
being referred to. The Local and Remote Address pair link being referred to. The Local and Remote Address pair link
descriptors follows semantics as specified in [RFC7752]. descriptors follows semantics as specified in [RFC7752].
Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6: Type I: IPv6 Global Prefix with optional SR Algorithm for SRv6:
The headend is required to resolve the specified IPv6 Global The headend is required to resolve the specified IPv6 Global
Prefix Address to the SRv6 END function SID (as defined in Prefix Address to an SRv6 SID corresponding to a Prefix SID
[I-D.filsfils-spring-srv6-network-programming]) corresponding segment (as defined in [RFC8402]), such as a SID associated
to the node which is originating the prefix. The SR Algorithm with the End behavior (as defined in
(refer to Section 3.1.1 of [RFC8402]) to be used MAY also be [I-D.ietf-spring-srv6-network-programming]), of the node which
provided. is originating the prefix. The SR Algorithm (refer to
Section 3.1.1 of [RFC8402]) to be used MAY also be provided.
Type J: IPv6 Prefix and Interface ID for link endpoints as Local, Type J: IPv6 Prefix and Interface ID for link endpoints as Local,
Remote pair for SRv6: Remote pair for SRv6:
This type allows identification of SRv6 END.X SID (as defined This type allows identification of an SRv6 SID corresponding to
in [I-D.filsfils-spring-srv6-network-programming]) for links an Adjacency SID or BGP Peer Adjacency SID (as defined in
with only Link Local IPv6 addresses. The headend is required [RFC8402]), such as a SID associated with the End.X behavior
to resolve the specified IPv6 Prefix Address to the Node (as defined in [I-D.ietf-spring-srv6-network-programming]),
originating it and then use the Local Interface ID to identify associated with link or adjacency with only Link Local IPv6
the point-to-point link whose adjacency is being referred to. addresses. The headend is required to resolve the specified
For other than point-to-point links, additionally the specific IPv6 Prefix Address to the Node originating it and then use the
adjacency needs to be resolved using the Remote Prefix and Local Interface ID to identify the point-to-point link whose
Interface ID. The Local and Remote pair of Prefix and adjacency is being referred to. For other than point-to-point
Interface ID link descriptor follows semantics as specified in links, additionally the specific adjacency needs to be resolved
[RFC7752]. using the Remote Prefix and Interface ID. The Local and Remote
pair of Prefix and Interface ID link descriptor follows
semantics as specified in [RFC7752].
Type K: IPv6 Addresses for link endpoints as Local, Remote pair for Type K: IPv6 Addresses for link endpoints as Local, Remote pair for
SRv6: SRv6:
This type allows identification of SRv6 END.X SID (as defined This type allows identification of an SRv6 SID corresponding to
in [I-D.filsfils-spring-srv6-network-programming]) for links an Adjacency SID or BGP Peer Adjacency SID (as defined in
with Global IPv6 addresses. The headend is required to resolve [RFC8402]), such as a SID associated with the End.X behavior
the specified Local IPv6 Address to the Node originating it and (as defined in [I-D.ietf-spring-srv6-network-programming]),
then use the Remote IPv6 Address to identify the link adjacency associated with link or adjacency with Global IPv6 addresses.
being referred to. The Local and Remote Address pair link The headend is required to resolve the specified Local IPv6
descriptors follows semantics as specified in [RFC7752]. Address to the Node originating it and then use the Remote IPv6
Address to identify the link adjacency being referred to. The
Local and Remote Address pair link descriptors follows
semantics as specified in [RFC7752].
Type L: SRv6 SID with Behavior
An SRv6 SID along with its behavior (as defined in
[I-D.ietf-spring-srv6-network-programming] or other SRv6
specifications) and structure (as defined in
[I-D.ietf-spring-srv6-network-programming]) can be used. This
type enables the headend to optionally perform validation of
the SID when using it for building the Segment List.
When the algorithm is not specified for the SID types above which When the algorithm is not specified for the SID types above which
optionally allow for it, the headend SHOULD use the Strict Shortest optionally allow for it, the headend SHOULD use the Strict Shortest
Path algorithm if available; otherwise it SHOULD use the default Path algorithm if available; otherwise it SHOULD use the default
Shortest Path algorithm. The specification of algorithm enables the Shortest Path algorithm. The specification of algorithm enables the
use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in use of IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific SIDs in
SR Policy. SR Policy.
For SID types C-through-K, a SID value may also be optionally For SID types C-through-L, a SID value may also be optionally
provided to the headend for verification purposes. Section 5.1. provided to the headend for verification purposes. Section 5.1.
describes the resolution and verification of the SIDs and Segment describes the resolution and verification of the SIDs and Segment
Lists on the headend. Lists on the headend.
When building the MPLS label stack or the IPv6 Segment list from the When building the MPLS label stack or the IPv6 Segment list from the
Segment List, the node instantiating the policy MUST interpret the Segment List, the node instantiating the policy MUST interpret the
set of Segments as follows: set of Segments as follows:
o The first Segment represents the topmost label or the first IPv6 o The first Segment represents the topmost label or the first IPv6
segment. It identifies the active segment the traffic will be segment. It identifies the active segment the traffic will be
skipping to change at page 16, line 6 skipping to change at page 16, line 6
A Segment-List of an explicit candidate path MUST be declared invalid A Segment-List of an explicit candidate path MUST be declared invalid
when: when:
o It is empty. o It is empty.
o Its weight is 0. o Its weight is 0.
o The headend is unable to perform path resolution for the first SID o The headend is unable to perform path resolution for the first SID
into one or more outgoing interface(s) and next-hop(s). into one or more outgoing interface(s) and next-hop(s).
o The headend is unable to perform SID resolution for any non-first o The headend is unable to perform SID resolution for any non-first
SID of type C-through-K into an MPLS label or an SRv6 SID. SID of type C-through-L into an MPLS label or an SRv6 SID.
o The headend verification fails for any SID for which verification o The headend verification fails for any SID for which verification
has been explicitly requested. has been explicitly requested.
"Unable to perform path resolution" means that the headend has no "Unable to perform path resolution" means that the headend has no
path to the SID in its SR database. path to the SID in its SR database.
SID verification is performed when the headend is explicitly SID verification is performed when the headend is explicitly
requested to verify SID(s) by the controller via the signaling requested to verify SID(s) by the controller via the signaling
protocol used. Implementations MAY provide a local configuration protocol used. Implementations MAY provide a local configuration
option to enable verification on a global or per policy or per option to enable verification on a global or per policy or per
candidate path basis. candidate path basis.
"Verification fails" for a SID means any of the following: "Verification fails" for a SID means any of the following:
o The headend is unable to find the SID in its SR DB o The headend is unable to find the SID in its SR DB
o The headend detects mis-match between the SID value and its o The headend detects mis-match between the SID value and its
context provided for SIDs of type C-through-K in its SR DB. context provided for SIDs of type C-through-L in its SR DB.
o The headend is unable to perform SID resolution for any non-first o The headend is unable to perform SID resolution for any non-first
SID of type C-through-K into an MPLS label or an SRv6 SID. SID of type C-through-L into an MPLS label or an SRv6 SID.
In multi-domain deployments, it is expected that the headend be In multi-domain deployments, it is expected that the headend be
unable to verify the reachability of the SIDs in remote domains. unable to verify the reachability of the SIDs in remote domains.
Types A or B MUST be used for the SIDs for which the reachability Types A or B MUST be used for the SIDs for which the reachability
cannot be verified. Note that the first SID MUST always be reachable cannot be verified. Note that the first SID MUST always be reachable
regardless of its type. regardless of its type.
In addition, a Segment-List MAY be declared invalid when: In addition, a Segment-List MAY be declared invalid when:
o Its last segment is not a Prefix SID (including BGP Peer Node-SID) o Its last segment is not a Prefix SID (including BGP Peer Node-SID)
skipping to change at page 17, line 15 skipping to change at page 17, line 15
The headend of the policy leverages its SR database to compute a The headend of the policy leverages its SR database to compute a
Segment-List ("solution Segment-List") that solves this optimization Segment-List ("solution Segment-List") that solves this optimization
problem. problem.
The headend re-computes the solution Segment-List any time the inputs The headend re-computes the solution Segment-List any time the inputs
to the problem change (e.g., topology changes). to the problem change (e.g., topology changes).
When local computation is not possible (e.g., a policy's tailend is When local computation is not possible (e.g., a policy's tailend is
outside the topology known to the headend) or not desired, the outside the topology known to the headend) or not desired, the
headend MAY send path computation request to a PCE supporting PCEP headend MAY send path computation request to a PCE supporting PCEP
extension specified in [I-D.ietf-pce-segment-routing]. extension specified in [RFC8664].
If no solution is found to the optimization objective and If no solution is found to the optimization objective and
constraints, then the dynamic candidate path MUST be declared constraints, then the dynamic candidate path MUST be declared
invalid. invalid.
[I-D.filsfils-spring-sr-policy-considerations] discusses some of the [I-D.filsfils-spring-sr-policy-considerations] discusses some of the
optimization objectives and constraints that may be considered by a optimization objectives and constraints that may be considered by a
dynamic candidate path. It illustrates some of the desirable dynamic candidate path. It illustrates some of the desirable
properties of the computation of the solution Segment-List. properties of the computation of the solution Segment-List.
skipping to change at page 19, line 27 skipping to change at page 19, line 27
An implementation MAY choose to associate a Binding SID with any type An implementation MAY choose to associate a Binding SID with any type
of interface (e.g. a layer 3 termination of an Optical Circuit) or a of interface (e.g. a layer 3 termination of an Optical Circuit) or a
tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE tunnel (e.g. IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
tunnel, etc). This enables the use of other non-SR enabled tunnel, etc). This enables the use of other non-SR enabled
interfaces and tunnels as segments in an SR Policy Segment-List interfaces and tunnels as segments in an SR Policy Segment-List
without the need of forming routing protocol adjacencies over them. without the need of forming routing protocol adjacencies over them.
The details of this kind of usage are beyond the scope of this The details of this kind of usage are beyond the scope of this
document. A specific packet optical integration use case is document. A specific packet optical integration use case is
described in [I-D.anand-spring-poi-sr] described in [I-D.anand-spring-poi-sr].
7. SR Policy State 7. SR Policy State
The SR Policy State is maintained on the headend to represent the The SR Policy State is maintained on the headend to represent the
state of the policy and its candidate paths. This is to provide an state of the policy and its candidate paths. This is to provide an
accurate representation of whether the SR Policy is being accurate representation of whether the SR Policy is being
instantiated in the forwarding plane and which of its candidate paths instantiated in the forwarding plane and which of its candidate paths
and segment-list(s) are active. The SR Policy state MUST also and segment-list(s) are active. The SR Policy state MUST also
reflect the reason when a policy and/or its candidate path is not reflect the reason when a policy and/or its candidate path is not
active due to validation errors or not being preferred. active due to validation errors or not being preferred.
The SR Policy state can be reported by the headend node via BGP-LS The SR Policy state can be reported by the headend node via BGP-LS
[I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
[I-D.sivabalan-pce-binding-label-sid]. [I-D.ietf-pce-binding-label-sid].
SR Policy state on the headend also includes traffic accounting SR Policy state on the headend also includes traffic accounting
information for the flows being steered via the policies. The information for the flows being steered via the policies. The
details of the SR Policy accounting are beyond the scope of this details of the SR Policy accounting are beyond the scope of this
document. The aspects related to the SR traffic counters and their document. The aspects related to the SR traffic counters and their
usage in the broader context of traffic accounting in a SR network usage in the broader context of traffic accounting in a SR network
are covered in [I-D.filsfils-spring-sr-traffic-counters] and are covered in [I-D.filsfils-spring-sr-traffic-counters] and
[I-D.ali-spring-sr-traffic-accounting] respectively. [I-D.ali-spring-sr-traffic-accounting] respectively.
Implementations MAY support an administrative state to control Implementations MAY support an administrative state to control
skipping to change at page 26, line 48 skipping to change at page 26, line 48
validity. validity.
This is the "drop upon invalid" option described in Section 8.2 This is the "drop upon invalid" option described in Section 8.2
applied to BGP-based steering. applied to BGP-based steering.
9. Protection 9. Protection
9.1. Leveraging TI-LFA local protection of the constituent IGP segments 9.1. Leveraging TI-LFA local protection of the constituent IGP segments
In any topology, Topology-Independent Loop Free Alternate (TI-LFA) In any topology, Topology-Independent Loop Free Alternate (TI-LFA)
[I-D.bashandy-rtgwg-segment-routing-ti-lfa] provides a 50msec local [I-D.ietf-rtgwg-segment-routing-ti-lfa] provides a 50msec local
protection technique for IGP SIDs. The backup path is computed on a protection technique for IGP SIDs. The backup path is computed on a
per IGP SID basis along the post-convergence path. per IGP SID basis along the post-convergence path.
In a network that has deployed TI-LFA, an SR Policy built on the In a network that has deployed TI-LFA, an SR Policy built on the
basis of TI-LFA protected IGP segments leverages the local protection basis of TI-LFA protected IGP segments leverages the local protection
of the constituent segments. of the constituent segments.
In a network that has deployed TI-LFA, an SR Policy instantiated only In a network that has deployed TI-LFA, an SR Policy instantiated only
with non-protected Adj SIDs does not benefit from any local with non-protected Adj SIDs does not benefit from any local
protection. protection.
skipping to change at page 28, line 9 skipping to change at page 28, line 9
The headend MAY compute a-priori and validate such backup candidate The headend MAY compute a-priori and validate such backup candidate
paths as well as provision them into forwarding plane as backup for paths as well as provision them into forwarding plane as backup for
the active path. A fast re-route mechanism MAY then be used to the active path. A fast re-route mechanism MAY then be used to
trigger sub 50msec switchover from the active to the backup candidate trigger sub 50msec switchover from the active to the backup candidate
path in the forwarding plane. Mechanisms like BFD MAY be used for path in the forwarding plane. Mechanisms like BFD MAY be used for
fast detection of such failures. fast detection of such failures.
10. Security Considerations 10. Security Considerations
This document does not define any new protocol extensions and does This document specifies in detail the SR Policy construct introduced
not impose any additional security challenges. in [RFC8402] and its instantiation on a router supporting SR along
with descriptions of mechanisms for steering of traffic flows over
it. Therefore, the security considerations of [RFC8402] apply. This
document does not define any new protocol extensions and does not
introduce any further security considerations.
11. IANA Considerations 11. IANA Considerations
This document requests IANA to create a new top-level registry called This document requests IANA to create a new top-level registry called
"Segment Routing Parameters". This registry is being defined to "Segment Routing Parameters". This registry is being defined to
serve as a top-level registry for keeping all other Segment Routing serve as a top-level registry for keeping all other Segment Routing
sub-registries. sub-registries.
The document also requests creation of a new sub-registry called The document also requests creation of a new sub-registry called
"Segment Types" to be defined under the top-level "Segment Routing "Segment Types" to be defined under the top-level "Segment Routing
skipping to change at page 29, line 17 skipping to change at page 29, line 17
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
| A | SR-MPLS Label | [This.ID] | | A | SR-MPLS Label | [This.ID] |
| B | SRv6 SID | [This.ID] | | B | SRv6 SID | [This.ID] |
| C | IPv4 Prefix with optional SR Algorithm | [This.ID] | | C | IPv4 Prefix with optional SR Algorithm | [This.ID] |
| D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | | D | IPv6 Global Prefix with optional SR Algorithm | [This.ID] |
| | for SR-MPLS | | | | for SR-MPLS | |
| E | IPv4 Prefix with Local Interface ID | [This.ID] | | E | IPv4 Prefix with Local Interface ID | [This.ID] |
| F | IPv4 Addresses for link endpoints as Local, | [This.ID] | | F | IPv4 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair | | | | Remote pair | |
| G | IPv6 Prefix and Interface ID for link | [This.ID] | | G | IPv6 Prefix and Interface ID for link | [This.ID] |
| | endpoints as Local, | | | | endpoints as Local, Remote pair for SR-MPLS | |
| | Remote pair for SR-MPLS | |
| H | IPv6 Addresses for link endpoints as Local, | [This.ID] | | H | IPv6 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair for SR-MPLS | | | | Remote pair for SR-MPLS | |
| I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] | | I | IPv6 Global Prefix with optional SR Algorithm | [This.ID] |
| | for SRv6 | | | | for SRv6 | |
| J | IPv6 Prefix and Interface ID for link | [This.ID] | | J | IPv6 Prefix and Interface ID for link | [This.ID] |
| | endpoints as Local, Remote pair for SRv6 | | | | endpoints as Local, Remote pair for SRv6 | |
| K | IPv6 Addresses for link endpoints as Local, | [This.ID] | | K | IPv6 Addresses for link endpoints as Local, | [This.ID] |
| | Remote pair for SRv6 | | | | Remote pair for SRv6 | |
| L | SRv6 SID with Behavior | [This.ID] |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
Table 2: Initial IANA Registration Table 2: Initial IANA Registration
11.1. Guidance for Designated Experts 11.1. Guidance for Designated Experts
The Designated Expert (DE) is expected to ascertain the existence of The Designated Expert (DE) is expected to ascertain the existence of
suitable documentation (a specification) as described in [RFC8126] suitable documentation (a specification) as described in [RFC8126]
and to verify that the document is permanently and publicly and to verify that the document is permanently and publicly
available. The DE is also expected to check the clarity of purpose available. The DE is also expected to check the clarity of purpose
skipping to change at page 29, line 50 skipping to change at page 29, line 50
the request to the SPRING Working Group mailing list (or a successor the request to the SPRING Working Group mailing list (or a successor
mailing list designated by the IESG). If the request comes from mailing list designated by the IESG). If the request comes from
within the IETF, it should be documented in an Internet-Draft. within the IETF, it should be documented in an Internet-Draft.
Lastly, the DE must ensure that any other request for a code point Lastly, the DE must ensure that any other request for a code point
does not conflict with work that is active or already published does not conflict with work that is active or already published
within the IETF. within the IETF.
12. Acknowledgement 12. Acknowledgement
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
Geib and Rob Shakir for their valuable comments and suggestions. Geib, Rob Shakir, Cheng Li and Dhruv Dhody for their review comments
and suggestions.
13. Contributors 13. Contributors
The following people have contributed to this document: The following people have contributed to this document:
Ketan Talaulikar Siva Sivabalan
Cisco Systems Cisco Systems
Email: ketant@cisco.com Email: msiva@cisco.com
Zafar Ali Zafar Ali
Cisco Systems Cisco Systems
Email: zali@cisco.com Email: zali@cisco.com
Jose Liste Jose Liste
Cisco Systems Cisco Systems
Email: jliste@cisco.com Email: jliste@cisco.com
Francois Clad Francois Clad
Cisco Systems Cisco Systems
Email: fclad@cisco.com Email: fclad@cisco.com
Kamran Raza Kamran Raza
Cisco Systems Cisco Systems
Email: skraza@cisco.com Email: skraza@cisco.com
Mike Koldychev
Cisco Systems
Email: mkoldych@cisco.com
Shraddha Hegde Shraddha Hegde
Juniper Networks Juniper Networks
Email: shraddha@juniper.net Email: shraddha@juniper.net
Steven Lin Steven Lin
Google, Inc. Google, Inc.
Email: stevenlin@google.com Email: stevenlin@google.com
Przemyslaw Krol Przemyslaw Krol
Google, Inc. Google, Inc.
skipping to change at page 30, line 48 skipping to change at page 31, line 4
Google, Inc. Google, Inc.
Email: pkrol@google.com Email: pkrol@google.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Email: martin.horneffer@telekom.de Email: martin.horneffer@telekom.de
Dirk Steinberg Dirk Steinberg
Steinberg Consulting Steinberg Consulting
Email: dws@steinbergnet.net Email: dws@steinbergnet.net
Bruno Decraene Bruno Decraene
Orange Business Services Orange Business Services
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Business Services Orange Business Services
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Luay Jalil Luay Jalil
Verizon Verizon
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
14.2. Informative References 14.2. Informative References
[I-D.ali-spring-sr-traffic-accounting] [I-D.ali-spring-sr-traffic-accounting]
Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer, Filsfils, C., Talaulikar, K., Sivabalan, S., Horneffer,
M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton, M., Raszuk, R., Litkowski, S., Voyer, D., and R. Morton,
"Traffic Accounting in Segment Routing Networks", draft- "Traffic Accounting in Segment Routing Networks", draft-
ali-spring-sr-traffic-accounting-04 (work in progress), ali-spring-sr-traffic-accounting-04 (work in progress),
February 2020. February 2020.
[I-D.anand-spring-poi-sr] [I-D.anand-spring-poi-sr]
Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J., Anand, M., Bardhan, S., Subrahmaniam, R., Tantsura, J.,
Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical Mukhopadhyaya, U., and C. Filsfils, "Packet-Optical
Integration in Segment Routing", draft-anand-spring-poi- Integration in Segment Routing", draft-anand-spring-poi-
sr-08 (work in progress), July 2019. sr-08 (work in progress), July 2019.
[I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
lfa-05 (work in progress), October 2018.
[I-D.filsfils-spring-sr-policy-considerations] [I-D.filsfils-spring-sr-policy-considerations]
Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and Filsfils, C., Talaulikar, K., Krol, P., Horneffer, M., and
P. Mattes, "SR Policy Implementation and Deployment P. Mattes, "SR Policy Implementation and Deployment
Considerations", draft-filsfils-spring-sr-policy- Considerations", draft-filsfils-spring-sr-policy-
considerations-05 (work in progress), April 2020. considerations-05 (work in progress), April 2020.
[I-D.filsfils-spring-sr-traffic-counters] [I-D.filsfils-spring-sr-traffic-counters]
Filsfils, C., Ali, Z., Horneffer, M., Filsfils, C., Ali, Z., Horneffer, M.,
daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk, daniel.voyer@bell.ca, d., Durrani, M., and R. Raszuk,
"Segment Routing Traffic Accounting Counters", draft- "Segment Routing Traffic Accounting Counters", draft-
filsfils-spring-sr-traffic-counters-00 (work in progress), filsfils-spring-sr-traffic-counters-00 (work in progress),
June 2018. June 2018.
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[I-D.ietf-idr-bgp-ls-segment-routing-msd] [I-D.ietf-idr-bgp-ls-segment-routing-msd]
Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G.,
and N. Triantafillis, "Signaling MSD (Maximum SID Depth) and N. Triantafillis, "Signaling MSD (Maximum SID Depth)
using Border Gateway Protocol - Link State", draft-ietf- using Border Gateway Protocol - Link State", draft-ietf-
idr-bgp-ls-segment-routing-msd-17 (work in progress), idr-bgp-ls-segment-routing-msd-18 (work in progress), May
April 2020. 2020.
[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-idr-segment-routing-te-policy] [I-D.ietf-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P.,
Rosen, E., Jain, D., and S. Lin, "Advertising Segment Rosen, E., Jain, D., and S. Lin, "Advertising Segment
Routing Policies in BGP", draft-ietf-idr-segment-routing- Routing Policies in BGP", draft-ietf-idr-segment-routing-
te-policy-08 (work in progress), November 2019. te-policy-09 (work in progress), May 2020.
[I-D.ietf-idr-te-lsp-distribution] [I-D.ietf-idr-te-lsp-distribution]
Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler, Previdi, S., Talaulikar, K., Dong, J., Chen, M., Gredler,
H., and J. Tantsura, "Distribution of Traffic Engineering H., and J. Tantsura, "Distribution of Traffic Engineering
(TE) Policies and State using BGP-LS", draft-ietf-idr-te- (TE) Policies and State using BGP-LS", draft-ietf-idr-te-
lsp-distribution-13 (work in progress), April 2020. lsp-distribution-13 (work in progress), April 2020.
[I-D.ietf-isis-segment-routing-msd]
Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling MSD (Maximum SID Depth) using IS-IS", draft-
ietf-isis-segment-routing-msd-19 (work in progress),
October 2018.
[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-07 (work in progress), April 2020. algo-07 (work in progress), April 2020.
[I-D.ietf-ospf-segment-routing-msd] [I-D.ietf-pce-binding-label-sid]
Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, Filsfils, C., Sivabalan, S., Tantsura, J., Hardwick, J.,
"Signaling MSD (Maximum SID Depth) using OSPF", draft- Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID
ietf-ospf-segment-routing-msd-25 (work in progress), in PCE-based Networks.", draft-ietf-pce-binding-label-
October 2018. sid-03 (work in progress), June 2020.
[I-D.ietf-pce-segment-routing] [I-D.ietf-rtgwg-segment-routing-ti-lfa]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B.,
and J. Hardwick, "PCEP Extensions for Segment Routing", Francois, P., Voyer, D., Clad, F., and P. Camarillo,
draft-ietf-pce-segment-routing-16 (work in progress), "Topology Independent Fast Reroute using Segment Routing",
March 2019. draft-ietf-rtgwg-segment-routing-ti-lfa-03 (work in
progress), March 2020.
[I-D.sivabalan-pce-binding-label-sid] [I-D.ietf-spring-srv6-network-programming]
Sivabalan, S., Filsfils, C., Tantsura, J., Hardwick, J., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Previdi, S., and C. Li, "Carrying Binding Label/Segment-ID Matsushima, S., and Z. Li, "SRv6 Network Programming",
in PCE-based Networks.", draft-sivabalan-pce-binding- draft-ietf-spring-srv6-network-programming-16 (work in
label-sid-07 (work in progress), July 2019. progress), June 2020.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>. December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>. 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
skipping to change at page 34, line 39 skipping to change at page 34, line 21
Previdi, "OSPF Traffic Engineering (TE) Metric Previdi, "OSPF Traffic Engineering (TE) Metric
Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
<https://www.rfc-editor.org/info/rfc7471>. <https://www.rfc-editor.org/info/rfc7471>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
RFC 7810, DOI 10.17487/RFC7810, May 2016,
<https://www.rfc-editor.org/info/rfc7810>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak,
Computation Element Communication Protocol (PCEP) "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476,
Extensions for PCE-Initiated LSP Setup in a Stateful PCE DOI 10.17487/RFC8476, December 2018,
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8476>.
<https://www.rfc-editor.org/info/rfc8281>.
Authors' Addresses [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[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>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
Authors' Addresses
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Pegasus Parc Pegasus Parc
De kleetlaan 6a, DIEGEM BRABANT 1831 De kleetlaan 6a, DIEGEM BRABANT 1831
BELGIUM BELGIUM
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Siva Sivabalan (editor) Ketan Talaulikar (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive India
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.com Email: ketant@cisco.com
Daniel Voyer Daniel Voyer
Bell Canada Bell Canada
671 de la gauchetiere W 671 de la gauchetiere W
Montreal, Quebec H3B 2M8 Montreal, Quebec H3B 2M8
Canada Canada
Email: daniel.voyer@bell.ca Email: daniel.voyer@bell.ca
Alex Bogdanov Alex Bogdanov
 End of changes. 70 change blocks. 
173 lines changed or deleted 168 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/