RFC 8665

OSPF Extensions for Segment Routing

📅 published December 2019, from ietf

OSPF Extensions for Segment Routing 🎀

Okay bestie, so this is RFC 8665 💅 It's a Standards Track document, which means it's the official, the-Internet-actually-follows-this kind of spec ✨. It's dated December 2019 and its ISSN is 2070-1721 🌸

The authors are P. Psenak (Ed.) and S. Previdi (Ed.) from Cisco Systems, Inc., with C. Filsfils also from Cisco. H. Gredler is from RtBrick Inc., R. Shakir is from Google, Inc., W. Henderickx is from Nokia, and J. Tantsura is from Apstra, Inc. 🧚 The title block lists no Obsoletes or Updates entries, so this RFC doesn't replace or patch any other RFC 👑

Abstract

Okay so, Segment Routing (SR) is lowkey amazing 🦋 It lets you describe end-to-end paths across IGP topologies by building them out of a bunch of topological subpaths called "segments." The link-state routing protocols (IS-IS and OSPF) are the ones that advertise these segments to everyone.

This doc is all about the OSPFv2 extensions that SR needs ✨

Status of This Memo

This is an Internet Standards Track document 💜

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🎀

For the current status of this document, any errata, and how to give feedback, head to https://www.rfc-editor.org/info/rfc8665 🌈

Copyright (c) 2019 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 stood on the date this document was published. Please actually read these, bestie, because they describe 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 with no warranty, as the Simplified BSD License describes.

Table of Contents

1.  Introduction
  1.1.  Requirements Language
2.  Segment Routing Identifiers
  2.1.  SID/Label Sub-TLV
3.  Segment Routing Capabilities
  3.1.  SR-Algorithm TLV
  3.2.  SID/Label Range TLV
  3.3.  SR Local Block TLV
  3.4.  SRMS Preference TLV
4.  OSPF Extended Prefix Range TLV
5.  Prefix-SID Sub-TLV
6.  Adjacency Segment Identifier (Adj-SID)
  6.1.  Adj-SID Sub-TLV
  6.2.  LAN Adj-SID Sub-TLV
7.  Elements of Procedure
  7.1.  Intra-area Segment Routing in OSPFv2
  7.2.  Inter-area Segment Routing in OSPFv2
  7.3.  Segment Routing for External Prefixes
  7.4.  Advertisement of Adj-SID
    7.4.1.  Advertisement of Adj-SID on Point-to-Point Links
    7.4.2.  Adjacency SID on Broadcast or NBMA Interfaces
8.  IANA Considerations
  8.1.  OSPF Router Information (RI) TLVs Registry
  8.2.  OSPFv2 Extended Prefix Opaque LSA TLVs Registry
  8.3.  OSPFv2 Extended Prefix TLV Sub-TLVs Registry
  8.4.  OSPFv2 Extended Link TLV Sub-TLVs Registry
  8.5.  IGP Algorithm Types Registry
9.  TLV/Sub-TLV Error Handling
10. Security Considerations
11. References
  11.1.  Normative References
  11.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

Segment Routing (SR) is the big idea here 🦋 It describes end-to-end paths within IGP topologies by encoding them as sequences of topological subpaths, which are called "segments." The link-state routing protocols (IS-IS and OSPF) advertise these segments.

There are a few flavours of segment. Prefix segments stand for an ECMP-aware shortest path to a prefix (or a node), and they follow whatever the IGP topology looks like right now 🌸 Adjacency segments stand for a hop over one specific adjacency between two nodes in the IGP. Generally, a prefix segment is a multi-hop path, while an adjacency segment is usually just a one-hop path.

SR's control plane works with both IPv6 and MPLS data planes, and it doesn't need any extra signaling beyond the IGP extensions 💅 The IPv6 data plane is out of scope for this spec, since it doesn't apply to OSPFv2, and OSPFv2 only supports the IPv4 address family 🙈 When SR runs over MPLS, SR paths don't need any LDP or RSVP-TE signaling. That said, SR can still play nicely with LSPs set up by RSVP or LDP 🫶

There are more segment types too, like the Binding Segment Identifier (SID), which you can read about in [RFC8402] 🌈

This document is where you'll find the OSPF extensions SR needs. The SR architecture lives in [RFC8402], and the SR use cases are in [RFC7855] 💜

1.1. Requirements Language

Here's the deal with the key words. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🎀 If they're lowercase, they're just regular words, bestie 💅

2. Segment Routing Identifiers 🌸

SR defines several types of Segment Identifiers (SIDs): Prefix-SID, Adjacency SID, LAN Adjacency SID, and Binding SID ✨

The Extended Prefix/Link Opaque Link State Advertisements (LSAs) from [RFC7684] are what carry the advertisements for each SID type 🦋

2.1. SID/Label Sub-TLV 💖

The SID/Label Sub-TLV shows up inside multiple TLVs and sub-TLVs defined later in this document. It advertises the SID or label tied to a prefix or an adjacency. Its format looks like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         SID/Label (variable)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field means:

  • Type: 1
  • Length: 3 or 4 octets. If the length is 3, the 20 rightmost bits are a label. If the length is 4, the value is a 32-bit SID ✨

