< draft-ietf-spring-segment-routing-03.txt   draft-ietf-spring-segment-routing-04.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: November 29, 2015 B. Decraene Expires: February 1, 2016 B. Decraene
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
British Telecom Individual
May 28, 2015 July 31, 2015
Segment Routing Architecture Segment Routing Architecture
draft-ietf-spring-segment-routing-03 draft-ietf-spring-segment-routing-04
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 local semantic 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 node to the SR domain.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
of IPv6 addresses in the routing extension header. The segment to of IPv6 addresses in the routing extension header. The segment to
process is indicated by a pointer in the routing extension header. process is indicated by a pointer in the routing extension header.
Upon completion of a segment, the pointer is incremented. Upon completion of a segment, the pointer is incremented.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 November 29, 2015. This Internet-Draft will expire on February 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 4 1.1. Companion Documents . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 6 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 7
3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . 6 3.1. IGP Segment, IGP SID . . . . . . . . . . . . . . . . . . . 7
3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 7 3.2. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . . 7
3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 8 3.3. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . . 9
3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 8 3.4. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . . 9
3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 9 3.5. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . . 12
3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 10 3.5.1. Parallel Adjacencies . . . . . . . . . . . . . . . . . 13
3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 11 3.5.2. LAN Adjacency Segments . . . . . . . . . . . . . . . . 14
3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 11 3.6. Binding Segment . . . . . . . . . . . . . . . . . . . . . 14
3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . 12 3.6.1. Mapping Server . . . . . . . . . . . . . . . . . . . . 14
3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . 12 3.6.2. Tunnel Headend . . . . . . . . . . . . . . . . . . . . 15
3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 12 3.7. Inter-Area Considerations . . . . . . . . . . . . . . . . 15
4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 13 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . . 16
5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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 local semantic 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.
skipping to change at page 4, line 19 skipping to change at page 5, line 12
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 Use cases are described in [I-D.ietf-spring-problem-statement],
[I-D.filsfils-spring-segment-routing-use-cases], [I-D.filsfils-spring-segment-routing-central-epe],
[I-D.filsfils-spring-segment-routing-msdc],
[I-D.ietf-spring-ipv6-use-cases], [I-D.ietf-spring-ipv6-use-cases],
[I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase] [I-D.ietf-spring-resiliency-use-cases], [I-D.geib-spring-oam-usecase]
and [I-D.kumar-spring-sr-oam-requirement]. and [I-D.kumar-spring-sr-oam-requirement].
Segment Routing for MPLS dataplane is documented in Segment Routing for MPLS dataplane is documented in
[I-D.ietf-spring-segment-routing-mpls]. [I-D.ietf-spring-segment-routing-mpls].
Segment Routing for IPv6 dataplane is documented in Segment Routing for IPv6 dataplane is documented in
[I-D.previdi-6man-segment-routing-header]. [I-D.previdi-6man-segment-routing-header].
skipping to change at page 5, line 36 skipping to change at page 6, line 31
architecture, SRGB is the set of local labels reserved for global architecture, SRGB is the set of local labels reserved for global
segments. In the IPv6 architecture, it is the set of locally segments. In the IPv6 architecture, it is the set of locally
relevant IPv6 addresses. Using the same SRGB on all nodes within the relevant IPv6 addresses. Using the same SRGB on all nodes within the
SR domain ease operations and troubleshooting and is expected to be a SR domain ease operations and troubleshooting and is expected to be a
deployment guideline. deployment guideline.
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 has a globally-unique index. The related local label at a
given node N is found by adding the globally-unique index to the SRGB given node N is found by adding the globally-unique index to the SRGB
of node N. In the IPv6 architecture, a global segment is a globally- of node N. In the IPv6 architecture, a global segment is a globally-
unique IPv6 address. 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 is a link-local outside the SRGB. In the IPv6 architecture, this is a link-local
address. address.
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.
skipping to change at page 6, line 32 skipping to change at page 7, line 27
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.
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 Routing and use-cases as they enable the expression of any
([I-D.filsfils-spring-segment-routing-use-cases]) as they enable the topological path throughout the IGP domain. Such a topological path
expression of any topological path throughout the IGP domain. Such a is either expressed as a single IGP segment or a list of multiple IGP
topological path is either expressed as a single IGP segment or a segments.
list of multiple IGP segments.
3.1. IGP Segment, IGP SID 3.1. IGP Segment, IGP SID
The terms "IGP Segment" and "IGP SID" are the generic names for a The terms "IGP Segment" and "IGP SID" are the generic names for a
segment attached to a piece of information advertised by a link-state segment attached to a piece of information advertised by a link-state
IGP, e.g. an IGP prefix or an IGP adjacency. IGP, e.g. an IGP prefix or an IGP adjacency.
3.2. IGP-Prefix Segment, Prefix-SID 3.2. 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.
skipping to change at page 7, line 30 skipping to change at page 8, line 24
P-Flag. A Node N advertising a Prefix-SID SID-R for its attached P-Flag. A Node N advertising a Prefix-SID SID-R for its attached
prefix R resets the P-Flag to allow its connected neighbors to prefix R resets the P-Flag to allow its connected neighbors to
perform the NEXT operation while processing SID-R. This behavior is perform the NEXT operation while processing SID-R. This behavior is
equivalent to Penultimate Hop Popping in MPLS. When set, the equivalent to Penultimate Hop Popping in MPLS. When set, the
neighbors of N must perform the CONTINUE operation while processing neighbors of N must perform the CONTINUE operation while processing
SID-R. SID-R.
While SR allows to attach a local segment to an IGP prefix (using the While SR allows to attach a local segment to an IGP prefix (using the
L-Flag), we specifically assume that when the terms "IGP-Prefix L-Flag), we specifically assume that when the terms "IGP-Prefix
Segment" and "Prefix-SID" are used, the segment is global (the SID is Segment" and "Prefix-SID" are used, the segment is global (the SID is
allocated from the SRGB). This is consistent with allocated from the SRGB). This is consistent with all the described
[I-D.filsfils-spring-segment-routing-use-cases] as all the described use-cases that require global segments attached to IGP prefixes.
use-cases require global segments attached to IGP prefixes.
A single Prefix-SID is allocated to an IGP Prefix in a topology. A single Prefix-SID is allocated to an IGP Prefix in a topology.
In the context of multiple topologies, multiple Prefix-SID's MAY be In the context of multiple topologies, multiple Prefix-SID's MAY be
allocated to the same IGP Prefix (e.g.: using the "algorithm" field allocated to the same IGP Prefix (e.g.: using the "algorithm" field
in the IGP advertisement as described in IGP SR extensions in the IGP advertisement as described in IGP SR extensions
documents). However, each prefix-SID MUST be associated with only documents). However, each prefix-SID MUST be associated with only
one topology. In other words: a prefix, within a topology, MUST have one topology. In other words: a prefix, within a topology, MUST have
only a single Prefix-SID. only a single Prefix-SID.
skipping to change at page 8, line 14 skipping to change at page 9, line 5
If a node learns a Prefix-SID having a value that falls outside the 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 Prefix- locally configured SRGB range, then the node MUST NOT use the Prefix-
SID and SHOULD issue an error log warning for misconfiguration. SID and SHOULD issue an error log warning for misconfiguration.
The required IGP protocol extensions are defined in IGP SR extensions The required IGP protocol extensions are defined in IGP SR extensions
documents. documents.
A node N attaching a Prefix-SID SID-R to its attached prefix R MUST A node N attaching a Prefix-SID SID-R to its attached prefix R MUST
maintain the following FIB entry: maintain the following FIB entry:
Incoming Active Segment: SID-R Incoming Active Segment: SID-R
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: NULL Egress interface: NULL
A remote node M MUST maintain the following FIB entry for any learned A remote node M MUST maintain the following FIB entry for any learned
Prefix-SID SID-R attached to IP prefix R: Prefix-SID SID-R attached to IP prefix R:
Incoming Active Segment: SID-R Incoming Active Segment: SID-R
Ingress Operation: Ingress Operation:
If the next-hop of R is the originator of R If the next-hop of R is the originator of R
and instructed to remove the active segment: NEXT and instructed to remove the active segment: NEXT
Else: CONTINUE Else: CONTINUE
Egress interface: the interface towards the next-hop along Egress interface: the interface towards the next-hop along
the shortest-path to prefix R. the shortest-path to prefix R.
3.3. IGP-Node Segment, Node-SID 3.3. IGP-Node Segment, Node-SID
An IGP-Node Segment is a an IGP-Prefix Segment which identifies a An IGP-Node Segment is a an IGP-Prefix Segment which identifies a
specific router (e.g. a loopback). The N flag is set. The terms specific router (e.g. a loopback). The N flag is set. The terms
"Node Segment" or "Node-SID" are often used as an abbreviation. "Node Segment" or "Node-SID" are often used as an abbreviation.
A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere A "Node Segment" or "Node-SID" is fundamental to SR. From anywhere
in the network, it enforces the ECMP-aware shortest- path forwarding in the network, it enforces the ECMP-aware shortest-path forwarding
of the packet towards the related node as explained in of the packet towards the related node.
[I-D.filsfils-spring-segment-routing-use-cases].
An IGP-Node-SID MUST NOT be associated with a prefix that is owned or An IGP-Node-SID MUST NOT be associated with a prefix that is owned or
advertised by more than one router within the same routing domain. advertised by more than one router within the same routing domain.
3.4. IGP-Anycast Segment, Anycast SID 3.4. IGP-Anycast Segment, Anycast SID
An IGP-Anycast Segment is an IGP-prefix segment which does not An IGP-Anycast Segment is an IGP-prefix segment which does not
identify a specific router, but a set of routers. The terms "Anycast identify a specific router, but a set of routers. The terms "Anycast
Segment" or "Anycast-SID" are often used as an abbreviation. 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 as described in mechanisms.
[I-D.filsfils-spring-segment-routing-use-cases].
The Anycast SID MUST be advertised with the N-flag unset. An IGP-Anycast Segment MUST NOT reference a particular node.
When anycast is used and multiple nodes advertise the same prefix Within an anycast group, all routers MUST advertise the same prefix
(with its SID), these nodes MUST use the same SRGB. with the same SID value.
The SID following the anycast SID MUST be understood by all nodes +--------------+
sharing the anycast SID. | Group A |
| 192.0.1.1/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
1.1.1.1/32 | | | / \ | | | 1.1.1.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3----+----R4------PE4
1.1.1.2/32 | | | \ / | | | 1.1.1.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----+-----B2---B4----+-----+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
Transit device groups
The figure above describes a network example with two groups of
transit devices. Group A consists of devices {A1, A2, A3 and A4}.
They are all provisioned with the anycast address 192.0.1.1/32 and
the anycast SID 100.
Similarly, group B consists of devices {B1, B2, B3 and B4} and are
all provisioned with the anycast address 192.0.1.2/32, anycast SID
200. In the above network topology, each PE device is connected to
two routers in each of the groups A and B.
PE1 can choose a particular transit device group when sending traffic
to PE3 or PE4. This will be done by pushing the anycast SID of the
group in the stack.
Processing the anycast, and subsequent segments, requires special
care.
Obviously, the value of the SID following the anycast SID MUST be
understood by all nodes advertising the same anycast segment.
+-------------------------+
| Group A |
| 192.0.1.1/32 |
| SID:100 |
|-------------------------|
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
+-------------------------+
Transit paths via anycast group A
Considering a MPLS deployment, in the above topology, if device PE1
(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
stack of labels.
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
destination PE3).
While the first label is easy to compute, in this case since there
are more than one topologically nearest devices (A1 and A2), unless
A1 and A2 allocated the same label value to the same prefix,
determining the second label is impossible. Devices A1 and A2 may be
devices from different hardware vendors. If both don't allocate the
same label value for SID 30, it is impossible to use the anycast
group "A" as a transit anycast group towards PE3. Hence, PE1 (or
PE2) cannot compute an appropriate label stack to steer the packet
exclusively through the group A devices. Same holds true for devices
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 configure the same SRGB on all nodes of a particular anycast
group. Using this method, as mentioned above, computation of the
label following the anycast segment is straightforward.
Using anycast segment without configuring the same SRGB on nodes
belonging to the same device group may lead to misrouting (in a MPLS
VPN deployment, some traffic may leak between VPNs).
3.5. IGP-Adjacency Segment, Adj-SID 3.5. IGP-Adjacency Segment, Adj-SID
An IGP-Adjacency Segment is an IGP segment attached to a An IGP-Adjacency Segment is an IGP segment attached to a
unidirectional adjacency or a set of unidirectional adjacencies. By unidirectional adjacency or a set of unidirectional adjacencies. By
default, an IGP-Adjacency Segment is local to the node which default, an IGP-Adjacency Segment is local to the node which
advertises it. However, an Adjacency Segment can be global if advertises it. However, an Adjacency Segment can be global if
advertised by the IGP as such. The SID of the IGP-Adjacency Segment advertised by the IGP as such. The SID of the IGP-Adjacency Segment
is called the Adj-SID. 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 load-
balances the traffic among the various members of the set. The use balances the traffic among the various members of the set. The use
of global Adj-SID allows to reduce the size of the segment list when of 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 as explained in a list of segments.
[I-D.filsfils-spring-segment-routing-use-cases].
The encodings of the Adj-SID include the B-flag. When set, the Adj- The encodings of the Adj-SID include the B-flag. When set, the Adj-
SID benefits from a local protection. SID benefits from a local protection.
The encodings of the Adj-SID include the L-flag. When set, the Adj- The encodings of the Adj-SID include the L-flag. When set, the Adj-
SID has local significance. By default the L-flag is set. 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
skipping to change at page 10, line 44 skipping to change at page 13, line 37
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 SPF algorithm.
3.5.1. Parallel Adjacencies 3.5.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: loadbalance 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 loadbalancing factor over the parallel adjacencies.
As shown in Figure 1, A and B are connected through two parallel As shown in Figure 1, A and B are connected through two parallel
adjacencies 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 1: 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
skipping to change at page 12, line 33 skipping to change at page 15, line 26
presented to the routing area as a routing adjacency and will be presented to the routing area as a routing adjacency and will be
considered as such by all area routers. The Remote-Binding SID is considered as such by all area routers. The Remote-Binding SID is
preferred as it allows to advertise the presence of a tunnel without preferred as it allows to advertise the presence of a tunnel without
influencing the LSDB and the SPF computation. influencing the LSDB and the SPF computation.
3.7. Inter-Area Considerations 3.7. 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.
! ! ! !
! ! ! !
B------C-----F----G-----K B------C-----F----G-----K
/ | | | / | | |
S---A/ | | | S---A/ | | |
\ | | | \ | | |
\D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150) \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150)
! ! ! !
Area-1 ! Backbone ! Area 2 Area-1 ! Backbone ! Area 2
! area ! ! area !
Figure 2: Inter-Area Topology Example Figure 2: Inter-Area Topology Example
In area 2, node Z allocates Node-SID 150 to his local prefix In area 2, node Z allocates Node-SID 150 to his local prefix
192.0.2.1/32. ABRs G and J will propagate the prefix into the 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 backbone area by creating a new instance of the prefix according to
normal inter-area/level IGP propagation rules. 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
skipping to change at page 14, line 43 skipping to change at page 17, line 35
This document does not require any action from IANA. This document does not require any action from IANA.
7. Security Considerations 7. Security Considerations
This document doesn't introduce new security considerations when This document doesn't introduce new security considerations when
applied to the MPLS dataplane. applied to the MPLS dataplane.
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 dataplane [RFC5095]. The new IPv6-based segment routing header IPv6 dataplane [RFC5095]. The new IPv6-based segment routing header
defined in [I-D.previdi-6man-segment-routing-header] and its defined in [I-D.previdi-6man-segment-routing-header] and its
associated security measures described in associated security measures address these concerns. The IPv6
[I-D.vyncke-6man-segment-routing-security] address these concerns. Segment Routing Header is defined in a way that blind attacks are
The IPv6 Segment Routing Header is defined in a way that blind never possible, i.e., attackers will be unable to send source routed
attacks are never possible, i.e., attackers will be unable to send packets that get successfully processed, without being part of the
source routed packets that get successfully processed, without being negations for setting up the source routes or being able to eavesdrop
part of the negations for setting up the source routes or being able legitimate source routed packets. In some networks this base level
to eavesdrop legitimate source routed packets. In some networks this security may be complemented with other mechanisms, such as packet
base level security may be complemented with other mechanisms, such filtering, cryptographic security, etc.
as packet filtering, cryptographic security, etc.
8. Contributors 8. Contributors
The following people have substantially contributed to the definition The following people have substantially contributed to the definition
of the Segment Routing architecture and to the editing of this of the Segment Routing architecture and to the editing of this
document: document:
Ahmed Bashandy Ahmed Bashandy
Cisco Systems, Inc. Cisco Systems, Inc.
Email: bashandy@cisco.com Email: bashandy@cisco.com
skipping to change at page 15, line 14 skipping to change at page 18, line 8
8. Contributors 8. Contributors
The following people have substantially contributed to the definition The following people have substantially contributed to the definition
of the Segment Routing architecture and to the editing of this of the Segment Routing architecture and to the editing of this
document: document:
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 Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com Email: wim.henderickx@alcatel-lucent.com
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
Email: Jeff.Tantsura@ericsson.com Email: Jeff.Tantsura@ericsson.com
Edward Crabbe Edward Crabbe
Individual 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
9. Acknowledgements 9. Acknowledgements
We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib and Hannes Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes Gredler
Gredler for their comments and review of this document. and Pushpasis Sarkar for their comments and review of this document.
10. References 10. References
10.1. Normative References 10.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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/
RFC4206, October 2005,
<http://www.rfc-editor.org/info/rfc4206>.
10.2. Informative References 10.2. Informative References
[I-D.filsfils-spring-segment-routing-central-epe] [I-D.filsfils-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Patel, K., Aries, E., Filsfils, C., Previdi, S., Patel, K., Aries, E.,
shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment shaw@fb.com, s., Ginsburg, D., and D. Afanasiev, "Segment
Routing Centralized Egress Peer Engineering", draft- Routing Centralized Egress Peer Engineering",
filsfils-spring-segment-routing-central-epe-03 (work in draft-filsfils-spring-segment-routing-central-epe-04 (work
progress), January 2015. in progress), July 2015.
[I-D.filsfils-spring-segment-routing-ldp-interop] [I-D.filsfils-spring-segment-routing-ldp-interop]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing interoperability with LDP", draft- "Segment Routing interoperability with LDP",
filsfils-spring-segment-routing-ldp-interop-03 (work in draft-filsfils-spring-segment-routing-ldp-interop-03 (work
progress), March 2015. in progress), March 2015.
[I-D.filsfils-spring-segment-routing-use-cases] [I-D.filsfils-spring-segment-routing-msdc]
Filsfils, C., Francois, P., Previdi, S., Decraene, B., Filsfils, C., Previdi, S., Mitchell, J., Aries, E.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., Lapukhov, P., Gaya, G., Afanasiev, D., Laberge, T.,
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Nkposong, E., Nanduri, M., Uttaro, J., and S. Ray, "BGP-
Crabbe, "Segment Routing Use Cases", draft-filsfils- Prefix Segment in large-scale data centers",
spring-segment-routing-use-cases-01 (work in progress), draft-filsfils-spring-segment-routing-msdc-03 (work in
October 2014. progress), July 2015.
[I-D.francois-spring-segment-routing-ti-lfa] [I-D.francois-spring-segment-routing-ti-lfa]
Francois, P., Filsfils, C., Bashandy, A., and B. Decraene, Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
"Topology Independent Fast Reroute using Segment Routing", "Topology Independent Fast Reroute using Segment Routing",
draft-francois-spring-segment-routing-ti-lfa-01 (work in draft-francois-spring-segment-routing-ti-lfa-01 (work in
progress), October 2014. progress), October 2014.
[I-D.geib-spring-oam-usecase] [I-D.geib-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
case for a scalable and topology aware MPLS data plane case for a scalable and topology aware MPLS data plane
monitoring system", draft-geib-spring-oam-usecase-04 (work monitoring system", draft-geib-spring-oam-usecase-06 (work
in progress), March 2015. in progress), July 2015.
[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. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment- Extensions for Segment Routing",
routing-extensions-04 (work in progress), May 2015. draft-ietf-isis-segment-routing-extensions-05 (work in
progress), June 2015.
[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",
segment-routing-extensions-02 (work in progress), February draft-ietf-ospf-ospfv3-segment-routing-extensions-03 (work
2015. in progress), June 2015.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing",
routing-extensions-04 (work in progress), February 2015. draft-ietf-ospf-segment-routing-extensions-05 (work in
progress), June 2015.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick, Lopez, V., Tantsura, J., Henderickx, W., and J. Hardwick,
"PCEP Extensions for Segment Routing", draft-ietf-pce- "PCEP Extensions for Segment Routing",
segment-routing-04 (work in progress), May 2015. draft-ietf-pce-segment-routing-05 (work in progress),
May 2015.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Leung, I., Previdi, S., Brzozowski, J., Leddy, J., Leung, I., Previdi, S.,
Townsley, W., Martin, C., Filsfils, C., and R. Maglione, Townsley, W., Martin, C., Filsfils, C., and R. Maglione,
"IPv6 SPRING Use Cases", draft-ietf-spring-ipv6-use- "IPv6 SPRING Use Cases",
cases-04 (work in progress), March 2015. draft-ietf-spring-ipv6-use-cases-04 (work in progress),
March 2015.
[I-D.ietf-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., and R. Shakir, "SPRING Problem Statement
and Requirements", draft-ietf-spring-problem-statement-04
(work in progress), April 2015.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir, Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", draft-ietf-spring- "Use-cases for Resiliency in SPRING",
resiliency-use-cases-01 (work in progress), March 2015. draft-ietf-spring-resiliency-use-cases-01 (work in
progress), March 2015.
[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., Tantsura, J., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane", and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-00 (work in draft-ietf-spring-segment-routing-mpls-01 (work in
progress), December 2014. progress), May 2015.
[I-D.kumar-spring-sr-oam-requirement] [I-D.kumar-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-kumar-spring-sr-oam-requirement-03 (work Network", draft-kumar-spring-sr-oam-requirement-03 (work
in progress), March 2015. in progress), March 2015.
[I-D.previdi-6man-segment-routing-header] [I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Previdi, S., Filsfils, C., Field, B., Leung, I., Aries,
Segment Routing Header (SRH)", draft-previdi-6man-segment- E., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing
routing-header-06 (work in progress), May 2015. Header (SRH)",
draft-previdi-6man-segment-routing-header-07 (work in
[I-D.vyncke-6man-segment-routing-security] progress), July 2015.
Vyncke, E., Previdi, S., and D. Lebrun, "IPv6 Segment
Routing Security Considerations", draft-vyncke-6man-
segment-routing-security-02 (work in progress), February
2015.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December of Type 0 Routing Headers in IPv6", RFC 5095,
2007. DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels,
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
skipping to change at page 19, line 4 skipping to change at page 21, line 41
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
British Telecom Individual
London
UK
Email: rob.shakir@bt.com Email: rjs@rob.sh
 End of changes. 52 change blocks. 
143 lines changed or deleted 238 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/