RFC 7770

Extensions to OSPF for Advertising Optional Router Capabilities

📅 published February 2016, from ietf

Extensions to OSPF for Advertising Optional Router Capabilities 💖

okay bestie, this RFC is a Standards Track spec 🎀 from the IETF, written by A. Lindem (Ed.), N. Shen, and JP. Vasseur of Cisco Systems, plus R. Aggarwal of Arktan and S. Shaffer of Akamai 🫶. It's RFC 7770, ISSN 2070-1721, dated February 2016, and it obsoletes RFC 4970 👑. The header doesn't list any updates.

Abstract ✨

okay so routers in an OSPFv2 or OSPFv3 routing domain really need to know what their neighbors and the other routers can do 🧚 this doc proposes extensions to OSPFv2 and OSPFv3 so routers can advertise optional capabilities. the star of the show is the Router Information (RI) LSA 💅 in OSPFv2 it rides as an Opaque LSA type ID, and in OSPFv3 it gets its own unique LSA type function code. either way, the RI LSA can be flooded at any of the defined scopes: link, area, or autonomous system (AS) 🌈

this doc obsoletes RFC 4970 with a glow-up 💜 it adds support for multiple instances of the RI LSA and a TLV for functional capabilities ✨

Status of This Memo 🌸

this is an Internet Standards Track document 🎀

it's a product of the Internet Engineering Task Force (IETF) 💖 it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 more on Internet Standards is in Section 2 of RFC 5741 📚

for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7770 🦋

Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication 📜 please actually read these, bestie, because they explain your rights and restrictions 🙈 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.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
  1.2.  Summary of Changes from RFC 4970  . . . . . . . . . . . .   3
2.  OSPF Router Information (RI) LSA  . . . . . . . . . . . . . .   4
  2.1.  OSPFv2 Router Information (RI) Opaque LSA . . . . . . . .   4
  2.2.  OSPFv3 Router Information (RI) Opaque LSA . . . . . . . .   5
  2.3.  OSPF Router Information LSA TLV Format  . . . . . . . . .   6
  2.4.  OSPF Router Informational Capabilities TLV  . . . . . . .   6
  2.5.  Assigned OSPF Router Informational Capability Bits  . . .   7
  2.6.  OSPF Router Functional Capabilities TLV . . . . . . . . .   8
  2.7.  Flooding Scope of the Router Information LSA  . . . . . .   9
3.  Backwards Compatibility . . . . . . . . . . . . . . . . . . .   9
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
  5.1.  OSPFv2 Opaque LSA Type Assignment . . . . . . . . . . . .  10
  5.2.  OSPFv3 LSA Function Code Assignment . . . . . . . . . . .  10
  5.3.  OSPF RI LSA TLV Type Assignment . . . . . . . . . . . . .  11
  5.4.  Registry for OSPF Router Informational Capability Bits  .  12
  5.5.  Registry for OSPF Router Functional Capability Bits . . .  12
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction 💖

okay so routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFv3] routing domain need to know what their neighbors and other routers can do ✨ this helps with both advertising and discovering OSPFv2 and OSPFv3 capabilities 🧚 through the doc, we just say OSPF when something applies to both, and OSPFv2 or OSPFv3 when the text is protocol specific 🎀

here's the tea 🫖 OSPF already uses the options field in LSAs and hello packets to advertise optional router capabilities. but in OSPFv2, every bit in that field is already allocated, so no new optional capabilities can be advertised that way 😭 this doc describes extensions that advertise these capabilities through Opaque LSAs in OSPFv2 and through LSAs with a unique type in OSPFv3 🦋 for existing OSPF capabilities, backwards compatibility means this advertisement is mainly informational 💅 but for future OSPF extensions, this advertisement MAY be used as the sole mechanism for advertisement and discovery 👑

this document obsoletes RFC 4970 with a revised spec that adds support for advertising multiple instances of the RI LSA and a TLV for functional capabilities 🌈

1.1. Requirements Notation

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC-KEYWORDS] 📚

1.2. Summary of Changes from RFC 4970

