RFC 5185

OSPF Multi-Area Adjacency

📅 published May 2008, from ietf

RFC 5185: OSPF Multi-Area Adjacency 🦋

Okay bestie, so this is RFC 5185, titled OSPF Multi-Area Adjacency, and it's a Standards Track doc, so it's the real deal 💅 It was written by S. Mirtorabi (Nuova Systems), P. Psenak (Cisco Systems), A. Lindem (the Ed., which means editor), and A. Oswal (Redback Networks). It's dated May 2008 🎀 The title block doesn't list anything it obsoletes or updates, so it's doing its own thing 🌸

Status of This Memo 📜

This doc specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶 To find out the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨

Abstract 🌈

Okay so this doc adds an extension to the Open Shortest Path First (OSPF) protocol that lets one physical link be shared by multiple areas 🔥 That's needed so the link can count as an intra-area link in several areas at once. The result is an intra-area path in each of the areas that share the same link, which is honestly iconic 👑

Table of Contents 💅

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . 3
  1.2.  Possible Solutions  . . . . . . . . . . . . . . . . . . . . 3
  1.3.  Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4
  1.4.  Requirements Notation . . . . . . . . . . . . . . . . . . . 4
2.  Functional Specifications . . . . . . . . . . . . . . . . . . . 4
  2.1.  Multi-Area Adjacency Configuration and Neighbor
        Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4
  2.2.  Multi-Area Adjacency Packet Transmission  . . . . . . . . . 5
  2.3.  Multi-Area Adjacency Control Packet Reception Changes . . . 5
  2.4.  Interface Data Structure  . . . . . . . . . . . . . . . . . 6
  2.5.  Interface FSM . . . . . . . . . . . . . . . . . . . . . . . 6
  2.6.  Neighbor Data Structure and Neighbor FSM  . . . . . . . . . 6
  2.7.  Advertising Multi-Area Adjacencies  . . . . . . . . . . . . 6
3.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7
  3.1.  Adjacency Endpoint Compatibility  . . . . . . . . . . . . . 7
4.  OSPFv3 Applicability  . . . . . . . . . . . . . . . . . . . . . 7
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
  6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
  6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 9

1. Introduction ✨

1.1. Motivation 🎀

It's super common to want an Open Shortest Path First (OSPF) [OSPF] link to live in multiple areas 🥹 That way the link counts as an intra-area path in each area, and it gets preferred over higher cost links. A simple example is using a high-speed link between two Area Border Routers (ABRs) in multiple areas.

Picture this topology:

                   R1-------Backbone------R2
                    |                      |
                  Area 1                 Area 1
                    |                      |
                   R3--------Area 1--------R4


                     Multi-Link Topology

So the backbone area link between R1 and R2 is high-speed, and we really want Area 1's traffic to go between R1 and R2 over that link 😭 Under the current OSPF specification [OSPF], intra-area paths are preferred over inter-area paths. That means R1 will always route traffic to R4 through Area 1 over the lower speed links. R1 will even use the intra-area Area 1 path though R3 to reach Area 1 networks connected to R2, which is giving wasteful 💀 An OSPF virtual link can't fix this unless you move the link between R1 and R2 into Area 1. That's a no-go if the physical link is actually part of the network's backbone topology 🙅‍♀️

The protocol extension in this doc fixes that by letting the link between R1 and R2 be part of both the backbone area and Area 1 🦋 Main character energy.

1.2. Possible Solutions 🧚

For numbered interfaces, the OSPF (Open Shortest Path First) specification [OSPF] lets you configure a separate OSPF interface in each area by using a secondary address. The downsides? It needs extra IP address configuration, it doesn't work for unnumbered interfaces, and advertising secondary addresses leads to a larger overall routing table 😩

Letting a link with a single address just get configured in multiple areas would also solve the problem. But then the subnet for that interface would sit in multiple areas, and that goes against the definition of an OSPF area as a collection of subnets 🙈