3. Segment Routing Capabilities 👑

SR needs some extra router capabilities to be advertised to the other routers in the area 🧚

These SR capabilities get advertised in the Router Information Opaque LSA, which is defined in [RFC7770]. The TLVs defined below work for both OSPFv2 and OSPFv3, so check out [RFC8666] too 💜

3.1. SR-Algorithm TLV 🦋

The SR-Algorithm TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]) 🌈

The SR-Algorithm TLV is optional. It SHOULD only be advertised once in the Router Information Opaque LSA. If a node doesn't advertise the SR-Algorithm TLV, that node counts as not being SR capable 🙈

So, an SR router can use different algorithms to figure out reachability to OSPF routers or prefixes in an OSPF area. Some examples are metric-based Shortest Path First (SPF), different flavours of Constrained SPF, and so on ✨ The SR-Algorithm TLV lets a router tell the other routers in the OSPF area which algorithms it's currently using. Its format looks like this:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Algorithm 1 | Algorithm...  |   Algorithm n |               |
+-                                                             -+
|                                                               |
+                                                               +

Here's what each field means:

  • Type: 8
  • Length: Variable, in octets, depending on how many algorithms get advertised
  • Algorithm: A single octet that identifies the algorithm. This document defines these values:
    • 0: The Shortest Path First (SPF) algorithm based on link metric. This is the standard shortest path algorithm the OSPF protocol computes. Matching what's normal for link-state protocols, Algorithm 0 lets any node overwrite the SPF path with a different path based on its local policy. If the SR-Algorithm TLV is advertised, Algorithm 0 MUST be included 🔥
    • 1: The Strict Shortest Path First (SPF) algorithm based on link metric. It's identical to Algorithm 0, except Algorithm 1 requires that every node along the path honour the SPF routing decision. Local policy at a node that claims support for Algorithm 1 MUST NOT alter the SPF paths Algorithm 1 computes 💀

When a router sends multiple SR-Algorithm TLVs, the receiver MUST use the first occurrence of the TLV in the Router Information Opaque LSA 🎀 If the SR-Algorithm TLV shows up in multiple Router Information Opaque LSAs with different flooding scopes, the one in the Router Information Opaque LSA with the area-scoped flooding scope MUST be used. If it shows up in multiple Router Information Opaque LSAs with the same flooding scope, the one in the Router Information (RI) Opaque LSA with the numerically smallest Instance ID MUST be used, and the later instances of the SR-Algorithm TLV MUST be ignored 🌸

The RI LSA can be advertised at any of the defined opaque flooding scopes: link, area, or Autonomous System (AS) 🌈 For advertising the SR-Algorithm TLV, area-scoped flooding is REQUIRED 🫶

3.2. SID/Label Range TLV ✨

okay so bestie, Prefix-SIDs MAY be advertised as an index, which you can read about in Section 5 🦋. That index is basically an offset into the SID/Label space the router is advertising, and the SID/Label Range TLV is the thing that advertises that space 💖.

The SID/Label Range TLV is a top-level TLV inside the Router Information Opaque LSA (defined in [RFC7770]) 🎀. It MAY show up multiple times, and it looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Range Size                 |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sub-TLVs (variable)                    |
   +-                                                             -+
   |                                                               |
   +                                                               +

where:

  • Type: 9
  • Length: Variable, in octets, depending on the sub-TLVs
  • Range Size: 3-octet SID/label range size (i.e., the number of SIDs or labels in the range including the first SID/label). It MUST be greater than 0. 🍓
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 🫶

Right now the only sub-TLV that's supported is the SID/Label Sub-TLV from Section 2.1 💅. The SID/Label Sub-TLV MUST be included in the SID/Label Range TLV, and the SID/Label in that sub-TLV is the first SID/Label in the advertised range 🌸.

Only a single SID/Label Sub-TLV MAY be advertised in the SID/Label Range TLV. If more than one SID/Label Sub-TLV is present, the SID/Label Range TLV MUST be ignored. 😭

Multiple SID/Label Range TLVs MAY be advertised so you can cover multiple ranges, and when you do, here's the tea 🫖:

  • The originating router MUST encode each range into a different SID/Label Range TLV. 🧚
  • The originating router decides the order the TLVs show up in the Router Information Opaque LSA. It MUST keep that order the same after a graceful restart (using checkpointing, nonvolatile storage, or any other mechanism), so the SID/Label range and SID index correspondence survives the restart 💜.
  • The receiving router MUST follow the advertised order when it calculates a SID/Label from a SID index 👑.
  • The originating router MUST NOT advertise overlapping ranges. 🙈
  • When a router gets multiple overlapping ranges, it MUST conform to the procedures defined in [RFC8660]. 🌈

Here's an example, because examples are everything 🎀. The originating router advertises these ranges:

      Range 1: Range Size: 100   SID/Label Sub-TLV: 100
      Range 1: Range Size: 100   SID/Label Sub-TLV: 1000
      Range 1: Range Size: 100   SID/Label Sub-TLV: 500