okay bestie, here's what changed from RFC 4970 [RFC4970] 🍓

  1. the big one: an OSPF router can now advertise multiple instances of the OSPF Router Information LSA 🔥 this change shows up all over the doc.
  2. Section 2.6 adds a TLV for functional capabilities ✨ the existing TLV is only for informational purposes, so this one is a whole different vibe 💜
  3. the IANA allocation policy changed from "Standards Action" to "IETF Review" [IANA-GUIDE] for these registries:
    • OSPFv3 LSA Function Codes
    • OSPF Router Information (RI) TLVs
    • OSPF Router Informational Capability Bits
    • OSPF Router Functional Capability Bits
  4. last but not least, references got updated for documents that became RFCs and for RFCs that got obsoleted since RFC 4970 was published 🫶

2. OSPF Router Information (RI) LSA 🎀

2.1. OSPFv2 Router Information (RI) Opaque LSA

okay so OSPFv2 routers advertise a link-scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE] 🦋 the OSPFv2 RI LSA has an Opaque type of 4, and its Opaque ID is the RI LSA Instance ID 🧚 the first Opaque ID, which is 0 (i.e., 0), SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV 💅 RI LSA instances after the first can hold whatever doesn't fit in the first one 🌸

ok, the same stuff again but in different words 🙈 OSPFv2 routers advertise a link-scoped, area-scoped, or AS-scoped Opaque LSA [OPAQUE]. the OSPFv2 Router Information LSA has an Opaque type of 4. the Opaque ID specifies the LSA Instance ID, and the first instance always has an Instance ID of 0 💖

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |     Options   |  9, 10, or 11 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       4       |     Opaque ID (Instance ID)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         LS checksum           |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

Figure 1. OSPFv2 Router Information Opaque LSA

the TLVs in the body of an RI LSA follow the format defined in Section 2.3 ✨

2.2. OSPFv3 Router Information (RI) Opaque LSA

okay so the OSPFv3 Router Information LSA has a function code of 12 🌈 the S1/S2 bits depend on the flooding scope you want for the LSA 🧚 the U bit gets set to say the OSPFv3 RI LSA should be flooded even if it isn't understood 💜 the Link State ID (LSID) for this LSA is the Instance ID 🦋 the first Instance ID, which is 0, SHOULD always contain the Router Informational Capabilities TLV and, if advertised, the Router Functional Capabilities TLV 💅 OSPFv3 Router Information LSAs after the first can hold whatever doesn't fit in the first instance 🌸 and OSPFv3 routers MAY advertise multiple RI LSAs per flooding scope 🔥

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            LS age             |1|S12|          12             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID (Instance ID)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Advertising Router                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       LS sequence number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                            TLVs                             -+
   |                             ...                               |

Figure 2. OSPFv3 Router Information LSA

the TLVs in the body of an RI LSA follow the format defined in Section 2.3 ✨

2.3. OSPF Router Information LSA TLV Format ✨

okay so the TLVs inside an RI LSA are built the same way as the ones from the Traffic Engineering Extensions to OSPF [TE] 🎀. Every RI LSA payload is one or more nested Type/Length/Value triplets, and each one is laid out 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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Value...                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 3.  TLV Format

The Length field counts the value portion in octets, so a TLV with no value portion has a length of 0 🌸. Every TLV is padded out to 4-octet alignment, but the padding is NOT counted in the length field. So a 3-octet value gets a length of 3, yet the whole TLV still takes up 8 octets 💅. Nested TLVs are 4-octet aligned too. For example, a 1-octet value has its length field set to 1, and then 3 octets of padding get tacked onto the end of the value portion 🧚. That padding is made of undefined bits. And if you run into a type you don't recognise, you just ignore it 🙈.

When a new Router Information LSA TLV is defined, the specification MUST explicitly state whether the TLV is applicable to OSPFv2 only, OSPFv3 only, or both OSPFv2 and OSPFv3. No guessing allowed, bestie 😤✨

2.4. OSPF Router Informational Capabilities TLV

An OSPF router advertising an OSPF RI LSA MAY include the Router Informational Capabilities TLV 🦋. If it does include it, the TLV MUST be the first TLV in the first instance, which is Instance 0, of the OSPF RI LSA. On top of that, the TLV MUST accurately reflect the OSPF router's capabilities in the scope being advertised. Here's the twist though: the informational capabilities advertised have NO impact on OSPF protocol operation. They're just there for information, full stop 💀✨

