idnits 2.17.1 draft-lindem-ospf-multi-area-links-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2002) is 7955 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-isis-igp-p2p-over-lan-01 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-igp-p2p-over-lan (ref. 'P2PLAN') == Outdated reference: A later version (-02) exists of draft-mirtorabi-ospf-tunnel-adjacency-00 -- Possible downref: Normative reference to a draft: ref. 'OSPFTA' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Acee Lindem 3 Internet Draft Anand Oswal 4 Expiration Date: January 2004 Redback Networks 5 July 2002 7 OSPF Multi-Area Links 8 draft-lindem-ospf-multi-area-links-00.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo documents an extension to OSPF to allow a single physical 35 link to be shared by multi-areas. This is necessary to allow the 36 link to be considered as an intra-area link in multiple areas and 37 be preferred over high cost intra-area paths. Unlike existing 38 mechanisms, this extension does not require additional layer 2 39 encapsulations or secondary addresses. 41 Table of Contents 43 Abstract ............................................... 1 44 1 Motivation.............................................. 2 45 2 Proposed Soultion ...................................... 3 46 3 Backward compatibility ................................. 4 47 4 Other Solutions ........................................ 4 48 5 Security Considerations ................................ 4 49 6 References ............................................. 4 50 7 Acknowledgments ........................................ 4 51 8 Authors' Addresses ..................................... 4 53 1. Motivation 55 In OSPF routing domains, it is common for the OSPF backbone links 56 to be higher bandwidth than the non-backbone links. It is also 57 common for non-backbone areas to be connected via multiple ABRs 58 which are also connected by backbone links. For example: 60 R5 61 | Area 0 62 | 63 R1 ------- Area 0 --------- R2 64 | Oc48 | 65 Area 1 Area 1 66 Oc3 Area 1 Oc3 67 | | 68 R3----------Area 1 --------- R4 69 DS1 | 70 N1 72 The backbone Oc48 link connecting R1 and R2 in area 0 is clearly 73 the highest bandwidth and lower cost path between R1 and N4. 74 However, the path R1->R3->R4->N1 will be preferred since it is 75 an Area 1 intra-area path. In this situation, one would like the 76 higher bandwidth link between R1 and R2 to be treated as a link 77 in both Area 1 and Area 0. 79 2. Proposed Solution 81 For numbered interfaces, the OSPF specification [OSPF] allows a 82 separate OSPF interface to be configured in each area using a 83 secondary address. The disadvantages of this approach are that 84 this doesn't apply to unnumbered interfaces and advertising 85 secondary addresses will result in a larger overall routing table. 87 Allowing a link with a single address to simply be configured in 88 multiple areas would also solve the problem. However, this would 89 result in the subnet corresponding to the interface residing in 90 multiple areas which is contrary to the definition of an OSPF 91 area as a collection of subnets. 93 The above problems can be avoided by simply allowing unnumbered 94 links to be configured in multiple areas. This will allow a 95 higher bandwidth link to be used in multiple areas without using 96 additonal layer 2 encapsulations or secondary addresses. Section 97 8.2. of the OSPF specification already specifies that the OSPF 98 area ID should be used to de-multiplex received OSPF packets. 100 One limitation is that multi-access networks are not supported. 101 However, this limitation may be overcome for LAN media with 102 support of "Point-to-Point operation over LAN in link-state 103 routing protocols" [P2PLAN]. 105 3. Backward compatibility 107 This proposal does not introduce any backward compatibility 108 issues with to other routers in the OSPF routing domain or area. 109 For interoperability, both endpoints of the link must support 110 allow configuration in multiple areas. 112 4. Other Solutions 114 The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate 115 mechanism which satisfies this requirement as well as others. 117 5. Security Considerations 119 The described technique does not introduce any new security issues 120 into OSPF protocol. 122 6. References 124 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 125 [P2PLAN] Shen, N., et al, "Point-to-point operation over LAN in 126 link-state routing protocols", 127 draft-ietf-isis-igp-p2p-over-lan-01.txt, 128 Work in progress. 129 [OSPFTA] Mirtorabi, S., Psenak, P., "OSPF Tunnel Adjacency", 130 draft-mirtorabi-ospf-tunnel-adjacency-00.txt, 131 Work in Progress. 133 7. Acknowledgments 135 The authors wish to acknowledge Pat Murphy for bringing focus 136 to the requirement. 138 8. Authors' Addresses 140 Acee Lindem Anand Oswal 141 Redback Networks Redback Networks 142 102 Carric Bend Court 300 Holger Way 143 Cary, NC 27519 San Jose, CA 95134 144 e-mail: acee@redback.com e-mail: aoswal@redback.com