RFC 9084

OSPF Prefix Originator Extensions

📅 published August 2021, from ietf

RFC 9084: OSPF Prefix Originator Extensions 🦋

Bestie, meet RFC 9084 🎀 It's a Standards Track document from the Internet Engineering Task Force (IETF), with Request for Comments: 9084, ISSN 2070-1721, dated August 2021 ✨

The authors are A. Wang (China Telecom), A. Lindem (Cisco Systems, Inc.), J. Dong (Huawei Technologies), P. Psenak (Cisco Systems, Inc.), and K. Talaulikar, Ed. (Cisco Systems, Inc.) 👑 The title block doesn't list anything this document obsoletes or updates, so it's standing on its own 💅

Abstract 💖

Okay so this doc adds OSPF extensions that carry info about the node that originated a prefix, riding along with the prefix advertisement itself 🧚 The best part is that none of this changes how OSPF does its core route computation. It just hands you juicy info for network analysis, troubleshooting, and stuff like traffic engineering 🔥

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 📚

Info about the current status of this doc, any errata, and how to give feedback on it lives at https://www.rfc-editor.org/info/rfc9084 🌸

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved ©️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this document need to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License ⚖️

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
2.  Protocol Extensions
  2.1.  Prefix Source OSPF Router-ID Sub-TLV
  2.2.  Prefix Source Router Address Sub-TLV
3.  Elements of Procedure
4.  Security Considerations
5.  Operational Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgement
Authors' Addresses

1. Introduction ✨

Okay so prefix attributes get advertised in OSPFv2 [RFC2328] using the Extended Prefix Opaque Link State Advertisement (LSA) [RFC7684], and in OSPFv3 [RFC5340] using the various Extended Prefix LSA types [RFC8362] 💅

Here's the tea: figuring out which router originated a prefix in OSPF depends on what kind of prefix it is, and right now it isn't always possible to get an accurate answer 😭 For intra-area prefixes, the originating router is the Advertising Router field of the area-scoped LSA used for those advertisements, which is nice and easy 🫶 But for inter-area prefixes advertised by an Area Border Router (ABR), the Advertising Router field of their area-scoped LSAs is set to the ABR itself, and the info about who really originated the prefix gets lost when the prefix moves across areas 💀 For Autonomous System (AS) external prefixes, the originating router may be considered the Autonomous System Border Router (ASBR), identified by the Advertising Router field of the AS-scoped LSA used. The actual originator, though, could be a remote router sitting outside the OSPF domain 👀 Same story with Not-So-Stubby Area (NSSA) [RFC3101] LSAs: when an ABR translates them into AS-external LSAs, the info about the NSSA ASBR (or the router outside the OSPF domain) doesn't get propagated across the OSPF domain 😤

Now, a router is usually identified in OSPF by its OSPF Router ID, but that isn't necessarily a reachable address for the router 🙃 The OSPF Router ID is a 32-bit number that's unique within the OSPF domain, and that's it. For OSPFv2, a common practice is to use one of the node's IPv4 addresses (for example, a loopback interface) as the OSPF Router ID. But you can't always assume that, and the approach doesn't apply to IPv6 addresses with OSPFv3 🥺 The IPv4/IPv6 Router Address, defined in [RFC3630] for OSPFv2 and [RFC5329] for OSPFv3, is what gives you an address to reach the advertising router 🦋

The main use case for the extensions in this document is being able to identify who originated a prefix in the network 🔍 When one router advertises multiple prefixes, it's also super useful to tie all of those prefixes back to that single router, even when they've been advertised outside the area they started in. It also helps you spot when the same prefix is being originated by multiple routers across areas 🧠

So this document proposes OSPF extensions that include info about the router that originated the prefix right in the prefix advertisement 💖 These extensions don't change the core OSPF route computation functionality. They just provide useful info for topology analysis and traffic engineering, especially on a controller, when this info gets advertised as an attribute of the prefixes through mechanisms like Border Gateway Protocol - Link State (BGP-LS) [RFC7752] [RFC9085] 🌟

1.1. Requirements Language 🎀

