RFC 8402
Segment Routing Architecture
Segment Routing Architecture 🎀
Okay bestie, this is RFC 8402 ✨ It's a Standards Track doc from the IETF (Internet Engineering Task Force) and it came out in July 2018. It's published under ISSN 2070-1721. The editors are C. Filsfils and S. Previdi, both marked (Ed.) for editor, and the rest of the author squad is L. Ginsberg (Cisco Systems, Inc.), B. Decraene and S. Litkowski (Orange), and R. Shakir (Google, Inc.) 🫶
The title block doesn't list anything that it obsoletes or updates, so this one isn't replacing or patching any older RFC. It's a brand new, official Standards Track spec 💜
Abstract
Segment Routing (SR) is built on the source routing paradigm 🌸 A node steers a packet through an ordered list of instructions called "segments". A segment can be any instruction, whether topological or service based. A segment can have a semantic that's local to an SR node or global within an SR domain. SR gives you a way to restrict a flow to one specific topological path while only keeping per-flow state at the ingress node(s) to the SR domain. Main character energy 👑
SR can be applied straight onto the MPLS architecture with no change to the forwarding plane 🦋 A segment is encoded as an MPLS label, and an ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Once a segment is complete, its related label gets popped off the stack. 🧚
SR can also be applied to the IPv6 architecture, using a new type of routing header 💅 A segment is encoded as an IPv6 address, and an ordered list of segments is encoded as an ordered list of IPv6 addresses inside that routing header. The active segment is shown by the Destination Address (DA) of the packet. The next active segment is shown by a pointer in the new routing header. It's giving organized 💖
Status of This Memo
This is an Internet Standards Track document. 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards is in Section 2 of RFC 7841 🍓
For the current status of this document, any errata, and how to send feedback on it, check https://www.rfc-editor.org/info/rfc8402.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date of this document. Please actually read these, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. ⚖️💀
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Link-State IGP Segments . . . . . . . . . . . . . . . . . . . 9
3.1. IGP-Prefix Segment (Prefix-SID) . . . . . . . . . . . . . 9
3.1.1. Prefix-SID Algorithm . . . . . . . . . . . . . . . . 9
3.1.2. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. IGP-Node Segment (Node-SID) . . . . . . . . . . . . . . . 13
3.3. IGP-Anycast Segment (Anycast-SID) . . . . . . . . . . . . 13
3.3.1. Anycast-SID in SR-MPLS . . . . . . . . . . . . . . . 13
3.4. IGP-Adjacency Segment (Adj-SID) . . . . . . . . . . . . . 15
3.4.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 17
3.4.2. LAN Adjacency Segments . . . . . . . . . . . . . . . 18
3.5. Inter-Area Considerations . . . . . . . . . . . . . . . . 18
4. BGP Segments . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. BGP-Prefix Segment . . . . . . . . . . . . . . . . . . . 19
4.2. BGP Peering Segments . . . . . . . . . . . . . . . . . . 20
5. Binding Segment . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. IGP Mirroring Context Segment . . . . . . . . . . . . . . 21
6. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8.1. SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.2. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.3. Congestion Control . . . . . . . . . . . . . . . . . . . 25
9. Manageability Considerations . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 321. Introduction ✨
Segment Routing (SR) is built on the source routing paradigm 💅 A node steers a packet through an SR Policy, which is instantiated as an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic that's local to an SR node or global within an SR domain. SR supports per-flow explicit routing while only keeping per-flow state at the ingress nodes to the SR domain. Obsessed 😭
A segment is often referred to by its Segment Identifier (SID). 🆔
A segment may be tied to a topological instruction. A topological local segment may tell a node to forward the packet out a specific outgoing interface 🦋 A topological global segment may tell an SR domain to forward the packet along a specific path to a destination. Different segments may exist for the same destination, each with its own path objectives (e.g., which metric is minimized, what constraints are specified). Choices, choices 🌸
A segment may also be tied to a service instruction (e.g., the packet should be processed by a container or Virtual Machine (VM) associated with the segment). A segment may be associated with a QoS treatment too (e.g., shape the packets received with this segment at x Mbps) 🎀
The SR architecture supports any type of instruction associated with a segment. Literally anything 🧚
The SR architecture supports any type of control plane: distributed, centralized, or hybrid. 👑
In a distributed scenario, the segments are allocated and signaled by IS-IS or OSPF or BGP. A node decides on its own to steer packets on an SR Policy (e.g., pre-computed local protection [RFC8355]). A node also computes the SR Policy on its own. Independent queen energy 💜
In a centralized scenario, the segments are allocated and instantiated by an SR controller. The SR controller decides which nodes need to steer which packets on which source-routed policies, and it computes those source-routed policies. The SR architecture does not restrict how the controller programs the network. Likely options are Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), and BGP. The SR architecture does not restrict the number of SR controllers either. Specifically, multiple SR controllers may program the same SR domain 🫶 The SR architecture lets these SR controllers discover which SIDs are instantiated at which nodes, and which sets of local (SRLB) and global (SRGB) labels are available at which node. Very organized, very iconic 🍓
A hybrid scenario adds a centralized controller on top of a base distributed control plane. For example, when the destination is outside the IGP domain, the SR controller may compute an SR Policy on behalf of an IGP node. The SR architecture does not restrict how the nodes that are part of the distributed control plane interact with the SR controller. Likely options are PCEP and BGP. 🌈
Hosts MAY be part of an SR domain. A centralized controller can tell hosts about policies, either by pushing those policies to hosts or by responding to requests from hosts. ✨
The SR architecture can be instantiated on various data planes. This document introduces two data-plane instantiations of SR: SR over MPLS (SR-MPLS) and SR over IPv6 (SRv6). Two flavours, both slay 💖
SR can be applied straight onto the MPLS architecture with no change to the forwarding plane [SR-MPLS] 🦋 A segment is encoded as an MPLS label, and an SR Policy is instantiated as a stack of labels. The segment to process (the active segment) sits on the top of the stack. Once a segment is complete, its related label gets popped off the stack. 🧚
SR can also be applied to the IPv6 architecture, using a new type of routing header called the SR Header (SRH) [IPv6-SRH] 💅 An instruction is associated with a segment and encoded as an IPv6 address. An SRv6 segment is also called an SRv6 SID. An SR Policy is instantiated as an ordered list of SRv6 SIDs in the routing header. The active segment is shown by the Destination Address (DA) of the packet. The next active segment is shown by the SegmentsLeft (SL) pointer in the SRH. When an SRv6 SID is completed, the SL gets decremented and the next segment is copied to the DA. When a packet is steered on an SR Policy, the related SRH gets added to the packet. Pointer energy 🌸
In the context of an IGP-based distributed control plane, two topological segments are defined: the IGP-Adjacency segment and the IGP-Prefix segment. 🍓
In the context of a BGP-based distributed control plane, two topological segments are defined: the BGP peering segment and the BGP-Prefix segment. 🌈
The headend of an SR Policy binds a SID (called a Binding segment or BSID) to its policy. When the headend receives a packet whose active segment matches the BSID of a local SR Policy, the headend steers the packet into the associated SR Policy. ⭐
This document defines the IGP, BGP, and Binding segments for the SR-MPLS and SRv6 data planes. 🎀
Note: This document defines the architecture for Segment Routing, including definitions of basic objects and functions and a description of the overall design. It does not define the means of implementing the architecture -- that is contained in numerous referenced documents, some of which are mentioned in this document as a convenience to the reader. 🙈
2. Terminology ✨
okay so bestie, before we dive into the juicy stuff we need to get the vocab locked in 💅 these are the words the whole spec is built on, so no skipping!!
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🎀 so those capital words are NOT just vibes, they carry real weight, and they only count when they're written in ALL CAPS, got it? 🙈
SR-MPLS: the instantiation of SR on the MPLS data plane. 🌸
SRv6: the instantiation of SR on the IPv6 data plane. 🦋
Segment: an instruction a node executes on the incoming packet (e.g., forward packet according to shortest path to destination, or, forward packet through a specific interface, or, deliver the packet to a given application/service instance). 💖 think of it like a little to-do item the packet carries for each router it meets!!
SID: a segment identifier. Note that the term SID is commonly used in place of the term "Segment", though this is technically imprecise as it overlooks any necessary translation. 🧚 everyone says SID when they mean segment, but technically that's a tiny bit sloppy, so just know the difference bestie 🤓
SR-MPLS SID: an MPLS label or an index value into an MPLS label space 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 the source-based routing model. These nodes may be connected to the same physical infrastructure (e.g., a Service Provider's network). They may as well be remotely connected to each other (e.g., an enterprise VPN or an overlay). If multiple protocol instances are deployed, the SR domain most commonly includes all of the protocol instances in a network. However, some deployments may wish to subdivide the network into multiple SR domains, each of which includes one or more protocol instances. It is expected that all nodes in an SR domain are managed by the same administrative entity. 👑 so basically the SR domain is the friend group that plays by the same source-routing rules, and it's usually run by one admin team. the squad can be physically together or spread out over VPNs and overlays, no cap 💅
Active Segment: the segment that is used by the receiving router to process the packet. In the MPLS data plane, it is the top label. In the IPv6 data plane, it is the destination address [IPv6-SRH]. 🦋 the active segment is the one the router is actually looking at right now, aka top label for MPLS or destination address for IPv6
PUSH: the operation consisting of the insertion of a segment at the 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 segment list is represented by the first segment in the Segment Routing Header as defined in [IPv6-SRH]. 🌸 PUSH means sticking a new segment on top of the list, periodt
NEXT: when the active segment is completed, NEXT is the operation consisting of the inspection of the next segment. The next segment becomes active. In SR-MPLS, NEXT is implemented as a POP of the top label. In SRv6, NEXT is implemented as the copy of the next segment from the SRH to the destination address of the IPv6 header. 💅 once the current segment is done, NEXT moves on to the next one and makes it the new active segment. it's giving "pass the baton" energy 🏃♀️
CONTINUE: the active segment is not completed; hence, it remains active. In SR-MPLS, the CONTINUE operation is implemented as a SWAP of the top label [RFC3031]. In SRv6, this is the plain IPv6 forwarding action of a regular IPv6 packet according to its destination address. 🧚 CONTINUE is the chill option: the segment isn't done yet, so it stays active and the packet just keeps going
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 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 SR-MPLS, using identical SRGBs on all nodes within the SR domain is strongly recommended. Doing so eases operations and troubleshooting 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. 🌈 the SRGB is the global pool of segments everyone in the domain agrees on. for MPLS, using identical SRGBs everywhere is strongly recommended, because then the same label means the same segment on every node, which makes troubleshooting way less of a headache 🙌
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 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 for local SRv6 SIDs. In a controller-driven network, some controllers or applications may use the control plane to discover the available set of local segments. 🍓 the SRLB is the node's own private stash of segments, and in controller-driven networks, some controllers or apps can use the control plane to find out what's in that stash 🕵️♀️
Global Segment: a segment that is part of the SRGB of the domain. The instruction associated with the segment is defined at the SR domain level. A topological shortest-path segment to a given destination within an SR domain is a typical example of a global segment. 🌸 global segments are the domain-wide vibes, and a shortest-path segment to some destination is the classic example
Local Segment: In SR-MPLS, this is a local label outside the SRGB. It may be part of the explicitly advertised SRLB. In SRv6, this can be any IPv6 address, i.e., the address may be part of the SRGB, but used such that it has local significance. The instruction associated with the segment is defined at the node level. 🦋 local segments are the node-only ones: for MPLS it's a label outside the SRGB, and for SRv6 it can be any IPv6 address, even one from the SRGB, as long as it only means something locally 💖
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 IGP adjacency. 🌈 IGP segment is the umbrella term for any segment hooked to something a link-state IGP advertises, like a prefix or an adjacency
IGP-Prefix Segment: an IGP-Prefix segment is an IGP segment representing an IGP prefix. When an IGP-Prefix segment is global within the SR IGP instance/topology, it identifies an instruction to forward the packet along the path computed using the routing algorithm specified in the algorithm field, in the topology, and in the IGP instance where it is advertised. Also referred to as "prefix segment". 👑 an IGP-Prefix segment is the IGP segment for a prefix, and when it's global it tells the packet to follow the path computed by the algorithm in the algorithm field. also called a "prefix segment" 💅
Prefix-SID: the SID of the IGP-Prefix segment. 🎀
IGP-Anycast Segment: an IGP-Anycast segment is an IGP-Prefix segment that identifies an anycast prefix advertised by a set of routers. 🌸 an anycast one is a prefix-segment flavour that points at an anycast prefix advertised by a whole group of routers
Anycast-SID: the SID of the IGP-Anycast segment. 🧚
IGP-Adjacency Segment: an IGP-Adjacency segment is an IGP segment attached to a unidirectional adjacency or a set of unidirectional adjacencies. By default, an IGP-Adjacency segment is local (unless explicitly advertised otherwise) to the node that advertises it. Also referred to as "Adj-SID". 💖 this one hooks onto a one-way adjacency (or a bunch of them), and it's local to the node advertising it by default, unless someone explicitly says otherwise. also called "Adj-SID" ✨
Adj-SID: the SID of the IGP-Adjacency segment. 🦋
IGP-Node Segment: an IGP-Node segment is an IGP-Prefix segment that identifies a specific router (e.g., a loopback). Also referred to as "Node Segment". 🌈 the node segment is the prefix-segment that points at one specific router, like its loopback 🫶
Node-SID: the SID of the IGP-Node segment. 💜
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 specified explicitly in SR-MPLS as a stack of labels and in SRv6 as an ordered list of SRv6 SIDs. Alternatively, the list of segments is computed based on a destination and a set of optimization objective and constraints (e.g., latency, affinity, SRLG, etc.). The computation can be local or delegated to a PCE server. An SR Policy can be configured by the operator, provisioned via NETCONF [RFC6241] or provisioned via PCEP [RFC5440]. An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons. 👑 an SR Policy is basically a to-do list of segments in order, and the headend is the one that steers packets onto it. the list can be spelled out by hand, or computed from a destination plus goals like latency or affinity, computed locally or handed off to a PCE server. operators can set it up themselves or use NETCONF or PCEP, and it can be for TE, OAM, or FRR. iconic behaviour 🔥
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 discover the depth-insertion capability of the node N. For example, the PCEP SR capability advertisement described in [PCEP-SR-EXT] is one means of discovering this capability. 🙈 segment list depth is just how many segments are in the policy, and whoever sets the policy up at node N should be able to find out how deep a stack node N can handle. the PCEP SR capability advertisement from [PCEP-SR-EXT] is one way to check that 💀
Forwarding Information Base (FIB): the forwarding table of a node 📋
3. Link-State IGP Segments 🌈
Within an SR domain, an SR-capable IGP node advertises segments for its attached prefixes and adjacencies. These segments are called "IGP segments" or "IGP SIDs". They play a key role in Segment Routing and use cases as they enable the expression of any path throughout the SR domain. Such a path is either expressed as a single IGP segment or a list of multiple IGP segments. 💅 so inside an SR domain, every SR-capable IGP node announces segments for its prefixes and adjacencies. these are the IGP segments (aka IGP SIDs), and they're the reason you can express basically any path across the domain, either as one segment or a whole list of them 🦋
Advertisement of IGP segments requires extensions in link-state IGP protocols. These extensions are defined in [ISIS-SR-EXT], [OSPF-SR-EXT], and [OSPFv3-SR-EXT]. 🧚 announcing IGP segments needs extensions to the link-state IGP protocols, and those are defined in [ISIS-SR-EXT], [OSPF-SR-EXT], and [OSPFv3-SR-EXT] 📚
3.1. IGP-Prefix Segment (Prefix-SID)
An IGP-Prefix segment is an IGP segment attached to an IGP prefix. An IGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain. The context for an IGP-Prefix segment includes the prefix, topology, and algorithm. Multiple SIDs MAY be allocated to the same prefix so long as the tuple <prefix, topology, algorithm> is unique. 🌸 an IGP-Prefix segment hooks onto an IGP prefix and is global by default across the SR domain. its context is the prefix, topology, and algorithm, and you're allowed (MAY, bestie, it's optional) to hand out multiple SIDs to the same prefix as long as that <prefix, topology, algorithm> tuple stays unique 💖
Multiple instances and topologies are defined in IS-IS and OSPF in: [RFC5120], [RFC8202], [RFC6549], and [RFC4915]. 🎀 the multi-instance and multi-topology stuff for IS-IS and OSPF lives in those four RFCs
3.1.1. Prefix-SID Algorithm ✨
Segment Routing supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. An algorithm identifier is included as part of a Prefix-SID advertisement. Specification of how an algorithm-specific path calculation is done is REQUIRED in the document defining the algorithm. 🌈 SR supports multiple routing algorithms, so you can have different constraint-based shortest-path calculations. the algorithm identifier rides along in the Prefix-SID advertisement, and the document that defines an algorithm REQUIRED to spell out how its path calculation works 🧠
This document defines two algorithms: 💜
- Shortest Path First: this algorithm is the default behavior. The packet is forwarded along the well known ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. However, it is explicitly allowed for a midpoint to implement another forwarding based on local policy. The Shortest Path First algorithm is, in fact, the default and current behavior of most of the networks where local policies may override the SPF decision. 🦋 SPF is the default vibe: packets follow the well-known ECMP-aware SPF that IGPs use. midpoints are explicitly allowed to do their own local-policy forwarding instead, and honestly that's how most networks run today 🌸
- Strict Shortest Path First (Strict-SPF): This algorithm mandates that the packet be forwarded according to the ECMP-aware SPF algorithm and instructs any router in the path to ignore any possible local policy overriding the SPF decision. The SID advertised with the Strict-SPF algorithm ensures that the path the packet is going to take is the expected, and not altered, SPF path. Note that Fast Reroute (FRR) [RFC5714] mechanisms are still compliant with the Strict Shortest Path First algorithm. In other words, a packet received with a Strict-SPF SID may be rerouted through an FRR mechanism. Strict-SPF uses the same topology used by the Shortest Path First algorithm. Obviously, nodes that do not support Strict-SPF will not install forwarding entries for this algorithm. Restricting the topology only to those nodes that support this algorithm will not produce the desired forwarding paths since the desired behavior is to follow the path calculated by the Shortest Path First algorithm. Therefore, a source SR node MUST NOT use an SR Policy containing a strict SPF segment if the path crosses a node not supporting the Strict-SPF algorithm. 🔥 Strict-SPF is the no-drama version: it MUST follow the ECMP-aware SPF path and tells every router on the way to ignore local policies that would override it. FRR is still totally allowed with it, so a Strict-SPF packet can get rerouted by FRR, no cap. nodes that don't support Strict-SPF just won't install entries for it, and you can't fix that by pruning the topology, because the goal is still the normal SPF path. and the big rule: a source SR node MUST NOT use an SR Policy with a strict SPF segment if the path crosses a node that doesn't support Strict-SPF 🙅♀️💀
An IGP-Prefix segment identifies the path, to the related prefix, computed as per the associated algorithm. A packet injected anywhere within the SR domain with an active Prefix-SID is expected to be forwarded along a path computed using the specified algorithm. For this to be possible, a fully connected topology of routers supporting the specified algorithm is REQUIRED. 🫶 so an IGP-Prefix segment points to the path toward its prefix, computed with its algorithm. a packet injected anywhere in the domain with an active Prefix-SID is expected to follow that algorithm's path, and for that to actually work, you NEED a fully connected topology of routers that all support the algorithm 💖
3.1.2. SR-MPLS ✨
okay so when SR is running over the MPLS data plane, a SID is either an MPLS label or an index into an MPLS label space (either the SRGB or the SRLB) 🦋
Where it's possible, it is recommended that identical SRGBs be configured on all nodes in an SR domain 🎀 bestie, this is lowkey the best move because the same label will point at the same prefix on every node, which makes troubleshooting so much easier 💅 It also makes anycast support simpler, as detailed in Section 3.3 🫶
The following behaviors are associated with SR operating over the MPLS data plane:
- The IGP signaling extension for the IGP-Prefix segment includes a flag that tells the directly connected neighbors of the node where the prefix is attached whether they should perform the NEXT operation or the CONTINUE operation when they process the SID 🌸 This is basically the same idea as Penultimate Hop Popping (NEXT) or Ultimate Hop Popping (CONTINUE) in MPLS, so it's giving familiar vibes 🧚
- A Prefix-SID gets allocated as an MPLS label (or an index in the SRGB), kinda like how IP addresses get handed out 🌈 Usually the operator (or Network Management System (NMS)) allocates it by policy, and the SID very rarely changes 💜
- SR does allow a local segment to be attached to an IGP prefix, where the terms "IGP-Prefix segment" or "Prefix-SID" are used, but the segment is assumed to be global (so the SID is defined from the advertised SRGB) 🍓 This matches all the described use cases that need global segments attached to IGP prefixes, so it's consistent, periodt 💖
- The allocation process MUST NOT allocate the same Prefix-SID to different prefixes. This one is non-negotiable, bestie 🙈
- If a node learns of a Prefix-SID whose value falls outside its locally configured SRGB range, then the node MUST NOT use that Prefix-SID, and it SHOULD issue an error log reporting a misconfiguration 😭 Not the vibe.
- If a node N advertises Prefix-SID SID-R for a prefix R that is attached to N and specifies CONTINUE as the operation to be performed by directly connected neighbors, then N MUST maintain the following FIB entry:
Incoming Active Segment: SID-R
Ingress Operation: NEXT
Egress interface: NULL- A remote node M MUST maintain the following FIB entry for any learned Prefix-SID SID-R attached to prefix R:
Incoming Active Segment: SID-R
Ingress Operation:
If the next-hop of R is the originator of R
and M has been instructed to remove the active segment: NEXT
Else: CONTINUE
Egress interface: the interface(s) towards the next-hop along the
path computed using the algorithm advertised with
the SID toward prefix R.Prefix-SIDs are specific to a given algorithm, so if traffic tied to an algorithm shows up at a node that doesn't support that algorithm, the traffic gets dropped 💀 There won't be any forwarding entry matching the incoming label, so it's over for that packet, no cap.
3.1.3. SRv6 💜
When SR is used over the IPv6 data plane:
- A Prefix-SID is an IPv6 address 🧚
- An operator MUST explicitly instantiate an SRv6 SID. IPv6 node addresses are not SRv6 SIDs by default, so don't assume they are, bestie 🙈
A node N advertising an IPv6 address R that is usable as a segment identifier MUST maintain the following FIB entry:
Incoming Active Segment: R
Ingress Operation: NEXT
Egress interface: NULLNote 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 that covers R 🦋
Independent of SR support, any remote IPv6 node will maintain a plain IPv6 FIB entry for any prefix, no matter whether the prefix represents a segment or not. This lets packets reach the node that owns the SID, even from nodes that don't support SR at all 🫶
Support of multiple algorithms applies to SRv6 too 🌈 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 that a node allocates. It's giving clean design, honestly ✨
Nodes that do not support a given algorithm may still have a FIB entry covering an algorithm-specific address, even though that node hasn't calculated an algorithm-specific path. This is mitigated by the fact that nodes that don't support a given algorithm won't be included in the topology associated with that algorithm-specific SPF, so traffic using the algorithm-specific destination will normally not flow via the excluded node 🍓 If such traffic does arrive and gets forwarded by such a node, it will still progress towards the destination node. The next-hop will be either a node that supports the algorithm (in which case the packet gets forwarded along algorithm-specific paths, or dropped if none are available), or a node that does NOT support the algorithm (in which case the packet keeps being forwarded along Algorithm 0 paths towards the destination node) 👑
3.2. IGP-Node Segment (Node-SID) 🎀
An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain. No sharing the Node-SID, bestie 🙈
3.3. IGP-Anycast Segment (Anycast-SID) 🦋
An Anycast segment or Anycast-SID enforces ECMP-aware shortest-path forwarding towards the closest node of the anycast set. This is super useful for expressing macro-engineering policies or protection mechanisms 💅
An IGP-Anycast segment MUST NOT reference a particular node. It's all about the group, not one specific router 🫶
Within an anycast group, all routers in an SR domain MUST advertise the same prefix with the same SID value. Consistency is everything, periodt 💖
3.3.1. Anycast-SID in SR-MPLS ✨
+--------------+
| Group A |
|192.0.2.10/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
203.0.113.1/32 | | | / \ | | | 203.0.113.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3---------R4------PE4
203.0.113.2/32 | | | \ / | | | 203.0.113.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----------B2---B4----------+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
Figure 1: Transit Device GroupsThe Figure 1 illustrates 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.2.10/32 and the Anycast-SID 100.
Similarly, Group B consists of devices {B1, B2, B3, and B4}, and they are all provisioned with the anycast address 192.0.2.1/32 and the Anycast-SID 200. In the above network topology, each Provide Edge (PE) device has a path to each of the groups: A and B 🧚
PE1 can choose a particular transit device group when sending traffic to PE3 or PE4. This is done by pushing the Anycast-SID of the group onto the stack 🌈
Processing the anycast segment, and the subsequent segments, requires special care 👀
+-------------------------+
| Group A |
| 192.0.2.10/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)|
| |
+-------------------------+
Figure 2: Transit Paths via Anycast Group AConsidering an MPLS deployment, in the above topology, if device PE1 (or PE2) needs to send a packet to device PE3 (or PE4), it needs to encapsulate the packet in an MPLS payload with the following stack of labels 🎀
- Label allocated by R1 for Anycast-SID 100 (outer label).
- Label allocated by the nearest router in Group A for SID 30 (for destination PE3).
In this case, the first label is easy to compute. However, because there is more than one device that is topologically nearest (A1 and A2), determining the second label is impossible unless A1 and A2 allocated the same label value to the same prefix 😭 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. The same holds true for devices PE3 and PE4 when trying to send a packet to PE1 or PE2 💀
To ease the use of an anycast segment, it is recommended to configure identical SRGBs on all nodes of a particular anycast group. Using this method, as mentioned above, computing the label following the anycast segment is straightforward 🦋
Using an anycast segment without configuring identical SRGBs on all nodes belonging to the same anycast group may lead to misrouting (in an MPLS VPN deployment, some traffic may leak between VPNs). Not a vibe, bestie 🙅♀️
3.4. IGP-Adjacency Segment (Adj-SID) ✨
okay so the adjacency is formed by the local node (the one advertising the adjacency in the IGP) and the remote node (the other end of it) 💅 the local node MUST be an IGP node, no exceptions bestie 🫶 the remote node can be an adjacent IGP neighbor OR a non-adjacent one, like a forwarding adjacency ([RFC4206]) 🦋
so picture this: a packet gets dropped anywhere inside the SR domain with a segment list {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID that node N attached to its adjacency over link L 🧚 it zooms along the shortest path to N, and then N just switches it out towards link L, totally ignoring IP shortest-path stuff. no cap, it's giving main character energy 👑 and if the Adj-SID stands for a set of adjacencies, N load-balances across the members of that set 🌈
same vibe with a global Adj-SID 🌸 a packet with a segment list {SNL}, where SNL is a global Adj-SID node N attached to its adjacency over link L, gets forwarded along the shortest path to N and then switched by N towards link L, again with no IP shortest-path consideration 💖 and if the Adj-SID covers a set of adjacencies, N does load-balance the traffic among the members of the set ✨ the perk is that a global Adj-SID lets you shrink the segment list when you're expressing a path 🎀 the tradeoff? extra state, because every router in the area has to stick the global Adj-SID in its forwarding table 💀
an "IGP-Adjacency segment" (or "Adj-SID") forces the packet to switch from a node towards a defined interface or set of interfaces 🔥 this is the key to proving that any path can be written as a list of segments, which is so iconic 😭
the Adj-SID encodings come with a set of flags for these vibes:
- Eligible for Protection (e.g., using IPFRR or MPLS-FRR) 🛡️ if the interface(s) tied to the Adj-SID go down, the packet can still get forwarded via an alternate path 💜 whether you want protection is a policy call, so it might or might not be desirable depending on the policy 🙈
- Indication of local or global scope 🌍 default scope SHOULD be local 🍓
- Indication of whether the Adj-SID persists across control plane restarts 🧊 persistence is a huge deal because it keeps an SR Policy from briefly misforwarding just because an Adj-SID got reassigned 😭
a weight (more on this below) is also attached to the Adj-SID advertisement ⭐
a node SHOULD allocate one Adj-SID for each of its adjacencies 🫶
a node MAY allocate multiple Adj-SIDs for the same adjacency 🌷 for example, one Adj-SID that IS eligible for protection and another that is NOT eligible for protection 🦋
a node MAY associate the same Adj-SID with multiple adjacencies 🧚
to advertise every Adj-SID representing the IGP adjacencies between two nodes in the IGP, parallel adjacency suppression MUST NOT be performed by the IGP 💅
when a node binds an Adj-SID V to a local data-link L, the node MUST install this FIB entry 🍒
Incoming Active Segment: V
Ingress Operation: NEXT
Egress Interface: Lbasically the Adj-SID means the router advertising it forwards the packet through the adjacency or adjacencies the Adj-SID identifies, regardless of IGP/SPF cost 💖 so adjacency segments override the routing decision the SPF algorithm made 👑 periodt 💅
3.4.1. Parallel Adjacencies 🎀
Adj-SIDs can represent a set of parallel interfaces between two adjacent routers 🌈
a node MUST install a FIB entry for any locally originated Adj-SID of value W attached to a set of links B, like this 🫶
Incoming Active Segment: W
Ingress Operation: NEXT
Egress interfaces: load-balance between any data-link within set Bwhen parallel adjacencies share the same Adj-SID, a "weight" factor can be attached to the Adj-SID advertised with each adjacency so the load-balancing gets optimized ✨ the weight tells the ingress (or an SDN/orchestration system) what the load-balancing factor is across the parallel adjacencies 🦋 check out Figure 3, where A and B are connected through two parallel adjacencies 👀
Link-1
+--------+
| |
S---A B---C
| |
+--------+
Link-2
Figure 3: Parallel Links and Adj-SIDsnode A advertises the following Adj-SIDs and weights 📣
- Link-1: Adj-SID 1000, weight: 1
- Link-2: Adj-SID 1000, weight: 2
node S gets the advertisements for the parallel adjacencies and figures out that by using Adj-SID 1000, node A load-balances across the parallel links (Link-1 and Link-2) in a 1:2 ratio 🧁 so twice as many packets flow over Link-2 as over Link-1 🌸
3.4.2. LAN Adjacency Segments 🏠
in LAN subnetworks, link-state protocols define a Designated Router (DR, in OSPF) or a Designated Intermediate System (DIS, in IS-IS) 👑 these do the flooding in broadcast subnetworks and describe the LAN topology in a special routing update (an OSPF Type2 LSA or an IS-IS Pseudonode LSP) 📜
the tricky part with LANs 😤 each router only advertises its connectivity to the DR/DIS, not to every individual node on the LAN 💀 so extra protocol mechanisms (IS-IS and OSPF) are needed so that each router on the LAN can advertise an Adj-SID for each neighbor on the LAN 🫶
3.5. Inter-Area Considerations 🗺️
in the example diagram below, it's assumed that all the areas are part of a single SR domain 💜
Figure 4 assumes the IPv6 control plane with the MPLS data plane 🌈
! !
! !
B------C-----F----G-----K
/ | | |
S---A/ | | |
\ | | |
\D------I----------J-----L----Z (2001:DB8::2:1/128, Node-SID 150)
! !
Area 1 ! Backbone ! Area 2
! area !
Figure 4: Inter-Area Topology Examplein Area 2, node Z allocates Node-SID 150 to its local IPv6 prefix 2001:DB8::2:1/128 🧚
Area Border Routers (ABRs) G and J propagate the prefix and its SIDs into the backbone area by creating a new instance of the prefix, following the normal inter-area/level IGP propagation rules 🦋
nodes C and I apply the same behavior when leaking prefixes from the backbone area down to area 1 🌷 so node S sees prefix 2001:DB8::2:1/128 with Prefix-SID 150, advertised by nodes C and I 👀
so the result is that a Prefix-SID stays attached to its 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-SID(150) as an active segment and forwards it to A 🚀
when a packet arrives at ABR I (or C), the ABR forwards it according to the active segment (Node-SID(150)) 🫶 forwarding keeps going across area borders using that same Node-SID(150) until the packet reaches its destination 🎯
4. BGP Segments 🌐
BGP segments may be allocated and distributed by BGP 💅
4.1. BGP-Prefix Segment 🎀
a BGP-Prefix segment is a BGP segment attached to a BGP prefix 💜
a BGP-Prefix segment is global (unless explicitly advertised otherwise) within the SR domain 🌍
the BGP-Prefix segment is the BGP equivalent of the IGP-Prefix segment 🦋
a likely use case for the BGP-Prefix segment is an IGP-free hyper-scale spine-leaf topology where connectivity is learned solely via BGP [RFC7938] 🍓
4.2. BGP Peering Segments 🤝
in the context of BGP Egress Peer Engineering (EPE), as described in [SR-CENTRAL-EPE], an EPE-enabled egress node MAY advertise segments for its attached peers 📡 these are called BGP peering segments or BGP peering SIDs, and they let you express source-routed inter-domain paths 🗺️
an ingress border router of an Autonomous System (AS) may compose a list of segments to steer a flow along a chosen path within the AS toward a selected egress border router C of the AS, and through a specific peer 🎯 at a minimum, a BGP peering engineering policy applied at an ingress node involves two segments: the Node-SID of the chosen egress node and the BGP peering segment for the chosen egress node peer or peering interface 🫶
three types of BGP peering segments/SIDs are defined: PeerNode SID, PeerAdj SID, and PeerSet SID 🎀
- PeerNode SID 💖: a BGP PeerNode segment/SID is a local segment. At the BGP node advertising it, its semantics are:
- SR operation: NEXT.
- Next-Hop: the connected peering node the segment is related to.
- PeerAdj SID 🧚: a BGP PeerAdj segment/SID is a local segment. At the BGP node advertising it, the semantics are:
- SR operation: NEXT.
- Next-Hop: the peer connected through the interface the segment is related to.
- PeerSet SID 🌈: a BGP PeerSet segment/SID is a local segment. At the BGP node advertising it, the semantics are:
- SR operation: NEXT.
- Next-Hop: load-balance across any connected interface to any peer in the related group.
a peer set could be all the connected peers from the same AS or a subset of them 🌸 a group could also span across ASes 🌍 the group definition is a policy set by the operator 💅
the BGP extensions needed to signal these BGP peering segments are defined in [BGPLS-SR-EPE] 📣
5. Binding Segment 🔗
to get greater scalability, network opacity, and service independence, SR uses a Binding SID (BSID) ✨ the BSID is bound to an SR Policy, whose instantiation may involve a list of SIDs 📜 any packets received with an active segment equal to the BSID get steered onto the bound SR Policy 🎯
a BSID may be either local or global 🌍 if it's local, a BSID SHOULD be allocated from the SRLB 🍓 if it's global, a BSID MUST be allocated from the SRGB 🔥
using a BSID means the instantiation of the policy (the SID list) only has to be stored on the node or nodes that need to impose the policy 🧁 directing traffic to a node that supports the policy then just requires imposing the BSID 💖 if the policy changes, only the nodes imposing it need updating, and users of the policy aren't impacted 🫶 literally so clean 💅
5.1. IGP Mirroring Context Segment ✨
okay so one big use case for a Binding segment is letting an IGP node say "hey, I can handle traffic that was originally meant for someone else" 🪞. That someone else is the "mirrored node," and it's identified by an IP address or a Node-SID. The catch is that a Mirroring Context segment has to go into the segment list before any service segment that's local to the mirrored node 💅.
So when node B wants to protect egress node A 🛡️, it advertises a segment that identifies node A's context. That segment is the "Mirroring Context segment," and its identifier is the Mirror SID 🦋.
The Mirror SID gets advertised using the Binding segment from the SR IGP protocol extensions [ISIS-SR-EXT] 📣.
If something fails 💥, a Point of Local Repair (PLR) that's diverting traffic from A over to B does a PUSH of the Mirror SID onto the protected traffic. Then, when B gets traffic with the Mirror SID as the active segment, B uses that segment and processes the underlying segments in the context of A 👑.
6. Multicast 🌊
Segment Routing is all about unicast, bestie 💜. Using the source-route idea for Multicast is out of scope for this document, so we're not touching it here 🙅.
7. IANA Considerations 📋
This document has zero IANA actions, so there's nothing to register here 🧾.
8. Security Considerations 🔐
SR works with both MPLS and IPv6 data planes 🌐.
okay so SR tacks metadata (instructions) onto the packet 📝. That's basically a list of the forwarding path elements (nodes, links, services, etc.) the packet has to go through ✨. Also, the whole source-routed path can be squished into a single segment, and that's exactly what a Binding SID does 🎀.
By default, SR lives inside a trusted domain 🏰. Traffic MUST be filtered at the domain boundaries 🚧.
Using best practices to lower the risk of tampering inside the trusted domain is super important 😤. Those practices are covered in [RFC4381], and they apply to both SR-MPLS and SRv6 💖.
8.1. SR-MPLS 🏷️
On the MPLS data plane, SR doesn't add any new behavior or change how MPLS already works 🙌. So from a security point of view, this document doesn't define any extra mechanism for the MPLS data plane.
SR lets you write a source-routed path as one single segment (the Binding SID) 🎯. Compared to RSVP-TE, which also gives you explicit routing, there's no fundamental difference in the info it provides. And yes, both RSVP-TE and SR can express a source-routed path with a single segment 🤝.
When a path is written with a single label, the metadata syntax is the same for RSVP-TE [RFC3209] and SR 🫶.
When the path is a list of segments, extra metadata gets added to the packet 📦. That metadata is the source-routed path the packet must follow, written as a segment list.
With a label stack 🥞, if you know what the labels mean (i.e., the Forwarding Equivalence Class), you know the explicit path. Since the MPLS data plane doesn't need any modification, the capability doesn't fundamentally change 🙃. Still, label stacking is going to happen way more often.
Boundary routers of an SR domain MUST filter any external traffic aimed at a label tied to a segment inside the trusted domain 🚫. That covers labels in the trusted domain's SRGB, labels in that boundary router's SRLB, and labels outside both of those blocks. "External" traffic just means anything arriving on an interface connected to a node outside the domain of trust 👀.
From a network protection standpoint, there's an assumed trust model: any node that imposes a label stack on a packet is assumed to be allowed to do so 🤷♀️. This is a big change compared to plain IP doing shortest path routing, but it isn't fundamentally different from existing explicit routing techniques like RSVP-TE. By default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain 🙊. SR extensions defined in various protocols lean on those protocols' security mechanisms, like encryption, authentication, filtering, etc. 🔒
In the general case, an SR-capable router only accepts and installs labels if they were previously advertised by a trusted source 🫡. The received info gets validated using existing control-plane protocols that provide authentication and security mechanisms. SR doesn't define any extra security mechanism in those control-plane protocols.
SR doesn't introduce signaling between the source and the midpoints of a source-routed path 🙅♀️. With SR, the source-routed path is computed using SIDs that were previously advertised in the IP control plane. So, on top of filtering and controlled advertisement of SIDs at the SR domain boundaries, filtering in the data plane is also required. Filtering MUST be performed on the forwarding plane at the boundaries of the SR domain, and it may require looking at multiple labels/instructions 🔍.
For the MPLS data plane, there are no new requirements, because the existing MPLS architecture already allows this kind of source routing by stacking multiple labels 🧚. And for security protection, [RFC4381] and [RFC5920] already call for filtering MPLS packets on trust boundaries 🏁.
8.2. SRv6 🌟
On the IPv6 data plane, Segment Routing does introduce the Segment Routing Header (SRH, [IPv6-SRH]), which is a type of Routing Extension header as defined in [RFC8200] 💫.
The SRH adds metadata to the IPv6 packet 📜. That's the list of forwarding path elements (nodes, links, services, etc.) the packet has to traverse, and they're represented by IPv6 addresses. A complete source-routed path can be encoded in the packet as a single segment (one 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 anything received from an interface connected to a node outside the domain of trust.
From a network-protection standpoint, there's an assumed trust model: any node adding an SRH to the packet is assumed to be allowed to do so 🫣. So, by default, the explicit routing information MUST NOT be leaked through the boundaries of the administered domain 🙈. Again, SR extensions in various protocols use those protocols' security mechanisms, like encryption, authentication, filtering, etc.
In the general case, an SRv6 router accepts and installs segment identifiers (in the form of IPv6 addresses), but only if those SIDs come from a trusted source 🔐. The received info gets validated using existing control-plane protocols that provide authentication and security mechanisms. Segment Routing doesn't define any extra security mechanism in those existing control-plane protocols.
Things can go sideways when those behaviors aren't implemented, or when the assumed trust model gets broken (e.g., through a security breach) 😱. The problems include:
- Malicious looping
- Evasion of access controls
- Hiding the source of DoS attacks
Security concerns with SR on the IPv6 data plane are discussed more fully in [RFC5095] 📖. The new IPv6-based Segment Routing Header is defined in [IPv6-SRH], and this document also discusses the security concerns above 💅.
8.3. Congestion Control 🚦
SR doesn't 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 that identifies the SR Policy 📊. Other solutions, such as the ones presented in [RFC8084], may be applicable too.
9. Manageability Considerations 🛠️
In SR-enabled networks, the path the packet takes is encoded in the header 📦. Since the path isn't signaled through a protocol, OAM mechanisms are needed so the network operator can validate that a path works and check and monitor its liveness and performance 🔎. The good news is that SR cuts the number of states in transit nodes way down 📉, so a transit node has fewer elements to manage.
SR OAM use cases for the MPLS data plane are defined in [RFC8403], and SR OAM procedures for the MPLS data plane are defined in [RFC8287] 🧰.
SR routers receive advertisements of SIDs (index, label, or IPv6 address) from the different routing protocols being extended for SR 📡. Each of those protocols has monitoring and troubleshooting mechanisms for its IP addresses, and those mechanisms need to be extended to cover troubleshooting and monitoring of the SID too 🕵️♀️.
SR architecture introduces global segments 🌍. Each global segment MUST be bound to a unique index or address within an SR domain. How the operator allocates those indexes or addresses is critical for network behavior, since mistakes can lead to things like misrouting 😬. On top of whatever allocation policy and tooling the operator has in place, an implementation SHOULD protect the network when a conflict is detected by providing a deterministic resolution approach 🛡️.
When a path is expressed using a label stack, label stacking will increase 📚. A node may want to signal its ability (in terms of the size of the label stack it can support) in the control plane 📶.
A YANG data model [RFC6020] for SR configuration and operations has been defined in [SR-YANG] 🪄.
When SR is applied to the IPv6 data plane, segments are identified through IPv6 addresses 🌈. Allocating, managing, and troubleshooting segment identifiers is no different from the existing mechanisms used for IPv6 addresses 💜.
The DA of the packet gives the active segment address 🎯. The segment list in the SRH gives the entire path of the packet 🗺️. Validating the source-routed path is done by inspecting the DA and the SRH in the packet header and matching them to the equivalent routing table entries 🔍.
In the context of the SRv6 data plane, the source-routed path is encoded in the SRH as described in [IPv6-SRH] 💖. The SRv6 source-routed path is put into the SRH as a list of IPv6 addresses, with the active segment in the DA field of the IPv6 packet header. Typically, by inspecting the packet header at any node, you can work out which source-routed path it belongs to 🧭. Similar to SR-MPLS, an implementation may originate path control and monitoring packets, where the source-routed path goes into the SRH and each segment of the path puts the relevant data in the packet so the end-to-end path and performance can be measured 📏✨.
10. References 📚
10.1. Normative References 📚
okay bestie, these are the must-reads 🫶 you can't really get through this RFC without them, so keep them in your back pocket.
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC3031]Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001,<https://www.rfc-editor.org/info/rfc3031>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.[RFC8200]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,<https://www.rfc-editor.org/info/rfc8200>.
10.2. Informative References 🦋
these ones are the extra-credit reading 🤓 not required, but SO worth a look if you want the full picture.
[BGPLS-SR-EPE]Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Dong, "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering", Work in Progress, draft-ietf-idr-bgpls-segment-routing-epe-15, March 2018.[IPv6-SRH]Filsfils, C., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, Ed., "IPv6 Segment Routing Header (SRH)", Work in Progress, draft-ietf-6man-segment-routing-header-14, June 2018.[ISIS-SR-EXT]Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Extensions for Segment Routing", Work in Progress, draft-ietf-isis-segment-routing-extensions-19, July 2018.[OSPF-SR-EXT]Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-segment-routing-extensions-25, April 2018.[OSPFv3-SR-EXT]Psenak, P., Ed., Filsfils, C., Previdi, S., Ed., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Segment Routing", Work in Progress, draft-ietf-ospf-ospfv3-segment-routing-extensions-13, May 2018.[PCEP-SR-EXT]Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", Work in Progress, draft-ietf-pce-segment-routing-12, June 2018.[RFC3209]Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,<https://www.rfc-editor.org/info/rfc3209>.[RFC4206]Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005,<https://www.rfc-editor.org/info/rfc4206>.[RFC4381]Behringer, M., "Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4381, DOI 10.17487/RFC4381, February 2006,<https://www.rfc-editor.org/info/rfc4381>.[RFC4915]Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007,<https://www.rfc-editor.org/info/rfc4915>.[RFC5095]Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007,<https://www.rfc-editor.org/info/rfc5095>.[RFC5120]Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008,<https://www.rfc-editor.org/info/rfc5120>.[RFC5440]Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009,<https://www.rfc-editor.org/info/rfc5440>.[RFC5714]Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010,<https://www.rfc-editor.org/info/rfc5714>.[RFC5920]Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,<https://www.rfc-editor.org/info/rfc5920>.[RFC6020]Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010,<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-Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012,<https://www.rfc-editor.org/info/rfc6549>.[RFC7938]Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016,<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 Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017,<https://www.rfc-editor.org/info/rfc8202>.[RFC8287]Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,<https://www.rfc-editor.org/info/rfc8287>.[RFC8355]Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018,<https://www.rfc-editor.org/info/rfc8355>.[RFC8403]Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018,<http://www.rfc-editor.org/info/rfc8403>.[SR-CENTRAL-EPE]Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", Work in Progress, draft-ietf-spring-segment-routing-central-epe-10, December 2017.[SR-MPLS]Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with MPLS data plane", Work in Progress, draft-ietf-spring-segment-routing-mpls-14, June 2018.[SR-YANG]Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Data Model for Segment Routing", Work in Progress, draft-ietf-spring-sr-yang-09, June 2018.
Acknowledgements 💜
huge thank-yous 🙏 to Dave Ward, Peter Psenak, Dan Frost, Stewart Bryant, Pierre Francois, Thomas Telkamp, Ruediger Geib, Hannes Gredler, Pushpasis Sarkar, Eric Rosen, Chris Bowers, and Alvaro Retana for reviewing this document and sharing their comments. you all are literal legends 🌈
Contributors 🎀
these people really put the work in ✨ they substantially contributed to the Segment Routing architecture and to editing this document:
Ahmed Bashandy
Cisco Systems, Inc.
Email: bashandy@cisco.com
Martin Horneffer
Deutsche Telekom
Email: Martin.Horneffer@telekom.de
Wim Henderickx
Nokia
Email: wim.henderickx@nokia.com
Jeff Tantsura
Email: jefftant@gmail.com
Edward Crabbe
Email: edward.crabbe@gmail.com
Igor Milojevic
Email: milojevicigor@gmail.com
Saku Ytti
TDC
Email: saku@ytti.fiAuthors' Addresses 🦋
and finally, the editors and authors, so you know who to ping 💅
Clarence Filsfils (editor)
Cisco Systems, Inc.
Brussels
Belgium
Email: cfilsfil@cisco.com
Stefano Previdi (editor)
Cisco Systems, Inc.
Italy
Email: stefano@previdi.net
Les Ginsberg
Cisco Systems, Inc.
Email: ginsberg@cisco.com
Bruno Decraene
Orange
FR
Email: bruno.decraene@orange.com
Stephane Litkowski
Orange
France
Email: stephane.litkowski@orange.com
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: robjs@google.com📦 where this page comes from
- ietf: rfc8402 2018-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms