Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8402

Proposed STD
Pages: 32
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: SPRING

Segment Routing Architecture

Part 1 of 2, p. 1 to 19
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                  C. Filsfils, Ed.
Request for Comments: 8402                               S. Previdi, Ed.
Category: Standards Track                                    L. Ginsberg
ISSN: 2070-1721                                      Cisco Systems, Inc.
                                                             B. Decraene
                                                            S. Litkowski
                                                                  Orange
                                                               R. Shakir
                                                            Google, Inc.
                                                               July 2018


                      Segment Routing Architecture

Abstract

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an ordered list of instructions, called
   "segments".  A segment can represent any instruction, topological or
   service based.  A segment can have a semantic local to an SR node or
   global within an SR domain.  SR provides a mechanism that allows a
   flow to be restricted to a specific topological path, while
   maintaining per-flow state only at the ingress node(s) to the SR
   domain.

   SR can be directly applied to the MPLS architecture with no change to
   the forwarding plane.  A segment is encoded as an MPLS label.  An
   ordered list of segments is encoded as a stack of labels.  The
   segment to process is on the top of the stack.  Upon completion of a
   segment, the related label is popped from the stack.

   SR can be applied to the IPv6 architecture, with a new type of
   routing header.  A segment is encoded as an IPv6 address.  An ordered
   list of segments is encoded as an ordered list of IPv6 addresses in
   the routing header.  The active segment is indicated by the
   Destination Address (DA) of the packet.  The next active segment is
   indicated by a pointer in the new routing header.

Top      ToC       Page 2 
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 has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
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  . . . . . . . . . . . . . . . . . . . . . . .  32

1.  Introduction

   Segment Routing (SR) leverages the source routing paradigm.  A node
   steers a packet through an SR Policy 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 local to an SR node or global within an SR domain.  SR
   supports per-flow explicit routing while maintaining per-flow state
   only at the ingress nodes to the SR domain.

   A segment is often referred to by its Segment Identifier (SID).

Top      ToC       Page 4 
   A segment may be associated with a topological instruction.  A
   topological local segment may instruct a node to forward the packet
   via a specific outgoing interface.  A topological global segment may
   instruct an SR domain to forward the packet via a specific path to a
   destination.  Different segments may exist for the same destination,
   each with different path objectives (e.g., which metric is minimized,
   what constraints are specified).

   A segment may be associated with 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 (e.g., shape the packets received with this segment at x
   Mbps).

   The SR architecture supports any type of instruction associated with
   a segment.

   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 individually decides to steer packets
   on an SR Policy (e.g., pre-computed local protection [RFC8355]).  A
   node individually computes the SR Policy.

   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.
   The SR controller computes the 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.  Specifically, multiple SR controllers may program the
   same SR domain.  The SR architecture allows these SR controllers to
   discover which SIDs are instantiated at which nodes and which sets of
   local (SRLB) and global (SRGB) labels are available at which node.

   A hybrid scenario complements a base distributed control plane with a
   centralized controller.  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
   inform hosts about policies either by pushing these policies to hosts
   or by responding to requests from hosts.

Top      ToC       Page 5 
   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).

   SR can be directly applied to the MPLS architecture with no change to
   the forwarding plane [SR-MPLS].  A segment is encoded as an 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.
   Upon completion of a segment, the related label is popped from the
   stack.

   SR can be applied to the IPv6 architecture with 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 indicated by the Destination Address (DA) of the packet.
   The next active segment is indicated by the SegmentsLeft (SL) pointer
   in the SRH.  When an SRv6 SID is completed, the SL is decremented and
   the next segment is copied to the DA.  When a packet is steered on an
   SR Policy, the related SRH is added to the packet.

   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 with active
   segment matching 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.

Top      ToC       Page 6 
2.  Terminology

   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.

   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).

   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.

   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.

   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].

   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].

Top      ToC       Page 7 
   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.

   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.

   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.

   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.

   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.

   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.

   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-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

Top      ToC       Page 8 
   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".

   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.

   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".

   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".

   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.

   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.

   Forwarding Information Base (FIB): the forwarding table of a node

Top      ToC       Page 9 
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.

   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].

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.

   Multiple instances and topologies are defined in IS-IS and OSPF in:
   [RFC5120], [RFC8202], [RFC6549], and [RFC4915].

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.

   This document defines two algorithms:

   o  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.

   o  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

Top      ToC       Page 10 
      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.

   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.