Okay so the big ALL-CAPS words you'll spot in this document are BCP 14 vibes. When you see "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document, they mean what BCP 14 [RFC2119] [RFC8174] says they mean. That only counts when they appear in all capitals, just like they do here 🫶

2. Protocol Extensions 🧚

This document defines the Prefix Source OSPF Router-ID and the Prefix Source Router Address Sub-TLVs. They're used, respectively, to include the Router ID of, and a reachable address of, the router that originates the prefix, as a prefix attribute ✨

2.1. Prefix Source OSPF Router-ID Sub-TLV 🍓

For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, it's an optional sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362], used when originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement 🌈

The Prefix Source OSPF Router-ID Sub-TLV has this 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           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        OSPF Router ID                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format

Where:

  • Type: 4 for OSPFv2 and 27 for OSPFv3
  • Length: 4
  • OSPF Router ID: the OSPF Router ID of the OSPF router that originated the prefix advertisement in the OSPF domain

The parent TLV of a prefix advertisement MAY include more than one Prefix Source OSPF Router-ID Sub-TLV, with one for each of the Equal-Cost Multipath (ECMP) nodes that originated the advertised prefix 🔥

For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field isn't the same as the Advertising Router field in the containing LSA. Similar validation can't be reliably done for inter-area and external prefix advertisements 😭

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be considered invalid and ignored. Also, receiving such sub-TLVs SHOULD be logged as an error (subject to rate limiting) 🚨

2.2. Prefix Source Router Address Sub-TLV 🦋

For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional sub-TLV of the OSPFv2 Extended Prefix TLV [RFC7684]. For OSPFv3, it's an optional sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and External-Prefix TLV [RFC8362], used when originating either an IPv4 [RFC5838] or an IPv6 prefix advertisement 💅

The Prefix Source Router Address Sub-TLV has this 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           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Router Address (4 or 16 octets)                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Prefix Source Router Address Sub-TLV Format

Where:

  • Type: 5 for OSPFv2 and 28 for OSPFv3
  • Length: 4 or 16
  • Router Address: a reachable IPv4 or IPv6 router address for the router that originated the IPv4 or IPv6 prefix advertisement, respectively. This address would be semantically equivalent to what may be advertised in the OSPFv2 Router Address TLV [RFC3630] or in the OSPFv3 Router IPv6 Address TLV [RFC5329] 🌸

The parent TLV of a prefix advertisement MAY include more than one Prefix Source Router Address Sub-TLV, with one for each of the Equal-Cost Multipath (ECMP) nodes that originated the advertised prefix 🧚

