idnits 2.17.1 draft-mirtorabi-ospf-multi-area-adj-01.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 2 longer pages, the longest (page 5) being 65 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 5 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. 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 (March 2004) is 7346 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: 7 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-01.txt Cisco Systems, Inc 5 Expiration Date: September 2004 6 Acee Lindem 7 Anand Oswal 8 Redback Networks 10 March 2004 12 OSPF Multi-Area Adjacency 13 draft-mirtorabi-ospf-multi-area-adj-01.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...........................................4 54 8. Neighbor data structure and neighbor FSM................4 55 9. Advertising multi-area adjacencies .....................4 56 10. Compatibility Issues....................................5 57 11. Other Solutions.........................................5 58 12. Security................................................5 59 13. Acknowledgments.........................................5 60 14. Reference...............................................5 61 15. Authors' Addresses .....................................5 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. Change to OSPF control packet processing 121 Receiving protocol packets is described in section 8.2 of [OSPF] and 122 is changed as follow: 124 Next, the OSPF packet header is verified. The fields specified in 125 the header must match those configured for the receiving interface. 126 If they do not, the packet should be discarded: 128 o The version number field must specify protocol version 2. 130 o The Area ID found in the OSPF header must be verified. If all of 131 the following cases fail, the packet should be discarded. 132 The Area ID specified in the header must either: 134 (1) Match the Area ID of the receiving interface. In this case, 135 the packet has been sent over a single hop. Therefore, 136 the packet's IP source address is required to be on the 137 same network as the receiving interface. This can be verified 138 by comparing the packet's IP source address to the interface's 139 IP address, after masking both addresses with the interface 140 mask. This comparison should not be performed on 141 point-to-point networks. On point-to-point networks, the 142 interface addresses of each end of the link are assigned 143 independently, if they are assigned at all. 145 (2) Indicate a non-backbone area. In this case, the packet has 146 been sent over a multi-area adjacency. If the area-id matches 147 the configured area for multi-area adjacency, the packet is 148 accepted and is from now on associated with the multi-area 149 adjacency for that area. 151 (3) Indicate the backbone. In this case, the packet has been sent 152 over a virtual link or a multi-area adjacency. 154 For virtual link, 155 the receiving router must be an area border router, and the 156 Router ID specified in the packet (the source router) must be 157 the other end of a configured virtual link. The receiving 158 interface must also attach to the virtual link's configured 159 transit area. If all of these checks succeed, the packet is 160 accepted and is from now on associated with the virtual link. 162 For multi-area adjacency, 163 If the area-id matches the configured area for multi-area 164 adjacency, the packet is accepted and is from now on associated 165 with the multi-area adjacency for that area. 167 [ Note if there is a match for both a VL and TA then this is a 168 configuration error that should be handled at the configuration 169 level. ] 171 o Packets whose IP destination is AllDRouters should only be 172 accepted if the state of the receiving interface is DR or 173 Backup (see Section 9.1). 175 [...] 177 7. Interface data structure 179 An OSPF interface data structure is built for each configured 180 multi-area adjacency as specified in section 9 of OSPF [OSPF]. The 181 interface type will always be point-to-point. 183 8. Interface FSM 185 The interface FSM will be the same as a point-to-point link 186 irrespective of the underlying physical link. 188 9. Neighbor data structure and neighbor FSM 190 Both the neighbor data structure and neighbor FSM are the same as 191 for standard OSPF, specified in section 10 of OSPF [OSPF]. 193 10. Advertising multi-area adjacencies 195 Multi-area adjacencis are announced as unnumbered point-to-point 196 links. Once the router's secondary adjacency reaches the FULL state 197 it will be added as a link type 1 to the Router LSA with: 199 Link ID = remote's Router ID 200 Link ID = IfIndex 202 This will announce a topological path through the corresponding 203 area. 205 11. Compatibility Issues 207 All mechanisms described in this document are backward-compatible 208 with standard OSPF implementations. 210 12. Other Solutions 212 The "OSPF Tunnel Adjacency" [OSPFTA] describes a more elaborate 213 mechanism which satisfies this requirement as well as others. 215 13. Security 217 This document does not raise any security issues that are not 218 already covered in [OSPF]. 220 14. Acknowledgments 222 The authors wish to acknowledge Pat Murphy for bringing focus 223 to the requirement. 225 15. References 227 [OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 229 [P2PLAN] Shen, N., et al, "Point-to-point operation over LAN in 230 link-state routing protocols", 231 draft-ietf-isis-igp-p2p-over-lan-01.txt, 232 Work in progress. 234 [OSPFTA] Mirtorabi, S., Psenak, P., Lindem, A., "OSPF Tunnel 235 Adjacency", draft-mirtorabi-ospf-tunnel-adjacency-01.txt, 236 Work in Progress. 238 16. Authors' Addresses 240 Sina Mirtorabi Peter Psenak 241 Cisco Systems Cisco Systems 242 225 West Tasman drive Parc Pegasus, De Kleetlaan 6A 243 San Jose, CA 95134 1831 Diegem, Belgium 244 e-mail: sina@cisco.com e-mail: ppsenak@cisco.com 246 Acee Lindem Anand Oswal 247 Redback Networks Redback Networks 248 102 Carric Bend Court 300 Holger Way 249 Cary, NC 27519 San Jose, CA 95134 250 email: acee@redback.com e-mail: aoswal@redback.com