< draft-ietf-spring-segment-routing-12.txt   draft-ietf-spring-segment-routing-13.txt >
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: December 22, 2017 B. Decraene Expires: May 1, 2018 L. Ginsberg
Cisco Systems, Inc
B. Decraene
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google, Inc. Google, Inc.
June 20, 2017 October 28, 2017
Segment Routing Architecture Segment Routing Architecture
draft-ietf-spring-segment-routing-12 draft-ietf-spring-segment-routing-13
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. A node Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called steers a packet through an ordered list of instructions, called
segments. A segment can represent any instruction, topological or segments. A segment can represent any instruction, topological or
service-based. A segment can have a semantic local to an SR node or service-based. A segment can have a semantic local to an SR node or
global within an SR domain. SR allows to enforce a flow through any global within an SR domain. SR allows to enforce a flow through any
topological path and service chain while maintaining per-flow state topological path while maintaining per-flow state only at the ingress
only at the ingress nodes to the SR domain. nodes to the SR domain.
Segment Routing can be directly applied to the MPLS architecture with Segment Routing can be directly applied to the MPLS architecture with
no change on the forwarding plane. A segment is encoded as an MPLS no change on the forwarding plane. A segment is encoded as an MPLS
label. An ordered list of segments is encoded as a stack of labels. label. An ordered list of segments is encoded as a stack of labels.
The segment to process is on the top of the stack. Upon completion The segment to process is on the top of the stack. Upon completion
of a segment, the related label is popped from the stack. of a segment, the related label is popped from the stack.
Segment Routing can be applied to the IPv6 architecture, with a new Segment Routing can be applied to the IPv6 architecture, with a new
type of routing header. A segment is encoded as an IPv6 address. An type of routing header. A segment is encoded as an IPv6 address. An
ordered list of segments is encoded as an ordered list of IPv6 ordered list of segments is encoded as an ordered list of IPv6
skipping to change at page 2, line 8 skipping to change at page 2, line 13
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [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 http://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 December 22, 2017. This Internet-Draft will expire on May 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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. Companion Documents . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 8
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 8
3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 8
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7 3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 8 3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 9 3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 12
3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10 3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 12
3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 10 3.3.1. Anycast SID in SR-MPLS . . . . . . . . . . . . . . . 12
3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 13 3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 14
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 14 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 15 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16
3.5. Binding Segment . . . . . . . . . . . . . . . . . . . . . 15 3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 17
3.5.1. Mapping Server . . . . . . . . . . . . . . . . . . . 15
3.5.2. Tunnel Head-end . . . . . . . . . . . . . . . . . . . 16 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 18
3.6. Inter-Area Considerations . . . . . . . . . . . . . . . . 16 4.1. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . 18
4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 17 4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 18
5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 18 5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 19
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 20 8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Manageability Considerations . . . . . . . . . . . . . . . . 21 8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Manageability Considerations . . . . . . . . . . . . . . . . 22
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
With Segment Routing (SR), a node steers a packet through an ordered Segment Routing (SR) leverages the source routing paradigm. A node
list of instructions, called segments. A segment can represent any steers a packet through an SR Policy instantiated as an ordered list
of instructions called segments. A segment can represent any
instruction, topological or service-based. A segment can have a instruction, topological or service-based. A segment can have a
semantic local to an SR node or global within an SR domain. SR semantic local to an SR node or global within an SR domain. SR
allows to enforce a flow through any path and service chain while supports per-flow explicit routing while maintaining per-flow state
maintaining per-flow state only at the ingress node of the SR domain. only at the ingress nodes to the SR domain.
Segment Routing can be directly applied to the MPLS architecture A segment is often referred by its Segment Identifier (SID).
([RFC3031]) with no change on the forwarding plane. A segment is
encoded as an MPLS label. An ordered list of segments is encoded as
a stack of labels. The active segment is on the top of the stack. A
completed segment is popped off the stack. The addition of a segment
is performed with a push.
In the Segment Routing MPLS instantiation, a segment could be of A segment may be associated with a topological instruction. A
several types: topological local segment may instruct a node to forward the packet
via a specific outgoing interface. A topological global segment may
instruct an SR domain to forward the packet via a specific path to a
destination. Different segments may exist for the same destination,
each with different path objectives (e.g., which metric is minimized,
what constraints are specified).
o an IGP segment, A segment may be associated with a service instruction (e.g. the
packet should be processed by a container or VM associated with the
segment). A segment may be associated with a QoS treatment (e.g.,
shape the packets received with this segment at x Mbps).
o a BGP Peering segment, The SR architecture supports any type of instruction associated with
a segment.
o an LDP LSP segment, The SR architecture supports any type of control-plane: distributed,
centralized or hybrid.
o an RSVP-TE LSP segment, In a distributed scenario, the segments are allocated and signaled by
IS-IS or OSPF or BGP. A node individually decides to steer packets
on a source-routed policy (e.g., pre-computed local protection
[I-D.ietf-spring-resiliency-use-cases] ) . A node individually
computes the source-routed policy.
o a BGP LSP segment. In a centralized scenario, the segments are allocated and
instantiated by an SR controller. The SR controller decides which
nodes need to steer which packets on which source-routed policies.
The SR controller computes the source-routed policies. The SR
architecture does not restrict how the controller programs the
network. Likely options are NETCONF, PCEP and BGP. The SR
architecture does not restrict the number of SR controllers.
Specifically multiple SR controllers may program the same SR domain.
The SR architecture allows these SR controllers to discover which
SID's are instantiated at which nodes and which sets of local (SRLB)
and global labels (SRGB) are available at which node.
The first two (IGP and BGP peering segments) types of segments are A hybrid scenario complements a base distributed control-plane with a
defined in this document. The use of the last three types of centralized controller. For example, when the destination is outside
segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. the IGP domain, the SR controller may compute a source-routed policy
on behalf of an IGP node. The SR architecture does not restrict how
the nodes which are part of the distributed control-plane interact
with the SR controller. Likely options are PCEP and BGP.
Segment Routing can be applied to the IPv6 architecture ([RFC2460]), Hosts MAY be part of an SR Domain. A centralized controller can
with a new type of routing header. A segment is encoded as an IPv6 inform hosts about policies either by pushing these policies to hosts
address. An ordered list of segments is encoded as an ordered list or responding to requests from hosts.
of IPv6 addresses in the routing header. The active segment is
indicated by the Destination Address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and
indicates the next segment.
Numerous use-cases illustrate the benefits of source routing either The SR architecture can be instantiated on various dataplanes. This
for FRR, OAM or Traffic Engineering reasons document introduces two dataplanes instantiations of SR: SR over MPLS
([I-D.ietf-spring-oam-usecase]). (SR-MPLS) and SR over IPv6 (SRv6).
This document defines a set of instructions (called segments) that Segment Routing can be directly applied to the MPLS architecture with
are required to fulfill the described use-cases. These segments can no change on the forwarding plane
either be used in isolation (one single segment defines the source [I-D.ietf-spring-segment-routing-mpls] A segment is encoded as an
route of the packet) or in combination (these segments are part of an MPLS label. An SR Policy is instantiated as a stack of labels. The
ordered list of segments that define the source route of the packet). segment to process (the active segment) is on the top of the stack.
Upon completion of a segment, the related label is popped from the
stack.
1.1. Companion Documents Segment Routing can be applied to the IPv6 architecture with a new
type of routing header called the SR header (SRH)
[I-D.ietf-6man-segment-routing-header] . An instruction is associated
with a segment and encoded as an IPv6 address. An SRv6 segment is
also called an SRv6 SID. An SR Policy is instantiated as an ordered
list of SRv6 SID's in the routing header. The active segment is
indicated by the Destination Address(DA) of the packet. The next
active segment is indicated by the SegmentsLeft (SL) pointer in the
SRH. When an SRv6 SID is completed, the SL is decremented and the
next segment is copied to the DA. When a packet is steered on an SR
policy, the related SRH is added to the packet.
This document defines the SR architecture, its routing model, the In the context of an IGP-based distributed control-plane, two
IGP-based segments, the BGP-based segments and the service segments. topological segments are defined: the IGP adjacency segment and the
IGP prefix segment.
The problem statement and requirements are described in [RFC7855]. In the context of a BGP-based distributed control-plane, two
topological segments are defined: the BGP peering segment and the BGP
prefix segment.
Use cases are described in .[I-D.ietf-spring-ipv6-use-cases], The headend of an SR Policy binds a SID (called Binding segment or
[I-D.ietf-spring-resiliency-use-cases] and BSID) to its policy. When the headend receives a packet with active
[I-D.ietf-spring-oam-usecase]. segment matching the BSID of a local SR Policy, the headend steers
the packet into the associated SR Policy.
This document defines the IGP, BGP and Binding segments for the SR-
MPLS and SRv6 dataplanes.
2. Terminology 2. Terminology
SR-MPLS: the instantiation of SR on the MPLS dataplane
SRv6: the instantiation of SR on the IPv6 dataplane.
Segment: an instruction a node executes on the incoming packet (e.g.: Segment: an instruction a node executes on the incoming packet (e.g.:
forward packet according to shortest path to destination, or, forward forward packet according to shortest path to destination, or, forward
packet through a specific interface, or, deliver the packet to a packet through a specific interface, or, deliver the packet to a
given application/service instance). given application/service instance).
SID: a segment identifier. Examples of SIDs are: an MPLS label, an SID: a segment identifier. Note that the term SID is commonly used
index value in an MPLS label space, an IPv6 address. Other types of in place of the term Segment, though this is technically imprecise as
SIDs can be defined in the future. it overlooks any necessary translation.
Segment List: ordered list of SIDs encoding the ordered set of SR-MPLS SID: an MPLS label or an index value into an MPLS label space
instructions to be applied to the packet as it traverses the SR explicitly associated with the segment.
domain. For example, the topological and service source route of the
packet. The Segment List is instantiated as a stack of labels in the
MPLS architecture and as an ordered list of IPv6 addresses in the
IPv6 architecture.
Segment Routing Domain (SR Domain): the set of nodes participating SRv6 SID: an IPv6 address explicitly associated with the segment.
into the source based routing model. These nodes may be connected to
the same physical infrastructure (e.g.: a Service Provider's Segment Routing Domain (SR Domain): the set of nodes participating in
network). They may as well be remotely connected to each other the source based routing model. These nodes may be connected to the
(e.g.: an enterprise VPN or an overlay). Note that an SR domain may same physical infrastructure (e.g.: a Service Provider's network).
also be confined within an IGP instance, in which case it is named They may as well be remotely connected to each other (e.g.: an
SR-IGP Domain. enterprise VPN or an overlay). If multiple protocol instances are
deployed, the SR domain most commonly includes all of the protocol
instances in a single SR domain. However, some deployments may wish
to sub-divide the network into multiple SR domains, each of which
includes one or more protocol instances. It is expected that all
nodes in an SR Domain are managed by the same administrative entity.
Active Segment: the segment that MUST be used by the receiving router Active Segment: the segment that MUST be used by the receiving router
to process the packet. In the MPLS dataplane it is the top label. to process the packet. In the MPLS dataplane it is the top label.
In the IPv6 dataplane it is the destination address of a packet In the IPv6 dataplane it is the destination address.
having the Segment Routing Header (SRH) as defined in
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
PUSH: the instruction consisting of the insertion of a segment at the PUSH: the instruction consisting of the insertion of a segment at the
top of the segment list. In the MPLS dataplane the top of the top of the segment list. In SR-MPLS the top of the segment list is
segment list is the topmost (outer) label of the label stack. In the the topmost (outer) label of the label stack. In SRv6, the top of
IPv6 dataplane, the top of the segment list is represented by the the segment list is represented by the first segment in the Segment
first segment in the Segment Routing Header as defined in Routing Header as defined in [I-D.ietf-6man-segment-routing-header].
[I-D.ietf-6man-segment-routing-header].
NEXT: when the active segment is completed, NEXT is the instruction NEXT: when the active segment is completed, NEXT is the instruction
consisting of the inspection of the next segment. The next segment consisting of the inspection of the next segment. The next segment
becomes active. becomes active. In SR-MPLS, NEXT is implemented as a POP of the top
label. In SRv6, NEXT is implemented as the copy of the next segment
from the SRH to the Destination Address of the IPv6 header.
CONTINUE: the active segment is not completed and hence remains CONTINUE: the active segment is not completed and hence remains
active. The CONTINUE instruction is implemented as the SWAP active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of
instruction in the MPLS dataplane. In IPv6, this is the plain IPv6 the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding
forwarding action of a regular IPv6 packet according to its action of a regular IPv6 packet according to its Destination Address.
Destination Address.
SR Global Block (SRGB): local property of an SR node. In the MPLS SR Global Block (SRGB): the set of global segments in the SR Domain.
architecture, SRGB is the set of local labels reserved for global If a node participates in multiple SR domains, there is one SRGB for
segments. Using the same SRGB on all nodes within the SR domain ease each SR domain. In SR-MPLS, SRGB is a local property of a node and
operations and troubleshooting and is expected to be a deployment identifies the set of local labels reserved for global segments. In
guideline. In the IPv6 architecture, the equivalent of the SRGB is SR-MPLS, using the same SRGB on all nodes within the SR Domain is
in fact the set of addresses used as global segments. Since there strongly recommended. Doing so eases operations and troubleshooting
are no restrictions on which IPv6 address can be used, the concept of as the same label represents the same global segment at each node.
the SRGB includes all IPv6 global address space used within the SR In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain.
domain.
Global Segment: the related instruction is supported by all the SR- SR Local Block (SRLB): local property of an SR node. If a node
capable nodes in the domain. In the MPLS architecture, a global participates in multiple SR domains, there is one SRLB for each SR
segment is represented by a globally-unique index. The related local domain. In SR-MPLS, SRLB is a set of local labels reserved for local
label at a given node N is found by adding the globally-unique index segments. In SRv6, SRLB is a set of local IPv6 addresses reserved
to the SRGB of node N. In the IPv6 architecture, a global segment is for local SRv6 SID's. In a controller-driven network, some
a globally-unique IPv6 address. controllers or applications MAY use the control plane to discover the
available set of local segments.
Local Segment: the related instruction is supported only by the node Global Segment: a segment which is part of the SRGB of the domain.
originating it. In the MPLS architecture, this is a local label The instruction associated to the segment is defined at the SR Domain
outside the SRGB. In the IPv6 architecture, this can be any IPv6 level. A topological shortest-path segment to a given destination
address whose reachability is not advertised in any routing protocol within an SR domain is a typical example of a global segment.
(hence, the segment is known only by the local node).
Local Segment: In SR-MPLS, this is a local label outside the SRGB.
It MAY be part of the explicitly advertised SRLB. In SRv6, this can
be any IPv6 address i.e., the address MAY be part of the SRGB but
used such that it has local significance. The instruction associated
to the segment is defined at the node level.
IGP Segment: the generic name for a segment attached to a piece of IGP Segment: the generic name for a segment attached to a piece of
information advertised by a link-state IGP, e.g. an IGP prefix or an information advertised by a link-state IGP, e.g. an IGP prefix or an
IGP adjacency. IGP adjacency.
IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment
representing an IGP prefix. An IGP-Prefix Segment is global (unless representing an IGP prefix. When an IGP-Prefix Segment is global
explicitly advertised otherwise) within the SR IGP instance/topology within the SR IGP instance/topology it identifies an instruction to
and identifies an instruction to forward the packet along the path forward the packet along the path computed using the routing
computed using the routing algorithm specified in the algorithm algorithm specified in the algorithm field, in the topology and the
field, in the topology and the IGP instance where it is advertised. IGP instance where it is advertised. Also referred to as Prefix
Also referred to as Prefix Segment. Segment.
Prefix SID: the SID of the IGP-Prefix Segment. Prefix SID: the SID of the IGP-Prefix Segment.
IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment
which identify an anycast prefix advertised by a set of routers. which identify an anycast prefix advertised by a set of routers.
Anycast-SID: the SID of the IGP-Anycast Segment. Anycast-SID: the SID of the IGP-Anycast Segment.
IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment
attached to a unidirectional adjacency or a set of unidirectional attached to a unidirectional adjacency or a set of unidirectional
skipping to change at page 6, line 40 skipping to change at page 7, line 44
Also referred to as Adjacency Segment. Also referred to as Adjacency Segment.
Adj-SID: the SID of the IGP-Adjacency Segment. Adj-SID: the SID of the IGP-Adjacency Segment.
IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which IGP-Node Segment: an IGP-Node Segment is an IGP-Prefix Segment which
identifies a specific router (e.g., a loopback). Also referred to as identifies a specific router (e.g., a loopback). Also referred to as
Node Segment. Node Segment.
Node-SID: the SID of the IGP-Node Segment. Node-SID: the SID of the IGP-Node Segment.
Note that for all of the above, the SID is often used to refer to the SR Policy: an ordered list of segments. The headend of an SR Policy
Segment itself. For example, Prefix-SID is sometimes used to refer steers packets onto the SR policy. The list of segments can be
to Prefix Segment. specified explicitly in SR-MPLS as a stack of labels and in SRv6 as
an ordered list of SRv6 SID's. Alternatively, the list of segments
is computed based on a destination and a set of optimization
objective and constraints (e.g., latency, affinity, SRLG, ...). The
computation can be local or delegated to a PCE server. An SR policy
can be configured by the operator, provisioned via NETCONF or
provisioned via PCEP [RFC5440] . An SR policy can be used for
traffic-engineering, OAM or FRR reasons.
SR Tunnel: a list of segments to be pushed on the packets directed on Segment List Depth: the number of segments of an SR policy. The
the tunnel. The list of segments can be specified explicitly or entity instantiating an SR Policy at a node N should be able to
implicitly via a set of abstract constraints (latency, affinity, discover the depth insertion capability of the node N. For example,
SRLG, ...). In the latter case, a constraint-based path computation the PCEP SR capability advertisement described in
is used to determine the list of segments associated with the tunnel. [I-D.ietf-pce-segment-routing] is one means of discovering this
The computation can be local or delegated to a PCE server. An SR capability.
tunnel can be configured by the operator, provisioned via netconf or
provisioned via PCEP. An SR tunnel can be used for traffic-
engineering, OAM or FRR reasons.
Segment List Depth: the number of segments of an SR tunnel. The Forwarding Information Base (FIB): the forwarding table of a node
entity instantiating an SR Tunnel at a node N should be able to
discover the depth insertion capability of the node N. The PCEP
discovery capability is described in [I-D.ietf-pce-segment-routing].
3. Link-State IGP Segments 3. Link-State IGP Segments
Within a link-state IGP domain, an SR-capable IGP node advertises Within an SR domain, an SR-capable IGP node advertises segments for
segments for its attached prefixes and adjacencies. These segments its attached prefixes and adjacencies. These segments are called IGP
are called IGP segments or IGP SIDs. They play a key role in Segment segments or IGP SIDs. They play a key role in Segment Routing and
Routing and use-cases as they enable the expression of any path use-cases as they enable the expression of any path throughout the SR
throughout the IGP domain. Such a path is either expressed as a domain. Such a path is either expressed as a single IGP segment or a
single IGP segment or a list of multiple IGP segments. list of multiple IGP segments.
IGP segments require extensions in link-state IGP protocols. IGP Advertisement of IGP segments requires extensions in link-state IGP
extensions are required in order to advertise the IGP segments. protocols. These extensions are defined in
[I-D.ietf-isis-segment-routing-extensions]
[I-D.ietf-ospf-segment-routing-extensions]
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]
3.1. IGP-Prefix Segment, Prefix-SID 3.1. IGP-Prefix Segment, Prefix-SID
An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is an IGP segment attached to an IGP prefix.
An IGP-Prefix segment is global (unless explicitly advertised An IGP-Prefix segment is global (unless explicitly advertised
otherwise) within the SR/IGP domain. otherwise) within the SR domain. The context for an IGP-Prefix
segment includes the prefix, topology, and algorithm. Multiple SIDs
3.1.1. Prefix-SID Algorithm MAY be allocated to the same prefix so long as the tuple <prefix,
topology, algorithm> is unique.
The IGP protocol extensions for Segment Routing define the Prefix-SID Multiple instances and topologies are defined in IS-IS and OSPF in:
advertisement which includes a set of flags and the algorithm field. [RFC5120], [RFC8202], [RFC6549] and [RFC4915].
The algorithm field has the purpose of associating a given Prefix-SID
to a routing algorithm.
In the context of an instance and a topology, multiple Prefix-SID's 3.1.1. Prefix-SID Algorithm
MAY be allocated to the same IGP Prefix as long as the algorithm
value is different in each one.
Multiple instances and topologies are defined in IS-IS and OSPF in: Segment Routing supports the use of multiple routing algorithms i.e,
[RFC5120], [RFC6822], [RFC6549] and [RFC4915]. different constraint based shortest path calculations can be
supported. An algorithm identifier is included as part of a Prefix-
SID advertisement.
Initially, two "algorithms" have been defined: This document defines two algorithms:
o "Shortest Path": this algorithm is the default behavior. The o "Shortest Path": this algorithm is the default behavior. The
packet is forwarded along the well known ECMP-aware SPF algorithm packet is forwarded along the well known ECMP-aware SPF algorithm
however it is explicitly allowed for a midpoint to implement employed by the IGPs. However it is explicitly allowed for a
another forwarding based on local policy. The "Shortest Path" midpoint to implement another forwarding based on local policy.
algorithm is in fact the default and current behavior of most of The "Shortest Path" algorithm is in fact the default and current
the networks where local policies may override the SPF decision. behavior of most of the networks where local policies may override
the SPF decision.
o "Strict Shortest Path": This algorithm mandates that the packet is o "Strict Shortest Path": This algorithm mandates that the packet is
forwarded according to ECMP-aware SPF algorithm and instruct any forwarded according to ECMP-aware SPF algorithm and instructs any
router in the path to ignore any possible local policy overriding router in the path to ignore any possible local policy overriding
SPF decision. The SID advertised with "Strict Shortest Path" the SPF decision. The SID advertised with "Strict Shortest Path"
algorithm ensures that the path the packet is going to take is the algorithm ensures that the path the packet is going to take is the
expected, and not altered, SPF path. expected, and not altered, SPF path. Note that Fast Reroute (FRR)
[RFC5714] mechanisms are still compliant with the Strict Shortest
Path. In other words, a packet received with a Strict-SPF SID may
be rerouted through a FRR mechanism.
An IGP-Prefix Segment identifies the path, to the related prefix, An IGP-Prefix Segment identifies the path, to the related prefix,
computed as per the algorithm field. computed as per the associated algorithm. A packet injected anywhere
within the SR domain with an active Prefix-SID is expected to be
forwarded along a path computed using the specified algorithm.
Clearly, if not all SR capable nodes in an SR Domain support a given
algorithm it is not possible to guarantee that the packet will follow
a path consistent with the associated algorithm.
A packet injected anywhere within the SR/IGP domain with an active A router MUST drop any SR traffic associated with an SR algorithm, if
Prefix-SID will be forwarded along path computed by the algorithm the nexthop router has not advertised support for the SR algorithm.
expressed in the algorithm field.
A router MUST drop any SR traffic associated with the SR algorithm to The ingress node of an SR domain SHOULD validate that the path to a
the adjacent router, if the adjacent router has not advertised prefix, advertised with a given algorithm, includes nodes all
support for such SR algorithm. supporting the advertised algorithm. If this constraint cannot be
met the packet SHOULD be dropped by the ingress node. Note that in
the special case of "Shortest Path", all nodes (SR Capable or not)
are assumed to support this algorithm.
The ingress node of an SR domain validates that the path to a prefix, 3.1.2. SR-MPLS
advertised with a given algorithm, includes nodes all supporting the
advertised algorithm. As a consequence, if a node on the path does
not support algorithm X, the IGP-Prefix segment will be interrupted
and will drop packet on that node. It's the responsibility of the
ingress node using a segment to check that all downstream nodes
support the algorithm of the segment.
It has to be noted that Fast Reroute (FRR) mechanisms are still When SR is used over the MPLS dataplane SIDs are an MPLS label or an
compliant with the Strict-SPF. In other words, a packet received index into an MPLS label space (either SRGB or SRLB). An SRGB/SRLB
with a Strict-SPF SID may be rerouted through a FRR mechanism. is advertised as an ordered set of ranges which has the following
properties:
Details of the two defined algorithms are defined in o Each range specifies a starting label and the number of labels in
[I-D.ietf-isis-segment-routing-extensions], that range
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
3.1.2. MPLS Dataplane o The set of ranges advertised by a given node MUST be disjoint
When the SID is an index, the mapping of the index to a label is
computed using the following algorithm:
When SR is used over the MPLS dataplane: r = # of advertised ranges
L(Ri) is the starting label of Range #i
N(Ri) is the number of labels in Range #i
X is the 0 based index
o the IGP signaling extension for IGP-Prefix segment includes the i = 1
P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag while ((i <= r) && (X >= N(Ri)) {
([I-D.ietf-ospf-segment-routing-extensions]). A Node N X = X - N(Ri)
advertising a Prefix-SID SID-R for its attached prefix R unsets i = i + 1
the P-Flag (or NP-Flag) in order to instruct its connected }
neighbors to perform the NEXT operation while processing SID-R. if (i <= r)
This behavior is equivalent to Penultimate Hop Popping in MPLS. LABEL = L(Ri) + X
When the flag is unset, the neighbors of N MUST perform the NEXT else
operation while processing SID-R. When the flag is set, the no valid label exists for this index
neighbors of N MUST perform the CONTINUE operation while
processing SID-R.
o A Prefix-SID is allocated in the form of an index in the SRGB (or Where possible, it is recommended that a consistent SRGB be
as a local MPLS label) according to a process similar to IP configured on all nodes in an SR Domain. This simplifies
address allocation. Typically, the Prefix-SID is allocated by troubleshooting as the same label will be associated with the same
policy by the operator (or NMS) and the SID very rarely changes. prefix on all nodes. In addition, it simplifies support for anycast
as detailed in Section 3.3.
o While SR allows to attach a local segment to an IGP prefix, we The following behaviors are associated with SR operating over the
specifically assume that when the terms "IGP-Prefix Segment" and MPLS dataplane:
o the IGP signaling extension for IGP-Prefix segment includes a flag
to indicate whether directly connected neighbors of the node on
which the prefix is attached should perform the NEXT operation or
the CONTINUE operation when processing the SID. This behavior is
equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop
Popping (CONTINUE) in MPLS.
o A Prefix-SID is allocated in the form of an MPLS label (or an
index in the SRGB) according to a process similar to IP address
allocation. Typically, the Prefix-SID is allocated by policy by
the operator (or NMS) and the SID very rarely changes.
o While SR allows to attach a local segment to an IGP prefix, it is
specifically assumed that when the terms "IGP-Prefix Segment" and
"Prefix-SID" are used, the segment is global (the SID is allocated "Prefix-SID" are used, the segment is global (the SID is allocated
from the SRGB or as an index). This is consistent with all the from the SRGB or as an index into the advertised SRGB). This is
described use-cases that require global segments attached to IGP consistent with all the described use-cases that require global
prefixes. segments attached to IGP prefixes.
o The allocation process MUST NOT allocate the same Prefix-SID to o The allocation process MUST NOT allocate the same Prefix-SID to
different IP prefixes. different IP prefixes.
o If a node learns a Prefix-SID having a value that falls outside o If a node learns a Prefix-SID having a value that falls outside
the locally configured SRGB range, then the node MUST NOT use the the locally configured SRGB range, then the node MUST NOT use the
Prefix-SID and SHOULD issue an error log warning for Prefix-SID and SHOULD issue an error log reporting a
misconfiguration. misconfiguration.
o If a node N advertises Prefix-SID SID-R for a prefix R that is o If a node N advertises Prefix-SID SID-R for a prefix R that is
attached to N, N MUST either clear the P-Flag in the advertisement attached to N, if N specifies CONTINUE as the operation to be
of SID-R, or else maintain the following FIB entry: performed by directly connected neighbors, N MUST maintain the
following FIB entry:
Incoming Active Segment: SID-R Incoming Active Segment: SID-R
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: NULL Egress interface: NULL
o A remote node M MUST maintain the following FIB entry for any o A remote node M MUST maintain the following FIB entry for any
learned Prefix-SID SID-R attached to IP prefix R: learned Prefix-SID SID-R attached to IP prefix R:
Incoming Active Segment: SID-R Incoming Active Segment: SID-R
Ingress Operation: Ingress Operation:
If the next-hop of R is the originator of R If the next-hop of R is the originator of R
and instructed to remove the active segment: NEXT and instructed to remove the active segment: NEXT
Else: CONTINUE Else: CONTINUE
Egress interface: the interface towards the next-hop along the Egress interface: the interface towards the next-hop along the
path computed using the algorithm advertised with path computed using the algorithm advertised with
the SID toward prefix R. the SID toward prefix R.
3.1.3. IPv6 Dataplane 3.1.3. SRv6
When SR is used over the IPv6 dataplane: When SR is used over the IPv6 dataplane:
o The Prefix-SID is the prefix itself. No additional identifier is o A Prefix-SID is an IPv6 address..
needed for Segment Routing over IPv6.
o Any address belonging to any of the node's prefixes can be used as
Prefix-SIDs.
o An operator may want to explicitly indicate which of the node's
prefixes can be used as Prefix-SIDs through the setting of a flag
(e.g.: using the IGP prefix attribute defined in [RFC7794]) in the
routing protocol used for advertising the prefix.
o A global SID is instantiated through any globally advertised IPv6
address.
o A local SID is instantiated through a local IPv6 prefix not being o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node
advertised and therefore known only by the local node. addresses are not SRv6 SIDs by default.
A node N advertising an IPv6 address R usable as a segment identifier A node N advertising an IPv6 address R usable as a segment identifier
MUST maintain the following FIB entry: MUST maintain the following FIB entry:
Incoming Active Segment: R Incoming Active Segment: R
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: NULL Egress interface: NULL
Regardless Segment Routing, any remote IPv6 node will maintain a Independent of Segment Routing support, any remote IPv6 node will
plain IPv6 FIB entry for any prefix, no matter if they represent a maintain a plain IPv6 FIB entry for any prefix, no matter if the
segment or not. represent a segment or not. This allows forwarding of packets to the
node which owns the SID even by nodes which do not support Segment
Routing.
3.2. IGP-Node Segment, Node-SID 3.2. IGP-Node Segment, Node-SID
An IGP Node-SID MUST NOT be associated with a prefix that is owned by An IGP Node-SID MUST NOT be associated with a prefix that is owned by
more than one router within the same routing domain. more than one router within the same routing domain.
3.3. IGP-Anycast Segment, Anycast SID 3.3. IGP-Anycast Segment, Anycast SID
An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware
shortest-path forwarding towards the closest node of the anycast set. shortest-path forwarding towards the closest node of the anycast set.
This is useful to express macro-engineering policies or protection This is useful to express macro-engineering policies or protection
mechanisms. mechanisms.
An IGP-Anycast segment MUST NOT reference a particular node. An IGP-Anycast segment MUST NOT reference a particular node.
Within an anycast group, all routers MUST advertise the same prefix Within an anycast group, all routers in an SR domain MUST advertise
with the same SID value. the same prefix with the same SID value.
3.3.1. Anycast SID in SR-MPLS
+--------------+ +--------------+
| Group A | | Group A |
|192.0.2.10/32 | |192.0.2.10/32 |
| SID:100 | | SID:100 |
| | | |
+-----------A1---A3----------+ +-----------A1---A3----------+
| | | \ / | | | | | | \ / | | |
SID:10 | | | / | | | SID:30 SID:10 | | | / | | | SID:30
203.0.113.1/32 | | | / \ | | | 203.0.113.3/32 203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
skipping to change at page 11, line 42 skipping to change at page 13, line 12
Figure 1: Transit device groups Figure 1: Transit device groups
The figure above describes a network example with two groups of The figure above describes a network example with two groups of
transit devices. Group A consists of devices {A1, A2, A3 and A4}. transit devices. Group A consists of devices {A1, A2, A3 and A4}.
They are all provisioned with the anycast address 192.0.2.10/32 and They are all provisioned with the anycast address 192.0.2.10/32 and
the anycast SID 100. the anycast SID 100.
Similarly, group B consists of devices {B1, B2, B3 and B4} and are Similarly, group B consists of devices {B1, B2, B3 and B4} and are
all provisioned with the anycast address 192.0.2.1/32, anycast SID all provisioned with the anycast address 192.0.2.1/32, anycast SID
200. In the above network topology, each PE device is connected to 200. In the above network topology, each PE device has a path to
two routers in each of the groups A and B. each of the groups A and B.
PE1 can choose a particular transit device group when sending traffic PE1 can choose a particular transit device group when sending traffic
to PE3 or PE4. This will be done by pushing the anycast SID of the to PE3 or PE4. This will be done by pushing the anycast SID of the
group in the stack. group in the stack.
Processing the anycast, and subsequent segments, requires special Processing the anycast, and subsequent segments, requires special
care. care.
Obviously, the value of the SID following the anycast SID MUST be
understood by all nodes advertising the same anycast segment.
+-------------------------+ +-------------------------+
| Group A | | Group A |
| 192.0.2.10/32 | | 192.0.2.10/32 |
| SID:100 | | SID:100 |
|-------------------------| |-------------------------|
| | | |
| SRGB: SRGB: | | SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30 SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3 PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ / \ / | | \ / | | \ /
skipping to change at page 13, line 19 skipping to change at page 14, line 33
Using anycast segment without configuring the same SRGB on nodes Using anycast segment without configuring the same SRGB on nodes
belonging to the same device group may lead to misrouting (in an MPLS belonging to the same device group may lead to misrouting (in an MPLS
VPN deployment, some traffic may leak between VPNs). VPN deployment, some traffic may leak between VPNs).
3.4. IGP-Adjacency Segment, Adj-SID 3.4. IGP-Adjacency Segment, Adj-SID
The adjacency is formed by the local node (i.e., the node advertising The adjacency is formed by the local node (i.e., the node advertising
the adjacency in the IGP) and the remote node (i.e., the other end of the adjacency in the IGP) and the remote node (i.e., the other end of
the adjacency). The local node MUST be an IGP node. The remote node the adjacency). The local node MUST be an IGP node. The remote node
MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a
Forwarding Adjacency, [RFC4206]). Forwarding Adjacency, [RFC4206]).
A packet injected anywhere within the SR domain with a segment list A packet injected anywhere within the SR domain with a segment list
{SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID
attached by node N to its adjacency over link L, will be forwarded attached by node N to its adjacency over link L, will be forwarded
along the shortest-path to N and then be switched by N, without any along the shortest-path to N and then be switched by N, without any
IP shortest-path consideration, towards link L. If the Adj-SID IP shortest-path consideration, towards link L. If the Adj-SID
identifies a set of adjacencies, then the node N load-balances the identifies a set of adjacencies, then the node N load-balances the
traffic among the various members of the set. traffic among the various members of the set.
skipping to change at page 13, line 47 skipping to change at page 15, line 12
global Adj-SID allows to reduce the size of the segment list when global Adj-SID allows to reduce the size of the segment list when
expressing a path at the cost of additional state (i.e.: the global expressing a path at the cost of additional state (i.e.: the global
Adj-SID will be inserted by all routers within the area in their Adj-SID will be inserted by all routers within the area in their
forwarding table). forwarding table).
An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the
packet from a node towards a defined interface or set of interfaces. packet from a node towards a defined interface or set of interfaces.
This is key to theoretically prove that any path can be expressed as This is key to theoretically prove that any path can be expressed as
a list of segments. a list of segments.
The encodings of the Adj-SID include the a set of flags among which The encodings of the Adj-SID include a set of flags supporting the
there is the B-flag. When set, the Adj-SID refers to an adjacency following functionalities:
that is eligible for protection (e.g.: using IPFRR or MPLS-FRR).
The encodings of the Adj-SID also include the L-flag. When set, the o Eligible for Protection (e.g.: using IPFRR or MPLS-FRR)
Adj-SID has local significance. By default, the L-flag is set.
A node SHOULD allocate one Adj-SIDs for each of its adjacencies. o Indication whether the Adj-SID has local or global scope. Default
scope SHOULD be Local.
A node MAY allocate multiple Adj-SIDs to the same adjacency. An A weight (as described below) is also associated with the Adj-SID
example is where the adjacency is established over a bundle advertisement.
interface. Each bundle member MAY have its own Adj-SID.
A node MAY allocate the same Adj-SID to multiple adjacencies. A node SHOULD allocate one Adj-SID for each of its adjacencies.
Obviously, in order to be able to advertise in the IGP all the Adj- A node MAY allocate multiple Adj-SIDs for the same adjacency. An
SIDs representing the IGP adjacencies between two nodes, parallel example is to support an Adj-SID which is eligible for protection and
an Adj-SID which is NOT eligible for protection.
A node MAY associate the same Adj-SID to multiple adjacencies.
In order to be able to advertise in the IGP all the Adj-SIDs
representing the IGP adjacencies between two nodes, parallel
adjacency suppression MUST NOT be performed by the IGP. adjacency suppression MUST NOT be performed by the IGP.
A node MUST install a FIB entry for any Adj-SID of value V attached When a node binds an Adj-SID to a local data-link L, the node MUST
to data-link L: install the following FIB entry:
Incoming Active Segment: V Incoming Active Segment: V
Ingress Operation: NEXT Ingress Operation: NEXT
Egress Interface: L Egress Interface: L
The Adj-SID implies, from the router advertising it, the forwarding The Adj-SID implies, from the router advertising it, the forwarding
of the packet through the adjacency identified by the Adj-SID, of the packet through the adjacency(ies) identified by the Adj-SID,
regardless its IGP/SPF cost. In other words, the use of adjacency regardless of its IGP/SPF cost. In other words, the use of adjacency
segments overrides the routing decision made by the SPF algorithm. segments overrides the routing decision made by the SPF algorithm.
3.4.1. Parallel Adjacencies 3.4.1. Parallel Adjacencies
Adj-SIDs can be used in order to represent a set of parallel Adj-SIDs can be used in order to represent a set of parallel
interfaces between two adjacent routers. interfaces between two adjacent routers.
A node MUST install a FIB entry for any locally originated adjacency A node MUST install a FIB entry for any locally originated adjacency
segment (Adj-SID) of value W attached to a set of link B with: segment (Adj-SID) of value W attached to a set of links B with:
Incoming Active Segment: W Incoming Active Segment: W
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: load-balance between any data-link within set B Egress interface: load-balance between any data-link within set B
When parallel adjacencies are used and associated to the same Adj- When parallel adjacencies are used and associated to the same Adj-
SID, and in order to optimize the load balancing function, a "weight" SID, and in order to optimize the load balancing function, a "weight"
factor can be associated to the Adj-SID advertised with each factor can be associated to the Adj-SID advertised with each
adjacency. The weight tells the ingress (or a SDN/orchestration adjacency. The weight tells the ingress (or an SDN/orchestration
system) about the load-balancing factor over the parallel system) about the load-balancing factor over the parallel
adjacencies. As shown in Figure 3, A and B are connected through two adjacencies. As shown in Figure 3, A and B are connected through two
parallel adjacencies parallel adjacencies
link-1 link-1
+--------+ +--------+
| | | |
S---A B---C S---A B---C
| | | |
+--------+ +--------+
link-2 link-2
Figure 3: Parallel Links and Adj-SIDs Figure 3: Parallel Links and Adj-SIDs
Node A advertises following Adj-SIDs and weights: Node A advertises following Adj-SIDs and weights:
o Link-1: Adj-SID 1000, weight: 1 o Link-1: Adj-SID 1000, weight: 1
o Link-2: Adj-SID 1000, weight: 2 o Link-2: Adj-SID 1000, weight: 2
Node S receives the advertisements of the parallel adjacencies and Node S receives the advertisements of the parallel adjacencies and
understands that by using Adj-SID 1000 node A will load-balance the understands that by using Adj-SID 1000 node A will load-balance the
traffic across the parallel links (link-1 and link-2) according to a traffic across the parallel links (link-1 and link-2) according to a
1:2 ratio. 1:2 ratio i.e., twice as many packets will flow over Link-2 as
compared to Link-1.
The weight value is advertised with the Adj-SID as defined in IGP SR
extensions documents.
3.4.2. LAN Adjacency Segments 3.4.2. LAN Adjacency Segments
In LAN subnetworks, link-state protocols define the concept of In LAN subnetworks, link-state protocols define the concept of
Designated Router (DR, in OSPF) or Designated Intermediate System Designated Router (DR, in OSPF) or Designated Intermediate System
(DIS, in IS-IS) that conduct flooding in broadcast subnetworks and (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and
that describe the LAN topology in a special routing update (OSPF that describe the LAN topology in a special routing update (OSPF
Type2 LSA or IS-IS Pseudonode LSP). Type2 LSA or IS-IS Pseudonode LSP).
The difficulty with LANs is that each router only advertises its The difficulty with LANs is that each router only advertises its
connectivity to the DR/DIS and not to each other individual nodes in connectivity to the DR/DIS and not to each of the individual nodes in
the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF)
are necessary in order for each router in the LAN to advertise an are necessary in order for each router in the LAN to advertise an
Adj-SID associated to each neighbor in the LAN. These extensions are Adj-SID associated to each neighbor in the LAN. These extensions are
defined in IGP SR extensions documents. defined in IGP SR extensions documents.
3.5. Binding Segment 3.5. Inter-Area Considerations
3.5.1. Mapping Server
A Remote-Binding SID S advertised by the mapping server M for remote
prefix R attached to non-SR-capable node N signals the same
information as if N had advertised S as a Prefix-SID. Further
details are described in the SR/LDP interworking procedures
([I-D.ietf-spring-segment-routing-ldp-interop].
The segment allocation and SRGB Maintenance rules are the same as
those defined for Prefix-SID.
3.5.2. Tunnel Head-end
The segment allocation and SRGB Maintenance rules are the same as
those defined for Adj-SID. A tunnel attached to a head-end H acts as
an adjacency attached to H.
Note: an alternative consists of representing tunnels as forwarding-
adjacencies ([RFC4206]). In such case, the tunnel is presented to
the routing area as a routing adjacency and is considered as such by
all area routers. The Remote-Binding SID is preferred as it allows
to advertise the presence of a tunnel without influencing the LSDB
and the SPF computation.
3.6. Inter-Area Considerations
In the following example diagram we assume an IGP deployed using In the following example diagram it is assumed that the all areas are
areas and where SR has been deployed. part of a single SR Domain.
The example here below assumes the IPv6 control plane with the MPLS The example here below assumes the IPv6 control plane with the MPLS
dataplane. dataplane.
! ! ! !
! ! ! !
B------C-----F----G-----K B------C-----F----G-----K
/ | | | / | | |
S---A/ | | | S---A/ | | |
\ | | | \ | | |
skipping to change at page 17, line 16 skipping to change at page 18, line 5
related IGP Prefix through the inter-area process. related IGP Prefix through the inter-area process.
When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- When node S sends traffic to 2001:DB8::2:1/128, it pushes Node-
SID(150) as active segment and forward it to A. SID(150) as active segment and forward it to A.
When packet arrives at ABR I (or C), the ABR forwards the packet When packet arrives at ABR I (or C), the ABR forwards the packet
according to the active segment (Node-SID(150)). Forwarding according to the active segment (Node-SID(150)). Forwarding
continues across area borders, using the same Node-SID(150), until continues across area borders, using the same Node-SID(150), until
the packet reaches its destination. the packet reaches its destination.
When an ABR propagates a prefix from one area to another it MUST set
the R-Flag.
4. BGP Peering Segments 4. BGP Peering Segments
BGP segments may be allocated and distributed by BGP.
4.1. BGP Prefix Segment
A BGP-Prefix segment is a BGP segment attached to a BGP prefix.
A BGP-Prefix segment is global (unless explicitly advertised
otherwise) within the SR domain.
The BGP Prefix SID is the BGP equivalent to the IGP Prefix Segment.
A likely use-case for the BGP Prefix Segment is an IGP-free hyper-
scale spine-leaf topology where connectivity is learned solely via
BGP [RFC7938]
4.2. BGP Peering Segments
In the context of BGP Egress Peer Engineering (EPE), as described in In the context of BGP Egress Peer Engineering (EPE), as described in
[I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress
PE node MAY advertise segments corresponding to its attached peers. PE node MAY advertise segments corresponding to its attached peers.
These segments are called BGP peering segments or BGP peering SIDs. These segments are called BGP peering segments or BGP peering SIDs.
They enable the expression of source-routed inter-domain paths. They enable the expression of source-routed inter-domain paths.
An ingress border router of an AS may compose a list of segments to An ingress border router of an AS may compose a list of segments to
steer a flow along a selected path within the AS, towards a selected steer a flow along a selected path within the AS, towards a selected
egress border router C of the AS and through a specific peer. At egress border router C of the AS and through a specific peer. At
minimum, a BGP peering Engineering policy applied at an ingress PE minimum, a BGP peering Engineering policy applied at an ingress PE
involves two segments: the Node SID of the chosen egress PE and then involves two segments: the Node SID of the chosen egress PE and then
the BGP peering segment for the chosen egress PE peer or peering the BGP peering segment for the chosen egress PE peer or peering
interface. interface.
Hereafter, we will define three types of BGP peering segments/SIDs: Three types of BGP peering segments/SIDs are defined: PeerNode SID,
PeerNode SID, PeerAdj SID and PeerSet SID. PeerAdj SID and PeerSet SID.
o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At
the BGP node advertising it, its semantics is: the BGP node advertising it, its semantics is:
* SR header operation: NEXT. * SR header operation: NEXT.
* Next-Hop: the connected peering node to which the segment is * Next-Hop: the connected peering node to which the segment is
related. related.
o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the
skipping to change at page 18, line 18 skipping to change at page 19, line 21
* SR header operation: NEXT. * SR header operation: NEXT.
* Next-Hop: load-balance across any connected interface to any * Next-Hop: load-balance across any connected interface to any
peer in the related group. peer in the related group.
A peer set could be all the connected peers from the same AS or a A peer set could be all the connected peers from the same AS or a
subset of these. A group could also span across AS. The group subset of these. A group could also span across AS. The group
definition is a policy set by the operator. definition is a policy set by the operator.
The BGP extensions necessary in order to signal these BGP peering The BGP extensions necessary in order to signal these BGP peering
segments will be defined in a separate document. segments are defined in [I-D.ietf-idr-bgpls-segment-routing-epe]
5. IGP Mirroring Context Segment 5. Binding Segment
It is beneficial for an IGP node to be able to advertise its ability An SR Policy is bound to a so-called Binding SID (BSID). Any packets
to process traffic originally destined to another IGP node, called received with active segment = BSID are steered onto the bound SR
the Mirrored node and identified by an IP address or a Node-SID, Policy.
provided that a "Mirroring Context" segment be inserted in the
segment list prior to any service segment local to the mirrored node. A BSID may either be a local or a global SID. If local, a BSID
SHOULD be allocated from the SRLB. If global, a BSID MUST be
allocated from the SRGB.
One of the possible use cases for a BSID is to overcome a Segment
List Depth limitation on a given node by requiring that node only to
impose a BSID which could be SWAPPED on downstream nodes with a set
of SIDs associated with an SR policy.
5.1. IGP Mirroring Context Segment
Another use case for a Binding Segment is to provide support for an
IGP node to advertise its ability to process traffic originally
destined to another IGP node, called the Mirrored node and identified
by an IP address or a Node-SID, provided that a "Mirroring Context"
segment be inserted in the segment list prior to any service segment
local to the mirrored node.
When a given node B wants to provide egress node A protection, it When a given node B wants to provide egress node A protection, it
advertises a segment identifying node's A context. Such segment is advertises a segment identifying node's A context. Such segment is
called "Mirror Context Segment" and identified by the Mirror SID. called "Mirror Context Segment" and identified by the Mirror SID.
The Mirror SID is advertised using the binding segment defined in SR The Mirror SID is advertised using the binding segment defined in SR
IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], IGP protocol extensions [I-D.ietf-isis-segment-routing-extensions] .
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
In the event of a failure, a point of local repair (PLR) diverting In the event of a failure, a point of local repair (PLR) diverting
traffic from A to B does a PUSH of the Mirror SID on the protected traffic from A to B does a PUSH of the Mirror SID on the protected
traffic. B, when receiving the traffic with the Mirror SID as the traffic. B, when receiving the traffic with the Mirror SID as the
active segment, uses that segment and processes underlying segments active segment, uses that segment and processes underlying segments
in the context of A. in the context of A.
6. Multicast 6. Multicast
Segment Routing is defined for unicast. The application of the Segment Routing is defined for unicast. The application of the
skipping to change at page 19, line 19 skipping to change at page 20, line 31
8. Security Considerations 8. Security Considerations
Segment Routing is applicable to both MPLS and IPv6 data planes. Segment Routing is applicable to both MPLS and IPv6 data planes.
Segment Routing adds some meta-data (instructions) on the packet, Segment Routing adds some meta-data (instructions) on the packet,
with the list of forwarding path elements (e.g.: nodes, links, with the list of forwarding path elements (e.g.: nodes, links,
services, etc.) that the packet must traverse. It has to be noted services, etc.) that the packet must traverse. It has to be noted
that the complete source routed path may be represented by a single that the complete source routed path may be represented by a single
segment. This is the case of the Binding SID. segment. This is the case of the Binding SID.
8.1. MPLS Data Plane 8.1. SR-MPLS
When applied to the MPLS data plane, Segment Routing does not When applied to the MPLS data plane, Segment Routing does not
introduce any new behavior or any change in the way MPLS data plane introduce any new behavior or any change in the way MPLS data plane
works. Therefore, from a security standpoint, this document does not works. Therefore, from a security standpoint, this document does not
define any additional mechanism in the MPLS data plane. define any additional mechanism in the MPLS data plane.
SR allows the expression of a source routed path using a single SR allows the expression of a source routed path using a single
segment (the Binding SID). Compared to RSVP-TE which also provides segment (the Binding SID). Compared to RSVP-TE which also provides
explicit routing capability, there are no fundamental differences in explicit routing capability, there are no fundamental differences in
term of information provided. Both RSVP-TE and Segment Routing may term of information provided. Both RSVP-TE and Segment Routing may
express a source routed path using a single segment. express a source routed path using a single segment.
When a path is expressed using a single label, the syntax of the When a path is expressed using a single label, the syntax of the
meta-data is equivalent between RSVP-TE and SR. meta-data is equivalent between RSVP-TE [RFC3209] and SR.
When a source routed path is expressed with a list of segments When a source routed path is expressed with a list of segments
additional meta-data is added to the packet consisting of the source additional meta-data is added to the packet consisting of the source
routed path the packet must follow expressed as a segment list. routed path the packet must follow expressed as a segment list.
When a path is expressed using a label stack, if one has access to When a path is expressed using a label stack, if one has access to
the meaning (i.e.: the Forwarding Equivalence Class) of the labels, the meaning (i.e.: the Forwarding Equivalence Class) of the labels,
one has the knowledge of the explicit path. For the MPLS data plane, one has the knowledge of the explicit path. For the MPLS data plane,
as no data plane modification is required, there is no fundamental as no data plane modification is required, there is no fundamental
change of capability. Yet, the occurrence of label stacking will change of capability. Yet, the occurrence of label stacking will
skipping to change at page 20, line 27 skipping to change at page 21, line 38
the mid points of a source routed path. With SR, the source routed the mid points of a source routed path. With SR, the source routed
path is computed using SIDs previously advertised in the IP control path is computed using SIDs previously advertised in the IP control
plane. Therefore, in addition to filtering and controlled plane. Therefore, in addition to filtering and controlled
advertisement of SIDs at the boundaries of the SR domain, filtering advertisement of SIDs at the boundaries of the SR domain, filtering
in the data plane is also required. Filtering MUST be performed on in the data plane is also required. Filtering MUST be performed on
the forwarding plane at the boundaries of the SR domain and may the forwarding plane at the boundaries of the SR domain and may
require looking at multiple labels/instruction. require looking at multiple labels/instruction.
For the MPLS data plane, there are no new requirement as the existing For the MPLS data plane, there are no new requirement as the existing
MPLS architecture already allows such source routing by stacking MPLS architecture already allows such source routing by stacking
multiple labels. And for security protection, [RFC4381] section 2.4 multiple labels. And for security protection, [RFC4381] and
and [RFC5920] section 8.2 already calls for the filtering of MPLS [RFC5920] already call for the filtering of MPLS packets on trust
packets on trust boundaries. boundaries.
8.2. IPv6 Data Plane 8.2. SRv6
When applied to the IPv6 data plane, Segment Routing does introduce When applied to the IPv6 data plane, Segment Routing does introduce
the Segment Routing Header (SRH, the Segment Routing Header (SRH,
[I-D.ietf-6man-segment-routing-header]) which is a type of Routing [I-D.ietf-6man-segment-routing-header]) which is a type of Routing
Extension header as defined in [RFC2460]. Extension header as defined in [RFC8200].
The SRH adds some meta-data on the IPv6 packet, with the list of The SRH adds some meta-data on the IPv6 packet, with the list of
forwarding path elements (e.g.: nodes, links, services, etc.) that forwarding path elements (e.g.: nodes, links, services, etc.) that
the packet must traverse and that are represented by IPv6 addresses. the packet must traverse and that are represented by IPv6 addresses.
A complete source routed path may be encoded in the packet using a A complete source routed path may be encoded in the packet using a
single segment (single IPv6 address). single segment (single IPv6 address).
From a network protection standpoint, there is an assumed trust model From a network protection standpoint, there is an assumed trust model
such that any node adding an SRH to the packet is assumed to be such that any node adding an SRH to the packet is assumed to be
allowed to do so. Therefore, by default, the explicit routing allowed to do so. Therefore, by default, the explicit routing
information MUST NOT be leaked through the boundaries of the information MUST NOT be leaked through the boundaries of the
administered domain. Segment Routing extensions that have been administered domain. Segment Routing extensions that have been
defined in various protocols, leverage the security mechanisms of defined in various protocols, leverage the security mechanisms of
these protocols such as encryption, authentication, filtering, etc. these protocols such as encryption, authentication, filtering, etc.
skipping to change at page 21, line 46 skipping to change at page 23, line 8
data plane are defined in [I-D.ietf-mpls-spring-lsp-ping]. data plane are defined in [I-D.ietf-mpls-spring-lsp-ping].
SR routers receive advertisements of SIDs (index, label or IPv6 SR routers receive advertisements of SIDs (index, label or IPv6
address) from the different routing protocols being extended for SR. address) from the different routing protocols being extended for SR.
Each of these protocols have monitoring and troubleshooting Each of these protocols have monitoring and troubleshooting
mechanisms to provide operation and management functions for IP mechanisms to provide operation and management functions for IP
addresses that MUST be extended in order to include troubleshooting addresses that MUST be extended in order to include troubleshooting
and monitoring functions of the SID. and monitoring functions of the SID.
SR architecture introduces the usage of global segments. Each global SR architecture introduces the usage of global segments. Each global
segment must be bound to a globally-unique index or address. The segment must be bound to a unique index or address within an SR
management of the allocation of such index or address by the operator domain. The management of the allocation of such index or address by
is critical for the network behavior to avoid situations like mis- the operator is critical for the network behavior to avoid situations
routing. In addition to the allocation policy/tooling that the like mis-routing. In addition to the allocation policy/tooling that
operator will have in place, an implementation SHOULD protect the the operator will have in place, an implementation SHOULD protect the
network in case of conflict detection by providing a deterministic network in case of conflict detection by providing a deterministic
resolution approach. resolution approach.
An operator may implement tools in order to audit the network and
ensure the good allocation of indexes, SIDs or IP addresses.
Conflict detection between SIDs, including Mapping Server binding
SIDs, and their resolution are addressed in
[I-D.ietf-spring-conflict-resolution].
SR with the MPLS data plane, can be gracefully introduced in an
existing LDP [RFC5036] network. This is described in
[I-D.ietf-spring-segment-routing-ldp-interop]. SR and LDP may also
inter-work. In this case, the introduction of mapping-server may
introduce some additional manageability considerations that are
discussed in [I-D.ietf-spring-segment-routing-ldp-interop].
When a path is expressed using a label stack, the occurrence of label When a path is expressed using a label stack, the occurrence of label
stacking will increase. A node may want to signal in the control stacking will increase. A node may want to signal in the control
plane its ability in terms of size of the label stack it can support. plane its ability in terms of size of the label stack it can support.
A YANG data model [RFC6020] for segment routing configuration and A YANG data model [RFC6020] for segment routing configuration and
operations has been defined in [I-D.ietf-spring-sr-yang]. operations has been defined in [I-D.ietf-spring-sr-yang].
When Segment Routing is applied to the IPv6 data plane, segments are When Segment Routing is applied to the IPv6 data plane, segments are
identified through IPv6 addresses. The allocation, management and identified through IPv6 addresses. The allocation, management and
troubleshooting of segment identifiers is no different than the troubleshooting of segment identifiers is no different than the
skipping to change at page 23, line 39 skipping to change at page 24, line 39
Igor Milojevic Igor Milojevic
Email: milojevicigor@gmail.com Email: milojevicigor@gmail.com
Saku Ytti Saku Ytti
TDC TDC
Email: saku@ytti.fi Email: saku@ytti.fi
11. Acknowledgements 11. Acknowledgements
We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart
Bryant, Pierre Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes
Hannes Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers and Alvaro Retana
their comments and review of this document. for their comments and review of this document.
12. References 12. References
12.1. Normative References 12.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,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<http://www.rfc-editor.org/info/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
Hierarchy with Generalized Multi-Protocol Label Switching (IPv6) Specification", STD 86, RFC 8200,
(GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC8200, July 2017,
DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc8200>.
<http://www.rfc-editor.org/info/rfc4206>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B., Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-06 (work in progress), March 2017. segment-routing-header-07 (work in progress), July 2017.
[I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-13 (work in progress), June 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com, Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
"IS-IS Extensions for Segment Routing", draft-ietf-isis- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-13 (work in progress), June segment-routing-extensions-13 (work in progress), June
2017. 2017.
[I-D.ietf-mpls-spring-lsp-ping] [I-D.ietf-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) S., and M. Chen, "Label Switched Path (LSP) Ping/
Ping/Traceroute for Segment Routing Networks with MPLS Traceroute for Segment Routing IGP Prefix and Adjacency
Dataplane", draft-ietf-mpls-spring-lsp-ping-03 (work in SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp-
progress), June 2017. ping-13 (work in progress), October 2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-09 (work in progress), March segment-routing-extensions-10 (work in progress),
2017. September 2017.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-16 (work in progress), May 2017. routing-extensions-21 (work in progress), October 2017.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-09 (work in progress), draft-ietf-pce-segment-routing-10 (work in progress),
April 2017. October 2017.
[I-D.ietf-spring-conflict-resolution]
Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
"Segment Routing MPLS Conflict Resolution", draft-ietf-
spring-conflict-resolution-04 (work in progress), May
2017.
[I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and
M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-11 (work in progress), June 2017.
[I-D.ietf-spring-oam-usecase] [I-D.ietf-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A
Scalable and Topology-Aware MPLS Dataplane Monitoring Scalable and Topology-Aware MPLS Dataplane Monitoring
System", draft-ietf-spring-oam-usecase-06 (work in System", draft-ietf-spring-oam-usecase-09 (work in
progress), February 2017. progress), July 2017.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
"Resiliency use cases in SPRING networks", draft-ietf- "Resiliency use cases in SPRING networks", draft-ietf-
spring-resiliency-use-cases-11 (work in progress), May spring-resiliency-use-cases-11 (work in progress), May
2017. 2017.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev,
"Segment Routing Centralized BGP Egress Peer Engineering", "Segment Routing Centralized BGP Egress Peer Engineering",
draft-ietf-spring-segment-routing-central-epe-05 (work in draft-ietf-spring-segment-routing-central-epe-06 (work in
progress), March 2017.
[I-D.ietf-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-08 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-09 data plane", draft-ietf-spring-segment-routing-mpls-10
(work in progress), June 2017. (work in progress), June 2017.
[I-D.ietf-spring-sr-oam-requirement] [I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-03 (work in Network", draft-ietf-spring-sr-oam-requirement-03 (work in
progress), January 2017. progress), January 2017.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
Data Model for Segment Routing", draft-ietf-spring-sr- Data Model for Segment Routing", draft-ietf-spring-sr-
yang-06 (work in progress), March 2017. yang-07 (work in progress), July 2017.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4381, Virtual Private Networks (VPNs)", RFC 4381,
DOI 10.17487/RFC4381, February 2006, DOI 10.17487/RFC4381, February 2006,
<http://www.rfc-editor.org/info/rfc4381>. <https://www.rfc-editor.org/info/rfc4381>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008, DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>. <https://www.rfc-editor.org/info/rfc5120>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, DOI 10.17487/RFC5714, January 2010,
<https://www.rfc-editor.org/info/rfc5714>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
March 2012, <http://www.rfc-editor.org/info/rfc6549>. March 2012, <https://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822,
DOI 10.17487/RFC6822, December 2012,
<http://www.rfc-editor.org/info/rfc6822>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 BGP for Routing in Large-Scale Data Centers", RFC 7938,
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, DOI 10.17487/RFC7938, August 2016,
March 2016, <http://www.rfc-editor.org/info/rfc7794>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
Litkowski, S., Horneffer, M., and R. Shakir, "Source Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
Packet Routing in Networking (SPRING) Problem Statement 2017, <https://www.rfc-editor.org/info/rfc8202>.
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <http://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Les Ginsberg
Cisco Systems, Inc
Email: ginsberg@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
FR FR
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
 End of changes. 126 change blocks. 
415 lines changed or deleted 472 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/