< draft-ietf-spring-segment-routing-13.txt   draft-ietf-spring-segment-routing-14.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 1, 2018 L. Ginsberg Expires: June 23, 2018 L. Ginsberg
Cisco Systems, Inc Cisco Systems, Inc
B. Decraene B. Decraene
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google, Inc. Google, Inc.
October 28, 2017 December 20, 2017
Segment Routing Architecture Segment Routing Architecture
draft-ietf-spring-segment-routing-13 draft-ietf-spring-segment-routing-14
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. A node Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called steers a packet through an ordered list of instructions, called
segments. A segment can represent any instruction, topological or segments. A segment can represent any instruction, topological or
service-based. A segment can have a semantic local to an SR node or service-based. A segment can have a semantic local to an SR node or
global within an SR domain. SR allows to enforce a flow through any global within an SR domain. SR allows to enforce a flow through any
topological path while maintaining per-flow state only at the ingress topological path while maintaining per-flow state only at the ingress
nodes to the SR domain. nodes to the SR domain.
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 1, 2018. This Internet-Draft will expire on June 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 8 3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 8
3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 8 3.1. IGP-Prefix Segment, Prefix-SID . . . . . . . . . . . . . 8
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 8 3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 8
3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 12 3.2. IGP-Node Segment, Node-SID . . . . . . . . . . . . . . . 12
3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 12 3.3. IGP-Anycast Segment, Anycast SID . . . . . . . . . . . . 12
3.3.1. Anycast SID in SR-MPLS . . . . . . . . . . . . . . . 12 3.3.1. Anycast SID in SR-MPLS . . . . . . . . . . . . . . . 12
3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 14 3.4. IGP-Adjacency Segment, Adj-SID . . . . . . . . . . . . . 15
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 15 3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 16
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 16 3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 17
3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 17 3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18
4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 18 4. BGP Peering Segments . . . . . . . . . . . . . . . . . . . . 19
4.1. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . 18 4.1. BGP Prefix Segment . . . . . . . . . . . . . . . . . . . 19
4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 18 4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 19
5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 19 5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 19 5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 20
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9. Manageability Considerations . . . . . . . . . . . . . . . . 22 8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Manageability Considerations . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
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 SR Policy instantiated as an ordered list steers a packet through an SR Policy instantiated as an ordered list
of instructions called segments. A segment can represent any of instructions called segments. A segment can represent any
instruction, topological or service-based. A segment can have a instruction, topological or service-based. A segment can have a
semantic local to an SR node or global within an SR domain. SR semantic local to an SR node or global within an SR domain. SR
supports per-flow explicit routing while maintaining per-flow state supports per-flow explicit routing while maintaining per-flow state
only at the ingress nodes to the SR domain. only at the ingress nodes to the SR domain.
A segment is often referred by its Segment Identifier (SID). A segment is often referred to by its Segment Identifier (SID).
A segment may be associated with a topological instruction. A A segment may be associated with a topological instruction. A
topological local segment may instruct a node to forward the packet topological local segment may instruct a node to forward the packet
via a specific outgoing interface. A topological global segment may via a specific outgoing interface. A topological global segment may
instruct an SR domain to forward the packet via a specific path to a instruct an SR domain to forward the packet via a specific path to a
destination. Different segments may exist for the same destination, destination. Different segments may exist for the same destination,
each with different path objectives (e.g., which metric is minimized, each with different path objectives (e.g., which metric is minimized,
what constraints are specified). what constraints are specified).
A segment may be associated with a service instruction (e.g. the A segment may be associated with a service instruction (e.g. the
skipping to change at page 4, line 35 skipping to change at page 4, line 38
the IGP domain, the SR controller may compute a source-routed policy the IGP domain, the SR controller may compute a source-routed policy
on behalf of an IGP node. The SR architecture does not restrict how on behalf of an IGP node. The SR architecture does not restrict how
the nodes which are part of the distributed control-plane interact the nodes which are part of the distributed control-plane interact
with the SR controller. Likely options are PCEP and BGP. with the SR controller. Likely options are PCEP and BGP.
Hosts MAY be part of an SR Domain. A centralized controller can Hosts MAY be part of an SR Domain. A centralized controller can
inform hosts about policies either by pushing these policies to hosts inform hosts about policies either by pushing these policies to hosts
or responding to requests from hosts. or responding to requests from hosts.
The SR architecture can be instantiated on various dataplanes. This The SR architecture can be instantiated on various dataplanes. This
document introduces two dataplanes instantiations of SR: SR over MPLS document introduces two dataplane instantiations of SR: SR over MPLS
(SR-MPLS) and SR over IPv6 (SRv6). (SR-MPLS) and SR over IPv6 (SRv6).
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 no change on the forwarding plane
[I-D.ietf-spring-segment-routing-mpls] A segment is encoded as an [I-D.ietf-spring-segment-routing-mpls] A segment is encoded as an
MPLS label. An SR Policy is instantiated as a stack of labels. The MPLS label. An SR Policy is instantiated as a stack of labels. The
segment to process (the active segment) is on the top of the stack. segment to process (the active segment) is on the top of the stack.
Upon completion of a segment, the related label is popped from the Upon completion of a segment, the related label is popped from the
stack. stack.
skipping to change at page 5, line 31 skipping to change at page 5, line 34
This document defines the IGP, BGP and Binding segments for the SR- This document defines the IGP, BGP and Binding segments for the SR-
MPLS and SRv6 dataplanes. MPLS and SRv6 dataplanes.
2. Terminology 2. Terminology
SR-MPLS: the instantiation of SR on the MPLS dataplane SR-MPLS: the instantiation of SR on the MPLS dataplane
SRv6: the instantiation of SR on the IPv6 dataplane. SRv6: the instantiation of SR on the IPv6 dataplane.
Segment: an instruction a node executes on the incoming packet (e.g.: Segment: an instruction a node executes on the incoming packet (e.g.,
forward packet according to shortest path to destination, or, forward forward packet according to shortest path to destination, or, forward
packet through a specific interface, or, deliver the packet to a packet through a specific interface, or, deliver the packet to a
given application/service instance). given application/service instance).
SID: a segment identifier. Note that the term SID is commonly used SID: a segment identifier. Note that the term SID is commonly used
in place of the term Segment, though this is technically imprecise as in place of the term Segment, though this is technically imprecise as
it overlooks any necessary translation. it overlooks any necessary translation.
SR-MPLS SID: an MPLS label or an index value into an MPLS label space SR-MPLS SID: an MPLS label or an index value into an MPLS label space
explicitly associated with the segment. explicitly associated with the segment.
SRv6 SID: an IPv6 address explicitly associated with the segment. SRv6 SID: an IPv6 address explicitly associated with the segment.
Segment Routing Domain (SR Domain): the set of nodes participating in Segment Routing Domain (SR Domain): the set of nodes participating in
the source based routing model. These nodes may be connected to the the source based routing model. These nodes may be connected to the
same physical infrastructure (e.g.: a Service Provider's network). same physical infrastructure (e.g., a Service Provider's network).
They may as well be remotely connected to each other (e.g.: an They may as well be remotely connected to each other (e.g., an
enterprise VPN or an overlay). If multiple protocol instances are enterprise VPN or an overlay). If multiple protocol instances are
deployed, the SR domain most commonly includes all of the protocol deployed, the SR domain most commonly includes all of the protocol
instances in a single SR domain. However, some deployments may wish instances in a network. However, some deployments may wish to sub-
to sub-divide the network into multiple SR domains, each of which divide the network into multiple SR domains, each of which includes
includes one or more protocol instances. It is expected that all one or more protocol instances. It is expected that all nodes in an
nodes in an SR Domain are managed by the same administrative entity. SR Domain are managed by the same administrative entity.
Active Segment: the segment that MUST be used by the receiving router Active Segment: the segment that is used by the receiving router to
to process the packet. In the MPLS dataplane it is the top label. process the packet. In the MPLS dataplane it is the top label. In
In the IPv6 dataplane it is the destination address. the IPv6 dataplane it is the destination address.
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
PUSH: the instruction consisting of the insertion of a segment at the PUSH: the instruction consisting of the insertion of a segment at the
top of the segment list. In SR-MPLS the top of the segment list is top of the segment list. In SR-MPLS the top of the segment list is
the topmost (outer) label of the label stack. In SRv6, the top of the topmost (outer) label of the label stack. In SRv6, the top of
the segment list is represented by the first segment in the Segment the segment list is represented by the first segment in the Segment
Routing Header as defined in [I-D.ietf-6man-segment-routing-header]. Routing Header as defined in [I-D.ietf-6man-segment-routing-header].
NEXT: when the active segment is completed, NEXT is the instruction NEXT: when the active segment is completed, NEXT is the instruction
consisting of the inspection of the next segment. The next segment consisting of the inspection of the next segment. The next segment
skipping to change at page 6, line 34 skipping to change at page 6, line 37
CONTINUE: the active segment is not completed and hence remains CONTINUE: the active segment is not completed and hence remains
active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of active. In SR-MPLS, CONTINUE instruction is implemented as a SWAP of
the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding the top label. [RFC3031] In SRv6, this is the plain IPv6 forwarding
action of a regular IPv6 packet according to its Destination Address. action of a regular IPv6 packet according to its Destination Address.
SR Global Block (SRGB): the set of global segments in the SR Domain. SR Global Block (SRGB): the set of global segments in the SR Domain.
If a node participates in multiple SR domains, there is one SRGB for If a node participates in multiple SR domains, there is one SRGB for
each SR domain. In SR-MPLS, SRGB is a local property of a node and each SR domain. In SR-MPLS, SRGB is a local property of a node and
identifies the set of local labels reserved for global segments. In identifies the set of local labels reserved for global segments. In
SR-MPLS, using the same SRGB on all nodes within the SR Domain is SR-MPLS, using identical SRGBs on all nodes within the SR Domain is
strongly recommended. Doing so eases operations and troubleshooting strongly recommended. Doing so eases operations and troubleshooting
as the same label represents the same global segment at each node. as the same label represents the same global segment at each node.
In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain. In SRv6, the SRGB is the set of global SRv6 SIDs in the SR Domain.
SR Local Block (SRLB): local property of an SR node. If a node SR Local Block (SRLB): local property of an SR node. If a node
participates in multiple SR domains, there is one SRLB for each SR participates in multiple SR domains, there is one SRLB for each SR
domain. In SR-MPLS, SRLB is a set of local labels reserved for local domain. In SR-MPLS, SRLB is a set of local labels reserved for local
segments. In SRv6, SRLB is a set of local IPv6 addresses reserved segments. In SRv6, SRLB is a set of local IPv6 addresses reserved
for local SRv6 SID's. In a controller-driven network, some for local SRv6 SID's. In a controller-driven network, some
controllers or applications MAY use the control plane to discover the controllers or applications may use the control plane to discover the
available set of local segments. available set of local segments.
Global Segment: a segment which is part of the SRGB of the domain. Global Segment: a segment which is part of the SRGB of the domain.
The instruction associated to the segment is defined at the SR Domain The instruction associated to the segment is defined at the SR Domain
level. A topological shortest-path segment to a given destination level. A topological shortest-path segment to a given destination
within an SR domain is a typical example of a global segment. within an SR domain is a typical example of a global segment.
Local Segment: In SR-MPLS, this is a local label outside the SRGB. Local Segment: In SR-MPLS, this is a local label outside the SRGB.
It MAY be part of the explicitly advertised SRLB. In SRv6, this can It may be part of the explicitly advertised SRLB. In SRv6, this can
be any IPv6 address i.e., the address MAY be part of the SRGB but be any IPv6 address i.e., the address may be part of the SRGB but
used such that it has local significance. The instruction associated used such that it has local significance. The instruction associated
to the segment is defined at the node level. to the segment is defined at the node level.
IGP Segment: the generic name for a segment attached to a piece of IGP Segment: the generic name for a segment attached to a piece of
information advertised by a link-state IGP, e.g. an IGP prefix or an information advertised by a link-state IGP, e.g. an IGP prefix or an
IGP adjacency. IGP adjacency.
IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment IGP-Prefix Segment: an IGP-Prefix Segment is an IGP Segment
representing an IGP prefix. When an IGP-Prefix Segment is global representing an IGP prefix. When an IGP-Prefix Segment is global
within the SR IGP instance/topology it identifies an instruction to within the SR IGP instance/topology it identifies an instruction to
skipping to change at page 7, line 51 skipping to change at page 8, line 5
Node-SID: the SID of the IGP-Node Segment. Node-SID: the SID of the IGP-Node Segment.
SR Policy: an ordered list of segments. The headend of an SR Policy SR Policy: an ordered list of segments. The headend of an SR Policy
steers packets onto the SR policy. The list of segments can be steers packets onto the SR policy. The list of segments can be
specified explicitly in SR-MPLS as a stack of labels and in SRv6 as specified explicitly in SR-MPLS as a stack of labels and in SRv6 as
an ordered list of SRv6 SID's. Alternatively, the list of segments an ordered list of SRv6 SID's. Alternatively, the list of segments
is computed based on a destination and a set of optimization is computed based on a destination and a set of optimization
objective and constraints (e.g., latency, affinity, SRLG, ...). The objective and constraints (e.g., latency, affinity, SRLG, ...). The
computation can be local or delegated to a PCE server. An SR policy computation can be local or delegated to a PCE server. An SR policy
can be configured by the operator, provisioned via NETCONF or can be configured by the operator, provisioned via NETCONF [RFC6241]
provisioned via PCEP [RFC5440] . An SR policy can be used for or provisioned via PCEP [RFC5440] . An SR policy can be used for
traffic-engineering, OAM or FRR reasons. traffic-engineering, OAM or FRR reasons.
Segment List Depth: the number of segments of an SR policy. The Segment List Depth: the number of segments of an SR policy. The
entity instantiating an SR Policy at a node N should be able to entity instantiating an SR Policy at a node N should be able to
discover the depth insertion capability of the node N. For example, discover the depth insertion capability of the node N. For example,
the PCEP SR capability advertisement described in the PCEP SR capability advertisement described in
[I-D.ietf-pce-segment-routing] is one means of discovering this [I-D.ietf-pce-segment-routing] is one means of discovering this
capability. capability.
Forwarding Information Base (FIB): the forwarding table of a node Forwarding Information Base (FIB): the forwarding table of a node
skipping to change at page 9, line 44 skipping to change at page 9, line 46
The ingress node of an SR domain SHOULD validate that the path to a The ingress node of an SR domain SHOULD validate that the path to a
prefix, advertised with a given algorithm, includes nodes all prefix, advertised with a given algorithm, includes nodes all
supporting the advertised algorithm. If this constraint cannot be supporting the advertised algorithm. If this constraint cannot be
met the packet SHOULD be dropped by the ingress node. Note that in met the packet SHOULD be dropped by the ingress node. Note that in
the special case of "Shortest Path", all nodes (SR Capable or not) the special case of "Shortest Path", all nodes (SR Capable or not)
are assumed to support this algorithm. are assumed to support this algorithm.
3.1.2. SR-MPLS 3.1.2. SR-MPLS
When SR is used over the MPLS dataplane SIDs are an MPLS label or an When SR is used over the MPLS dataplane SIDs are an MPLS label or an
index into an MPLS label space (either SRGB or SRLB). An SRGB/SRLB index into an MPLS label space (either SRGB or SRLB).
is advertised as an ordered set of ranges which has the following
properties:
o Each range specifies a starting label and the number of labels in
that range
o The set of ranges advertised by a given node MUST be disjoint
When the SID is an index, the mapping of the index to a label is
computed using the following algorithm:
r = # of advertised ranges
L(Ri) is the starting label of Range #i
N(Ri) is the number of labels in Range #i
X is the 0 based index
i = 1
while ((i <= r) && (X >= N(Ri)) {
X = X - N(Ri)
i = i + 1
}
if (i <= r)
LABEL = L(Ri) + X
else
no valid label exists for this index
Where possible, it is recommended that a consistent SRGB be Where possible, it is recommended that identical SRGBs be configured
configured on all nodes in an SR Domain. This simplifies on all nodes in an SR Domain. This simplifies troubleshooting as the
troubleshooting as the same label will be associated with the same same label will be associated with the same prefix on all nodes. In
prefix on all nodes. In addition, it simplifies support for anycast addition, it simplifies support for anycast as detailed in
as detailed in Section 3.3. Section 3.3.
The following behaviors are associated with SR operating over the The following behaviors are associated with SR operating over the
MPLS dataplane: MPLS dataplane:
o the IGP signaling extension for IGP-Prefix segment includes a flag o the IGP signaling extension for IGP-Prefix segment includes a flag
to indicate whether directly connected neighbors of the node on to indicate whether directly connected neighbors of the node on
which the prefix is attached should perform the NEXT operation or which the prefix is attached should perform the NEXT operation or
the CONTINUE operation when processing the SID. This behavior is the CONTINUE operation when processing the SID. This behavior is
equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop
Popping (CONTINUE) in MPLS. Popping (CONTINUE) in MPLS.
skipping to change at page 11, line 35 skipping to change at page 11, line 18
and instructed to remove the active segment: NEXT and instructed to remove the active segment: NEXT
Else: CONTINUE Else: CONTINUE
Egress interface: the interface towards the next-hop along the Egress interface: the interface towards the next-hop along the
path computed using the algorithm advertised with path computed using the algorithm advertised with
the SID toward prefix R. the SID toward prefix R.
3.1.3. SRv6 3.1.3. SRv6
When SR is used over the IPv6 dataplane: When SR is used over the IPv6 dataplane:
o A Prefix-SID is an IPv6 address.. o A Prefix-SID is an IPv6 address.
o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node
addresses are not SRv6 SIDs by default. addresses are not SRv6 SIDs by default.
A node N advertising an IPv6 address R usable as a segment identifier A node N advertising an IPv6 address R usable as a segment identifier
MUST maintain the following FIB entry: MUST maintain the following FIB entry:
Incoming Active Segment: R Incoming Active Segment: R
Ingress Operation: NEXT Ingress Operation: NEXT
Egress interface: NULL Egress interface: NULL
Note that forwarding to R does not require an entry in the FIBs of
all other routers for R. Forwarding can be and most often will be
achieved by a shorter mask prefix which covers R.
Independent of Segment Routing support, any remote IPv6 node will Independent of Segment Routing support, any remote IPv6 node will
maintain a plain IPv6 FIB entry for any prefix, no matter if the maintain a plain IPv6 FIB entry for any prefix, no matter if the
represent a segment or not. This allows forwarding of packets to the prefix represents a segment or not. This allows forwarding of
node which owns the SID even by nodes which do not support Segment packets to the node which owns the SID even by nodes which do not
Routing. support Segment Routing.
Support of multiple algorithms applies to SRv6. Since algorithm
specific SIDs are simply IPv6 addresses, algorithm specific
forwarding entries can be achieved by assigning algorithm specific
subnets to the (set of) algorithm specific SIDs which a node
allocates.
Nodes which do not support a given algorithm may still have a FIB
entry covering an algorithm specific address even though an algorithm
specific path has not been calculated by that node. This is
mitigated by the fact that nodes which do not support a given
algorithm will not be included in the topology associated with that
algorithm specific SPF and so traffic using the algorithm specific
destination will normally not flow via the excluded node. If such
traffic were to arrive and be forwarded by such a node, it will still
progress towards the destination node. The nexthop will either be a
node which supports the algorithm - in which case the packet will be
forwarded along algorithm specific paths (or be dropped if none are
available) - or the nexthop will be a node which does NOT support the
algorithm - in which case the packet will continue to be forwarded
along Algorithm 0 paths towards the destination node.
3.2. IGP-Node Segment, Node-SID 3.2. IGP-Node Segment, Node-SID
An IGP Node-SID MUST NOT be associated with a prefix that is owned by An IGP Node-SID MUST NOT be associated with a prefix that is owned by
more than one router within the same routing domain. more than one router within the same routing domain.
3.3. IGP-Anycast Segment, Anycast SID 3.3. IGP-Anycast Segment, Anycast SID
An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware
shortest-path forwarding towards the closest node of the anycast set. shortest-path forwarding towards the closest node of the anycast set.
skipping to change at page 14, line 19 skipping to change at page 14, line 50
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,
determining the second label is impossible. Devices A1 and A2 may be determining the second label is impossible. Devices A1 and A2 may be
devices from different hardware vendors. If both don't allocate the devices from different hardware vendors. If both don't allocate the
same label value for SID 30, it is impossible to use the anycast 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 group "A" as a transit anycast group towards PE3. Hence, PE1 (or
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, it is recommended to configure
to configure the same SRGB on all nodes of a particular anycast identical SRGBs on all nodes of a particular anycast group. Using
group. Using this method, as mentioned above, computation of the this method, as mentioned above, computation of the label following
label following the anycast segment is straightforward. the anycast segment is straightforward.
Using anycast segment without configuring the same SRGB on nodes Using anycast segment without configuring identical SRGBs on all
belonging to the same device group may lead to misrouting (in an MPLS nodes belonging to the same device group may lead to misrouting (in
VPN deployment, some traffic may leak between VPNs). an MPLS VPN deployment, some traffic may leak between VPNs).
3.4. IGP-Adjacency Segment, Adj-SID 3.4. IGP-Adjacency Segment, Adj-SID
The adjacency is formed by the local node (i.e., the node advertising The adjacency is formed by the local node (i.e., the node advertising
the adjacency in the IGP) and the remote node (i.e., the other end of the adjacency in the IGP) and the remote node (i.e., the other end of
the adjacency). The local node MUST be an IGP node. The remote node the adjacency). The local node MUST be an IGP node. The remote node
may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a may be an adjacent IGP neighbor or a non-adjacent neighbor (e.g., a
Forwarding Adjacency, [RFC4206]). Forwarding Adjacency, [RFC4206]).
A packet injected anywhere within the SR domain with a segment list A packet injected anywhere within the SR domain with a segment list
{SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID
attached by node N to its adjacency over link L, will be forwarded attached by node N to its adjacency over link L, will be forwarded
along the shortest-path to N and then be switched by N, without any along the shortest-path to N and then be switched by N, without any
IP shortest-path consideration, towards link L. If the Adj-SID IP shortest-path consideration, towards link L. If the Adj-SID
identifies a set of adjacencies, then the node N load-balances the identifies a set of adjacencies, then the node N load-balances the
traffic among the various members of the set. traffic among the various members of the set.
skipping to change at page 15, line 15 skipping to change at page 15, line 47
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 a set of flags supporting the The encodings of the Adj-SID include a set of flags supporting the
following functionalities: following functionalities:
o Eligible for Protection (e.g.: using IPFRR or MPLS-FRR) o Eligible for Protection (e.g., using IPFRR or MPLS-FRR).
Protection allows that in the event the interface(s) associated
with the Adj-SID are down, that the packet can still be forwarded
via an alternate path to the node at the remote end of the
interface(s). The use of protection is clearly a policy based
decision i.e., for a given policy protection may or may not be
desirable.
o Indication whether the Adj-SID has local or global scope. Default o Indication whether the Adj-SID has local or global scope. Default
scope SHOULD be Local. scope SHOULD be Local.
o Indication whether the Adj-SID is persistent across control plane
restarts. Persistence is a key attribute in ensuring that an SR
Policy does not temporarily result in misforwarding due to
reassignment of an Adj-SID.
A weight (as described below) is also associated with the Adj-SID A weight (as described below) is also associated with the Adj-SID
advertisement. advertisement.
A node SHOULD allocate one Adj-SID for each of its adjacencies. A node SHOULD allocate one Adj-SID for each of its adjacencies.
A node MAY allocate multiple Adj-SIDs for the same adjacency. An A node MAY allocate multiple Adj-SIDs for the same adjacency. An
example is to support an Adj-SID which is eligible for protection and example is to support an Adj-SID which is eligible for protection and
an Adj-SID which is NOT eligible for protection. an Adj-SID which is NOT eligible for protection.
A node MAY associate the same Adj-SID to multiple adjacencies. A node MAY associate the same Adj-SID to multiple adjacencies.
skipping to change at page 17, line 5 skipping to change at page 17, line 51
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 of the individual nodes in connectivity to the DR/DIS and not to each of the individual nodes in
the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF) the LAN. Therefore, additional protocol mechanisms (IS-IS and OSPF)
are necessary in order for each router in the LAN to advertise an are necessary in order for each router in the LAN to advertise an
Adj-SID associated to each neighbor in the LAN. These extensions are Adj-SID associated to each neighbor in the LAN.
defined in IGP SR extensions documents.
3.5. Inter-Area Considerations 3.5. Inter-Area Considerations
In the following example diagram it is assumed that the all areas are In the following example diagram it is assumed that the all areas are
part of a single SR Domain. part of a single SR Domain.
The example here below assumes the IPv6 control plane with the MPLS The example here below assumes the IPv6 control plane with the MPLS
dataplane. dataplane.
! ! ! !
skipping to change at page 17, line 32 skipping to change at page 18, line 29
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150) \D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! ! ! !
Area-1 ! Backbone ! Area 2 Area-1 ! Backbone ! Area 2
! area ! ! area !
Figure 4: Inter-Area Topology Example Figure 4: Inter-Area Topology Example
In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix In area 2, node Z allocates Node-SID 150 to his local IPv6 prefix
2001:DB8::2:1/128. 2001:DB8::2:1/128.
ABRs G and J will propagate the prefix and its SIDs into the backbone Area Border Routers (ABR) G and J will propagate the prefix and its
area by creating a new instance of the prefix according to normal SIDs into the backbone area by creating a new instance of the prefix
inter-area/level IGP propagation rules. 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
2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and 2001:DB8::2:1/128 with Prefix-SID 150 and advertised by nodes C and
I. 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, which is the
expected behavior in a single SR Domain.
When node S sends traffic to 2001:DB8::2:1/128, it pushes Node- When node S sends traffic to 2001:DB8::2:1/128, it pushes Node-
SID(150) as active segment and forward it to A. SID(150) as active segment and forward it to A.
When packet arrives at ABR I (or C), the ABR forwards the packet When packet arrives at ABR I (or C), the ABR forwards the packet
according to the active segment (Node-SID(150)). Forwarding according to the active segment (Node-SID(150)). Forwarding
continues across area borders, using the same Node-SID(150), until continues across area borders, using the same Node-SID(150), until
the packet reaches its destination. the packet reaches its destination.
4. BGP Peering Segments 4. BGP Peering Segments
skipping to change at page 19, line 25 skipping to change at page 20, line 25
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 are defined in [I-D.ietf-idr-bgpls-segment-routing-epe] segments are defined in [I-D.ietf-idr-bgpls-segment-routing-epe]
5. Binding Segment 5. Binding Segment
An SR Policy is bound to a so-called Binding SID (BSID). Any packets In order to provide greater scalability, network opacity, and service
received with active segment = BSID are steered onto the bound SR independence, SR utilizes a Binding SID (BSID). The BSID is bound to
Policy. an SR policy, instantiation of which may involve a list of SIDs. Any
packets received with active segment = BSID are steered onto the
bound SR Policy.
A BSID may either be a local or a global SID. If local, a BSID A BSID may either be a local or a global SID. If local, a BSID
SHOULD be allocated from the SRLB. If global, a BSID MUST be SHOULD be allocated from the SRLB. If global, a BSID MUST be
allocated from the SRGB. allocated from the SRGB.
One of the possible use cases for a BSID is to overcome a Segment Use of a BSID allows the instantiation of the policy (the SID list)
List Depth limitation on a given node by requiring that node only to to be stored only on the node(s) which need to impose the policy.
impose a BSID which could be SWAPPED on downstream nodes with a set Direction of traffic to a node supporting the policy then only
of SIDs associated with an SR policy. requires imposition of the BSID. If the policy changes, this also
means that only the nodes imposing the policy need to be updated.
Users of the policy are not impacted.
5.1. IGP Mirroring Context Segment 5.1. IGP Mirroring Context Segment
Another use case for a Binding Segment is to provide support for an One use case for a Binding Segment is to provide support for an IGP
IGP node to advertise its ability to process traffic originally node to advertise its ability to process traffic originally destined
destined to another IGP node, called the Mirrored node and identified to another IGP node, called the Mirrored node and identified by an IP
by an IP address or a Node-SID, provided that a "Mirroring Context" address or a Node-SID, provided that a "Mirroring Context" segment be
segment be inserted in the segment list prior to any service segment inserted in the segment list prior to any service segment local to
local to the mirrored node. 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] .
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
skipping to change at page 20, line 25 skipping to change at page 21, line 32
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 (instructions) on the packet, Segment Routing adds some meta-data (instructions) to the packet,
with the list of forwarding path elements (e.g.: nodes, links, with the list of forwarding path elements (e.g., nodes, links,
services, etc.) that the packet must traverse. It has to be noted services, etc.) that the packet must traverse. It has to be noted
that the complete source routed path may be represented by a single that the complete source routed path may be represented by a single
segment. This is the case of the Binding SID. segment. This is the case of the Binding SID.
SR by default operates within a trusted domain. Traffic MUST be
filtered at the domain boundaries.
8.1. SR-MPLS 8.1. SR-MPLS
When applied to the MPLS data plane, Segment Routing does not When applied to the MPLS data plane, Segment Routing does not
introduce any new behavior or any change in the way MPLS data plane introduce any new behavior or any change in the way MPLS data plane
works. Therefore, from a security standpoint, this document does not works. Therefore, from a security standpoint, this document does not
define any additional mechanism in the MPLS data plane. define any additional mechanism in the MPLS data plane.
SR allows the expression of a source routed path using a single SR allows the expression of a source routed path using a single
segment (the Binding SID). Compared to RSVP-TE which also provides segment (the Binding SID). Compared to RSVP-TE which also provides
explicit routing capability, there are no fundamental differences in explicit routing capability, there are no fundamental differences in
skipping to change at page 21, line 9 skipping to change at page 22, line 19
additional meta-data is added to the packet consisting of the source additional meta-data is added to the packet consisting of the source
routed path the packet must follow expressed as a segment list. routed path the packet must follow expressed as a segment list.
When a path is expressed using a label stack, if one has access to When a path is expressed using a label stack, if one has access to
the meaning (i.e.: the Forwarding Equivalence Class) of the labels, the meaning (i.e.: the Forwarding Equivalence Class) of the labels,
one has the knowledge of the explicit path. For the MPLS data plane, one has the knowledge of the explicit path. For the MPLS data plane,
as no data plane modification is required, there is no fundamental as no data plane modification is required, there is no fundamental
change of capability. Yet, the occurrence of label stacking will change of capability. Yet, the occurrence of label stacking will
increase. increase.
SR domain boundary routers MUST filter any external traffic destined
to a label associated with a segment within the trusted domain. This
includes labels within the SRGB of the trusted domain, labels within
the SRLB of the specific boundary router, and labels outside either
of these blocks. External traffic is any traffic received from an
interface connected to a node outside the domain of trust.
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 requirements as the
MPLS architecture already allows such source routing by stacking existing MPLS architecture already allows such source routing by
multiple labels. And for security protection, [RFC4381] and stacking multiple labels. And for security protection, [RFC4381] and
[RFC5920] already call for the filtering of MPLS packets on trust [RFC5920] already call for the filtering of MPLS packets on trust
boundaries. boundaries.
8.2. SRv6 8.2. SRv6
When applied to the IPv6 data plane, Segment Routing does introduce When applied to the IPv6 data plane, Segment Routing does introduce
the Segment Routing Header (SRH, the Segment Routing Header (SRH,
[I-D.ietf-6man-segment-routing-header]) which is a type of Routing [I-D.ietf-6man-segment-routing-header]) which is a type of Routing
Extension header as defined in [RFC8200]. Extension header as defined in [RFC8200].
The SRH adds some meta-data on the IPv6 packet, with the list of The SRH adds some meta-data to the IPv6 packet, with the list of
forwarding path elements (e.g.: nodes, links, services, etc.) that forwarding path elements (e.g., nodes, links, services, etc.) that
the packet must traverse and that are represented by IPv6 addresses. the packet must traverse and that are represented by IPv6 addresses.
A complete source routed path may be encoded in the packet using a A complete source routed path may be encoded in the packet using a
single segment (single IPv6 address). single segment (single IPv6 address).
SR domain boundary routers MUST filter any external traffic destined
to an address within the SRGB of the trusted domain or the SRLB of
the specific boundary router. External traffic is any traffic
received from an interface connected to a node outside the domain of
trust.
From a network protection standpoint, there is an assumed trust model From a network protection standpoint, there is an assumed trust model
such that any node adding an SRH to the packet is assumed to be such that any node adding an SRH to the packet is assumed to be
allowed to do so. Therefore, by default, the explicit routing allowed to do so. Therefore, by default, the explicit routing
information MUST NOT be leaked through the boundaries of the information MUST NOT be leaked through the boundaries of the
administered domain. Segment Routing extensions that have been administered domain. Segment Routing extensions that have been
defined in various protocols, leverage the security mechanisms of defined in various protocols, leverage the security mechanisms of
these protocols such as encryption, authentication, filtering, etc. these protocols such as encryption, authentication, filtering, etc.
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 Problems which may arise when the above behaviors are not done
plane filters so to only accept packets whose DA and SRH (if any) include:
contain addresses previously advertised as SIDs.
There are a number of security concerns with source routing at the o Malicious looping
IPv6 data plane [RFC5095]. The new IPv6-based segment routing header
is defined in [I-D.ietf-6man-segment-routing-header]. This document o Evasion of access controls
also discusses the above security concerns. o Hiding the source of DOS attacks
Security concerns with source routing at the IPv6 data plane are more
completely discussed in [RFC5095]. The new IPv6-based segment
routing header is defined in [I-D.ietf-6man-segment-routing-header].
This document also discusses the above security concerns.
8.3. Congestion Control
SR does not introduce new requirements for congestion control. By
default, traffic delivery is assumed to be best effort. Congestion
control may be implemented at endpoints. Where SR policies are in
use bandwidth allocation may be managed by monitoring incoming
traffic associated with the binding SID identifying the SR policy.
Other solutions such as [RFC8084] may be applicable.
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 for the MPLS data plane are defined in
in [I-D.ietf-spring-oam-usecase] and [I-D.ietf-spring-oam-usecase]. SR OAM procedures for the MPLS data
[I-D.ietf-spring-sr-oam-requirement]. SR OAM procedures for the MPLS plane are defined in [I-D.ietf-mpls-spring-lsp-ping].
data plane are defined in [I-D.ietf-mpls-spring-lsp-ping].
SR routers receive advertisements of SIDs (index, label or IPv6 SR routers receive advertisements of SIDs (index, label or IPv6
address) from the different routing protocols being extended for SR. address) from the different routing protocols being extended for SR.
Each of these protocols have monitoring and troubleshooting Each of these protocols have monitoring and troubleshooting
mechanisms to provide operation and management functions for IP mechanisms to provide operation and management functions for IP
addresses that MUST be extended in order to include troubleshooting addresses that must be extended in order to include troubleshooting
and monitoring functions of the SID. and monitoring functions of the SID.
SR architecture introduces the usage of global segments. Each global SR architecture introduces the usage of global segments. Each global
segment must be bound to a unique index or address within an SR segment MUST be bound to a unique index or address within an SR
domain. The management of the allocation of such index or address by domain. The management of the allocation of such index or address by
the operator is critical for the network behavior to avoid situations the operator is critical for the network behavior to avoid situations
like mis-routing. In addition to the allocation policy/tooling that like mis-routing. In addition to the allocation policy/tooling that
the operator will have in place, an implementation SHOULD protect the the operator will have in place, an implementation SHOULD protect the
network in case of conflict detection by providing a deterministic network in case of conflict detection by providing a deterministic
resolution approach. resolution approach.
When a path is expressed using a label stack, the occurrence of label When a path is expressed using a label stack, the occurrence of label
stacking will increase. A node may want to signal in the control stacking will increase. A node may want to signal in the control
plane its ability in terms of size of the label stack it can support. plane its ability in terms of size of the label stack it can support.
skipping to change at page 25, line 29 skipping to change at page 27, line 17
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi, Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,
T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk, T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,
"IPv6 Segment Routing Header (SRH)", draft-ietf-6man- "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
segment-routing-header-07 (work in progress), July 2017. segment-routing-header-07 (work in progress), July 2017.
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing- Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-13 (work in progress), June 2017. epe-14 (work in progress), December 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., Ginsberg, L., Filsfils, C., Bashandy, A.,
Litkowski, S., Decraene, B., and j. jefftant@gmail.com, Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
"IS-IS Extensions for Segment Routing", draft-ietf-isis- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-13 (work in progress), June segment-routing-extensions-15 (work in progress), December
2017. 2017.
[I-D.ietf-mpls-spring-lsp-ping] [I-D.ietf-mpls-spring-lsp-ping]
Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini, Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini,
S., and M. Chen, "Label Switched Path (LSP) Ping/ S., and M. Chen, "Label Switched Path (LSP) Ping/
Traceroute for Segment Routing IGP Prefix and Adjacency Traceroute for Segment Routing IGP Prefix and Adjacency
SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp- SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp-
ping-13 (work in progress), October 2017. ping-13 (work in progress), October 2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-10 (work in progress), segment-routing-extensions-10 (work in progress),
September 2017. September 2017.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-21 (work in progress), October 2017. routing-extensions-24 (work in progress), December 2017.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-10 (work in progress), draft-ietf-pce-segment-routing-11 (work in progress),
October 2017. November 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-09 (work in System", draft-ietf-spring-oam-usecase-10 (work in
progress), July 2017. progress), December 2017.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
"Resiliency use cases in SPRING networks", draft-ietf- "Resiliency use cases in SPRING networks", draft-ietf-
spring-resiliency-use-cases-11 (work in progress), May spring-resiliency-use-cases-12 (work in progress),
2017. December 2017.
[I-D.ietf-spring-segment-routing-central-epe] [I-D.ietf-spring-segment-routing-central-epe]
Filsfils, C., Previdi, S., Aries, E., and D. Afanasiev, Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
"Segment Routing Centralized BGP Egress Peer Engineering", Afanasiev, "Segment Routing Centralized BGP Egress Peer
draft-ietf-spring-segment-routing-central-epe-06 (work in Engineering", draft-ietf-spring-segment-routing-central-
progress), June 2017. epe-08 (work in progress), December 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10 data plane", draft-ietf-spring-segment-routing-mpls-11
(work in progress), June 2017. (work in progress), October 2017.
[I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-03 (work in
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-07 (work in progress), July 2017. yang-07 (work in progress), July 2017.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
skipping to change at page 28, line 10 skipping to change at page 29, line 39
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>. <https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
March 2012, <https://www.rfc-editor.org/info/rfc6549>. March 2012, <https://www.rfc-editor.org/info/rfc6549>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers",
BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
<https://www.rfc-editor.org/info/rfc8084>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
2017, <https://www.rfc-editor.org/info/rfc8202>. 2017, <https://www.rfc-editor.org/info/rfc8202>.
Authors' Addresses Authors' Addresses
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
 End of changes. 56 change blocks. 
150 lines changed or deleted 197 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/