The receiving routers concatenate the ranges and build the Segment Routing Global Block (SRGB) like this:

   SRGB = [100, 199]
          [1000, 1099]
          [500, 599]

And the indexes span across those multiple ranges:

      index 0 means label 100
      ...
      index 99 means label 199
      index 100 means label 1000
      index 199 means label 1099
      ...
      index 200 means label 500
      ...

The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)) ✨. For SID/Label Range TLV advertisement, area-scoped flooding is REQUIRED 🔥.

3.3. SR Local Block TLV 🌸

The SR Local Block TLV (SRLB TLV) contains the range of labels the node has reserved for Local SIDs 🦋. SIDs from the SRLB MAY be used for Adjacency SIDs, but they can also be used by components other than the OSPF protocol. For example, an application or a controller can tell the router to allocate a specific Local SID 🧚. Some controllers or applications can use the control plane to discover the available set of Local SIDs on a particular router, and in those cases the SRLB is advertised in the control plane. The requirement to advertise the SRLB is described further in [RFC8660], and the SRLB TLV is what actually advertises it 💖.

The SRLB TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]) 🎀.

The SRLB TLV MAY appear multiple times in the Router Information Opaque LSA and looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Range Size                 |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sub-TLVs (variable)                    |
   +-                                                             -+
   |                                                               |
   +                                                               +

where:

  • Type: 14
  • Length: Variable, in octets, depending on the sub-TLVs
  • Range Size: 3-octet SID/Label range size (i.e., the number of SIDs or labels in the range including the first SID/Label). It MUST be greater than 0. 🍓
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 🫶

Initially, the only supported sub-TLV is the SID/Label Sub-TLV from Section 2.1 💅. The SID/Label Sub-TLV MUST be included in the SRLB TLV, and the SID/Label in it represents the first SID/Label in the advertised range 🌸.

Only a single SID/Label Sub-TLV MAY be advertised in the SRLB TLV. If more than one SID/Label Sub-TLV is present, the SRLB TLV MUST be ignored 😭.

The originating router MUST NOT advertise overlapping ranges. 🙈

Every time a SID from the SRLB gets allocated, it SHOULD also be reported to all the components (like a controller or applications) so they all have an up-to-date view of the current SRLB allocation. This is REQUIRED to avoid collisions between allocation instructions? No, wait, let me be precise, bestie: the original says this is required to avoid collisions between allocation instructions 👑.

Within the context of OSPF, reporting Local SIDs is done through OSPF sub-TLVs, such as the Adjacency SID (Section 6) 🌈. Reporting allocated Local SIDs can also happen through other means and protocols, but those are outside the scope of this document ✨.

A router advertising the SRLB TLV MAY also have other label ranges outside of the SRLB, used for its own local allocation and not advertised in the SRLB TLV 🦋. For example, an Adjacency SID might be allocated from a local label that isn't part of the SRLB 💜.

The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)) 🔥. For SRLB TLV advertisement, area-scoped flooding is REQUIRED 💅.

3.4. SRMS Preference TLV 💖

The Segment Routing Mapping Server Preference TLV (SRMS Preference TLV) advertises a preference associated with the node acting as an SR Mapping Server 🧚. The role of an SRMS is described in [RFC8661], and SRMS preference is defined there too 🎀.

The SRMS Preference TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]) 🌸.

The SRMS Preference TLV MAY only be advertised once in the Router Information Opaque LSA and looks like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Preference    |                 Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 15
  • Length: 4 octets
  • Preference: 1 octet, with an SRMS preference value from 0 to 255
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 🫶

When multiple SRMS Preference TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information Opaque LSA. If the SRMS Preference TLV appears in multiple Router Information Opaque LSAs with different flooding scopes, the one in the LSA with the narrowest flooding scope MUST be used. If it appears in multiple Router Information Opaque LSAs with the same flooding scope, the one in the LSA with the numerically smallest Instance ID MUST be used, and subsequent instances of the SRMS Preference TLV MUST be ignored 👑.

The RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)) ✨. For SRMS Preference TLV advertisement, AS-scoped flooding SHOULD be used 🦋, because SRMS servers can be in a different area from the consumers of the SRMS advertisements 💜. If the SRMS advertisements from the SRMS server are only used inside the SRMS server's area, area-scoped flooding MAY be used 🌈.

4. OSPF Extended Prefix Range TLV ✨

Sometimes it's super useful to advertise attributes for a whole range of prefixes at once, instead of one prefix at a time 🧚. The SR Mapping Server from [RFC8661] is a perfect example: it needs one advertisement to cover SIDs for multiple prefixes from a contiguous address range. Iconic efficiency 💅.

That's where the OSPF Extended Prefix Range TLV comes in 🎀. It's a top-level TLV of the Extended Prefix LSA described in [RFC7684], and it was made for exactly this job.

Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each OSPF Extended Prefix Opaque LSA 🌸. BUT (and this is important, bestie) all prefix ranges in a single OSPF Extended Prefix Opaque LSA MUST have the same flooding scope 🚨. Here's what the TLV looks like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |     AF        |         Range Size            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Flags       |                Reserved                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Address Prefix (variable)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sub-TLVs (variable)                      |
   +-                                                             -+
   |                                                               |