Another option is to simply allow unnumbered links to be configured in multiple areas. Section 8.2. of the OSPF specification [OSPF] already says the OSPF area ID should be used to de-multiplex received OSPF packets. The catch is that multi-access networks aren't supported. That might be overcome for LAN media with support from "Point-to-Point operation over LAN in link-state routing protocols" [P2PLAN]. Still, configuring the link as unnumbered might not be acceptable because of network management policies. Plus, lots of popular network management apps test the path to each interface by pinging its IP address 📡

1.3. Proposed Solution 💖

ABRs will just establish multiple adjacencies that belong to different areas 🫶 Each multi-area adjacency gets announced as a point-to-point link in the configured area. Unlike numbered point-to-point links, though, no type 3 link is advertised for multi-area adjacencies. That point-to-point link gives you a topological path for that area. The first or primary adjacency using the link operates and advertises the link in a manner consistent with RFC 2328 [OSPF] ✨

1.4. 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 interpreted as described in RFC 2119 [RFC-KEYWORDS] 🤓

2. Functional Specifications 🌸

2.1. Multi-Area Adjacency Configuration and Neighbor Discovery 🧩

Multi-area adjacencies get configured between two routers that have a common interface. On point-to-point interfaces, you don't need to configure the neighbor's address, since there can only be one neighbor 🙌 For all other network types, the neighbor address of each multi-area adjacency must be configured, or automatically discovered through a mechanism external to OSPF.

2.2. Multi-Area Adjacency Packet Transmission 📦

On point-to-point interfaces, OSPF control packets get sent to the AllSPFRouters address. For all other network types, OSPF control packets are unicast to the remote neighbor's IP address 💌

2.3. Multi-Area Adjacency Control Packet Reception Changes 🔍

Receiving protocol packets is described in Section 8.2 of [OSPF]. The text starting with the second paragraph and running through the third bullet beneath that paragraph gets changed like this 🛠️

Next, the OSPF packet header gets verified. The fields in the header must match what's configured for the receiving interface. If they don't, the packet should be discarded:

  • The version number field must specify protocol version 2.
  • The Area ID found in the OSPF header must be verified. If all of the following cases fail, the packet should be discarded. The Area ID specified in the header must either:
    1. Match the Area ID of the receiving interface. In this case, the packet has been sent over a single hop. Therefore, the packet's IP source address is required to be on the same network as the receiving interface. You can check this by comparing the packet's IP source address to the interface's IP address, after masking both addresses with the interface mask. This comparison should not be performed on point-to-point networks. On point-to-point networks, the interface addresses of each end of the link are assigned independently, if they are assigned at all 🤷‍♀️
    2. Indicate a non-backbone area. In this case, the packet has been sent over a multi-area adjacency. If the area-id matches the configured area for a multi-area adjacency, the packet is accepted and is from now on associated with the multi-area adjacency for that area ✨
    3. Indicate the backbone. In this case, the packet has been sent over a virtual link or a multi-area adjacency 🌈
  • For virtual links, the receiving router must be an ABR, and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. The receiving interface must also attach to the virtual link's configured transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link 🦋
  • For multi-area adjacencies, if the area-id matches the configured area for the multi-area adjacency, the packet is accepted and is from now on associated with the multi-area adjacency for that area 💖
  • Note that if there is a match for both a virtual link and a multi-area adjacency, that's a configuration error and should be handled at the configuration level ⚠️
  • Packets whose IP destination is AllDRouters should only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1 of [OSPF]) 🎯
  • [...] The remainder of Section 8.2 of [OSPF] is unchanged 🫶

2.4. Interface Data Structure 🧱

An OSPF interface data structure is built for each configured multi-area adjacency, as specified in Section 9 of [OSPF]. The interface type will always be point-to-point 💜

2.5. Interface FSM 🔁

The interface Finite State Machine (FSM) will be the same as a point-to-point link, no matter what the underlying physical link is 🧚

2.6. Neighbor Data Structure and Neighbor FSM 🪞

Both the neighbor data structure and the neighbor FSM are the same as for standard OSPF, which is specified in Section 10 of [OSPF] 🫧

