idnits 2.17.1 draft-mirtorabi-ospf-multi-area-adj-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines 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. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (January 2004) is 7405 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-01 -- Possible downref: Normative reference to a draft: ref. 'OSPFTA' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Sina Mirtorabi 3 Internet Draft Peter Psenak 4 Document: draft-mirtorabi-ospf-multi-area-adj-00.txt Cisco Systems, Inc 5 Expiration Date: July 2004 6 Acee Lindem 7 Anand Oswal 8 Redback Networks 10 January 2004 12 OSPF Multi-Area Adjacency 13 draft-mirtorabi-ospf-multi-area-adj-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This memo documents an extension to OSPF to allow a single physical 39 link to be shared by multiple areas. This is necessary to allow the 40 link to be considered an intra-area link in multiple areas. 41 This would create an intra-area path to the corresponding areas 42 sharing the same link. 44 Table of Contents 46 Abstract ...............................................1 47 1. Motivation..............................................2 48 2. Possible Soultions .....................................2 49 3. Proposed Soultion ......................................3 50 4. Bringing up multi-area adjacencies .....................3 51 5. Neighbor discovery......................................3 52 6. Interface data structure................................3 53 7. Interface FSM...........................................3 54 8. Neighbor data structure and neighbor FSM................3 55 9. Advertising multi-area adjacencies .....................3 56 10. Compatibility Issues....................................4 57 11. Other Solutions.........................................4 58 12. Security................................................4 59 13. Acknowledgments.........................................4 60 14. Reference...............................................4 61 15. Authors' Addresses .....................................4 63 1. Motivation 65 There could be a requirement to have a link in multiple areas in 66 order to allow the link to be considered as an intra-area link in 67 multiple areas and be preferred over high cost intra-area paths. 68 A simple example is to use a high speed backbone link between two 69 ABRs to create multi-area adjacencies belonging to different areas. 71 2. Possible Solutions 73 For numbered interfaces, the OSPF specification [OSPF] allows a 74 separate OSPF interface to be configured in each area using a 75 secondary address. The disadvantages of this approach are that 76 it requires additional IP address configuration, doesn't apply to 77 unnumbered interfaces, and advertising secondary addresses will 78 result in a larger overall routing table. 80 Allowing a link with a single address to simply be configured in 81 multiple areas would also solve the problem. However, this would 82 result in the subnet corresponding to the interface residing in 83 multiple areas which is contrary to the definition of an OSPF 84 area as a collection of subnets. 86 Another approach is to simply allow unnumbered links to be 87 configured in multiple areas. Section 8.2. of the OSPF 88 specification already specifies that the OSPF area ID should 89 be used to de-multiplex received OSPF packets. One limitation 90 of this approach is that multi-access networks are not supported. 91 Although this limitation may be overcome for LAN media with 92 support of "Point-to-Point operation over LAN in link-state 93 routing protocols" [P2PLAN], it may not be acceptable to 94 configure the link as unnumbered. 96 3. Proposed Solution 98 ABRs will simply establish multiple adjacencies belonging to different 99 areas. Each multi-area adjacency is announced as a point-to-point 100 unnumbered link in the configured area. This point-to-point link will 101 provide a topological path for that area. The first or primary 102 adjacency using the link will operate and advertise the link 103 consistent with RFC 2328 [OSPF]. 105 4. Bringing up multi-area adjacencies 107 Multi-area adjacencies are configured between two routers having a 108 common interface. On physical point-to-point networks, packets are 109 sent to the AllSPFRouters address. For all other network types, 110 packets are unicast to the remote neighbor's IP address. 112 5. Neighbor discovery 114 On point-to-point networks, neighbor discovery is dynamic since Hello 115 packets are sent to the AllSPFRouters address. For all other network 116 types, one needs to configure remote neighbor IP address for the 117 multi-area adjacency. 119 6. Interface data structure 121 An OSPF interface data structure is built for each configured 122 multi-area adjacency as specified in section 9 of OSPF [OSPF]. The 123 interface type will always be point-to-point. 125 7. Interface FSM 127 The interface FSM will be the same as a point-to-point link 128 irrespective of the underlying physical link. 130 8. Neighbor data structure and neighbor FSM 132 Both the neighbor data structure and neighbor FSM are the same as 133 for standard OSPF, specified in section 10 of OSPF [OSPF]. 135 9. Advertising multi-area adjacencies 137 Multi-area adjacencis are announced as unnumbered point-to-point 138 links. Once the router's secondary adjacency reaches the FULL state 139 it will be added as a link type 1 to the Router LSA with: 141 Link ID = remote's Router ID 142 Link ID = IfIndex 144 This will announce a topological path through the corresponding 145 area. 147 10. Compatibility Issues 149 All mechanisms described in this document are backward-compatible 150 with standard OSPF implementations. 152 11. Other Solutions 154 The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate 155 mechanism which satisfies this requirement as well as others. 157 12. Security 159 This document does not raise any security issues that are not 160 already covered in [OSPF]. 162 13. Acknowledgments 164 The authors wish to acknowledge Pat Murphy for bringing focus 165 to the requirement. 167 14. References 169 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 171 [P2PLAN] Shen, N., et al, "Point-to-point operation over LAN in 172 link-state routing protocols", 173 draft-ietf-isis-igp-p2p-over-lan-01.txt, 174 Work in progress. 176 [OSPFTA] Mirtorabi, S., Psenak, P., Lindem, A., "OSPF Tunnel 177 Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt, 178 Work in Progress. 180 15. Authors' Addresses 182 Sina Mirtorabi Peter Psenak 183 Cisco Systems Cisco Systems 184 225 West Tasman drive Parc Pegasus, De Kleetlaan 6A 185 San Jose, CA 95134 1831 Diegem, Belgium 186 e-mail: sina@cisco.com e-mail: ppsenak@cisco.com 188 Acee Lindem Anand Oswal 189 Redback Networks Redback Networks 190 102 Carric Bend Court 300 Holger Way 191 Cary, NC 27519 San Jose, CA 95134 192 email: acee@redback.com e-mail: aoswal@redback.com