3.1.2.  SR-MPLS

   When SR is used over the MPLS data plane, SIDs are an MPLS label or
   an index into an MPLS label space (either SRGB or SRLB).

   Where possible, it is recommended that identical SRGBs be configured
   on all nodes in an SR domain.  This simplifies troubleshooting as the
   same label will be associated with the same prefix on all nodes.  In
   addition, it simplifies support for anycast as detailed in
   Section 3.3.

   The following behaviors are associated with SR operating over the
   MPLS data plane:

   o  The IGP signaling extension for IGP-Prefix segment includes a flag
      to indicate whether directly connected neighbors of the node on
      which the prefix is attached should perform the NEXT operation or
      the CONTINUE operation when processing the SID.  This behavior is
      equivalent to Penultimate Hop Popping (NEXT) or Ultimate Hop
      Popping (CONTINUE) in MPLS.

   o  A Prefix-SID is allocated in the form of an MPLS label (or an
      index in the SRGB) according to a process similar to IP address
      allocation.  Typically, the Prefix-SID is allocated by policy by
      the operator (or Network Management System (NMS)), and the SID
      very rarely changes.

Top      ToC       Page 11 
   o  While SR allows a local segment to be attached to an IGP prefix,
      where the terminology "IGP-Prefix segment" or "Prefix-SID" is
      used, the segment is assumed to be global (i.e., the SID is
      defined from the advertised SRGB).  This is consistent with all
      the described use cases that require global segments attached to
      IGP prefixes.

   o  The allocation process MUST NOT allocate the same Prefix-SID to
      different prefixes.

   o  If a node learns of a Prefix-SID that has a value that falls
      outside the locally configured SRGB range, then the node MUST NOT
      use the Prefix-SID and SHOULD issue an error log reporting a
      misconfiguration.

   o  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

   o  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.

   As Prefix-SIDs are specific to a given algorithm, if traffic
   associated with an algorithm arrives at a node that does not support
   that algorithm, the traffic will be dropped as there will be no
   forwarding entry matching the incoming label.

Top      ToC       Page 12 
3.1.3.  SRv6

   When SR is used over the IPv6 data plane:

   o  A Prefix-SID is an IPv6 address.

   o  An operator MUST explicitly instantiate an SRv6 SID.  IPv6 node
      addresses are not SRv6 SIDs by default.

   A node N advertising an IPv6 address R usable as a segment identifier
   MUST maintain the following FIB entry:

      Incoming Active Segment: R
      Ingress Operation: NEXT
      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 that covers R.

   Independent of SR support, any remote IPv6 node will maintain a plain
   IPv6 FIB entry for any prefix, no matter if the prefix represents a
   segment or not.  This allows forwarding of packets to the node that
   owns the SID even by nodes that do not support SR.

   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 that a node
   allocates.

   Nodes that 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 that do not support a given
   algorithm will not be included in the topology associated with that
   algorithm-specific SPF; therefore, 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 next-hop will
   be either a node that supports the algorithm -- in which case, the
   packet will be forwarded along algorithm-specific paths (or be
   dropped if none are available) -- or a node that does NOT support the
   algorithm -- in which case, the packet will continue to be forwarded
   along Algorithm 0 paths towards the destination node.

Top      ToC       Page 13 
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.

3.3.  IGP-Anycast Segment (Anycast-SID)

   An Anycast segment or Anycast-SID enforces the ECMP-aware shortest-
   path forwarding towards the closest node of the anycast set.  This is
   useful to express macro-engineering policies or protection
   mechanisms.

   An IGP-Anycast segment MUST NOT reference a particular node.

   Within an anycast group, all routers in an SR domain MUST advertise
   the same prefix with the same SID value.

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 Groups

Top      ToC       Page 14 
   The 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 will be done by pushing the Anycast-SID of the
   group in the stack.

   Processing the anycast, and 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 A

Top      ToC       Page 15 
   Considering an MPLS deployment, in the above topology, if device PE1
   (or PE2) requires the sending of a packet to the device PE3 (or PE4),
   it needs to encapsulate the packet in an MPLS payload with the
   following stack of labels.

   o  Label allocated by R1 for Anycast-SID 100 (outer label).

   o  Label allocated by the nearest router in Group A for SID 30 (for
      destination PE3).

   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.  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, computation of 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).

3.4.  IGP-Adjacency Segment (Adj-SID)

   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).  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
   forwarding adjacency, [RFC4206]).

   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
   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
   IP shortest-path consideration, towards link L.  If the Adj-SID
   identifies a set of adjacencies, then the node N load-balances the
   traffic among the various members of the set.

