< draft-ietf-spring-segment-routing-policy-15.txt   draft-ietf-spring-segment-routing-policy-16.txt >
SPRING Working Group C. Filsfils SPRING Working Group C. Filsfils
Internet-Draft K. Talaulikar, Ed. Internet-Draft K. Talaulikar, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: July 30, 2022 D. Voyer Expires: August 1, 2022 D. Voyer
Bell Canada Bell Canada
A. Bogdanov A. Bogdanov
British Telecom British Telecom
P. Mattes P. Mattes
Microsoft Microsoft
January 26, 2022 January 28, 2022
Segment Routing Policy Architecture Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-15 draft-ietf-spring-segment-routing-policy-16
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-path states are eliminated thanks along any path. Intermediate per-path 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 packets steered into an SR Policy carry an ordered list of The packets steered into an SR Policy carry an ordered list of
segments associated with that SR Policy. This document details the segments associated with that SR Policy. This document details the
concepts of SR Policy and steering into an SR Policy. concepts of SR Policy and steering into an SR Policy.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 July 30, 2022. This Internet-Draft will expire on August 1, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. SR Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Identification of an SR Policy . . . . . . . . . . . . . 4 2.1. Identification of an SR Policy . . . . . . . . . . . . . 4
2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5 2.2. Candidate Path and Segment List . . . . . . . . . . . . . 5
2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6 2.3. Protocol-Origin of a Candidate Path . . . . . . . . . . . 6
2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6 2.4. Originator of a Candidate Path . . . . . . . . . . . . . 6
2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7 2.5. Discriminator of a Candidate Path . . . . . . . . . . . . 7
2.6. Identification of a Candidate Path . . . . . . . . . . . 7 2.6. Identification of a Candidate Path . . . . . . . . . . . 8
2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8 2.7. Preference of a Candidate Path . . . . . . . . . . . . . 8
2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8 2.8. Validity of a Candidate Path . . . . . . . . . . . . . . 8
2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 8 2.9. Active Candidate Path . . . . . . . . . . . . . . . . . . 9
2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 10 2.10. Validity of an SR Policy . . . . . . . . . . . . . . . . 10
2.11. Instantiation of an SR Policy in the Forwarding Plane . . 10 2.11. Instantiation of an SR Policy in the Forwarding Plane . . 10
2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 10 2.12. Priority of an SR Policy . . . . . . . . . . . . . . . . 10
2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Segment Routing Database . . . . . . . . . . . . . . . . . . 12 3. Segment Routing Database . . . . . . . . . . . . . . . . . . 12
4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Segment Types . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Explicit Null . . . . . . . . . . . . . . . . . . . . . . 16
5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 17 5. Validity of a Candidate Path . . . . . . . . . . . . . . . . 17
5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 17 5.1. Explicit Candidate Path . . . . . . . . . . . . . . . . . 17
5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 18 5.2. Dynamic Candidate Path . . . . . . . . . . . . . . . . . 18
skipping to change at page 2, line 47 skipping to change at page 2, line 47
6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. Binding SID . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 19 6.1. BSID of a candidate path . . . . . . . . . . . . . . . . 19
6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 19 6.2. BSID of an SR Policy . . . . . . . . . . . . . . . . . . 19
6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 21 6.3. Forwarding Plane . . . . . . . . . . . . . . . . . . . . 21
6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 21 6.4. Non-SR usage of Binding SID . . . . . . . . . . . . . . . 21
7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 21 7. SR Policy State . . . . . . . . . . . . . . . . . . . . . . . 21
8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 22 8. Steering into an SR Policy . . . . . . . . . . . . . . . . . 22
8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 22 8.1. Validity of an SR Policy . . . . . . . . . . . . . . . . 22
8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 22 8.2. Drop upon invalid SR Policy . . . . . . . . . . . . . . . 22
8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 23 8.3. Incoming Active SID is a BSID . . . . . . . . . . . . . . 23
8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 23 8.4. Per-Destination Steering . . . . . . . . . . . . . . . . 24
8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 25 8.5. Recursion on an on-demand dynamic BSID . . . . . . . . . 25
8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 25 8.6. Per-Flow Steering . . . . . . . . . . . . . . . . . . . . 25
8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 27 8.7. Policy-based Routing . . . . . . . . . . . . . . . . . . 27
8.8. Optional Steering Modes for BGP Destinations . . . . . . 27 8.8. Optional Steering Modes for BGP Destinations . . . . . . 27
9. Recovering from Network Failures . . . . . . . . . . . . . . 29 9. Recovering from Network Failures . . . . . . . . . . . . . . 29
9.1. Leveraging TI-LFA local protection of the constituent IGP 9.1. Leveraging TI-LFA local protection of the constituent IGP
segments . . . . . . . . . . . . . . . . . . . . . . . . 29 segments . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2. Using an SR Policy to locally protect a link . . . . . . 29 9.2. Using an SR Policy to locally protect a link . . . . . . 30
9.3. Using a Candidate Path for Path Protection . . . . . . . 30 9.3. Using a Candidate Path for Path Protection . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Manageability Considerations . . . . . . . . . . . . . . . . 31 11. Manageability Considerations . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
12.1. Guidance for Designated Experts . . . . . . . . . . . . 32 12.1. Guidance for Designated Experts . . . . . . . . . . . . 32
13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32 13. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 32
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
15.1. Normative References . . . . . . . . . . . . . . . . . . 34 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 35 15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
skipping to change at page 3, line 37 skipping to change at page 3, line 37
routing path. Intermediate per-path states are eliminated thanks to routing path. Intermediate per-path states are eliminated thanks to
source routing. source routing.
The headend node is said to steer a flow into a Segment Routing The headend node is said to steer a flow into a Segment Routing
Policy (SR Policy). [RFC8402] introduces the SR Policy construct and Policy (SR Policy). [RFC8402] introduces the SR Policy construct and
provides an overview of how it is leveraged for Segment Routing use- provides an overview of how it is leveraged for Segment Routing use-
cases. cases.
The packets steered into an SR Policy carry an ordered list of The packets steered into an SR Policy carry an ordered list of
segments associated with that SR Policy. [RFC8660] describes the segments associated with that SR Policy. [RFC8660] describes the
representation and processing of these ordered list of segments as an representation and processing of this ordered list of segments as an
MPLS label stack for SR-MPLS. While [RFC8754] and [RFC8986] describe MPLS label stack for SR-MPLS. While [RFC8754] and [RFC8986] describe
the same for Segment Routing over IPv6 (SRv6) with the use of the the same for Segment Routing over IPv6 (SRv6) with the use of the
Segment Routing Header (SRH). Segment Routing Header (SRH).
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 SR-MPLS and SRv6 into an SR Policy. These apply equally to the SR-MPLS and SRv6
instantiations of segment routing. instantiations of segment routing.
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 4, line 22 skipping to change at page 4, line 22
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.
This section defines the key aspects and constituents of an SR This section defines the key aspects and constituents of an SR
Policy. Policy.
2.1. Identification of an SR Policy 2.1. Identification of an SR Policy
An SR Policy is identified through the tuple <headend, color, An SR Policy MUST be identified through the tuple <headend, color,
endpoint>. In the context of a specific headend, one may identify an endpoint>. In the context of a specific headend, an SR policy MUST
SR policy by the <color, endpoint> tuple. be identified by the <color, endpoint> tuple.
The headend is the node where the policy is instantiated/implemented. The headend is the node where the policy is instantiated/implemented.
The headend is specified as an IPv4 or IPv6 address and is expected The headend is specified as an IPv4 or IPv6 address and is expected
to be unique in the domain. to be unique in the domain.
The endpoint indicates the destination of the policy. The endpoint The endpoint indicates the destination of the policy. The endpoint
is specified as an IPv4 or IPv6 address and is expected to be unique is specified as an IPv4 or IPv6 address and is expected to be unique
in the domain. In a specific case (refer to Section 8.8.1), the in the domain. In a specific case (refer to Section 8.8.1), the
endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6). endpoint can be the null address (0.0.0.0 for IPv4, ::0 for IPv6).
The color is an unsigned non-zero 32-bit numerical value that The color is an unsigned non-zero 32-bit numerical value that
associates the SR Policy with an intent or objective (e.g. low- associates the SR Policy with an intent or objective (e.g. low-
latency). 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 the assignment of a symbolic name
of printable ASCII [RFC0020] characters to an SR Policy to serve as a comprising of printable ASCII [RFC0020] [RFC5234] characters to an SR
user-friendly attribute for debugging and troubleshooting purposes. Policy to serve as a user-friendly attribute for debugging and
Such symbolic names may identify an SR Policy when the naming scheme troubleshooting purposes. Such symbolic names MAY identify an SR
ensures uniqueness. The SR Policy name MAY also be signaled along Policy when the naming scheme ensures uniqueness. The SR Policy name
with a candidate path of the SR Policy (refer to Section 2.2). An SR MAY also be signaled along with a candidate path of the SR Policy
Policy may have multiple names associated with it in the scenario (refer to Section 2.2). An SR Policy MAY have multiple names
where the headend receives different SR Policy names along with associated with it in the scenario where the headend receives
candidate paths for the same SR Policy. 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 protocol extensions like Path Computation Element (PCE) via protocol extensions like Path Computation Element (PCE)
Communication Protocol (PCEP) [RFC8664] Communication Protocol (PCEP) [RFC8664]
[I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy [I-D.ietf-pce-segment-routing-policy-cp] or BGP SR Policy
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy].
skipping to change at page 6, line 5 skipping to change at page 6, line 5
o The colors of each of the constituent SR Policies and the parent o The colors of each of the constituent SR Policies and the parent
SR Policy MUST be different SR Policy MUST be different
o the constituent SR Policies MUST NOT use composite candidate paths o the constituent SR Policies MUST NOT use composite candidate paths
Each constituent SR Policy of a composite candidate path is Each constituent SR Policy of a composite candidate path is
associated with weight for load-balancing purposes (refer to associated with weight for load-balancing purposes (refer to
Section 2.11 for details). The default weight is 1. Section 2.11 for details). The default weight is 1.
The Section 2.13 illustrates an information model for heirarchical
relationships between the SR Policy constructs described in this
section.
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
[RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP [RFC8664] [I-D.ietf-pce-segment-routing-policy-cp] or BGP
[I-D.ietf-idr-segment-routing-te-policy]. [I-D.ietf-idr-segment-routing-te-policy].
Protocol-Origin of a candidate path is an 8-bit value associated with Protocol-Origin of a candidate path is an 8-bit value associated with
the mechanism or protocol used for signaling/provisioning the SR the mechanism or protocol used for signaling/provisioning the SR
Policy. It helps identify the protocol/mechanism that provides or Policy. It helps identify the protocol/mechanism that provides or
signals the candidate path and indicates its preference relative to signals the candidate path and indicates its preference relative to
other protocols/mechanisms. other protocols/mechanisms.
The head-end assigns different Protocol-Origin values to each source The head-end assigns different Protocol-Origin values to each source
of SR Policy information. The Protocol-Origin value is used as a of SR Policy information. The Protocol-Origin value is used as a
tie-breaker between candidate-paths of equal preference, as described tie-breaker between candidate paths of equal preference, as described
in Section 2.9. The table below specifies the RECOMMENDED default in Section 2.9. The table below specifies the RECOMMENDED default
values of Protocol-Origin: values of Protocol-Origin:
+-----------------+-------------------+ +-----------------+-------------------+
| Protocol-Origin | Description | | Protocol-Origin | Description |
+-----------------+-------------------+ +-----------------+-------------------+
| 10 | PCEP | | 10 | PCEP |
| 20 | BGP SR Policy | | 20 | BGP SR Policy |
| 30 | Via Configuration | | 30 | Via Configuration |
+-----------------+-------------------+ +-----------------+-------------------+
skipping to change at page 8, line 20 skipping to change at page 8, line 28
The identity of a candidate path MUST be uniquely established in the The identity of a candidate path MUST be uniquely established in the
context of an SR Policy <headend, color, endpoint> to handle add, context of an SR Policy <headend, color, endpoint> to handle add,
delete or modify operations on them in an unambiguous manner delete or modify operations on them in an unambiguous manner
regardless of their source(s). regardless of their source(s).
The tuple <Protocol-Origin, originator, discriminator> uniquely The tuple <Protocol-Origin, originator, discriminator> uniquely
identifies a candidate path. identifies a candidate path.
Candidate paths MAY also be assigned or signaled with a symbolic name Candidate paths MAY also be assigned or signaled with a symbolic name
comprising printable ASCII [RFC0020] characters to serve as a user- comprising printable ASCII [RFC0020] [RFC5234] characters to serve as
friendly attribute for debugging and troubleshooting purposes. Such a user-friendly attribute for debugging and troubleshooting purposes.
symbolic names MUST NOT be considered as identifiers for a candidate Such symbolic names MUST NOT be considered as identifiers for a
path. candidate path.
2.7. Preference of a Candidate Path 2.7. Preference of a Candidate Path
The preference of the candidate path is used to select the best The preference of the candidate path is used to select the best
candidate path for an SR Policy. It is a 32-bit value where a higher candidate path for an SR Policy. It is a 32-bit value where a higher
value indicates higher preference and the default preference value is value indicates higher preference and the default preference value is
100. 100.
It is RECOMMENDED that each candidate path of a given SR policy has a It is RECOMMENDED that each candidate path of a given SR policy has a
different preference. different preference.
skipping to change at page 10, line 39 skipping to change at page 10, line 50
weights of the Segment-List of the active candidate path of that weights of the Segment-List of the active candidate path of that
constituent SR Policy. constituent SR Policy.
The accuracy of the weighted load-balancing depends on the platform The accuracy of the weighted load-balancing depends on the platform
implementation. implementation.
2.12. Priority of an SR Policy 2.12. Priority of an SR Policy
Upon topological change, many policies could be recomputed or Upon topological change, many policies could be recomputed or
revalidated. An implementation MAY provide a per-policy priority revalidated. An implementation MAY provide a per-policy priority
configuration. The operator may set this field to indicate the order configuration. The operator MAY set this field to indicate the order
in which the policies should be re-computed. Such a priority is in which the policies should be re-computed. Such a priority is
represented by an integer in the range (0, 255) where the lowest represented by an integer in the range (0, 255) where the lowest
value is the highest priority. The default value of priority is 128. value is the highest priority. The default value of priority is 128.
An SR Policy may comprise multiple Candidate Paths received from the An SR Policy MAY comprise multiple Candidate Paths received from the
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 and the SR Policy distinct signaled non-default priority values and the SR Policy
itself does not have a priority value configured, the SR Policy as a itself does not have a priority value configured, 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 = H1, color = 1, endpoint = E1> 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
Priority 10 Priority 10
Weight W1, SID-List1 <SID11...SID1i> Segment List 1 <SID11...SID1i>, Weight W1
Weight W2, SID-List2 <SID21...SID2j> Segment List 2 <SID21...SID2j>, Weight W2
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
Priority 10 Priority 10
Weight W3, SID-List3 <SID31...SID3i> Segment List 3 <SID31...SID3i>, Weight W3
Weight W4, SID-List4 <SID41...SID4j> Segment List 4 <SID41...SID4j>, Weight W4
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 has the highest CP1 is the active candidate path (it is valid and 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).
The information model of SR Policy POL100 having a composite The information model of SR Policy POL100 having a composite
candidate path is the following: candidate path is the following:
SR policy POL100 <headend = H1, color = 100, endpoint = E1> SR policy POL100 <headend = H1, color = 100, 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, SR policy <color = 1> SR policy <color = 1>, Weight W1
Weight W2, SR policy <color = 2> SR policy <color = 2>, Weight W2
The constituent SR Policies POL1 and POL2 have an information model The constituent SR Policies POL1 and POL2 have an information model
as described at the start of this section. They are referenced only as described at the start of this section. They are referenced only
by color in the composite candidate path since their headend and by color in the composite candidate path since their headend and
endpoint are identical to the POL100. The valid Segment-Lists of the endpoint are identical to the POL100. The valid Segment-Lists of the
active candidate path of POL1 and POL2 are installed in the active candidate path of POL1 and POL2 are installed in the
forwarding. Traffic steered on POL100 is flow-based hashed on POL1 forwarding. Traffic steered on POL100 is flow-based hashed on POL1
with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing with a ratio W1/(W1+W2). Within the POL1, the flow-based hashing
over its Segment-Lists are performed as described earlier in this over its Segment-Lists are performed as described earlier in this
section. section.
skipping to change at page 13, line 23 skipping to change at page 13, line 32
... Sn> where S1 is the first segment. ... Sn> where S1 is the first segment.
Based on the desired dataplane, either the MPLS label stack or the Based on the desired dataplane, either the MPLS label stack or the
SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. SRv6 Segment Routing Header [RFC8754] is built from the Segment-List.
However, the Segment-List itself can be specified using different However, the Segment-List itself can be specified using different
segment-descriptor types and the following are currently defined: segment-descriptor types and the following are currently defined:
Type A: SR-MPLS Label: Type A: SR-MPLS Label:
An MPLS label corresponding to any of the segment types defined An 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, special purpose
like explicit-null or in general any MPLS label may also be labels like explicit-null or in general any MPLS label MAY also
used. E.g. this type can be used to specify a label be used. E.g. this type can be used to specify a label
representation that maps to an optical transport path on a representation that 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 SID behaviors for An IPv6 address corresponding to any of the SID behaviors for
SRv6 (as defined in [RFC8986] or other SRv6 specifications) can SRv6 (as defined in [RFC8986] or other SRv6 specifications) can
be used. This type does not require the headend to perform SID be used. This type does not require the headend to perform SID
resolution. Optionally, the SRv6 SID behavior (as defined in resolution. Optionally, the SRv6 SID behavior (as defined in
[RFC8986] or other SRv6 specifications) and structure (as [RFC8986] or other SRv6 specifications) and structure (as
skipping to change at page 16, line 12 skipping to change at page 16, line 20
behavior (as defined in [RFC8986] or other SRv6 specifications) behavior (as defined in [RFC8986] or other SRv6 specifications)
and structure (as defined in [RFC8986]) MAY also be provided. and structure (as defined in [RFC8986]) MAY also be provided.
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 the algorithm enables Shortest Path algorithm. The specification of the algorithm enables
the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific
SIDs in SR Policy. SIDs in SR Policy.
For SID types C-through-K, a SID value may also be optionally For SID types C-through-K, 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
directed toward along the explicit SR path. directed toward along the explicit SR path.
o The last Segment represents the bottommost label or the last IPv6 o The last Segment represents the bottommost label or the last IPv6
segment the traffic will be directed toward along the explicit SR segment the traffic will be directed toward along the explicit SR
path. path.
4.1. Explicit Null 4.1. Explicit Null
A Type A SID may be any MPLS label, including reserved labels. A Type A SID MAY be any MPLS label, including special purpose labels.
For example, assuming that the desired traffic-engineered path from a For example, assuming that the desired traffic-engineered path from a
headend 1 to an endpoint 4 can be expressed by the Segment-List headend 1 to an endpoint 4 can be expressed by the Segment-List
<16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer <16002, 16003, 16004> where 16002, 16003 and 16004 respectively refer
to the IPv4 Prefix SIDs bound to node 2, 3, and 4, then IPv6 traffic to the IPv4 Prefix SIDs bound to nodes 2, 3, and 4, then IPv6 traffic
can be traffic-engineered from nodes 1 to 4 via the previously can be traffic-engineered from nodes 1 to 4 via the previously
described path using an SR Policy with Segment-List <16002, 16003, described path using an SR Policy with Segment-List <16002, 16003,
16004, 2> where the MPLS label value of 2 represents the "IPv6 16004, 2> where the MPLS label value of 2 represents the "IPv6
Explicit NULL Label". Explicit NULL Label".
The penultimate node before node 4 will pop 16004 and will forward The penultimate node before node 4 will pop 16004 and will forward
the frame on its directly connected interface to node 4. the frame on its directly connected interface to node 4.
The endpoint receives the traffic with the top label "2" which The endpoint receives the traffic with the top label "2" which
indicates that the payload is an IPv6 packet. indicates that the payload is an IPv6 packet.
skipping to change at page 17, line 35 skipping to change at page 17, line 44
is forwarded based on the inner label or an IP lookup in the case of is forwarded based on the inner label or an IP lookup in the case of
unlabeled IP packets. Such an explicit path can serve as a fallback unlabeled IP packets. Such an explicit path can serve as a fallback
or path of last resort for traffic being steered into an SR Policy or path of last resort for traffic being steered into an SR Policy
using its BSID (refer to Section 8.3). using its BSID (refer to Section 8.3).
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 any of the following is true: when any of the following is true:
o It is empty. o It is empty.
o Its weight is 0. o Its weight is 0.
o It comprises of a mix of SR-MPLS and SRv6 segment types. o It comprises a mix of SR-MPLS and SRv6 segment types.
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-K 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 a mis-match between the SID value and its o The headend detects a mismatch 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-K 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-K 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 may 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.
Additionally, a Segment-List MAY be declared invalid when: Additionally, 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)
advertised by the node specified as the endpoint of the advertised by the node specified as the endpoint of the
corresponding SR policy. corresponding SR policy.
o Its last segment is not an Adjacency SID (including BGP Peer o Its last segment is not an Adjacency SID (including BGP Peer
Adjacency SID) of any of the links present on neighbor nodes and Adjacency SID) of any of the links present on neighbor nodes and
that terminate on the node specified as the endpoint of the that terminate on the node specified as the endpoint of the
corresponding SR policy. corresponding SR policy.
An explicit candidate path is invalid as soon as it has no valid An explicit candidate path is invalid as soon as it has no valid
Segment-List. Segment-List.
Additionally, an explicit candidate path MAY be declared invalid when Additionally, an explicit candidate path MAY be declared invalid when
its constituent segment lists (valid or invalid) are using segment its constituent segment lists (valid or invalid) are using segment
types of different SR dataplanes. types of different SR data planes.
5.2. Dynamic Candidate Path 5.2. Dynamic Candidate Path
A dynamic candidate path is specified as an optimization objective A dynamic candidate path is specified as an optimization objective
and constraints. and constraints.
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 for either the SR-MPLS or the SRv6 data-plane as specified. problem for either the SR-MPLS or the SRv6 data-plane as specified.
skipping to change at page 23, line 15 skipping to change at page 23, line 28
8.3. Incoming Active SID is a BSID 8.3. Incoming Active SID is a BSID
Let us assume that headend H has a valid SR Policy P of Segment-List Let us assume that headend H has a valid SR Policy P of Segment-List
<S1, S2, S3> and BSID B. <S1, S2, S3> and BSID B.
In the case of SR-MPLS, when H receives a packet K with label stack In the case of SR-MPLS, when H receives a packet K with label stack
<B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the <B, L2, L3>, H pops B and pushes <S1, S2, S3> and forwards the
resulting packet according to SID S1. resulting packet according to SID S1.
"Forwarding the resulting packet according to S1" means: If S1 is "Forwarding the resulting packet according to S1" means: If S1 is
an Adj SID or a PHP-enabled prefix SID advertised by a neighbor, H an Adj-SID or a PHP-enabled prefix SID advertised by a neighbor, H
sends the resulting packet with label stack <S2, S3, L2, L3> on sends the resulting packet with label stack <S2, S3, L2, L3> on
the outgoing interface associated with S1; Else H sends the the outgoing interface associated with S1; Else H sends the
resulting packet with label stack <S1, S2, S3, L2, L3> along the resulting packet with label stack <S1, S2, S3, L2, L3> along the
path of S1. path of S1.
In the case of SRv6, the processing is similar and follows the SR In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of [RFC8986]. Policy headend behaviors as specified in section 5 of [RFC8986].
H has steered the packet into the SR policy P. H has steered the packet into the SR policy P.
skipping to change at page 24, line 26 skipping to change at page 24, line 40
Note that any SID associated with the BGP route is inserted after the Note that any SID associated with the BGP route is inserted after the
Segment-List of the SR Policy (i.e., <S1, S2, S3, V>). Segment-List of the SR Policy (i.e., <S1, S2, S3, V>).
In the case of SRv6, the processing is similar and follows the SR In the case of SRv6, the processing is similar and follows the SR
Policy headend behaviors as specified in section 5 of [RFC8986]. Policy headend behaviors as specified in section 5 of [RFC8986].
The same behavior applies to any type of service route: any AFI/SAFI The same behavior applies to any type of service route: any AFI/SAFI
of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830]. of BGP [RFC4760] any AFI/SAFI of LISP [RFC6830].
In a BGP multi-path scenario, the BGP route may be resolved over a In a BGP multi-path scenario, the BGP route MAY be resolved over a
mix of paths that include those that are steered over SR Policies and mix of paths that include those that are steered over SR Policies and
others resolved via the normal BGP nexthop resolution. others resolved via the normal BGP nexthop resolution.
Implementations MAY provide options to prefer one type over the other Implementations MAY provide options to prefer one type over the other
or other forms of local policy to determine the paths that are or other forms of local policy to determine the paths that are
selected. selected.
8.4.1. Multiple Colors 8.4.1. Multiple Colors
When a BGP route has multiple Color Extended communities each with a When a BGP route has multiple Color Extended communities each with a
valid SR Policy, the BGP process installs the route on the SR Policy valid SR Policy, the BGP process installs the route on the SR Policy
skipping to change at page 26, line 20 skipping to change at page 26, line 34
o Entry A(2) set to SR Policy P2 of BSID=B2. o Entry A(2) set to SR Policy P2 of BSID=B2.
H receives three packets K, K1, and K2 on its incoming interface. H receives three packets K, K1, and K2 on its incoming interface.
These three packets either longest-match on N or more likely on a These three packets either longest-match on N or more likely on a
BGP/service route which recurses on N. H colors these 3 packets BGP/service route which recurses on N. H colors these 3 packets
respectively with forwarding-class 0, 1, and 2. respectively with forwarding-class 0, 1, and 2.
As a result, for SR-MPLS: As a result, for SR-MPLS:
o H forwards K along the shortest path to N (i.e., pushes the o H forwards K along the shortest path to N (i.e., pushes the
prefix-SID of N). Prefix-SID of N).
o H pushes <S1, S2, S3> on packet K1 and forwards the resulting o H pushes <S1, S2, S3> on packet K1 and forwards the resulting
frame along the shortest path to S1. frame along the shortest path to S1.
o H pushes <S4, S5, S6> on packet K2 and forwards the resulting o H pushes <S4, S5, S6> on packet K2 and forwards the resulting
frame along the shortest path to S4. frame along the shortest path to S4.
For SRv6, the processing is similar and the segment lists of the For SRv6, the processing is similar and the segment lists of the
individual SR Policies P1 and P2 are enforced for packet K1 and K2 individual SR Policies P1 and P2 are enforced for packets K1 and K2
using the SR Policy headend behaviors as specified in section 5 of using the SR Policy headend behaviors as specified in section 5 of
[RFC8986]. [RFC8986].
If the local configuration does not specify any explicit forwarding If the local configuration does not specify any explicit forwarding
information for an entry of the array, then this entry is filled with information for an entry of the array, then this entry is filled with
the same information as entry 0 (i.e. the IGP shortest path). the same information as entry 0 (i.e. the IGP shortest path).
If the SR Policy mapped to an entry of the array becomes invalid, If the SR Policy mapped to an entry of the array becomes invalid,
then this entry is filled with the same information as entry 0. When then this entry is filled with the same information as entry 0. When
all the array entries have the same information as entry0, the all the array entries have the same information as entry0, the
skipping to change at page 27, line 7 skipping to change at page 27, line 21
This realizes per-flow steering: different flows bound to the same This realizes per-flow steering: different flows bound to the same
BGP endpoint are steered on different IGP or SR Policy paths. BGP endpoint are steered on different IGP or SR Policy paths.
A headend MAY support options to apply per-flow steering only for A headend MAY support options to apply per-flow steering only for
traffic matching specific prefixes (e.g. specific IGP or BGP traffic matching specific prefixes (e.g. specific IGP or BGP
prefixes). prefixes).
8.7. Policy-based Routing 8.7. Policy-based Routing
Finally, headend H may be configured with a local routing policy Finally, headend H MAY be configured with a local routing policy
which overrides any BGP/IGP path and steer a specified packet on an which overrides any BGP/IGP path and steer a specified packet on an
SR Policy. This includes the use of mechanisms like IGP Shortcut for SR Policy. This includes the use of mechanisms like IGP Shortcut for
automatic routing of IGP prefixes over SR Policies intended for such automatic routing of IGP prefixes over SR Policies intended for such
purpose. purpose.
8.8. Optional Steering Modes for BGP Destinations 8.8. Optional Steering Modes for BGP Destinations
8.8.1. Color-Only BGP Destination Steering 8.8.1. Color-Only BGP Destination Steering
In the previous section, it is seen that the steering on an SR Policy In the previous section, it is seen that the steering on an SR Policy
skipping to change at page 30, line 4 skipping to change at page 30, line 10
of the constituent segments. Since TI-LFA protection is based on IGP of the constituent segments. Since TI-LFA protection is based on IGP
computation, there are cases where the path used during the fast- computation, there are cases where the path used during the fast-
reroute time window may not meet the exact constraints of the SR reroute time window may not meet the exact constraints of the SR
Policy. Policy.
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.
9.2. Using an SR Policy to locally protect a link 9.2. Using an SR Policy to locally protect a link
1----2-----6----7 1----2-----6----7
| | | | | | | |
4----3-----9----8 4----3-----9----8
Figure 1: Local protection using SR Policy Figure 1: Local protection using SR Policy
An SR Policy can be instantiated at node 2 to protect the link 2to6. An SR Policy can be instantiated at node 2 to protect link 2to6. A
A typical explicit Segment-List would be <3, 9, 6>. typical explicit Segment-List would be <3, 9, 6>.
A typical use-case occurs for links outside an IGP domain: e.g. 1, 2, A typical use-case occurs for links outside an IGP domain: e.g. 1, 2,
3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are 3, and 4 are part of IGP/SR sub-domain 1 while 6, 7, 8, and 9 are
part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9 part of IGP/SR sub-domain 2. In such a case, links 2to6 and 3to9
cannot benefit from TI-LFA automated local protection. The SR Policy cannot benefit from TI-LFA automated local protection. The SR Policy
with Segment-List <3, 9, 6> on node 2 can be locally configured to be with Segment-List <3, 9, 6> on node 2 can be locally configured to be
a fast-reroute backup path for the link 2to6. a fast-reroute backup path for the link 2to6.
9.3. Using a Candidate Path for Path Protection 9.3. Using a Candidate Path for Path Protection
skipping to change at page 31, line 26 skipping to change at page 31, line 34
been defined in [I-D.ietf-spring-sr-policy-yang]. been defined in [I-D.ietf-spring-sr-policy-yang].
12. IANA Considerations 12. IANA Considerations
The document requests IANA to create a new sub-registry called The document requests IANA to create a new sub-registry called
"Segment Types" under the top-level "Segment Routing" registry that "Segment Types" under the top-level "Segment Routing" registry that
was created by [RFC8986]. This sub-registry maintains the alphabetic was created by [RFC8986]. This sub-registry maintains the alphabetic
identifiers for the segment types (as specified in section 4) that identifiers for the segment types (as specified in section 4) that
may be used within a Segment List of an SR Policy. The alphabetical may be used within a Segment List of an SR Policy. The alphabetical
identifiers run from A to Z and may be extended on exhaustion with identifiers run from A to Z and may be extended on exhaustion with
the identifiers AA to AZ, BA to BZ and so on through till ZZ. This the identifiers AA to AZ, BA to BZ, and so on through till ZZ. This
sub-registry would follow the Specification Required allocation sub-registry would follow the Specification Required allocation
policy as specified in [RFC8126]. policy as specified in [RFC8126].
The initial registrations for this sub-registry are as follows: The initial registrations for this sub-registry are as follows:
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-----------------------------------------------+-----------+ +-------+-----------------------------------------------+-----------+
| A | SR-MPLS Label | [This.ID] | | A | SR-MPLS Label | [This.ID] |
| B | SRv6 SID | [This.ID] | | B | SRv6 SID | [This.ID] |
skipping to change at page 32, line 49 skipping to change at page 32, line 49
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.
13. Acknowledgement 13. Acknowledgement
The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger The authors would like to thank Tarek Saad, Dhanendra Jain, Ruediger
Geib, Rob Shakir, Cheng Li, Dhruv Dhody and Gyan Mishra for their Geib, Rob Shakir, Cheng Li, Dhruv Dhody, Gyan Mishra, Nandan Saha,
review comments and suggestions. Jim Guichard, Martin Vigoureux, Benjamin Schwartz, David Schinazi,
and Matthew Bocci for their review comments and suggestions.
14. Contributors 14. Contributors
The following people have contributed to this document: The following people have contributed to this document:
Siva Sivabalan Siva Sivabalan
Cisco Systems Cisco Systems
Email: msiva@cisco.com Email: msiva@cisco.com
Zafar Ali Zafar Ali
skipping to change at page 37, line 10 skipping to change at page 37, line 10
[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>.
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
 End of changes. 39 change blocks. 
56 lines changed or deleted 68 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/