A received Prefix Source Router Address Sub-TLV whose length is invalid (that is, not consistent with the prefix's address family) MUST be considered invalid and ignored. Also, receiving such sub-TLVs SHOULD be logged as an error (subject to rate limiting) 💖

3. Elements of Procedure ✨

Okay bestie, this is where we get into the actual how-to 💅. This section explains how the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs get advertised together with the prefix they describe 🦋.

The OSPF Router ID in the Prefix Source OSPF Router-ID is set to the OSPF Router ID of the node that originates the prefix in the OSPF domain 🌸.

If the originating node is advertising an OSPFv2 Router Address TLV [RFC3630] or an OSPFv3 Router IPv6 Address TLV [RFC5329], then the same address MUST be used in the Router Address field of the Prefix Source Router Address Sub-TLV 🫶. If the originating node isn't advertising one of those addresses, implementations can pick a unique and reachable local address on the originating node to put in the Router Address field. Good examples are an address advertised with the N-Flag set [RFC7684] or the N-bit set [RFC8362] 🔥.

Now the ABR situation, which is a little dramatic 😭. When an ABR generates inter-area prefix advertisements into its non-backbone areas, and those correspond to an inter-area prefix advertisement that came from the backbone area, the only way to figure out the originating node is by looking at the Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs in the inter-area prefix advertisement. That advertisement was originated into the backbone area by an ABR coming from another non-backbone area. The ABR runs its prefix calculation to find the set of nodes that contribute to ECMP paths for the prefix. It MUST only use prefix originator information from that set of nodes. And the ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it can't work out the information for the originating nodes that contribute ECMP paths 💀.

Implementations may support carrying the originating node information along with a redistributed prefix into the OSPF domain from another routing domain. The details of how that works are out of scope for this document 🌈. Those implementations may also give you control over whether the Router Address in the Prefix Source Router Address Sub-TLV is set to the ASBR node address, or to the address of the actual node outside the OSPF domain that owns the prefix 💜.

When an NSSA ABR translates NSSA prefix advertisements [RFC3101] into AS external prefix advertisements, it follows the same procedures as an ABR generating inter-area prefix advertisements when propagating the originating node information 🧚.

4. Security Considerations 🔒

Okay, this part is serious bestie, so listen up 🙈. Since this document extends the OSPFv2 Extended Prefix LSA, the security considerations for [RFC7684] apply. Similarly, since this document extends the OSPFv3 E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and E-NSSA-LSA, the security considerations for [RFC8362] apply too 💅. The new sub-TLVs introduced in this document are optional, and they don't affect OSPF route computation. That means they don't change the security aspects of OSPF protocol operations ✨.

That said, a rogue node that can inject prefix advertisements could use the extensions in this document to advertise bogus prefix source information 💀. Be careful out there, fr fr 😭.

5. Operational Considerations 🍓

Consideration should be given to the operational impact of the bigger OSPF Link-State Database that results from the protocol extensions in this document 📈. Depending on the deployment design and requirements, you might pick a subset of prefixes that need originating node information included in their advertisements 🦋.

Propagating prefix source node information across OSPF area or domain boundaries exposes information outside the area or domain where the base OSPF protocol would normally hide or abstract it 👀. Based on deployment design and requirements, that propagation can be limited to a subset of prefixes on the ABRs or ASBRs, depending on which boundary is in play 🌸.

Knowing which node originates a specific prefix can really help when you're debugging prefix reachability issues within an OSPF network 🔍 (main character debugging energy).

6. IANA Considerations 📋

Per this document, IANA has allocated the following codepoints from the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open Shortest Path First v2 (OSPFv2) Parameters" registry 🎀.

        +=======+==============================+===========+
        | Value | Description                  | Reference |
        +=======+==============================+===========+
        | 4     | Prefix Source OSPF Router-ID | RFC 9084  |
        +-------+------------------------------+-----------+
        | 5     | Prefix Source Router Address | RFC 9084  |
        +-------+------------------------------+-----------+

           Table 1: Codepoints in OSPFv2 Extended Prefix
                            TLV Sub-TLVs

Per this document, IANA has also allocated the following codepoints from the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest Path First v3 (OSPFv3) Parameters" registry 🧁.

        +=======+==============================+===========+
        | Value | Description                  | Reference |
        +=======+==============================+===========+
        | 27    | Prefix Source OSPF Router-ID | RFC 9084  |
        +-------+------------------------------+-----------+
        | 28    | Prefix Source Router Address | RFC 9084  |
        +-------+------------------------------+-----------+

        Table 2: Codepoints in OSPFv3 Extended-LSA Sub-TLVs

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgement 💖

Huge thanks to Les Ginsberg for his suggestions on this document 🫶. Also a big shoutout to Jeff Tantsura, Rob Shakir, Gunter Van de Velde, Goethals Dirk, Smita Selot, Shaofu Peng, John E. Drake, and Baalajee S. for their review and valuable comments 👑. The authors also want to thank Alvaro Retana for his detailed review and suggestions for improving this document ✨.

Authors' Addresses 🌸

Aijun Wang
China Telecom
Beiqijia Town
Changping District
Beijing
102209
China

Email: wangaj3@chinatelecom.cn
Acee Lindem
Cisco Systems, Inc.
301 Midenhall Way
Cary, NC 27513
United States of America

Email: acee@cisco.com
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China

Email: jie.dong@huawei.com
Peter Psenak
Cisco Systems, Inc.
Eurovea Centre, Central 3
Pribinova Street 10
81109 Bratislava
Slovakia

Email: ppsenak@cisco.com
Ketan Talaulikar (editor)
Cisco Systems, Inc.
India

Email: ketant@cisco.com
📦 where this page comes from