Top      ToC       Page 16 
   Similarly, when using a global Adj-SID, a packet injected anywhere
   within the SR domain with a segment list {SNL}, where SNL is a global
   Adj-SID attached by node N to its adjacency over link L, will be
   forwarded along the shortest path to N and then be switched by N,
   without any IP shortest-path consideration, towards link L.  If the
   Adj-SID identifies a set of adjacencies, then the node N does load-
   balance the traffic among the various members of the set.  The use of
   global Adj-SID allows to reduce the size of the segment list when
   expressing a path at the cost of additional state (i.e., the global
   Adj-SID will be inserted by all routers within the area in their
   forwarding table).

   An "IGP-Adjacency segment" or "Adj-SID" enforces the switching of the
   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
   a list of segments.

   The encodings of the Adj-SID include a set of flags supporting the
   following functionalities:

   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.  The use of protection is clearly a policy-
      based decision; that is, for a given policy protection may or may
      not be desirable.

   o  Indication whether the Adj-SID has local or global scope.  Default
      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
   advertisement.

   A node SHOULD allocate one Adj-SID for each of its adjacencies.

   A node MAY allocate multiple Adj-SIDs for the same adjacency.  An
   example is to support an Adj-SID that is eligible for protection and
   an Adj-SID that is NOT eligible for protection.

   A node MAY associate the same Adj-SID to multiple adjacencies.

Top      ToC       Page 17 
   In order to be able to advertise in the IGP all the Adj-SIDs
   representing the IGP adjacencies between two nodes, parallel
   adjacency suppression MUST NOT be performed by the IGP.

   When a node binds an Adj-SID V to a local data-link L, the node MUST
   install the following FIB entry:

      Incoming Active Segment: V
      Ingress Operation: NEXT
      Egress Interface: L

   The Adj-SID implies, from the router advertising it, the forwarding
   of the packet through the adjacency or adjacencies identified by the
   Adj-SID, regardless of its IGP/SPF cost.  In other words, the use of
   adjacency segments overrides the routing decision made by the SPF
   algorithm.

3.4.1.  Parallel Adjacencies

   Adj-SIDs can be used in order to 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 with:

      Incoming Active Segment: W
      Ingress Operation: NEXT
      Egress interfaces: load-balance between any data-link within set B

   When parallel adjacencies are used and associated with the same Adj-
   SID, and, in order to optimize the load-balancing function, a
   "weight" factor can be associated with the Adj-SID advertised with
   each adjacency.  The weight tells the ingress (or an SDN/
   orchestration system) about the load-balancing factor over the
   parallel adjacencies.  As shown in Figure 3, A and B are connected
   through two parallel adjacencies

                                  Link-1
                                +--------+
                                |        |
                            S---A        B---C
                                |        |
                                +--------+
                                  Link-2

                   Figure 3: Parallel Links and Adj-SIDs

Top      ToC       Page 18 
   Node A advertises following Adj-SIDs and weights:

   o  Link-1: Adj-SID 1000, weight: 1

   o  Link-2: Adj-SID 1000, weight: 2

   Node S receives the advertisements of the parallel adjacencies and
   understands that by using Adj-SID 1000 node A will load-balance the
   traffic across the parallel links (Link-1 and Link-2) according to a
   1:2 ratio i.e., twice as many packets will flow over Link-2 as
   compared to Link-1.

3.4.2.  LAN Adjacency Segments

   In LAN subnetworks, link-state protocols define the concept of
   Designated Router (DR, in OSPF) or Designated Intermediate System
   (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and
   that describe the LAN topology in a special routing update (OSPF
   Type2 LSA or IS-IS Pseudonode LSP).

   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
   the LAN.  Therefore, additional protocol mechanisms (IS-IS and OSPF)
   are necessary in order for each router in the LAN to advertise an
   Adj-SID associated with each neighbor in the LAN.

3.5.  Inter-Area Considerations

   In the following example diagram, it is assumed that the all areas
   are part of a single SR domain.

   The 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 Example

Top      ToC       Page 19 
   In Area 2, node Z allocates Node-SID 150 to his local IPv6 prefix
   2001:DB8::2:1/128.

   Area Border Routers (ABRs) G and J will propagate the prefix and its
   SIDs into the backbone area by creating a new instance of the prefix
   according to normal inter-area/level IGP propagation rules.

   Nodes C and I will apply the same behavior when leaking prefixes from
   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
   I.

   Therefore, the result is that a Prefix-SID remains 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 the packet
   according to the active segment (Node-SID(150)).  Forwarding
   continues across area borders, using the same Node-SID(150) until the
   packet reaches its destination.



(page 19 continued on part 2)

Next Section