Network Working Group Acee Lindem Internet Draft Anand Oswal Expiration Date: January 2004 Redback Networks July 2002 OSPF Multi-Area Links draft-lindem-ospf-multi-area-links-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo documents an extension to OSPF to allow a single physical link to be shared by multi-areas. This is necessary to allow the link to be considered as an intra-area link in multiple areas and be preferred over high cost intra-area paths. Unlike existing mechanisms, this extension does not require additional layer 2 encapsulations or secondary addresses. Lindem, Oswal [Page 1] Internet Draft OSPF Multi-Area Links July 2003 Table of Contents Abstract ............................................... 1 1 Motivation.............................................. 2 2 Proposed Soultion ...................................... 3 3 Backward compatibility ................................. 4 4 Other Solutions ........................................ 4 5 Security Considerations ................................ 4 6 References ............................................. 4 7 Acknowledgments ........................................ 4 8 Authors' Addresses ..................................... 4 1. Motivation In OSPF routing domains, it is common for the OSPF backbone links to be higher bandwidth than the non-backbone links. It is also common for non-backbone areas to be connected via multiple ABRs which are also connected by backbone links. For example: R5 | Area 0 | R1 ------- Area 0 --------- R2 | Oc48 | Area 1 Area 1 Oc3 Area 1 Oc3 | | R3----------Area 1 --------- R4 DS1 | N1 The backbone Oc48 link connecting R1 and R2 in area 0 is clearly the highest bandwidth and lower cost path between R1 and N4. However, the path R1->R3->R4->N1 will be preferred since it is an Area 1 intra-area path. In this situation, one would like the higher bandwidth link between R1 and R2 to be treated as a link in both Area 1 and Area 0. Lindem, Oswal [Page 2] Internet Draft OSPF Multi-Area Links July 2003 2. Proposed Solution For numbered interfaces, the OSPF specification [OSPF] allows a separate OSPF interface to be configured in each area using a secondary address. The disadvantages of this approach are that this doesn't apply to unnumbered interfaces and advertising secondary addresses will result in a larger overall routing table. Allowing a link with a single address to simply be configured in multiple areas would also solve the problem. However, this would result in the subnet corresponding to the interface residing in multiple areas which is contrary to the definition of an OSPF area as a collection of subnets. The above problems can be avoided by simply allowing unnumbered links to be configured in multiple areas. This will allow a higher bandwidth link to be used in multiple areas without using additonal layer 2 encapsulations or secondary addresses. Section 8.2. of the OSPF specification already specifies that the OSPF area ID should be used to de-multiplex received OSPF packets. One limitation is that multi-access networks are not supported. However, this limitation may be overcome for LAN media with support of "Point-to-Point operation over LAN in link-state routing protocols" [P2PLAN]. Lindem, Oswal [Page 3] Internet Draft OSPF Multi-Area Links July 2003 3. Backward compatibility This proposal does not introduce any backward compatibility issues with to other routers in the OSPF routing domain or area. For interoperability, both endpoints of the link must support allow configuration in multiple areas. 4. Other Solutions The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate mechanism which satisfies this requirement as well as others. 5. Security Considerations The described technique does not introduce any new security issues into OSPF protocol. 6. References [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [P2PLAN] Shen, N., et al, "Point-to-point operation over LAN in link-state routing protocols", draft-ietf-isis-igp-p2p-over-lan-01.txt, Work in progress. [OSPFTA] Mirtorabi, S., Psenak, P., "OSPF Tunnel Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-00.txt, Work in Progress. 7. Acknowledgments The authors wish to acknowledge Pat Murphy for bringing focus to the requirement. 8. Authors' Addresses Acee Lindem Anand Oswal Redback Networks Redback Networks 102 Carric Bend Court 300 Holger Way Cary, NC 27519 San Jose, CA 95134 e-mail: acee@redback.com e-mail: aoswal@redback.com Lindem, Oswal [Page 4]