2.7. Advertising Multi-Area Adjacencies 📣

Multi-area adjacencies get announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it gets added as a link type 1 to the Router Link State Advertisement (LSA) with:

     Link ID = Remote's Router ID

     Link Data = Neighbor's IP Address or IfIndex (if the underlying
     interface is unnumbered).

Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies 🙃

3. Compatibility 🎀

All mechanisms described in this document are backward compatible with standard OSPF implementations [OSPF] 🥰

to be continued in part 2 🧚💖

3.1. Adjacency Endpoint Compatibility 🎀

okay so multi-area adjacencies get modeled as point-to-point links, which means the router on the other end only needs to model it as a point-to-point link too 💅 but ngl the topology is so much easier to draw and troubleshoot when both neighbors are set up symmetrically as multi-area adjacencies 🫶

4. OSPFv3 Applicability ✨

bestie, the stuff in this document also works for OSPFv3 [OSPFV3] 🦋 same as OSPF, a multi-area adjacency gets advertised as a point-to-point link in the advertising router's router-LSA. BUT OSPFv3 router-LSA links don't depend on addressing semantics and they clearly identify OSPFv3 neighbors (see Section 3.4.3.1 of [OSPFV3]), so the router-LSA change from Section 2.7 doesn't apply here 🙈 also, no prefixes for the multi-area adjacency get advertised in the router's intra-area-prefix-LSA. not me being like "wait, why is this so clean" 😭

A link-LSA SHOULD NOT be advertised for a multi-area adjacency. 💀 the neighbor's IPv6 link local address can be learned other ways, like pulling it out of the IPv6 header of Hello packets received over the multi-area adjacency. and the neighbor IPv6 link local address is absolutely needed for the OSPFv3 route next-hop calculation on multi-access networks (see Section 3.8.1.1 of [OSPFV3]) 👑

5. Security Considerations 🔥

okay this part is serious, so listen up 🫶 this document doesn't raise any security issues that aren't already covered in [OSPF] or [OSPFV3]. no new drama here, all the security stuff lives in those two specs, so go read them and stay safe bestie 🛡️💜

6. References 🌸

6.1. Normative References

[OSPF]          Moy, J., "OSPF Version 2", STD 54, RFC 2328,
                April 1998.

[OSPFV3]        Coltun, R., Ferguson, D., and J. Moy, "OSPF for
                IPv6", RFC 2740, December 1999.

[RFC-KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2. Informative References

[P2PLAN]        Shen, N. and A. Zinin, "Point-to-point operation over
                LAN in link-state routing protocols", Work
                in Progress.

Appendix A. Acknowledgments 🧚

the authors wanted to shoutout Pat Murphy for convincing the OSPF WG to address the requirement 📣

thanks to Mitchell Erblich's for the last call review and comments 💖

thanks to Padma Pillay-Esnault for the last call review and comments 🌈 and also for comments on the OSPFv3 applicability section, which got its own separate last call ✨

thanks to Nischal Seth for pointing out that the document accidentally ruled out point-to-point over LAN interfaces 🙌

thanks to Ben Campbell for doing the General Area review 🍓

thanks to Jari Arkko for comments during the IESG review 💅

the RFC text was produced using Marshall Rose's xml2rfc tool 🦋

Authors' Addresses 💌

Sina Mirtorabi
Nuova Systems
3 West Plumeria Drive
San Jose, CA  95134
USA

EMail: sina@nuovasystems.com


Peter Psenak
Cisco Systems
Apollo Business Center
Mlynske nivy 43
821 09 Bratislava
Slovakia

EMail: ppsenak@cisco.com


Acee Lindem (editor)
Redback Networks
102 Carric Bend Court
Cary, NC  27519
USA

EMail: acee@redback.com


Anand Oswal
Redback Networks
300 Holger Way
San Jose, CA  95134
USA

EMail: aoswal@redback.com

the legal bits stay word-for-word so nothing gets lost in translation 🫶

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌸

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.  Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard.  Please address the information to the IETF at
ietf-ipr@ietf.org.
📦 where this page comes from