Here's what each field is doing:

  • Type: 2 🔥
  • Length: Variable, in octets, depending on the sub-TLVs 📏
  • Prefix Length: Length of prefix in bits 🔢
  • AF: The address family for the prefix. Right now, the only supported value is 0 for IPv4 unicast. Having AF in this TLV leaves room for future extension ✨.
  • Range Size: The number of prefixes covered by the advertisement 🌈. The Range Size MUST NOT exceed the number of prefixes that could be satisfied by the Prefix Length without including the IPv4 multicast address range (224.0.0.0/3). So no sneaking multicast in there, periodt 🙅‍♀️.
  • Flags: A single-octet field 🦋. The following flags are defined:
    0  1  2  3  4  5  6  7
  +--+--+--+--+--+--+--+--+
  |IA|  |  |  |  |  |  |  |
  +--+--+--+--+--+--+--+--+
  • IA-Flag (Inter-Area Flag): If set, the advertisement is of inter-area type 🗺️. An Area Border Router (ABR) that advertises the OSPF Extended Prefix Range TLV between areas MUST set this bit 👑.

This bit is what stops redundant flooding of Prefix Range TLVs between areas, and here's how it works 🧠:

  • An ABR only propagates an inter-area Prefix Range advertisement from the backbone area to connected nonbackbone areas if that advertisement is considered to be the best one. To pick the best range from the set of advertisements for the same Prefix Range, these rules apply:
    • An ABR always prefers intra-area Prefix Range advertisements over inter-area advertisements 💖.
    • An ABR does not consider inter-area Prefix Range advertisements coming from nonbackbone areas 🙈.
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception 🫶.
  • Address Prefix: For the IPv4 unicast address family, the prefix itself is encoded as a 32-bit value 💜. The default route is represented by a prefix of length 0 🌍. Prefix encoding for other address families is beyond the scope of this specification, so that's a different story for a different day 📚.

5. Prefix-SID Sub-TLV ✨

okay so the Prefix-SID Sub-TLV is a sub-TLV that lives inside two parents: the OSPF Extended Prefix TLV from [RFC7684] and the OSPF Extended Prefix Range TLV from Section 4. It MAY show up more than once in its parent TLV 💅. Here's the layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Flags    |   Reserved    |      MT-ID    |    Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     SID/Index/Label (variable)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:

  • Type: 2
  • Length: 7 or 8 octets, depending on the V-Flag
  • Flags: a single-octet field. These flags are defined:
 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
|  |NP|M |E |V |L |  |  |
+--+--+--+--+--+--+--+--+
  • NP-Flag (No-PHP, Penultimate Hop Popping) 🙈: if set, the penultimate hop MUST NOT pop the Prefix-SID before delivering packets to the node that advertised the Prefix-SID.
  • M-Flag (Mapping Server) 🗺️: if set, the SID was advertised by an SR Mapping Server as described in [RFC8661].
  • E-Flag (Explicit Null) 🧊: if set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with the Explicit NULL label (0 for IPv4) before forwarding the packet.
  • V-Flag (Value/Index) 🔢: if set, the Prefix-SID carries an absolute value. If not set, it carries an index.
  • L-Flag (Local/Global) 🌍: if set, the value/index carried by the Prefix-SID has local significance. If not set, the value/index carried by this sub-TLV has global significance.
  • Other bits: reserved. These MUST be zero when sent and are ignored when received.
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception.
  • MT-ID: Multi-Topology ID (as defined in [RFC4915]).
  • Algorithm: a single octet identifying the algorithm the Prefix-SID is associated with, as defined in Section 3.1. A router that receives a Prefix-SID from a remote node, with an algorithm value the remote node has not advertised in the SR-Algorithm TLV (Section 3.1), MUST ignore the Prefix-SID Sub-TLV. 🚫
  • SID/Index/Label: what this field holds depends on the V- and L-Flags:
    • V-Flag set to 0 and L-Flag set to 0: the SID/Index/Label field is a 4-octet index defining the offset in the SID/Label space advertised by this router.
    • V-Flag set to 1 and L-Flag set to 1: the SID/Index/Label field is a 3-octet local label, where the 20 rightmost bits are used for encoding the label value.
    • All other combinations of V-Flag and L-Flag are invalid, and any SID Advertisement received with an invalid setting for V- and L-Flags MUST be ignored. 💀

If an OSPF router advertises multiple Prefix-SIDs for the same prefix, topology, and algorithm, all of them MUST be ignored. Yikes, no double-dipping 😭

When calculating the outgoing label for the prefix, the router MUST take into account, as described below, the E-, NP-, and M-Flags advertised by the next-hop router if that router advertised the SID for the prefix. This MUST be done regardless of whether the next-hop router contributes to the best path to the prefix. ✨

