IPv6 Support for Segment Routing: SRv6+Juniper NetworksHerndon20171VirginiaUSArbonica@juniper.netNTT Communications Corporation3-4-1 Shibaura, Minato-kuTokyo108-8118Japan: y.kamite@ntt.comLiquid TelecomNairobiKenyaAndrew.Alston@liquidtelecom.comLiquid TelecomJohannesburgSouth Africadaniam.henriques@liquidtelecom.comEricssonP. O. Box 6049LeesburgVirginia20178USAjoel.halpern@ericsson.comGoogleMountain ViewCalifornia94043USAfurry@google.com
Routing Area
SPRING Working GroupSegment RoutingIPv6This document describes SRv6+. SRv6+ is a Segment Routing (SR)
solution that leverages IPv6. It supports a wide variety of use-cases
while remaining in strict compliance with IPv6 specifications. SRv6+ is
optimized for for ASIC-based forwarding devices that operate at high
data rates.Network operators deploy Segment Routing (SR)
so that they can forward packets through SR paths. An SR path
provides unidirectional connectivity from its ingress node to its egress
node. While an SR path can follow the least cost path from ingress to
egress, it can also follow any other path.An SR path contains one or more segments. A segment provides
unidirectional connectivity from its ingress node to its egress node. It
includes a topological instruction that controls its behavior.The topological instruction is executed on the segment ingress node.
It determines the segment egress node and the method by which the
segment ingress node forwards packets to the segment egress node.Per-segment service instructions can augment a segment. Per-segment
service instructions, if present, are executed on the segment egress
node.Likewise, a per-path service instruction can augment a path. The
per-path service instruction, if present, is executed on the path egress
node. of this document illustrates
the relationship between SR paths, segments and instructions.A Segment Identifier (SID) identifies each segment. Because there is
a one-to-one mapping between segments and the topological instructions
that control them, the SID that identifies a segment also identifies the
topological instruction that controls it.A SID is different from the topological instruction that it
identifies. While a SID identifies a topological instruction, it does
not contain the topological instruction that it identifies. Therefore, a
SID can be encoded in relatively few bits, while the topological
instruction that it identifies may require many more bits for
encoding.An SR path can be represented by its ingress node as an ordered
sequence of SIDs. In order to forward a packet through an SR path, the
SR ingress node encodes the SR path into the packet as an ordered
sequence of SIDs. It can also augment the packet with service
instructions.Because the SR ingress node is also the first segment ingress node,
it executes the topological instruction associated with the first
segment. This causes the packet to be forwarded to the first segment
egress node. When the first segment egress node receives the packet, it
executes any per-segment service instructions that augment the first
segment.If the SR path contains exactly one segment, the first segment egress
node is also the path egress node. In this case, that node executes any
per-path service instruction that augments the path, and SR forwarding
is complete.If the SR path contains multiple segments, the first segment egress
node is also the second segment ingress node. In this case, that node
executes the topological instruction associated with the second segment.
The above-described procedure continues until the packet arrives at the
SR egress node.In the above-described procedure, only the SR ingress node maintains
path information. Segment ingress and egress nodes maintain information
regarding the segments in which they participate, but they do not
maintain path information.The SR architecture, described above, can leverage either an MPLS data plane or an IPv6 data plane. SR-MPLS leverages
MPLS. SRv6 leverages IPv6.This document describes SRv6+. SRv6+ is another SR variant that
leverages IPv6. It supports a wide variety of use-cases while remaining
in strict compliance with IPv6 specifications. SRv6+ is optimized for
ASIC-based forwarding devices that operate at high data rates. of this document highlights differences
between SRv6 and SRv6+.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 when, and only
when, they appear in all capitals, as shown here.An SRv6+ path is determined by the segments that it contains. It can
be represented by its ingress node as an ordered sequence of SIDs.A segment is determined by its ingress node and by the topological
instruction that controls its behavior. The topological instruction
determines the segment egress node and the method by which the segment
ingress node forwards packets to the segment egress node.Per-segment service instructions augment, but do not determine,
segments. A segment ingress node can:Send one packet through a segment with one per-segment service
instruction.Send another packet through the same segment with a different
per-segment service instruction.Send another packet through the same segment without any
per-segment service instructions.Likewise, per-path service instructions augment, but do not
determine, paths. depicts an SRv6+ path. The path provides
unidirectional connectivity from its ingress node (i.e., Node A) to its
egress node (i.e., Node F). It contains Segment A-C, Segment C-D and
Segment D-F.In Segment A-C, Node A is the ingress node, Node B is a transit node,
and Node C is the egress node. Therefore, the topological instruction
that controls the segment is executed on Node A, while per-segment
service instructions that augment the segment (if any exist) are
executed on Node C.In Segment C-D, Node C is the ingress node and Node D is the egress
node. Therefore, the topological instruction that controls the segment
is executed on Node C, while per-segment service instructions that
augment the segment (if any exist) are executed on Node D.In Segment D-F, Node D is the ingress node, Node E is a transit node,
and Node F is the egress node. Therefore, the topological instruction
that controls the segment is executed on Node D, while per-segment
service instructions that augment the segment (if any exist) are
executed on Node F.Node F is also the path egress node. Therefore, if a per-path service
instruction augments the path, it is executed on Node F.Segments A-C, C-D and D-F are also contained by other paths that are
not included in the figure.SRv6+ supports the following segment types:strictly routedloosely routedStrictly routed segments forward packets through a specified link
that connects the segment ingress node to the segment egress node.
Loosely routed segments forward packets through the least cost path from
the segment ingress node to the segment egress node.Each segment type is described below.When a packet is submitted to a strictly routed segment, the
topological instruction associated with that segment operates upon the
packet. The topological instruction executes on the segment ingress
node and accepts the following parameters:An IPv6 address that identifies an interface on the segment
egress node.A primary interface identifier.Zero or more secondary interface identifiers.The topological instruction behaves as follows:If none of the interfaces identified by the above-mentioned
parameters are operational, discard the packet and send an ICMPv6 Destination Unreachable message
(Code: 5, Source Route Failed) to the packet's source node.Decrement the packet's Hop Count.If the Hop Count has expired, discard the packet and send an
ICMPv6 Time Expired message to the packet's source node.Overwrite the packet's Destination Address with the IPv6
address that was received as a parameter.If the primary interface is active, forward the packet through
the primary interface.If the primary interface is not active and any of the secondary
interfaces are active, forward the packet through one of the
secondary interfaces. Execute procedures so that all packets
belonging to a flow are forwarded through the same secondary
interface.When a packet is submitted to a loosely routed segment, the
topological instruction associated with that segment operates upon the
packet. The topological instruction executes on the segment ingress
node and accepts an IPv6 address as a parameter. The IPv6 address
identifies an interface on the segment egress node.The topological instruction behaves as follows:If the segment ingress node does not have a viable route to the
IPv6 address included as a parameter, discard the packet and send
an ICMPv6 Destination Unreachable message (Code:1 Net Unreachable)
to the packet's source node.Decrement the packet's Hop Count.If the Hop Count has expired, discard the packet and send an
ICMPv6 Time Expired message to the packet's source node.Overwrite the packet's Destination Address with the destination
address that was included as a parameter.Forward the packet to the next hop along the least cost path
the segment egress node. If there are multiple least cost paths to
the segment egress node (i.e., Equal Cost Multipath), execute
procedures so that all packets belonging to a flow are forwarded
through the same next hop.A Segment Identifier (SID) is an unsigned integer that identifies a
segment. Because there is a one-to-one mapping between segments and the
topological instructions that control them, the SID that identifies a
segment also identifies the topological instruction that controls
it.A SID is different from the topological instruction that it
identifies. While a SID identifies a topological instruction, it does
not contain the topological instruction that it identifies. Therefore, a
SID can be encoded in relatively few bits, while the topological
instruction that it identifies may require many more bits for
encoding.SIDs have node-local significance. This means that a segment ingress
node MUST identify each segment that it originates with a unique SID.
However, a SID that is used by one segment ingress node to identify a
segment that it originates can be used by another segment ingress node
to identify another segment.Although SIDs have node-local significance, an SRv6+ path can be
uniquely identified by its ingress node and an ordered sequence of SIDs.
This is because the topological instruction associated with each segment
determines the ingress node of the next segment (i.e., the node upon
which the next SID has significance.)Although SIDs have node-local significance, they can be assigned in a
manner that facilitates debugging. See and
for details.SID values range from 0 to a configurable Maximum SID Value (MSV).
The values 0 through 15 are reserved for future use. The following are
valid MSVs:65,535 (i.e., 2**16 minus 1)4,294,967,295 (i.e., 2**32 minus 1)In order to optimize packet
encoding , network operators can configure all nodes within an
SRv6+ domain to have the smallest feasible MSV. The following
paragraphs explain how an operator determines the smallest feasible
MSV.Consider an SRv6+ domain that contains 5,000 nodes connected to one
another by point-to-point infrastructure links. The network topology
is not a full-mesh. In fact, each node supports 200 point-to-point
infrastructure links or fewer. Given this SRv6+ domain, we will
determine the smallest feasible MSV under the following
conditions:The SRv6+ domain contains strictly routed segments only.The SRv6+ domain contains loosely routed segments only.The SRv6+ domain contains both strictly and loosely routed
segments.If an SRv6+ domain contains strictly routed segments only,
and each node creates a strictly routed segment to each of its
neighbors, each node will create 200 segments or fewer and consume 200
SIDs or fewer. This is because each node has 200 neighbors or fewer.
Because SIDs have node-local significance (i.e., they can be reused
across nodes), the smallest feasible MSV is 65,535.Adding nodes to this SRv6+ domain will not increase the smallest
feasible MSV, so long as each node continues to support 65,519
point-to-point infrastructure links or fewer. If a single node is
added to the domain and that node supports 240 infrastructure links,
the smallest feasible MSV will increase to 65,535.If an SRv6+ domain contains loosely routed segments only, and every
node creates a loosely routed segment to every other node, every node
will create 4,999 segments and consume 4,999 SIDs. This is because the
domain contains 5,000 nodes. Because SIDs have node-local significance
(i.e., they can be reused across nodes), the smallest feasible MSV is
65,535.Adding nodes to this SRv6+ domain will not increase the smallest
feasible MSV until the number of nodes exceeds 65,519. When the
smallest feasible MSV increases, it becomes 4,294,967,295.If an SRv6+ domain contains both strictly and loosely routed
segments, each node will create 5,199 segments or fewer and consume
5,199 SIDs or fewer. This value is the sum of the following:The number of loosely routed segments that each node will
create, given that every node creates a loosely routed segment to
every other node (i.e., 4,999).The number of strictly routed segments that each node will
create, given that each node creates a strictly routed segment to
each of its neighbors (i.e., 200 or fewer).Because SIDs have node-local significance (i.e., they can be
reused across nodes), the smallest feasible MSV is 65,535.Adding nodes to this SRv6+ domain will not increase the smallest
feasible MSV until the number of nodes plus the maximum number of
infrastructure links per node exceeds 65,519. When the smallest
feasible MSV increases, it becomes 4,294,967,295.Network operators can establish conventions by which they assign
SIDs to strictly routed segments. These conventions can facilitate
debugging.For example, a network operator can reserved a range of SIDs for
strictly routed segments. It can further divide that range into
subranges, so that all segments sharing a common egress node are
identified by SIDs from the same subrange.In order to facilitate debugging, all loosely routed segments that
share a common egress node are identified by the same SID. In order to
maintain this discipline, network wide co-ordination is required.For example, assume that an SRv6+ domain contains N nodes. Network
administrators reserve a block of N SIDs and configure one of those
SIDs on each node. Each node advertises its SID into the control
plane. When another node receives that advertisement, it creates a
loosely routed segment between itself and the advertising node. It
also associates the SID that it received in the advertisement with the
newly created segment. See for details.SRv6+ supports the following service instruction types:Per-segmentPer-pathEach is described below.Per-segment service instructions can augment a segment. Per-segment
service instructions, if present, are executed on the segment egress
node. Because the path egress node is also a segment egress node, it
can execute per-segment service instructions.The following are examples of per-segment service instructions:Expose a packet to a firewall policy.Expose a packet to a sampling policy.Per-segment Service Instruction Identifiers identify a set of
service instructions. Per-segment Service Instruction Identifiers are
allocated and distributed by a controller. They have domain-wide
significance.A per-path service instruction can augment a path. The per-path
service instruction, if present, is executed on the path egress
node.The following are examples of per-path service instructions:De-encapsulate a packet and forward its newly exposed payload
through a specified interface.De-encapsulate a packet and forward its newly exposed payload
using a specified routing table.Per-path Service Instruction Identifiers identify per-path
service instructions. Per-path Service Instruction Identifiers are
allocated and distributed by the processing node (i.e., the path
egress node). They have node-local significance. This means that the
path egress node MUST allocate a unique Per-path Service Instruction
Identifier for each per-path service instruction that it
instantiates.SRv6+ ingress nodes generate IPv6 header chains that represent SRv6+
paths. An IPv6 header chain contains an IPv6 header. It can also contain
one or more extension headers.An extension header chain that represents an SRv6+ path can contain
any valid combination of IPv6 extension headers. The following bullet
points describe how SRv6+ leverages IPv6 extension headers:If an SRv6+ path contains multiple segments, the IPv6 header
chain that represents it MUST contain a Routing header. The SRv6+
path MUST be encoded in the Routing header as an ordered sequence of
SIDs.If an SRv6+ path is augmented by a per-path service instruction,
the IPv6 header chain that represents it MUST contain a Destination
Options header. The Destination Options header MUST immediately
precede an upper-layer header and it MUST include a Per-Path Service
Instruction Identifier.If an SRv6+ path contains a segment that is augmented by a
per-segment service instruction, the IPv6 chain that represents it
MUST contain a Routing header and a Destination Options header. The
Destination Options header MUST immediately precede a Routing header
and it MUST include the Per-Segment Service Instruction
Identifier.The following subsections describe how SRv6+ uses the Routing
header and the Destination Options header.SRv6+ defines a new Routing header type, called the Compressed Routing Header
(CRH). The CRH contains the following fields:Next Header - Identifies the header immediately following the
CRH.Hdr Ext Len - Length of the CRH.Routing Type - Identifies the Routing header variant (i.e.,
CRH)Segments Left - The number of segments still to be traversed
before reaching the path egress node.Last Entry - Represents the index of the last element of the
Segment List.Com (Compression) - Represents the length of each entry in the
SID List. Values are reserved (0), sixteen bits (1), thirty-two
bits (2), and reserved (3). In order to maximize header
compression, this value should reflect the smallest feasible MSV.SID List - Represents the SRv6+ path as an ordered list of
SIDs. SIDs are listed in reverse order, with SID[0] representing
the final segment, SID[1] representing the penultimate segment,
and so forth. SIDs are listed in reverse order so that Segments
Left can be used as an index to the SID List. The SID indexed by
Segments Left is called the current SID.As per , when an IPv6 node receives a
packet, it examines the packet's destination address. If the
destination address represents an interface belonging to the node, the
node processes the next header. If the node encounters and recognizes
the CRH, it processes the CRH as follows:If Segments Left equal 0, skip over the CRH and process the
next header in the packet.Decrement Segments Left.Search for the current SID in a local table that maps SID's to
topological instructions. If the current SID cannot be found in
that table, send an ICMPv6 Parameter Problem message to the
packet's Source Address and discard the packet.Execute the topological instruction found in the table as
described in . This causes the packet to
be forwarded to the segment egress node.When the packet arrives at the segment egress node, the
above-described procedure is repeated.According to , the Destination Options
header contains one or more IPv6 options. It can occur twice within a
packet, once before a Routing header and once before an upper-layer
header. The Destination Options header that occurs before a Routing
header is processed by the first destination that appears in the IPv6
Destination Address field plus subsequent destinations that are listed
in the Routing header. The Destination Options header that occurs
before an upper-layer header is processed by the packet's final
destination only.Therefore, SRv6+ defines the following new IPv6 options:The SRv6+
Per-Segment Service Instruction Option The SRv6+ Per-Path
Service Instruction OptionThe SRv6+ Per-Segment Service Instruction Option is encoded
in a Destination Options header that precedes the CRH. Therefore, it
is processed by every segment egress node. It includes a Per-Segment
Service Instruction Identifier and causes segment egress nodes to
execute per-segment service instructions.The SRv6+ Per-Path Service Instruction Option is encoded in a
Destination Options header that precedes the upper-layer header.
Therefore, it is processed by the path egress node only. It includes a
Per-Path Service Instruction Identifier and causes the path egress
node to execute a per-path service instruction.IS-IS extensions
have been defined for the following purposes:So that SRv6+ segment ingress nodes can flood information
regarding strictly routed segments that they originateSo that SRv6+ segment egress nodes can flood information
regarding loosely routed segments that they terminateBGP extensions are being defined
so that SRv6+ path egress nodes can associated path-terminating service
instructions with Network Layer Reachability Information (NLRI).SRv6 defines a Routing header type, called the Segment Routing
Header (SRH). The SRH contains a field that represents the SRv6 path
as an ordered sequence of SIDs. Each SID contained by that field is
128 bits long.Likewise, SRv6+ defines a Routing Header Type, called the
Compressed Routing Header (CRH). The CRH contains a field that
represents the SRv6+ path as an ordered sequence of SIDs. Within that
field, SIDs can be 16 or 32 bits long.SIDsSRv6 SRH (128-bit SID)SRv6+ CRH (16-bit SID)SRv6+ CRH (32-bit SID)1241616240161635616244721624588243261042432712024408136244091523248101683248111843256122003256132164064142324064152484072162644072 reflects Routing header size as a
function of Routing header type and Number of SIDs contained by the
Routing header.Large Routing headers are undesirable for the following
reasons:Many ASIC-based forwarders copy the entire IPv6 extension
header chain from buffer memory to on-chip memory. As the size of
the IPv6 extension header chain increases, so does the cost of
this copy.Because Path MTU Discovery
(PMTUD) is not entirely reliable, many IPv6 hosts refrain
from sending packets larger than the IPv6 minimum link MTU (i.e.,
1280 bytes). When packets are small, the overhead imposed by large
Routing headers becomes pronounced.SRv6+ decouples topological instructions from service instructions.
Topological instructions are invoked at the segment ingress node, as a
result of CRH processing, while service instructions are invoked at
the segment egress node, as a result of Destination Option processing.
Therefore, network operators can use SRv6+ mechanisms to support
topological instructions, service instructions, or both. illustrates this point by depicting
design options available to network operators offering Ethernet Virtual Private Network services
over Virtual eXtensible Local Area Network
(VXLAN) . In Option 1, the network operator encodes topological
instructions in the CRH, while encoding service instructions in a
VXLAN header. In Option 2, the network operator encodes service
instructions in a Destination Options header, while allowing traffic
to traverse the least cost path between the ingress and egress
Provider Edge (PE) routers. In Option 3, the network operator encodes
topological instructions in the CRH, and encodes service instructions
in a Destination Options header.The IPv6 Authentication Header (AH)
can be used to authenticate SRv6+ packets. However, AH processing is
not defined in SRv6.SRv6+ supports traffic engineering solutions that rely exclusively
upon strictly routed segments. For example, consider an SRv6+ network
whose diameter is 12 hops and whose minimum feasible MSV is 65,525. In
that network, in the worst case, SRv6+ overhead is 72 bytes (i.e., a
40-byte IPv6 header and a 32-byte CRH).SRv6 also supports traffic engineering solutions that rely
exclusively upon strictly routed segments (i.e., END.X SIDs). However,
SRv6 overhead may be prohibitive. For example, consider an SRv6
network whose diameter is 12 hops. In the worst case, SRv6 overhead is
240 bytes (i.e., a 40 byte IPv6 header and a 200-byte SRH).In SRv6, an IPv6 address can represent either of the following:A network interfaceAn instruction instantiated on a node (i.e., an SRv6 SID)In SRv6+ an IPv6 address always represents a network interface, as
per .In order to be compliant with this specification, an SRv6+
implementation MUST:Be able to process IPv6 options as described in Section 4.2 of
.Be able to process the Routing header as described in Section 4.4
of .Be able to process the Destination Options header as described in
Section 4.6 of .Recognize the CRH.Be able to encode an SRv6+ path in the CRH as an ordered sequence
of 32-bit SIDs.Be able to process a CRH that includes 32-bit SIDs.Additionally, an SRv6+ implementation MAY:Be able to encode an SRv6+ path in the CRH as an ordered sequence
of 16-bit SIDs.Be able to process a CRH that includes 16-bit SIDs.Recognize the Per-Segment Service Instruction Option.Recognize the Per-Path Service Instruction Option.Ping and Traceroute both operate
correctly in SRv6+ (i.e., in the presence of the CRH).As per , SRv6+ nodes rate limit the ICMPv6
messages that they emit.An SRv6+ implementation MAY include a configuration option that
determines how it encodes SIDs (i.e., in 16 or 32 bits). In order to
reduce operational complexity, network operators typically configure
their networks so that every node encodes SIDs identically.As a network grows, its minimum feasible MSV may increase. In this
case, the network may need to migrate from one SID encoding to
another. The following bullet points describe a migration strategy for
an SRv6+ network that is migrating from 16-bit SIDs to 32-bit
SIDs:.Ensure that all nodes can process a CRH that includes 32-bit
SIDs.Configure each nodes so that encodes SIDs in 32-bits.Configure SIDs whose value exceeds 65,535.SID values 0-15 are reserved for future use. They may be assigned by
IANA, based on IETF Consensus.IANA is requested to establish a "Registry of SRv6+ Reserved SIDs".
Values 0-15 are reserved for future use.SRv6+ domains MUST NOT span security domains. In order to enforce
this requirement, security domain edge routers MUST do one of the
following:Discard all inbound SRv6+ packetsAuthenticate all inbound SRv6+ packetsThe authors wish to acknowledge Dr. Vanessa Ameen and John
Scudder.