Here's how the Router Informational Capabilities TLV is shaped:

       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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Informational Capabilities                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     A 16-bit field set to 1.

      Length   A 16-bit field that indicates the length of the value
               portion in octets and will be a multiple of 4 octets
               dependent on the number of capabilities advertised.
               Initially, the length will be 4, denoting 4 octets of
               informational capability bits.

      Value    A variable-length sequence of capability bits rounded to
               a multiple of 4 octets padded with undefined bits.
               Initially, there are 4 octets of capability bits.  Bits
               are numbered left to right starting with the most
               significant bit being bit 0.

           Figure 4.  OSPF Router Informational Capabilities TLV

Quick breakdown, because the details matter 🔍:

  • Type: a 16-bit field set to 1.
  • Length: a 16-bit field giving the length of the value portion in octets. It's always a multiple of 4 octets, depending on how many capabilities get advertised. At the start it's 4, which means 4 octets of informational capability bits.
  • Value: a variable-length run of capability bits, rounded up to a multiple of 4 octets and padded with undefined bits. At the start there are 4 octets of capability bits. The bits are numbered left to right, with the most significant bit being bit 0 🌈.

The Router Informational Capabilities TLV MAY be followed by optional TLVs that further specify a capability 🍓.

2.5. Assigned OSPF Router Informational Capability Bits

these are the informational capability bits that have been assigned so far 👑:

      Bit       Capabilities

      0         OSPF graceful restart capable [GRACE]
      1         OSPF graceful restart helper  [GRACE]
      2         OSPF Stub Router support [STUB]
      3         OSPF Traffic Engineering support [TE]
      4         OSPF point-to-point over LAN [P2PLAN]
      5         OSPF Experimental TE [EXP-TE]
      6-31      Unassigned (IETF Review)

      Figure 5.  OSPF Router Informational Capabilities Bits

References for [GRACE], [STUB], [TE], [P2PLAN], and [EXP-TE] are included herein 📚💜

2.6. OSPF Router Functional Capabilities TLV

this spec also defines the Router Functional Capabilities TLV, which gets advertised in the OSPF Router Information LSA 🔥. An OSPF router advertising an OSPF RI LSA MAY include the Router Functional Capabilities TLV. If it does, the TLV MUST be included in the first instance of the LSA. The TLV also MUST reflect the advertising OSPF router's actual functional capabilities, because that info is used to dictate OSPF protocol operation within the flooding scope of the containing OSPF RI LSA. This is NOT just for show, bestie 😭. If the TLV isn't included, or the length doesn't cover the assigned OSPF functional capability bit, then that corresponding OSPF functional capability is implicitly advertised as not being supported by the advertising OSPF router 🙅‍♀️.

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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Functional Capabilities                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type     A 16-bit field set to 2.

      Length   A 16-bit field that indicates the length of the value
               portion in octets and will be a multiple of 4 octets
               dependent on the number of capabilities advertised.
               Initially, the length will be 4, denoting 4 octets of
               informational capability bits.

      Value    A variable-length sequence of capability bits rounded
               to a multiple of 4 octets padded with undefined bits.
               Initially, there are 4 octets of capability bits.  Bits
               are numbered left to right starting with the most
               significant bit being bit 0.

             Figure 6.  OSPF Router Functional Capabilities TLV
  • Type: a 16-bit field set to 2.
  • Length: a 16-bit field giving the length of the value portion in octets. It's a multiple of 4 octets depending on how many capabilities get advertised. At the start it's 4, denoting 4 octets of informational capability bits.
  • Value: a variable-length run of capability bits, rounded to a multiple of 4 octets and padded with undefined bits. At the start there are 4 octets of capability bits, numbered left to right with the most significant bit being bit 0 ✨.

The Router Functional Capabilities TLV MAY be followed by optional TLVs that further specify a capability 🧚. Now here's the big difference from the informational one: the OSPF extensions advertised in THIS TLV MAY be used by other OSPF routers to dictate protocol operation 😳. So the specifications for functional capabilities advertised in this TLV MUST describe protocol behaviour AND address backwards compatibility. Non-negotiable, periodt 💅🔥

