< draft-ietf-spring-segment-routing-10.txt   draft-ietf-spring-segment-routing-11.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: May 23, 2017 B. Decraene Expires: August 20, 2017 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google Google, Inc.
November 19, 2016 February 16, 2017
Segment Routing Architecture Segment Routing Architecture
draft-ietf-spring-segment-routing-10 draft-ietf-spring-segment-routing-11
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 local semantic 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 and service chain while maintaining per-flow state
only at the ingress node to the SR domain. only at the ingress 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 15 skipping to change at page 2, line 15
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 http://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 May 23, 2017. This Internet-Draft will expire on August 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://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 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7
3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 7 3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7
3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7
3.2.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 7 3.1.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 8
3.2.2. MPLS Dataplane . . . . . . . . . . . . . . . . . . . 9 3.1.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 9
3.2.3. IPv6 Dataplane . . . . . . . . . . . . . . . . . . . 10 3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10
3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 10 3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 10
3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 11 3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 13
3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 14 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 14
3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 15
3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16 3.5. Binding Segment . . . . . . . . . . . . . . . . . . . . . 15
3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 16 3.5.1. Mapping Server . . . . . . . . . . . . . . . . . . . 15
3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 16 3.5.2. Tunnel Head-end . . . . . . . . . . . . . . . . . . . 16
3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 17 3.6. Inter-Area Considerations . . . . . . . . . . . . . . . . 16
3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 17 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 17
4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 18 5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 18
5. IGP Mirroring Context Segment . . . . . . . . . . . . . . . 19 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 20 8.1. MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . 19
8.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 21 8.2. IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . . 20
9. Manageability Considerations . . . . . . . . . . . . . . . . 22 9. Manageability Considerations . . . . . . . . . . . . . . . . 21
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
With Segment Routing (SR), a node steers a packet through an ordered With Segment Routing (SR), a node steers a packet through an ordered
list of instructions, called segments. A segment can represent any 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
local semantic 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 allows to enforce a flow through any path and service chain while
maintaining per-flow state only at the ingress node of the SR domain. maintaining per-flow state only at the ingress node of the SR domain.
Segment Routing can be directly applied to the MPLS architecture Segment Routing can be directly applied to the MPLS architecture
([RFC3031]) with no change on the forwarding plane. A segment is ([RFC3031]) with no change on the forwarding plane. A segment is
encoded as an MPLS label. An ordered list of segments is encoded as 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 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 completed segment is popped off the stack. The addition of a segment
is performed with a push. is performed with a push.
In the Segment Routing MPLS instantiation, a segment could be of In the Segment Routing MPLS instantiation, a segment could be of
several types: several types:
o an IGP segment, o an IGP segment,
o a BGP Peering segments, o a BGP Peering segment,
o an LDP LSP segment, o an LDP LSP segment,
o an RSVP-TE LSP segment, o an RSVP-TE LSP segment,
o a BGP LSP segment. o a BGP LSP segment.
The first two (IGP and BGP Peering segments) types of segments are The first two (IGP and BGP peering segments) types of segments are
defined in this document. The use of the last three types of defined in this document. The use of the last three types of
segments is illustrated in [I-D.ietf-spring-segment-routing-mpls]. segments is illustrated in [I-D.ietf-spring-segment-routing-mpls].
Segment Routing can be applied to the IPv6 architecture ([RFC2460]), Segment Routing can be applied to the IPv6 architecture ([RFC2460]),
with a new type of routing header. A segment is encoded as an IPv6 with a new type of routing header. A segment is encoded as an IPv6
address. An ordered list of segments is encoded as an ordered list address. An ordered list of segments is encoded as an ordered list
of IPv6 addresses in the routing header. The active segment is of IPv6 addresses in the routing header. The active segment is
indicated by the Destination Address of the packet. Upon completion indicated by the Destination Address of the packet. Upon completion
of a segment, a pointer in the new routing header is incremented and of a segment, a pointer in the new routing header is incremented and
indicates the next segment. indicates the next segment.
Numerous use-cases illustrate the benefits of source routing either Numerous use-cases illustrate the benefits of source routing either
for FRR, OAM or Traffic Engineering reasons. for FRR, OAM or Traffic Engineering reasons
([I-D.ietf-spring-oam-usecase]).
This document defines a set of instructions (called segments) that This document defines a set of instructions (called segments) that
are required to fulfill the described use-cases. These segments can are required to fulfill the described use-cases. These segments can
either be used in isolation (one single segment defines the source either be used in isolation (one single segment defines the source
route of the packet) or in combination (these segments are part of an route of the packet) or in combination (these segments are part of an
ordered list of segments that define the source route of the packet). ordered list of segments that define the source route of the packet).
1.1. Companion Documents 1.1. Companion Documents
This document defines the SR architecture, its routing model, the This document defines the SR architecture, its routing model, the
IGP-based segments, the BGP-based segments and the service segments. IGP-based segments, the BGP-based segments and the service segments.
Use cases are described in [RFC7855], The problem statement and requirements are described in [RFC7855].
[I-D.ietf-spring-segment-routing-central-epe],
[I-D.ietf-spring-segment-routing-msdc],
[I-D.filsfils-spring-large-scale-interconnect],
[I-D.ietf-spring-ipv6-use-cases],
[I-D.ietf-spring-resiliency-use-cases], [I-D.ietf-spring-oam-usecase]
and [I-D.ietf-spring-sr-oam-requirement].
Segment Routing for MPLS dataplane is documented in
[I-D.ietf-spring-segment-routing-mpls].
Segment Routing for IPv6 dataplane is documented in
[I-D.ietf-6man-segment-routing-header].
IGP protocol extensions for Segment Routing are described in
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this
document as "IGP SR extensions documents".
The FRR solution for SR is documented in
[I-D.francois-rtgwg-segment-routing-ti-lfa].
The PCEP protocol extensions for Segment Routing are defined in
[I-D.ietf-pce-segment-routing].
The interaction between SR/MPLS with other MPLS Signaling planes is Use cases are described in .[I-D.ietf-spring-ipv6-use-cases],
documented in [I-D.ietf-spring-segment-routing-ldp-interop]. [I-D.ietf-spring-resiliency-use-cases] and
[I-D.ietf-spring-oam-usecase].
2. Terminology 2. Terminology
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: a MPLS label, an SID: a segment identifier. Examples of SIDs are: an MPLS label, an
index value in a MPLS label space, an IPv6 address. Other types of index value in an MPLS label space, an IPv6 address. Other types of
SIDs can be defined in the future. SIDs can be defined in the future.
Segment List: ordered list of SID's encoding the topological and Segment List: ordered list of SIDs encoding the ordered set of
service source route of the packet. It is a stack of labels in the instructions to be applied to the packet as it traverses the SR
MPLS architecture. It is an ordered list of IPv6 addresses in the 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. IPv6 architecture.
Segment Routing Domain (SR Domain): the set of nodes participating Segment Routing Domain (SR Domain): the set of nodes participating
into the source based routing model. These nodes may be connected to into the source based routing model. These nodes may be connected to
the same physical infrastructure (e.g.: a Service Provider's network) the same physical infrastructure (e.g.: a Service Provider's
as well as nodes remotely connected to each other (e.g.: an network). They may as well be remotely connected to each other
enterprise VPN or an overlay). Note that a SR domain may also be (e.g.: an enterprise VPN or an overlay). Note that an SR domain may
confined within an IGP instance, in which case it is named SR-IGP also be confined within an IGP instance, in which case it is named
Domain. SR-IGP Domain.
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 is the top label. In to process the packet. In the MPLS dataplane it is the top label.
the IPv6 dataplane is the destination address of a packet having the In the IPv6 dataplane it is the destination address of a packet
Segment Routing Header as defined in 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 insertion of a segment at the head of the Segment list. 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
segment list is the topmost (outer) label of the label stack. In the
IPv6 dataplane, the top of the segment list is represented by the
first segment in the Segment Routing Header as defined in
[I-D.ietf-6man-segment-routing-header].
NEXT: the active segment is completed, the next segment becomes NEXT: when the active segment is completed, NEXT is the instruction
active. consisting of the inspection of the next segment. The next segment
becomes active.
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. The CONTINUE instruction is implemented as the SWAP
instruction in the MPLS dataplane. In IPv6, this is the plain IPv6 instruction in the MPLS dataplane. In IPv6, this is the plain IPv6
forwarding action of a regular IPv6 packet according to its forwarding 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): local property of an SR node. In the MPLS
architecture, SRGB is the set of local labels reserved for global architecture, SRGB is the set of local labels reserved for global
segments. Using the same SRGB on all nodes within the SR domain ease segments. Using the same SRGB on all nodes within the SR domain ease
operations and troubleshooting and is expected to be a deployment operations and troubleshooting and is expected to be a deployment
guideline. In the IPv6 architecture, the equivalent of the SRGB is guideline. In the IPv6 architecture, the equivalent of the SRGB is
in fact the set of addresses used as global segments. Since there in fact the set of addresses used as global segments. Since there
are no restrictions on which IPv6 address can be used, the concept of are no restrictions on which IPv6 address can be used, the concept of
the SRGB includes all IPv6 global address space used within the SR the SRGB includes all IPv6 global address space used within the SR
domain. domain.
Global Segment: the related instruction is supported by all the SR- Global Segment: the related instruction is supported by all the SR-
capable nodes in the domain. In the MPLS architecture, a Global capable nodes in the domain. In the MPLS architecture, a global
Segment has a globally-unique index. The related local label at a segment is represented by a globally-unique index. The related local
given node N is found by adding the globally-unique index to the SRGB label at a given node N is found by adding the globally-unique index
of node N. In the IPv6 architecture, a global segment is a globally- to the SRGB of node N. In the IPv6 architecture, a global segment is
unique IPv6 address. a globally-unique IPv6 address.
Local Segment: the related instruction is supported only by the node Local Segment: the related instruction is supported only by the node
originating it. In the MPLS architecture, this is a local label originating it. In the MPLS architecture, this is a local label
outside the SRGB. In the IPv6 architecture, this can be any IPv6 outside the SRGB. In the IPv6 architecture, this can be any IPv6
address whose reachability is not advertised in any routing protocol address whose reachability is not advertised in any routing protocol
(hence, the segment is known only by the local node). (hence, the segment is known only by the local node).
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, Prefix-SID: an IGP-Prefix Segment is an IGP IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment
segment attached to an IGP prefix. An IGP-Prefix Segment is global representing an IGP prefix. An IGP-Prefix Segment is global (unless
(unless explicitly advertised otherwise) within the SR IGP instance/ explicitly advertised otherwise) within the SR IGP instance/topology
topology and identifies an instruction to forward the packet along and identifies an instruction to forward the packet along the path
the path computed using the routing algorithm specified in the computed using the routing algorithm specified in the algorithm
algorithm field, in the topology and the IGP instance where it is field, in the topology and the IGP instance where it is advertised.
advertised. The Prefix-SID is the SID of the IGP-Prefix Segment. Also referred to as Prefix Segment.
IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which Prefix SID: the SID of the IGP-Prefix Segment.
does not identify a specific router, but a set of routers. The terms
"Anycast Segment" or "Anycast-SID" are often used as an abbreviation.
IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to IGP-Anycast Segment: an IGP-Anycast Segment is an IGP-Prefix Segment
an unidirectional adjacency or a set of unidirectional adjacencies. which identify an anycast prefix advertised by a set of routers.
By default, an IGP-Adjacency Segment is local (unless explicitly
advertised otherwise) to the node that advertises it.
IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which Anycast-SID: the SID of the IGP-Anycast Segment.
identifies a specific router (e.g. a loopback). The terms "Node
Segment" or Node-SID" are often used as an abbreviation. IGP-Adjacency Segment: an IGP-Adjacency Segment is an IGP Segment
attached to a unidirectional adjacency or a set of unidirectional
adjacencies. By default, an IGP-Adjacency Segment is local (unless
explicitly advertised otherwise) to the node that advertises it.
Also referred to as Adjacency Segment.
Adj-SID: the SID of the IGP-Adjacency Segment.
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
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
Segment itself. For example, Prefix-SID is sometimes used to refer
to Prefix Segment.
SR Tunnel: a list of segments to be pushed on the packets directed on SR Tunnel: a list of segments to be pushed on the packets directed on
the tunnel. The list of segments can be specified explicitly or the tunnel. The list of segments can be specified explicitly or
implicitly via a set of abstract constraints (latency, affinity, implicitly via a set of abstract constraints (latency, affinity,
SRLG, ...). In the latter case, a constraint-based path computation SRLG, ...). In the latter case, a constraint-based path computation
is used to determine the list of segments associated with the tunnel. is used to determine the list of segments associated with the tunnel.
The computation can be local or delegated to a PCE server. An SR The computation can be local or delegated to a PCE server. An SR
tunnel can be configured by the operator, provisioned via netconf or tunnel can be configured by the operator, provisioned via netconf or
provisioned via PCEP. An SR tunnel can be used for traffic- provisioned via PCEP. An SR tunnel can be used for traffic-
engineering, OAM or FRR reasons. engineering, OAM or FRR reasons.
skipping to change at page 7, line 20 skipping to change at page 7, line 17
Segment List Depth: the number of segments of an SR tunnel. The Segment List Depth: the number of segments of an SR tunnel. The
entity instantiating an SR Tunnel at a node N should be able to entity instantiating an SR Tunnel at a node N should be able to
discover the depth insertion capability of the node N. The PCEP discover the depth insertion capability of the node N. The PCEP
discovery capability is described in [I-D.ietf-pce-segment-routing]. 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 a link-state IGP domain, an SR-capable IGP node advertises
segments for its attached prefixes and adjacencies. These segments segments for its attached prefixes and adjacencies. These segments
are called IGP segments or IGP SIDs. They play a key role in Segment are called IGP segments or IGP SIDs. They play a key role in Segment
Routing and use-cases as they enable the expression of any Routing and use-cases as they enable the expression of any path
topological path throughout the IGP domain. Such a topological path throughout the IGP domain. Such a path is either expressed as a
is either expressed as a single IGP segment or a list of multiple IGP single IGP segment or a list of multiple IGP segments.
segments.
3.1. IGP Segment, IGP SID
The terms "IGP Segment" and "IGP SID" are the generic names for a IGP segments require extensions in link-state IGP protocols. IGP
segment attached to a piece of information advertised by a link-state extensions are required in order to advertise the IGP segments.
IGP, e.g. an IGP prefix or an IGP adjacency.
3.2. 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/IGP domain.
The required IGP protocol extensions are defined in IGP SR extensions 3.1.1. Prefix-SID Algorithm
documents.
3.2.1. Prefix-SID Algorithm
The IGP protocol extensions for Segment Routing define the Prefix-SID The IGP protocol extensions for Segment Routing define the Prefix-SID
advertisement which includes a set of flags and the algorithm field. advertisement which includes a set of flags and the algorithm field.
The algorithm field has the purpose of associating a given Prefix-SID The algorithm field has the purpose of associating a given Prefix-SID
to a routing algorithm. to a routing algorithm.
In the context of an instance and a topology, multiple Prefix-SID's In the context of an instance and a topology, multiple Prefix-SID's
MAY be allocated to the same IGP Prefix as long as the algorithm MAY be allocated to the same IGP Prefix as long as the algorithm
value is different in each one. value is different in each one.
Multiple instances and topologies are defined in IS-IS and OSPF in: Multiple instances and topologies are defined in IS-IS and OSPF in:
[RFC5120], [RFC6822], [RFC6549] and [RFC4915]. [RFC5120], [RFC6822], [RFC6549] and [RFC4915].
Initially, two "algorithms" have been defined: Initially, two "algorithms" have been defined:
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 however it is explicitly allowed for a midpoint to implement
another forwarding based on local policy.. The "Shortest Path" another forwarding based on local policy. The "Shortest Path"
algorithm is in fact the default and current behavior of most of algorithm is in fact the default and current behavior of most of
the networks where local policies may override the SPF decision. 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 instruct 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" 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.
An IGP-Prefix Segment identifies the path, to the related prefix, An IGP-Prefix Segment identifies the path, to the related prefix,
along the path computed as per the algorithm field. computed as per the algorithm field.
A packet injected anywhere within the SR/IGP domain with an active A packet injected anywhere within the SR/IGP domain with an active
Prefix-SID will be forwarded along path computed by the algorithm Prefix-SID will be forwarded along path computed by the algorithm
expressed in the algorithm field. expressed in the algorithm field.
A router MUST drop any SR traffic associated with the SR algorithm to
the adjacent router, if the adjacent router has not advertised
support for such SR algorithm.
The ingress node of an SR domain validates that the path to a prefix, The ingress node of an SR domain validates that the path to a prefix,
advertised with a given algorithm, includes nodes all supporting the advertised with a given algorithm, includes nodes all supporting the
advertised algorithm. As a consequence, if a node on the path does advertised algorithm. As a consequence, if a node on the path does
not support algorithm X, the IGP-Prefix segment will be interrupted not support algorithm X, the IGP-Prefix segment will be interrupted
and will drop packet on that node. It's the responsibility of the and will drop packet on that node. It's the responsibility of the
ingress node using a segment to check that all downstream nodes ingress node using a segment to check that all downstream nodes
support the algorithm of the segment. support the algorithm of the segment.
A router MUST NOT forward any SR traffic associated with the SR It has to be noted that Fast Reroute (FRR) mechanisms are still
algorithm to the adjacent router, if the adjacent router has not compliant with the Strict-SPF. In other words, a packet received
advertised support for such SR algorithm. with a Strict-SPF SID may be rerouted through a FRR mechanism.
It has to be noted that Fast Reroute (FRR) mechanisms, such as the
one described in [I-D.francois-rtgwg-segment-routing-ti-lfa], that
are based on post-convergence SPF, are still compliant to the Strict-
SPF algorithm definition.
Details of the two defined algorithms are defined in Details of the two defined algorithms are defined in
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
3.2.2. MPLS Dataplane 3.1.2. MPLS Dataplane
When SR is used over the MPLS dataplane: When SR is used over the MPLS dataplane:
o the IGP signaling extension for IGP-Prefix segment includes the o the IGP signaling extension for IGP-Prefix segment includes the
P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag
([I-D.ietf-ospf-segment-routing-extensions]). A Node N ([I-D.ietf-ospf-segment-routing-extensions]). A Node N
advertising a Prefix-SID SID-R for its attached prefix R unset the advertising a Prefix-SID SID-R for its attached prefix R unsets
P-Flag (or NP-Flag) in order to instruct its connected neighbors the P-Flag (or NP-Flag) in order to instruct its connected
to perform the NEXT operation while processing SID-R. This neighbors to perform the NEXT operation while processing SID-R.
behavior is equivalent to Penultimate Hop Popping in MPLS. When This behavior is equivalent to Penultimate Hop Popping in MPLS.
the flag is unset, the neighbors of N MUST perform the NEXT When the flag is unset, the neighbors of N MUST perform the NEXT
operation while processing SID-R. When the flag is set, the operation while processing SID-R. When the flag is set, the
neighbors of N MUST perform the CONTINUE operation while neighbors of N MUST perform the CONTINUE operation while
processing SID-R. processing SID-R.
o A Prefix-SID is allocated in the form of an index in the SRGB (or o A Prefix-SID is allocated in the form of an index in the SRGB (or
as a local MPLS label) according to a process similar to IP as a local MPLS label) according to a process similar to IP
address allocation. Typically the Prefix-SID is allocated by address allocation. Typically, the Prefix-SID is allocated by
policy by the operator (or NMS) and the SID very rarely changes. 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 (using o While SR allows to attach a local segment to an IGP prefix, we
the L-Flag), we specifically assume that when the terms "IGP- specifically assume that when the terms "IGP-Prefix Segment" and
Prefix Segment" and "Prefix-SID" are used, the segment is global "Prefix-SID" are used, the segment is global (the SID is allocated
(the SID is allocated from the SRGB or as an index). This is from the SRGB or as an index). This is consistent with all the
consistent with all the described use-cases that require global described use-cases that require global segments attached to IGP
segments attached to IGP prefixes. 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 warning for
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
skipping to change at page 10, line 14 skipping to change at page 9, line 47
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.2.3. IPv6 Dataplane 3.1.3. IPv6 Dataplane
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 The Prefix-SID is the prefix itself. No additional identifier is
needed for Segment Routing over IPv6. needed for Segment Routing over IPv6.
o Any address belonging to any of the node's prefixes can be used as o Any address belonging to any of the node's prefixes can be used as
Prefix-SIDs. Prefix-SIDs.
o An operator may want to explicitly indicate which of the node's o An operator may want to explicitly indicate which of the node's
skipping to change at page 10, line 46 skipping to change at page 10, line 33
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 Regardless Segment Routing, any remote IPv6 node will maintain a
plain IPv6 FIB entry for any prefix, no matter if they represent a plain IPv6 FIB entry for any prefix, no matter if they represent a
segment or not. segment or not.
3.3. IGP-Node Segment, Node-SID 3.2. IGP-Node Segment, Node-SID
An IGP Node Segment is a an IGP Prefix Segment which identifies a
specific router (e.g. a loopback). The terms "Node Segment" or
"Node-SID" are often used as an abbreviation. The IGP SR extensions
define a flag that identifies Node-SIDs.
A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere
in the network, it enforces the ECMP-aware shortest-path forwarding
of the packet towards the related node.
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.4. IGP-Anycast Segment, Anycast SID 3.3. IGP-Anycast Segment, Anycast SID
An IGP-Anycast Segment is an IGP-prefix segment which does not
identify a specific router, but a set of routers. The terms "Anycast
Segment" or "Anycast-SID" are often used as an abbreviation.
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 MUST advertise the same prefix
with the same SID value. with the same SID value.
+--------------+ +--------------+
| Group A | | Group A |
|192.0.2.10/32 | |192.0.2.10/32 |
| SID:100 | | SID:100 |
| | | |
+-----------A1---A3----------+ +-----------A1---A3----------+
skipping to change at page 12, line 22 skipping to change at page 11, line 22
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
PE1------R1----------A2---A4---------R3------PE3 PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ / \ /| | | |\ /
\ / | +--------------+ | \ / \ / | +--------------+ | \ /
\ / | | \ / \ / | | \ /
/ | | / / | | /
/ \ | | / \ / \ | | / \
/ \ | +--------------+ | / \ / \ | +--------------+ | / \
/ \| | | |/ \ / \| | | |/ \
PE2------R2----------B1---B3----+----R4------PE4 PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32 | | | \ / | | | 203.0.113.4/32 203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
SID:20 | | | / | | | SID:40 SID:20 | | | / | | | SID:40
| | | / \ | | | | | | / \ | | |
+-----+-----B2---B4----+-----+ +-----------B2---B4----------+
| | | |
| Group B | | Group B |
| 192.0.2.1/32 | | 192.0.2.1/32 |
| SID:200 | | SID:200 |
+--------------+ +--------------+
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 is connected to
two routers in each of the groups A and B. two routers in each of the groups A and B.
skipping to change at page 13, line 30 skipping to change at page 12, line 30
(7000-8000) R1 | | \ | | R3 (6000-7000) (7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \ / \ | | / \ | | / \
/ \ | | +-----+ \ | | / \ / \ | | +-----+ \ | | / \
/ \ | | / \ | | / \ / \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4 PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40 SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)| |(2000-3000) (4000-5000)|
| | | |
+-------------------------+ +-------------------------+
Transit paths via anycast group A Figure 2: Transit paths via anycast group A
Considering a MPLS deployment, in the above topology, if device PE1 Considering an MPLS deployment, in the above topology, if device PE1
(or PE2) requires to send a packet to the device PE3 (or PE4) it (or PE2) requires to send a packet to the device PE3 (or PE4) it
needs to encapsulate the packet in a MPLS payload with the following needs to encapsulate the packet in an MPLS payload with the following
stack of labels. stack of labels.
o Label allocated by R1 for anycast SID 100 (outer label). o Label allocated by R1 for anycast SID 100 (outer label).
o Label allocated by the nearest router in group A for SID 30 (for o Label allocated by the nearest router in group A for SID 30 (for
destination PE3). destination PE3).
While the first label is easy to compute, in this case since there While the first label is easy to compute, in this case since there
are more than one topologically nearest devices (A1 and A2), unless are more than one topologically nearest devices (A1 and A2), unless
A1 and A2 allocated the same label value to the same prefix, A1 and A2 allocated the same label value to the same prefix,
skipping to change at page 14, line 11 skipping to change at page 13, line 11
PE2) cannot compute an appropriate label stack to steer the packet PE2) cannot compute an appropriate label stack to steer the packet
exclusively through the group A devices. Same holds true for devices exclusively through the group A devices. Same holds true for devices
PE3 and PE4 when trying to send a packet to PE1 or PE2. PE3 and PE4 when trying to send a packet to PE1 or PE2.
To ease the use of anycast segment in a short term, it is recommended To ease the use of anycast segment in a short term, it is recommended
to configure the same SRGB on all nodes of a particular anycast to configure the same SRGB on all nodes of a particular anycast
group. Using this method, as mentioned above, computation of the group. Using this method, as mentioned above, computation of the
label following the anycast segment is straightforward. label following the anycast segment is straightforward.
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 a 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.5. IGP-Adjacency Segment, Adj-SID 3.4. IGP-Adjacency Segment, Adj-SID
An IGP-Adjacency Segment is an IGP segment attached to a
unidirectional adjacency or a set of unidirectional adjacencies. By
default, an IGP-Adjacency Segment is local to the node which
advertises it. However, an Adjacency Segment can be global if
advertised by the IGP as such. The SID of the IGP-Adjacency Segment
is called the 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.
Similarly, when using a global Adj-SID, a packet injected anywhere Similarly, when using a global Adj-SID, a packet injected anywhere
within the SR domain with a segment list {SNL}, where SNL is a global within the SR domain with a segment list {SNL}, where SNL is a global
Adj-SID attached by node N to its adjacency over link L, will be Adj-SID 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, forwarded along the shortest-path to N and then be switched by N,
without any IP shortest-path consideration, towards link L. If the without any IP shortest-path consideration, towards link L. If the
Adj-SID identifies a set of adjacencies, then the node N load- Adj-SID identifies a set of adjacencies, then the node N does load-
balances the traffic among the various members of the set. The use balance the traffic among the various members of the set. The use of
of 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 B-flag. When set, the Adj- The encodings of the Adj-SID include the a set of flags among which
SID refers to an adjacency that is eligible for protection (e.g.: there is the B-flag. When set, the Adj-SID refers to an adjacency
using IPFRR or MPLS-FRR). that is eligible for protection (e.g.: using IPFRR or MPLS-FRR).
The encodings of the Adj-SID include the L-flag. When set, the Adj- The encodings of the Adj-SID also include the L-flag. When set, the
SID has local significance. By default the L-flag is set. Adj-SID has local significance. By default, the L-flag is set.
A node SHOULD allocate one Adj-SIDs for each of its adjacencies. A node SHOULD allocate one Adj-SIDs for each of its adjacencies.
A node MAY allocate multiple Adj-SIDs to the same adjacency. An A node MAY allocate multiple Adj-SIDs to the same adjacency. An
example is where the adjacency is established over a bundle example is where the adjacency is established over a bundle
interface. Each bundle member MAY have its own Adj-SID. interface. Each bundle member MAY have its own Adj-SID.
A node MAY allocate the same Adj-SID to multiple adjacencies. A node MAY allocate the same Adj-SID to multiple adjacencies.
Adjacency suppression MUST NOT be performed by the IGP. Obviously, 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.
A node MUST install a FIB entry for any Adj-SID of value V attached A node MUST install a FIB entry for any Adj-SID of value V attached
to data-link L: to data-link L:
Incoming Active Segment: V Incoming Active Segment: V
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 identified by the Adj-SID,
regardless its IGP/SPF cost. In other words, the use of Adjacency regardless its IGP/SPF cost. In other words, the use of adjacency
Segments overrides the routing decision made by SPF algorithm. segments overrides the routing decision made by the SPF algorithm.
3.5.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 link B with:
Incoming Active Segment: W Incoming Active Segment: W
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: loadbalance 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 a SDN/orchestration
system) about the loadbalancing factor over the parallel adjacencies. system) about the load-balancing factor over the parallel
As shown in Figure 1, A and B are connected through two parallel adjacencies. As shown in Figure 3, A and B are connected through two
adjacencies parallel adjacencies
link-1 link-1
+--------+ +--------+
| | | |
S---A B---C S---A B---C
| | | |
+--------+ +--------+
link-2 link-2
Figure 1: 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 loadbalance 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.
The weight value is advertised with the Adj-SID as defined in IGP SR The weight value is advertised with the Adj-SID as defined in IGP SR
extensions documents. extensions documents.
3.5.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 other 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.6. Binding Segment 3.5. Binding Segment
3.6.1. Mapping Server 3.5.1. Mapping Server
A Remote-Binding SID S advertised by the mapping server M for remote 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 prefix R attached to non-SR-capable node N signals the same
information as if N had advertised S as a Prefix-SID. Further information as if N had advertised S as a Prefix-SID. Further
details are described in the SR/LDP interworking procedures details are described in the SR/LDP interworking procedures
([I-D.ietf-spring-segment-routing-ldp-interop]. ([I-D.ietf-spring-segment-routing-ldp-interop].
The segment allocation and SRGB Maintenance rules are the same as The segment allocation and SRGB Maintenance rules are the same as
those defined for Prefix-SID. those defined for Prefix-SID.
3.6.2. Tunnel Headend 3.5.2. Tunnel Head-end
The segment allocation and SRGB Maintenance rules are the same as 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 those defined for Adj-SID. A tunnel attached to a head-end H acts as
an adjacency attached to H. an adjacency attached to H.
Note: an alternative consists of representing tunnels as forwarding- Note: an alternative consists of representing tunnels as forwarding-
adjacencies ( [RFC4206]). In such case, the tunnel is presented to adjacencies ([RFC4206]). In such case, the tunnel is presented to
the routing area as a routing adjacency and is considered as such by 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 all area routers. The Remote-Binding SID is preferred as it allows
to advertise the presence of a tunnel without influencing the LSDB to advertise the presence of a tunnel without influencing the LSDB
and the SPF computation. and the SPF computation.
3.7. Inter-Area Considerations 3.6. Inter-Area Considerations
In the following example diagram we assume an IGP deployed using In the following example diagram we assume an IGP deployed using
areas and where SR has been deployed. areas and where SR has been deployed.
! ! The example here below assumes the IPv6 control plane with the MPLS
! ! dataplane.
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150)
! !
Area-1 ! Backbone ! Area 2
! area !
Figure 2: Inter-Area Topology Example ! !
! !
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! !
Area-1 ! Backbone ! Area 2
! area !
In area 2, node Z allocates Node-SID 150 to his local prefix Figure 4: Inter-Area Topology Example
192.0.2.1/32. ABRs G and J will propagate the prefix into the
backbone area by creating a new instance of the prefix according to In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix
normal inter-area/level IGP propagation rules. 2001:DB8::2:1/128.
ABRs G and J will propagate the prefix and its SIDs into the backbone
area by creating a new instance of the prefix according to normal
inter-area/level IGP propagation rules.
Nodes C and I will apply the same behavior when leaking prefixes from Nodes C and I will apply the same behavior when leaking prefixes from
the backbone area down to area 1. Therefore, node S will see prefix the backbone area down to area 1. Therefore, node S will see prefix
192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I. 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and
I.
It therefore results that a Prefix-SID remains attached to its It therefore results that a Prefix-SID remains attached to its
related IGP Prefix through the inter-area process. related IGP Prefix through the inter-area process.
When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as When node S sends traffic to 2001:DB8::2:1/128, it pushes Node-
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 When an ABR propagates a prefix from one area to another it MUST set
the R-Flag. the R-Flag.
4. BGP Peering Segments 4. 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/SID's: Hereafter, we will define three types of BGP peering segments/SIDs:
PeerNodeSID, PeerAdjSID and PeerSetSID. PeerNode 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
BGP node advertising it, its semantics is: BGP node advertising it, the semantic is:
* SR header operation: NEXT. * SR header operation: NEXT.
* Next-Hop: the peer connected through the interface to which the * Next-Hop: the peer connected through the interface to which the
segment is related. segment is related.
o PeerSet SID. A BGP PeerSet segment/SID is a local segment. At o PeerSet SID. a BGP PeerSet segment/SID is a local segment. At the
the BGP node advertising it, its semantics is: BGP node advertising it, the semantic is:
* SR header operation: NEXT. * SR header operation: NEXT.
* Next-Hop: loadbalance 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 will be defined in a separate document.
5. IGP Mirroring Context Segment 5. IGP Mirroring Context Segment
skipping to change at page 19, line 27 skipping to change at page 18, line 32
It is beneficial for an IGP node to be able to advertise its ability It is beneficial for an IGP node to be able to advertise its ability
to process traffic originally destined to another IGP node, called to process traffic originally destined to another IGP node, called
the Mirrored node and identified by an IP address or a Node-SID, the Mirrored node and identified by an IP address or a Node-SID,
provided that a "Mirroring Context" segment be inserted in the provided that a "Mirroring Context" segment be inserted in the
segment list prior to any service segment local to the mirrored node. 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-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]). [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 process underlying segments in active segment, uses that segment and processes underlying segments
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
source-route concept to Multicast is not in the scope of this source-route concept to Multicast is not in the scope of this
document. document.
7. IANA Considerations 7. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
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 on the packet, with the list of Segment Routing adds some meta-data (instructions) on the packet,
forwarding path elements (e.g.: nodes, links, services, etc.) that with the list of forwarding path elements (e.g.: nodes, links,
the packet must traverse. It has to be noted that the complete services, etc.) that the packet must traverse. It has to be noted
source routed path may be represented by a single segment. This is that the complete source routed path may be represented by a single
the case of the Binding SID. segment. This is the case of the Binding SID.
8.1. MPLS Data Plane 8.1. MPLS Data Plane
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
skipping to change at page 20, line 45 skipping to change at page 20, line 4
change of capability. Yet, the occurrence of label stacking will change of capability. Yet, the occurrence of label stacking will
increase. increase.
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 imposing a label stack on a packet is assumed to such that any node imposing a label stack on a packet is assumed to
be allowed to do so. This is a significant change compared to plain be allowed to do so. This is a significant change compared to plain
IP offering shortest path routing but not fundamentally different IP offering shortest path routing but not fundamentally different
compared to existing techniques providing explicit routing capability compared to existing techniques providing explicit routing capability
such as RSVP-TE. By default, the explicit routing information MUST such as RSVP-TE. By default, the explicit routing information MUST
NOT be leaked through the boundaries of the administered domain. NOT be leaked through the boundaries of the administered domain.
Segment Routing extensions that have been defined in various Segment Routing extensions that have been defined in various
protocols, leverage the security mechanisms of these protocols such protocols, leverage the security mechanisms of these protocols such
as encryption, authentication, filtering, etc. as encryption, authentication, filtering, etc.
In the general case, a segment routing capable router accepts and In the general case, a segment routing capable router accepts and
install labels, only if these labels have been previously advertised install labels, only if these labels have been previously advertised
by a trusted source. The received information is validated using by a trusted source. The received information is validated using
existing control plane protocols providing authentication and existing control plane protocols providing authentication and
security mechanisms. Segment routing does not define any additional security mechanisms. Segment Routing does not define any additional
security mechanism in existing control plane protocols. security mechanism in existing control plane protocols.
Segment Routing does not introduce signaling between the source and Segment Routing does not introduce signaling between the source and
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 allow 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] section 2.4
and [RFC5920] section 8.2 already calls for the filtering of MPLS and [RFC5920] section 8.2 already calls for the filtering of MPLS
packets on trust boundaries. packets on trust boundaries.
8.2. IPv6 Data Plane 8.2. IPv6 Data Plane
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 [RFC2460].
skipping to change at page 21, line 47 skipping to change at page 21, line 9
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.
In the general case, an SR IPv6 router accepts and install segments In the general case, an SR IPv6 router accepts and install segments
identifiers (in the form of IPv6 addresses), only if these SIDs are identifiers (in the form of IPv6 addresses), only if these SIDs are
advertised by a trusted source. The received information is advertised by a trusted source. The received information is
validated using existing control plane protocols providing validated using existing control plane protocols providing
authentication and security mechanisms. Segment routing does not authentication and security mechanisms. Segment Routing does not
define any additional security mechanism in existing control plane define any additional security mechanism in existing control plane
protocols. protocols.
In addition, SR domain boundary routers, by default, MUST apply data In addition, SR domain boundary routers, by default, MUST apply data
plane filters so to only accept packets whose DA and SRH (if any) plane filters so to only accept packets whose DA and SRH (if any)
contain addresses previously advertised as SIDs. contain addresses previously advertised as SIDs.
There are a number of security concerns with source routing at the There are a number of security concerns with source routing at the
IPv6 data plane [RFC5095]. The new IPv6-based segment routing header IPv6 data plane [RFC5095]. The new IPv6-based segment routing header
defined in [I-D.ietf-6man-segment-routing-header] and its associated is defined in [I-D.ietf-6man-segment-routing-header]. This document
security measures address these concerns. The IPv6 Segment Routing also discusses the above security concerns.
Header is defined in a way that blind attacks are never possible,
i.e., attackers will be unable to send source routed packets that get
successfully processed, without being part of the negations for
setting up the source routes or being able to eavesdrop legitimate
source routed packets. In some networks this base level security may
be complemented with other mechanisms, such as packet filtering,
cryptographic security, etc.
9. Manageability Considerations 9. Manageability Considerations
In SR enabled networks, the path the packet takes is encoded in the In SR enabled networks, the path the packet takes is encoded in the
header. As the path is not signaled through a protocol, OAM header. As the path is not signaled through a protocol, OAM
mechanisms are necessary in order for the network operator to mechanisms are necessary in order for the network operator to
validate the effectiveness of a path as well as to check and monitor validate the effectiveness of a path as well as to check and monitor
its liveness and performance. However, it has to be noted that SR its liveness and performance. However, it has to be noted that SR
allows to reduce substantially the number of states in transit nodes allows to reduce substantially the number of states in transit nodes
and hence the number of elements that a transit node has to manage is and hence the number of elements that a transit node has to manage is
smaller. smaller.
SR OAM use cases and requirements for the MPLS data plane are defined SR OAM use cases and requirements for the MPLS data plane are defined
in [I-D.ietf-spring-oam-usecase] and in [I-D.ietf-spring-oam-usecase] and
[I-D.ietf-spring-sr-oam-requirement]. OAM procedures for the MPLS [I-D.ietf-spring-sr-oam-requirement]. SR OAM procedures for the MPLS
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 advertisement 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 so 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 globally-unique index or address. The
management of the allocation of such index or address by the operator management of the allocation of such index or address by the operator
is critical for the network behavior to avoid situations like mis- is critical for the network behavior to avoid situations like mis-
routing. In addition to the allocation policy/tooling that the routing. In addition to the allocation policy/tooling that the
operator will have in place, an implementation SHOULD protect 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
skipping to change at page 23, line 18 skipping to change at page 22, line 18
SIDs, and their resolution are addressed in SIDs, and their resolution are addressed in
[I-D.ietf-spring-conflict-resolution]. [I-D.ietf-spring-conflict-resolution].
SR with the MPLS data plane, can be gracefully introduced in an SR with the MPLS data plane, can be gracefully introduced in an
existing LDP [RFC5036] network. This is described in existing LDP [RFC5036] network. This is described in
[I-D.ietf-spring-segment-routing-ldp-interop]. SR and LDP may also [I-D.ietf-spring-segment-routing-ldp-interop]. SR and LDP may also
inter-work. In this case, the introduction of mapping-server may inter-work. In this case, the introduction of mapping-server may
introduce some additional manageability considerations that are introduce some additional manageability considerations that are
discussed in [I-D.ietf-spring-segment-routing-ldp-interop]. discussed in [I-D.ietf-spring-segment-routing-ldp-interop].
When a path is expressed using a a label stack, the occurrence of When a path is expressed using a label stack, the occurrence of label
label stacking will increase. A node may want to signal in the stacking will increase. A node may want to signal in the control
control plane it's ability in terms of size of the label stack it can plane its ability in terms of size of the label stack it can support.
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
existing mechanisms applied to the allocation and management of IPv6 existing mechanisms applied to the allocation and management of IPv6
addresses. addresses.
In the SR over IPv6 data plane context, the allocation of SIDs The DA of the packet gives the active segment address. The segment
results into the allocation of IPv6 addresses. Therefore, list in the SRH gives the entire path of the packet. The validation
management, troubleshooting, monitoring functions are the same as the of the source routed path is done through inspection of DA and SRH
one used for IPv6 addresses. present in the packet header matched to the equivalent routing table
entries.
The control of a source routed path of an IPv6 packet having an SRH
SHOULD be implemented through the inspection of the packet header and
more precisely its DA and segment list (in the SRH). The DA of the
packet gives the active segment address. The segment list in the SRH
gives the entire path of the packet. The validation of the source
routed path is done through inspection of DA and SRH present in the
packet header matched to the equivalent routing table entries.
In the context of SR over the IPv6 data plane, the source routed path In the context of SR over the IPv6 data plane, the source routed path
is encoded in the SRH as described in is encoded in the SRH as described in
[I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed [I-D.ietf-6man-segment-routing-header]. The SR IPv6 source routed
path is instantiated into the SRH as a list of IPv6 address where the path is instantiated into the SRH as a list of IPv6 address where the
active segment is in the Destination Address (DA) field of the IPv6 active segment is in the Destination Address (DA) field of the IPv6
packet header. Typically, by inspecting in any node the packet packet header. Typically, by inspecting in any node the packet
header, it is possible to derive the source routed path it belongs header, it is possible to derive the source routed path it belongs
to. Similar to the context of SR over MPLS data plane, an to. Similar to the context of SR over MPLS data plane, an
implementation may originate path control and monitoring packets implementation may originate path control and monitoring packets
skipping to change at page 24, line 24 skipping to change at page 23, line 20
Ahmed Bashandy Ahmed Bashandy
Cisco Systems, Inc. Cisco Systems, Inc.
Email: bashandy@cisco.com Email: bashandy@cisco.com
Martin Horneffer Martin Horneffer
Deutsche Telekom Deutsche Telekom
Email: Martin.Horneffer@telekom.de Email: Martin.Horneffer@telekom.de
Wim Henderickx Wim Henderickx
Alcatel-Lucent Nokia
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@nokia.com
Jeff Tantsura Jeff Tantsura
Ericsson Email: jefftant@gmail.com
Email: Jeff.Tantsura@ericsson.com
Edward Crabbe Edward Crabbe
Individual
Email: edward.crabbe@gmail.com Email: edward.crabbe@gmail.com
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, Dan Frost, Stewart Bryant, Pierre We would like to thank Dave Ward, Peter Psenak, Dan Frost, Stewart
Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes Bryant, Pierre Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib,
Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for their Hannes Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for
comments and review of this document. 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>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 25, line 31 skipping to change at page 24, line 22
<http://www.rfc-editor.org/info/rfc3031>. <http://www.rfc-editor.org/info/rfc3031>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, (GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005, DOI 10.17487/RFC4206, October 2005,
<http://www.rfc-editor.org/info/rfc4206>. <http://www.rfc-editor.org/info/rfc4206>.
12.2. Informative References 12.2. Informative References
[I-D.filsfils-spring-large-scale-interconnect]
Filsfils, C., Cai, D., Previdi, S., Henderickx, W.,
Cooper, D., Ferguson, F., Laberge, T., Lin, S., Decraene,
B., Jalil, L., jefftant@gmail.com, j., and R. Shakir,
"Interconnecting Millions Of Endpoints With Segment
Routing", draft-filsfils-spring-large-scale-
interconnect-04 (work in progress), October 2016.
[I-D.francois-rtgwg-segment-routing-ti-lfa]
Francois, P., Bashandy, A., and C. Filsfils, "Abstract",
draft-francois-rtgwg-segment-routing-ti-lfa-02 (work in
progress), November 2016.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova, Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun, J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-02 (work in progress), September segment-routing-header-05 (work in progress), February
2016. 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-09 (work in progress), October segment-routing-extensions-09 (work in progress), October
2016. 2016.
[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., Swallow, G., Pignataro, C., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
Ping/Trace for Segment Routing Networks Using MPLS Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-ietf-mpls-spring-lsp-ping-01 (work in Dataplane", draft-ietf-mpls-spring-lsp-ping-02 (work in
progress), October 2016. progress), December 2016.
[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-07 (work in progress), October segment-routing-extensions-07 (work in progress), October
2016. 2016.
[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.,
skipping to change at page 26, line 45 skipping to change at page 25, line 24
J. Hardwick, "PCEP Extensions for Segment Routing", draft- J. Hardwick, "PCEP Extensions for Segment Routing", draft-
ietf-pce-segment-routing-08 (work in progress), October ietf-pce-segment-routing-08 (work in progress), October
2016. 2016.
[I-D.ietf-spring-conflict-resolution] [I-D.ietf-spring-conflict-resolution]
Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
"Segment Routing Conflict Resolution", draft-ietf-spring- "Segment Routing Conflict Resolution", draft-ietf-spring-
conflict-resolution-02 (work in progress), October 2016. conflict-resolution-02 (work in progress), October 2016.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and
R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring- W. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-07 (work in progress), July 2016. ipv6-use-cases-09 (work in progress), February 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-04 (work in System", draft-ietf-spring-oam-usecase-05 (work in
progress), October 2016. progress), February 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-08 (work in progress), October spring-resiliency-use-cases-08 (work in progress), October
2016. 2016.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D. Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev,
Afanasiev, "Segment Routing Centralized BGP Peer "Segment Routing Centralized BGP Peer Engineering", draft-
Engineering", draft-ietf-spring-segment-routing-central- ietf-spring-segment-routing-central-epe-03 (work in
epe-02 (work in progress), September 2016. progress), November 2016.
[I-D.ietf-spring-segment-routing-ldp-interop] [I-D.ietf-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP", S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-04 (work in draft-ietf-spring-segment-routing-ldp-interop-06 (work in
progress), July 2016. progress), February 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., Horneffer, M., Shakir, R., Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing- with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-05 (work in progress), July 2016. mpls-07 (work in progress), February 2017.
[I-D.ietf-spring-segment-routing-msdc]
Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P.
Lapukhov, "BGP-Prefix Segment in large-scale data
centers", draft-ietf-spring-segment-routing-msdc-02 (work
in progress), October 2016.
[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-02 (work in Network", draft-ietf-spring-sr-oam-requirement-03 (work in
progress), July 2016. 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-05 (work in progress), October 2016. yang-05 (work in progress), October 2016.
[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>. <http://www.rfc-editor.org/info/rfc4381>.
skipping to change at page 29, line 27 skipping to change at page 28, line 4
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@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
Rob Shakir Rob Shakir
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US
Email: robjs@google.com Email: robjs@google.com
 End of changes. 112 change blocks. 
319 lines changed or deleted 261 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/