The NP-Flag (No-PHP) MUST be set and the E-Flag MUST be clear for Prefix-SIDs allocated to inter-area prefixes that are originated by the ABR based on intra-area or inter-area reachability between areas, unless the advertised prefix is directly attached to the ABR. 🌉

The NP-Flag (No-PHP) MUST be set and the E-Flag MUST be clear for Prefix-SIDs allocated to redistributed prefixes, unless the redistributed prefix is directly attached to the Autonomous System Boundary Router (ASBR). 🌐

If the NP-Flag is not set, then:

  • Any upstream neighbor of the Prefix-SID originator MUST pop the Prefix-SID. This is equivalent to the penultimate hop-popping mechanism used in the MPLS data plane.
  • The received E-Flag is ignored.

If the NP-Flag is set and the E-Flag is not set, then:

  • Any upstream neighbor of the Prefix-SID originator MUST keep the Prefix-SID on top of the stack. This is useful when the originator of the Prefix-SID needs to stitch the incoming packet into a continuing MPLS LSP to the final destination. This could occur at an ABR (prefix propagation from one area to another) or at an ASBR (prefix propagation from one domain to another). 🧵

If both the NP-Flag and E-Flag are set, then:

  • Any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with an Explicit NULL label. This is useful, e.g., when the originator of the Prefix-SID is the final destination for the related prefix and the originator wishes to receive the packet with the original EXP bits. 🎀

When the M-Flag is set, the NP-Flag and the E-Flag MUST be ignored on reception. 🗺️

As the Mapping Server does not specify the originator of a prefix advertisement, it is not possible to determine PHP behavior solely based on the Mapping Server Advertisement. However, PHP behavior SHOULD be done in the following cases:

  • The Prefix is intra-area type and the downstream neighbor is the originator of the prefix.
  • The Prefix is inter-area type and the downstream neighbor is an ABR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-Flag set for this prefix as described in Section 2.1 of [RFC7684].
  • The Prefix is external type and the downstream neighbor is an ASBR, which is advertising prefix reachability and is also generating the Extended Prefix TLV with the A-Flag set for this prefix as described in Section 2.1 of [RFC7684].

When a Prefix-SID is advertised in an Extended Prefix Range TLV, the value advertised in the Prefix-SID Sub-TLV is interpreted as a starting SID/Label value. 🧮

Example 1: If the following router addresses (loopback addresses) need to be mapped into the corresponding Prefix-SID indexes:

          Router-A: 192.0.2.1/32, Prefix-SID: Index 1
          Router-B: 192.0.2.2/32, Prefix-SID: Index 2
          Router-C: 192.0.2.3/32, Prefix-SID: Index 3
          Router-D: 192.0.2.4/32, Prefix-SID: Index 4

then the Prefix field in the Extended Prefix Range TLV would be set to 192.0.2.1, Prefix Length would be set to 32, Range Size would be set to 4, and the Index value in the Prefix-SID Sub-TLV would be set to 1.

Example 2: If the following prefixes need to be mapped into the corresponding Prefix-SID indexes:

           192.0.2.0/30, Prefix-SID: Index 51
           192.0.2.4/30, Prefix-SID: Index 52
           192.0.2.8/30, Prefix-SID: Index 53
          192.0.2.12/30, Prefix-SID: Index 54
          192.0.2.16/30, Prefix-SID: Index 55
          192.0.2.20/30, Prefix-SID: Index 56
          192.0.2.24/30, Prefix-SID: Index 57

then the Prefix field in the Extended Prefix Range TLV would be set to 192.0.2.0, Prefix Length would be set to 30, Range Size would be 7, and the Index value in the Prefix-SID Sub-TLV would be set to 51. 🍓

6. Adjacency Segment Identifier (Adj-SID) 💖

An Adjacency Segment Identifier (Adj-SID) represents a router adjacency in Segment Routing. Basically, it's the label that says "send it down this link" 🦋

6.1. Adj-SID Sub-TLV 🎀

Adj-SID is an optional sub-TLV of the Extended Link TLV defined in [RFC7684]. It MAY appear multiple times in the Extended Link TLV. Here's the format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Flags     |    Reserved   |   MT-ID       |  Weight       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+---------------------------------------------------------------+