2.7. Flooding Scope of the Router Information LSA

the flooding scope for an RI LSA is set by its LSA type 🌊. For OSPFv2, a type 9 (link-scoped), type 10 (area-scoped), or type 11 (AS-scoped) Opaque LSA may be flooded. For OSPFv3, the S1 and S2 bits in the LSA type decide the flooding scope. If you pick AS-wide flooding scope, the originating router should also advertise area-scoped LSA(s) into any attached Not-So-Stubby Area (NSSA) area(s) 🦋. An OSPF router MAY advertise different capabilities when both NSSA area-scoped LSA(s) and an AS-scoped LSA are advertised. This lets functional capabilities be limited in scope 🎀. For example, a router might be an area border router but only support traffic engineering (TE) in a subset of its attached areas. Main character router energy 👑

The choice of flooding scope belongs to the advertising router and is a matter of local policy 🫶. The originating router MAY advertise multiple RI LSAs with the same Instance ID, as long as the flooding scopes differ. TLV flooding-scope rules will be specified on a per-TLV basis, and they MUST be specified in the accompanying specifications for future Router Information LSA TLVs 📜.

3. Backwards Compatibility

okay this part is all about keeping old stuff working 🥹. For backwards compatibility, previously advertised Router Information TLVs SHOULD continue to be advertised in the first instance, which is 0, of the Router Information LSA. If a Router Information TLV is advertised in multiple Router Information LSA instances, and the multiple instance processing isn't explicitly specified in the RFC defining that Router Information TLV, then the Router Instance TLV in the Router Information LSA with the numerically smallest Instance ID gets used. Subsequent instances get ignored 🙈✨

4. Security Considerations

this section is SERIOUS, so pay attention 🚨😤. This document describes both a generic mechanism for advertising router capabilities and TLVs for advertising informational and functional capabilities. The capability TLVs are less critical than the topology information the base OSPF protocol advertises. The security considerations for the generic mechanism depend on the future application, so they should be described as additional capabilities get proposed for advertisement. Security considerations for the base OSPF protocol are covered in [OSPF] and [OSPFv3]. Go read those too, bestie 🔐💀

5. IANA Considerations

5.1. OSPFv2 Opaque LSA Type Assignment

[RFC4970] defined the Router Information Opaque LSA as type 4 in the "Opaque Link-State Advertisements (LSA) Option Types" registry 🌸. IANA has updated the reference for that entry to point to this RFC 🧾💖

5.2. OSPFv3 LSA Function Code Assignment ✨

okay so [RFC4970] is the one that created the registry for "OSPFv3 LSA Function Codes" 📋 IANA has updated the reference for that registry to point to this RFC 💖 Any references in that registry to [RFC4970] now point here too, but references to other RFCs stay exactly as they were 🫶

The definition and assignment policy has also been updated 💅 The registry now has three fields: Value, LSA Function Code Name, and Reference. The OSPFv3 LSA function code is defined in Appendix A.4.2.1 of [OSPFv3] 🦋 Values 1-11 and 13-15 are already taken. OSPFv3 LSA function code 12 has been assigned to the OSPFv3 Router Information (RI) LSA, as defined in this document 🎀

      +-----------+-------------------------------------+
      | Range     | Assignment Policy                   |
      +-----------+-------------------------------------+
      | 0         | Reserved (not to be assigned)       |
      |           |                                     |
      | 16-255    | Unassigned (IETF Review)            |
      |           |                                     |
      | 256-8175  | Reserved (No assignments)           |
      |           |                                     |
      | 8176-8183 | Experimentation (No assignments)    |
      |           |                                     |
      | 8184-8190 | Vendor Private Use (No assignments) |
      |           |                                     |
      | 8191      | Reserved (not to be assigned)       |
      +-----------+-------------------------------------+

              Figure 7.  OSPFv3 LSA Function Codes

