RFC 8510

OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement

📅 published January 2019, from ietf

Okay bestie, let's get into this one 💖 The title block tells us the basics first:

  • RFC number: 8510 🎀
  • Title: OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement
  • Authors: P. Psenak (editor), K. Talaulikar, and W. Henderickx, with P. Pillay-Esnault. Psenak and Talaulikar are at Cisco Systems, Inc., Henderickx is at Nokia, and Pillay-Esnault is at Huawei USA. 🌈
  • Category: Standards Track 🔥
  • ISSN: 2070-1721
  • Date: January 2019 🌸
  • Obsoletes / Updates: The title block doesn't list any documents this one obsoletes or updates. ⭐

Abstract

Every OSPF interface gets an Interface ID that uniquely identifies it on the router. Sometimes it's really useful to know the Interface ID that the other side of the adjacency assigned, which is called the Remote Interface ID 🦋

This document describes the extensions to OSPF link-local signaling (LLS) that advertise the Local Interface ID. ✨

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

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc8510 💜

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 in effect on the date of publication of this document. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License. 🫶

Table of Contents 🧚

   1. Introduction ....................................................3
      1.1. Interface ID Exchange Using Link Local TE Opaque LSA .......4
      1.2. Requirements Language ......................................4
   2. Interface ID Exchange Using OSPF LLS ............................4
      2.1. Local Interface ID TLV .....................................5
   3. Backward Compatibility with RFC 4203 ............................5
   4. IANA Considerations .............................................6
   5. Security Considerations .........................................6
   6. References ......................................................6
      6.1. Normative References .......................................6
      6.2. Informative References .....................................7
   Acknowledgments ....................................................8
   Authors' Addresses .................................................8

1. Introduction ✨

Okay so the big idea is that every OSPF interface gets an Interface ID that uniquely identifies it on the router. [RFC2328] uses this Interface ID in the Router Link State Advertisement (Router-LSA) Link Data for unnumbered links, and it uses the value of the MIB-II ifIndex [RFC2863]. [RFC4203] calls these Interface IDs the Link Local/Remote Identifiers and defines a way to advertise and use them for GMPLS purposes. [RFC8379] defines a way to advertise Local/Remote Interface IDs in the OSPFv2 Extended Link Opaque LSA. 💅

Now here's the problem 😭 OSPFv2 has a known issue with verifying bidirectional connectivity over parallel unnumbered links. Say there are two parallel unnumbered links between a pair of routers, and each link is only advertised from one direction. Some other router doing the OSPF route computation can end up treating those two one-way parallel links as one valid bidirectional link. 🙈 If each link is advertised with both its Local and Remote Interface IDs, then both sides of the adjacency can verify the advertisement by cross-checking the Local and Remote Interface IDs in both advertisements. It's giving puzzle pieces clicking together 🧩

From the advertising router's point of view, the Local Interface ID is already known. The Remote Interface ID, though, has to be learned before it can be advertised. [RFC4203] suggests using the TE Link Local LSA [RFC3630] to tell neighbors on the link about the Local Interface ID. That works, but it has some drawbacks. 🥲

This document proposes an extension to OSPF link-local signaling (LLS) [RFC5613] that advertises the Local Interface ID. Main character energy 👑

Using the Link Local TE Opaque LSA to pass the Local Interface ID to neighbors on the link is described in [RFC4203]. This mechanism has a couple of problems 💀

  • LSAs can only be flooded over an existing adjacency that's in Exchange state or greater. The adjacency state machine moves along independently on each side, so one side can hit Full before the Link Local TE Opaque LSA shows up. The result is that the link can first get advertised without the Remote Interface ID. Later, when the Link Local TE Opaque LSA arrives, the link has to be advertised again, this time with the valid Remote Interface ID. Implementations can choose to wait before advertising the link, but there's no guarantee the neighbor will ever send the Link Local TE Opaque LSA with the Interface ID. Basically, the existing mechanism doesn't guarantee that the Remote Interface ID is known when the link gets advertised. 😤
  • The Link Local TE Opaque LSA is defined for MPLS Traffic Engineering, but knowing the Remote Interface ID is useful even when MPLS TE isn't in use. The example mentioned above is the lack of a valid 2-way connectivity check for parallel point-to-point links between OSPF routers. 🙄

1.2. Requirements Language

Here's how the key words work in this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 📚🎀

2. Interface ID Exchange Using OSPF LLS ✨

To fix the problems we just talked about, and to let the Interface ID exchange be part of the neighbor discovery process, we propose extending OSPF link-local signaling so the Local Interface ID gets advertised in OSPF Hello and Database Description (DD) packets. Honestly so smart 🧠🦋

2.1. Local Interface ID TLV

The Local Interface ID TLV is an LLS TLV. Here's its 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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Local Interface ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 18
  • Length: 4 octets
  • Local Interface ID: The value of the Local Interface ID.

Local Interface ID TLV signaling using LLS applies to all OSPF interface types except virtual links. 🌸

3. Backward Compatibility with RFC 4203 🫶

Here's the deal if you're still using the Link Local TE Opaque LSA alongside the new LLS mechanism. Implementations that support Local Interface ID signaling using LLS MUST prefer the Local Interface ID value received through LLS over the value received through the Link Local TE Opaque LSA, as long as both come from the same OSPF router. 💅

Implementations that support Local Interface ID signaling via the Link Local TE Opaque LSA MAY keep doing that for backward compatibility. If they also support Local Interface ID signaling using LLS, as described in this document, they MUST signal the same Local Interface ID through both mechanisms. ✨

Now, the rare times when the Local Interface ID changes can create a short window where the values advertised through LLS and through the Link Local TE Opaque LSA don't match. That's temporary 🥹 The two values should become equal as soon as the originator regenerates the next Hello and/or Link Local TE Opaque LSA.

Part 2 picks up with Section 4 (IANA Considerations), Section 5 (Security Considerations), and Section 6 (References), so stay tuned 🦋

6.1. Normative References

okay bestie, these are the docs this RFC needs you to have read first 📚✨ BCP 14 labels stay exactly as written. [RFC8174] is the one that clears up the uppercase vs lowercase confusion 💅

6.2. Informative References

these ones are more like bonus reading 🌸 you don't need them to get the spec, but they're lowkey useful for the backstory

Acknowledgments 🫶

big thank you to Tony Przygienda 💖 he went through the whole thing with a fine-toothed comb and left really useful comments. literally the MVP 👑

Authors' Addresses 🎀

these are the people who wrote it, so here's where to find them 🦋

Peter Psenak (editor) 💅

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

Email: ppsenak@cisco.com

Ketan Talaulikar 🌈

Ketan Talaulikar
Cisco Systems, Inc.
S.No. 154/6, Phase I, Hinjawadi
Pune, Maharashtra  411 057
India

Email: ketant@cisco.com

Wim Henderickx ✨

Wim Henderickx
Nokia
Copernicuslaan 50
Antwerp  2018
Belgium

Email: wim.henderickx@nokia.com

Padma Pillay-Esnault 🧚

Padma Pillay-Esnault
Huawei USA
2330 Central Expressway
Santa Clara,  CA 95050
United States of America

Email: padma@huawei.com
📦 where this page comes from