where:

  • Type: 2
  • Length: 7 or 8 octets, depending on the V-Flag
  • Flags: a single-octet field containing these flags:
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|V|L|G|P|     |
+-+-+-+-+-+-+-+-+
  • B-Flag (Backup) 🛡️: if set, the Adj-SID refers to an adjacency that is eligible for protection (e.g., using IP Fast Reroute or MPLS-FRR (MPLS-Fast Reroute)) as described in Section 2.1 of [RFC8402].
  • V-Flag (Value/Index) 🔢: if set, the Adj-SID carries an absolute value. If not set, it carries an index.
  • L-Flag (Local/Global) 🌍: if set, the value/index carried by the Adj-SID has local significance. If not set, the value/index carried by this sub-TLV has global significance.
  • G-Flag (Group) 👯: when set, the G-Flag indicates that the Adj-SID refers to a group of adjacencies (and therefore MAY be assigned to other adjacencies as well).
  • P-Flag (Persistent) 📌: when set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap.
  • Other bits: reserved. These MUST be zero when sent and are ignored when received.
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception.
  • MT-ID: Multi-Topology ID (as defined in [RFC4915].
  • Weight: weight used for load-balancing purposes. The use of the weight is defined in [RFC8402].
  • SID/Index/Label: as described in Section 5.

An SR-capable router MAY allocate an Adj-SID for each of its adjacencies, and set the B-Flag when the adjacency is eligible for protection by an FRR mechanism (IP or MPLS) as described in Section 3.5 of [RFC8402]. 🌸

An SR-capable router MAY allocate more than one Adj-SID to an adjacency. 🧁

An SR-capable router MAY allocate the same Adj-SID to different adjacencies. 🔁

When the P-Flag is not set, the Adj-SID MAY be persistent. When the P-Flag is set, the Adj-SID MUST be persistent. 💜

6.2. LAN Adj-SID Sub-TLV 🎀

okay so the LAN Adjacency SID is an optional sub-TLV of the Extended Link TLV defined in [RFC7684] 🫶 It MAY appear multiple times in the Extended Link TLV. It's used to advertise a SID/Label for an adjacency to a non-DR (Designated Router) router on a broadcast, Non-Broadcast Multi-Access (NBMA), or hybrid [RFC6845] network ✨

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Type             |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Flags     |    Reserved   |     MT-ID     |    Weight     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Neighbor ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    SID/Label/Index (variable)                 |
   +---------------------------------------------------------------+

where:

  • Type: 3
  • Length: 11 or 12 octets, depending on the V-Flag
  • Flags: Same as in Section 6.1
  • Reserved: SHOULD be set to 0 on transmission and MUST be ignored on reception
  • MT-ID: Multi-Topology ID (as defined in [RFC4915])
  • Weight: Weight used for load-balancing purposes. The use of the weight is defined in [RFC8402].
  • Neighbor ID: The Router ID of the neighbor for which the LAN Adjacency SID is advertised
  • SID/Index/Label: As described in Section 5

When the P-Flag is not set, the LAN Adjacency SID MAY be persistent. When the P-Flag is set, the LAN Adjacency SID MUST be persistent. no cap, the P-Flag is the boss here 👑

7. Elements of Procedure 🌈

7.1. Intra-area Segment Routing in OSPFv2

An OSPFv2 router that supports Segment Routing MAY advertise Prefix-SIDs for any prefix to which it is advertising reachability (e.g., a loopback IP address as described in Section 5). 💖

A Prefix-SID can also be advertised by the SR Mapping Servers (as described in [RFC8661]). A Mapping Server advertises Prefix-SIDs for remote prefixes that exist in the OSPFv2 routing domain. Multiple Mapping Servers can advertise Prefix-SIDs for the same prefix; in which case, the same Prefix-SID MUST be advertised by all of them. The flooding scope of the OSPF Extended Prefix Opaque LSA that is generated by the SR Mapping Server could be either area scoped or AS scoped and is determined based on the configuration of the SR Mapping Server. the mapping server is giving organizer, ngl 🧚

An SR Mapping Server MUST use the OSPF Extended Prefix Range TLV when advertising SIDs for prefixes. Prefixes of different route types can be combined in a single OSPF Extended Prefix Range TLV advertised by an SR Mapping Server. Because the OSPF Extended Prefix Range TLV doesn't include a Route-Type field, as in the OSPF Extended Prefix TLV, it is possible to include adjacent prefixes from different route types in the OSPF Extended Prefix Range TLV.

Area-scoped OSPF Extended Prefix Range TLVs are propagated between areas. Similar to propagation of prefixes between areas, an ABR only propagates the OSPF Extended Prefix Range TLV that it considers to be the best from the set it received. The rules used to pick the best OSPF Extended Prefix Range TLV are described in Section 4.

When propagating an OSPF Extended Prefix Range TLV between areas, ABRs MUST set the IA-Flag. This is used to prevent redundant flooding of the OSPF Extended Prefix Range TLV between areas as described in Section 4. 🦋

7.2. Inter-area Segment Routing in OSPFv2

In order to support SR in a multiarea environment, OSPFv2 MUST propagate Prefix-SID information between areas. The following procedure is used to propagate Prefix-SIDs between areas.

When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area prefix to all its connected areas, it will also originate an OSPF Extended Prefix Opaque LSA as described in [RFC7684]. The flooding scope of the OSPF Extended Prefix Opaque LSA type will be set to area-local scope. The route type in the OSPF Extended Prefix TLV is set to inter-area. The Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID value will be set as follows:

  • The ABR will look at its best path to the prefix in the source area and find the advertising router associated with the best path to that prefix.
  • The ABR will then determine if this router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas.
  • If no Prefix-SID was advertised for the prefix in the source area by the router that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas.

When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area route to all its connected areas, it will also originate an OSPF Extended Prefix Opaque LSA as described in [RFC7684]. The flooding scope of the OSPF Extended Prefix Opaque LSA type will be set to area-local scope. The route type in the OSPF Extended Prefix TLV is set to inter-area. The Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID will be set as follows:

  • The ABR will look at its best path to the prefix in the backbone area and find the advertising router associated with the best path to that prefix.
  • The ABR will then determine if such a router advertised a Prefix-SID for the prefix and use it when advertising the Prefix-SID to other connected areas.
  • If no Prefix-SID was advertised for the prefix in the backbone area by the ABR that contributes to the best path to the prefix, the originating ABR will use the Prefix-SID advertised by any other router when propagating the Prefix-SID for the prefix to other areas.

7.3. Segment Routing for External Prefixes

Type-5 LSAs are flooded domain wide. When an ASBR, which supports SR, generates Type-5 LSAs, it SHOULD also originate OSPF Extended Prefix Opaque LSAs as described in [RFC7684]. The flooding scope of the OSPF Extended Prefix Opaque LSA type is set to AS-wide scope. The route type in the OSPF Extended Prefix TLV is set to external. The Prefix-SID Sub-TLV is included in this LSA and the Prefix-SID value will be set to the SID that has been reserved for that prefix. 🔥

When a Not-So-Stubby Area (NSSA) [RFC3101] ABR translates Type-7 LSAs into Type-5 LSAs, it SHOULD also advertise the Prefix-SID for the prefix. The NSSA ABR determines its best path to the prefix advertised in the translated Type-7 LSA and finds the advertising router associated with that path. If the advertising router has advertised a Prefix-SID for the prefix, then the NSSA ABR uses it when advertising the Prefix-SID for the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other router will be used. 🍓

7.4. Advertisement of Adj-SID

The Adjacency Segment Routing Identifier (Adj-SID) is advertised using the Adj-SID Sub-TLV as described in Section 6. 🧚

An Adj-SID MAY be advertised for any adjacency on a point-to-point (P2P) link that is in neighbor state 2-Way or higher. If the adjacency on a P2P link transitions from the FULL state, then the Adj-SID for that adjacency MAY be removed from the area. If the adjacency transitions to a state lower than 2-Way, then the Adj-SID Advertisement MUST be withdrawn from the area. 🙈

7.4.2. Adjacency SID on Broadcast or NBMA Interfaces

Broadcast, NBMA, or hybrid [RFC6845] networks in OSPF are represented by a star topology where the Designated Router (DR) is the central point to which all other routers on the broadcast, NBMA, or hybrid network connect. As a result, routers on the broadcast, NBMA, or hybrid network advertise only their adjacency to the DR. Routers that do not act as DR do not form or advertise adjacencies with each other. They do, however, maintain 2-Way adjacency state with each other and are directly reachable. 🌸

When Segment Routing is used, each router on the broadcast, NBMA, or hybrid network MAY advertise the Adj-SID for its adjacency to the DR using the Adj-SID Sub-TLV as described in Section 6.1.

SR-capable routers MAY also advertise a LAN Adjacency SID for other neighbors (e.g., Backup Designated Router, DR-OTHER, etc.) on the broadcast, NBMA, or hybrid network using the LAN Adj-SID Sub-TLV as described in Section 6.2. 💜

8. IANA Considerations 🦋

This specification updates several existing OSPF registries and creates a new IGP registry.

8.1. OSPF Router Information (RI) TLVs Registry

The following values have been allocated:

+-------+---------------------+---------------+
| Value | TLV Name            | Reference     |
+=======+=====================+===============+
| 8     | SR-Algorithm TLV    | This document |
+-------+---------------------+---------------+
| 9     | SID/Label Range TLV | This document |
+-------+---------------------+---------------+
| 14    | SR Local Block TLV  | This document |
+-------+---------------------+---------------+
| 15    | SRMS Preference TLV | This document |
+-------+---------------------+---------------+

Table 1: OSPF Router Information (RI) TLVs

8.2. OSPFv2 Extended Prefix Opaque LSA TLVs Registry

The following values have been allocated:

+-------+--------------------------------+---------------+
| Value | Description                    | Reference     |
+=======+================================+===============+
| 2     | OSPF Extended Prefix Range TLV | This document |
+-------+--------------------------------+---------------+

Table 2: OSPFv2 Extended Prefix Opaque LSA TLVs

8.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry

The following values have been allocated:

+-------+--------------------+---------------+
| Value | Description        | Reference     |
+=======+====================+===============+
| 1     | SID/Label Sub-TLV  | This document |
+-------+--------------------+---------------+
| 2     | Prefix-SID Sub-TLV | This document |
+-------+--------------------+---------------+

Table 3: OSPFv2 Extended Prefix TLV Sub-TLVs

The following initial values have been allocated:

+-------+---------------------------+---------------+
| Value | Description               | Reference     |
+=======+===========================+===============+
| 1     | SID/Label Sub-TLV         | This document |
+-------+---------------------------+---------------+
| 2     | Adj-SID Sub-TLV           | This document |
+-------+---------------------------+---------------+
| 3     | LAN Adj-SID/Label Sub-TLV | This document |
+-------+---------------------------+---------------+

Table 4: OSPFv2 Extended Link TLV Sub-TLVs

8.5. IGP Algorithm Types Registry 🌈

okay so IANA made a new subregistry called "IGP Algorithm Type" 🎀 and it lives under the "Interior Gateway Protocol (IGP) Parameters" registry. the registration policy is "Standards Action" ([RFC8126] and [RFC7120]) so it's not a free-for-all, it's a whole vibe check 💅

values in this registry come from the range 0-255 🔢

here are the starter values in the IGP Algorithm Type registry 👑

+-------+--------------------------------------------+-----------+
| Value | Description                                | Reference |
+=======+============================================+===========+
| 0     | Shortest Path First (SPF) algorithm based  | This      |
|       | on link metric.  This is the standard      | document  |
|       | shortest path algorithm as computed by the |           |
|       | IGP protocol.  Consistent with the         |           |
|       | deployed practice for link-state           |           |
|       | protocols, Algorithm 0 permits any node to |           |
|       | overwrite the SPF path with a different    |           |
|       | path based on its local policy.            |           |
+-------+--------------------------------------------+-----------+
| 1     | Strict Shortest Path First (SPF) algorithm | This      |
|       | based on link metric.  The algorithm is    | document  |
|       | identical to Algorithm 0, but Algorithm 1  |           |
|       | requires that all nodes along the path     |           |
|       | will honor the SPF routing decision.       |           |
|       | Local policy at the node claiming support  |           |
|       | for Algorithm 1 MUST NOT alter the SPF     |           |
|       | paths computed by Algorithm 1.             |           |
+-------+--------------------------------------------+-----------+

                      Table 5: IGP Algorithm Types

so Algorithm 0 is the classic SPF that any node can overwrite with its own local policy 🙃, while Algorithm 1 is the strict one 💖. it's the same math, but every node along the path has to actually honor the SPF decision, and a node that says it supports Algorithm 1 MUST NOT alter the SPF paths Algorithm 1 computes. no local policy drama allowed 🚫✨

9. TLV/Sub-TLV Error Handling 🫶

bestie, this one's important 🥺 for any new TLVs/sub-TLVs defined in this document, if the length is invalid, the LSA they're advertised in is considered malformed and MUST be ignored. an error SHOULD be logged too, but it has to be rate limited 🚦 so nobody gets spammed into oblivion 💀

10. Security Considerations 😭🔥

okay this section is giving drama and I respect it 💅

with the OSPFv2 Segment Routing extensions in this doc, OSPFv2 will now program the MPLS data plane [RFC3031] as well as the IP data plane 🌸. before this, LDP [RFC5036] or some other label distribution mechanism was needed to advertise MPLS labels and program the MPLS data plane 🏃‍♀️

in general, the same kinds of attacks that work on the IP control plane can also work on the MPLS control plane, and that can misroute traffic in the respective data planes 🙈. the sneaky part is that this one is way harder to detect and isolate 😬

the existing security extensions in [RFC2328] and [RFC7684] apply to these Segment Routing extensions too 🦋. OSPF usually lives under a single administrative domain, but there can be deployments where attackers have access to one or more networks in the OSPF routing domain 👀. in those cases, stronger authentication mechanisms like the ones in [RFC7474] SHOULD be used 🔐

implementations MUST make sure that malformed TLVs and sub-TLVs defined in this document are detected and don't give attackers a way to crash the OSPFv2 router or routing process 🚨. receiving malformed TLVs or sub-TLVs SHOULD be counted and/or logged for further analysis, and that logging SHOULD be rate limited so a Denial of Service (DoS) attack (distributed or otherwise) can't flood the OSPF control plane 🌊

11. References 📚

11.1. Normative References 💜

11.2. Informative References 🧚

Acknowledgements 🎀

we want to give a huge thank you to Anton Smirnov for his contribution 🫶

and a big ol' thanks to Acee Lindem for the super detailed review of the document, the corrections, and the chats about the encoding details 👑

Contributors 💖

these people gave a substantial contribution to the content of this document, so they're literal legends 🌟: Acee Lindem, Ahmed Bashandy, Martin Horneffer, Bruno Decraene, Stephane Litkowski, Igor Milojevic, and Saku Ytti ✨

Authors' Addresses 🧁

Peter Psenak (editor)
Cisco Systems, Inc.
Apollo Business Center, Mlynske nivy 43
821 09 Bratislava
Slovakia

Email: ppsenak@cisco.com


Stefano Previdi (editor)
Cisco Systems, Inc.
Via Del Serafico, 200
00142 Rome
Italy

Email: stefano@previdi.net


Clarence Filsfils
Cisco Systems, Inc.
Brussels
Belgium

Email: cfilsfil@cisco.com


Hannes Gredler
RtBrick Inc.

Email: hannes@rtbrick.com


Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America

Email: robjs@google.com


Wim Henderickx
Nokia
Copernicuslaan 50
2018 Antwerp
Belgium

Email: wim.henderickx@nokia.com


Jeff Tantsura
Apstra, Inc.

Email: jefftant.ietf@gmail.com
📦 where this page comes from