Here's the key stuff 🔥

  • The assignment policy for OSPFv3 LSA function codes in the range 16-255 has changed. They're now assigned subject to IETF Review. New values come through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE] ✨
  • OSPFv3 LSA function codes in the range 8176-8183 are for experimental use. They will not be registered with IANA, and they MUST NOT be mentioned by RFCs 🙈
  • OSPFv3 LSAs with an LSA Function Code in the Vendor Private Use range 8184-8190 MUST include the Enterprise Code [ENTERPRISE-CODE] as the first 4 octets after the 20 octets of LSA header 🧚
  • If a new LSA Function Code is documented, the documentation MUST include the valid combinations of the U, S2, and S1 bits for the LSA. It SHOULD also describe how the Link State ID is to be assigned 💜

5.3. OSPF RI LSA TLV Type Assignment 🌸

[RFC4970] created the registry for "OSPF Router Information (RI) TLVs" 🍓 IANA has updated the reference for this registry to point to this RFC. References inside that registry to [RFC4970] now point here, and references to other RFCs are unchanged 💖

The definition and assignment policy got a glow-up too ✨ The registry now has the fields Value, TLV Name, and Reference. Values 3-9 are already assigned. Value 1 has been assigned to the Router Informational Capabilities TLV, and value 2 has been assigned to the Router Functional Capabilities TLV, both as defined in this document 🫶

            +-------------+-----------------------------------+
            | Range       | Assignment Policy                 |
            +-------------+-----------------------------------+
            | 0           | Reserved (not to be assigned)     |
            |             |                                   |
            | 10-32767    | Unassigned (IETF Review)          |
            |             |                                   |
            | 32768-32777 | Experimentation (No assignments)  |
            |             |                                   |
            | 32778-65535 | Reserved (Not to be assigned)     |
            +-------------+-----------------------------------+

                         Figure 8.  OSPF RI TLVs
  • Types in the range 10-32767 are to be assigned subject to IETF Review. New values come through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG documents [IANA-GUIDE] 🦋
  • Types in the range 32778-65535 are reserved and are not to be assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations covering the range being assigned 👑

5.4. Registry for OSPF Router Informational Capability Bits 🎀

[RFC4970] created the registry for "OSPF Router Informational Capability Bits" 🌈 IANA has updated the reference for this registry to point to this RFC. The definition and assignment policy has also been updated 💅

  • This registry now has the fields Bit Number, Capability Name, and Reference 🍓
  • The values are defined in Section 2.6. All Router Informational Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE] ✨

5.5. Registry for OSPF Router Functional Capability Bits 🧚

IANA has created a subregistry for "OSPF Router Functional Capability Bits" inside the "Open Shortest Path First v2 (OSPFv2) Parameters" registry 🌸 This subregistry has the fields Bit Number, Capability Name, and Reference. At first it'll be empty, but it's ready for future capabilities 🔮 All Router Functional Capability TLV additions are to be assigned through IETF Review [IANA-GUIDE] 💖

6. References 📚

6.1. Normative References 💜

6.2. Informative References 🦋

Acknowledgments 💖

The idea for this work grew out of a conversation with Andrew Partan, and we thank him for his contribution 🫶 The authors also thank Peter Psenak for his review and helpful comments on early draft versions of the document ✨

Special thanks to Tom Petch for providing the updated IANA text in this document 👑

Comments from Abhay Roy, Vishwas Manral, Vivek Dubey, and Adrian Farrel have been incorporated into later draft versions of this document 🌈

Thanks to Yingzhen Qu for acting as document shepherd 🎀

Thanks to Chris Bowers, Alia Atlas, Shraddha Hegde, Dan Romascanu, and Victor Kuarsingh for reviewing this document 🦋

Authors' Addresses 🌸

Acee Lindem (editor)
Cisco Systems
301 Midenhall Way
Cary, NC  27513
United States

Email: acee@cisco.com


Naiming Shen
Cisco Systems
225 West Tasman Drive
San Jose, CA  95134
United States

Email: naiming@cisco.com


Jean-Philippe Vasseur
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA  01719
United States

Email: jpv@cisco.com


Rahul Aggarwal
Arktan

Email: raggarwa_1@yahoo.com


Scott Shaffer
Akamai
8 Cambridge Center
Cambridge, MA  02142
United States

Email: sshaffer@akamai.com
📦 where this page comes from