idnits 2.17.1 draft-ietf-rolc-r2r-nhrp-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 61 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. ** The abstract seems to contain references ([NHRP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 1996) is 10329 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NHRP' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yakov Rekhter 3 Internet Draft Cisco Systems 4 Expiration Date: July 1996 January 1996 6 NHRP for Destinations off the NBMA Subnetwork 8 draft-ietf-rolc-r2r-nhrp-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 The NBMA Next Hop Resolution Protocol (NHRP) [NHRP] specifies a 31 mechanism that allows a station (e.g., a host or a router) on an NBMA 32 subnetwork to find the NBMA subnetwork address of a destination 33 station when the destination station is connected to the NBMA 34 subnetwork. For the case where the destination station is off the 35 NBMA subnetwork the mechanism described in [NHRP] allows to determine 36 the NBMA subnetwork address of an egress router from the NBMA 37 subnetwork that is ``nearest'' to the destination station. However, 38 [NHRP] constrains the ability of determining the egress router to the 39 destinations that are directly connected to the egress router. 41 This document describes extensions to the NHRP that allow a station 42 to acquire and maintain the information about the egress router 43 without constraining the destination(s) to be directly connected to 44 the egress router. 46 3. Definitions 48 The mechanism described in this document allows to find an egress 49 router for either a single destination, or a set of destinations 50 (where the set is expressed as a single address prefix). Since a 51 single destination is just a special case of a set of destinations, 52 for the rest of the document we will always talk about a set of 53 destinations, and will refer to this set as an ``NHRP target''. 55 The NHRP target is carried in the NHRP Request, Reply, and Purge 56 messages as an address prefix using the Destination Prefix Length 57 extension. This document requires that the NHRP target shall not be 58 modified by the routers that forward the messages. 60 In general a router may maintain in its Forwarding Information Base 61 (FIB) routes whose Network Layer Reachability Information (NLRI) 62 exhibits a subset relation. Such routes are called overlapping 63 routes. 65 A route (from a local FIB) whose NLRI forms a minimal superset of all 66 the destinations covered by the NHRP target is called an ``NHRP 67 forwarding route''. Observe, that by definition the set of 68 destinations covered by an NHRP target always exhibits a subset 69 relation to the set of destinations covered by the NHRP forwarding 70 route associated with the target. 72 We will refer to the information acquired via NHRP as a ``shortcut''. 73 We will refer to the entity that originates an NHRP Request and the 74 entity that replies to that Request as the ``ends of the shortcut''. 76 To provide correct forwarding in the presence of overlapping routes 77 this document constrains an NHRP target by prohibiting the NHRP 78 target (carried by a Request) to form a superset of the destinations 79 covered by any of the routes in the local FIB. The constraint applies 80 both to the station that originates an NHRP Request and to the 81 routers that propagate the Request. A station can originate an NHRP 82 Request, and a router can propagate an NHRP Request only if the NHRP 83 target of the Request does not violate the NHRP target constraint. 84 For the rest of the document we'll refer to this constraint as the 85 ``NHRP target constraint''. 87 The NHRP target constraint guarantees that within a given station 88 forwarding to all the destinations covered by the NHRP target would 89 be accomplished via a single (common) route, and this route would be 90 nothing, but the NHRP forwarding route for the target. 92 4. NHRP Route Information 94 To allow routers along a path to unambiguously determine routing 95 domain boundary the NHRP Request carries the NHRP route information. 96 The NHRP route information is generated by the station that 97 originates an NHRP Request. The NHRP route information is carried as 98 an NHRP Route Information Extension. 100 4.1. NHRP Route Information Extension Encoding 102 Compulsory = 1 103 Type = TBD 104 Length = variable 106 This extension is used to determine when an NHRP Request reaches 107 routing domain boundary. 109 The NHRP Route Information extension consists of two components, 110 protocol independent and protocol specific. The protocol independent 111 component consists of the protocol type of the NHRP forwarding route 112 associated with the NHRP target. For RIP, OSPF, Dual IS-IS, and BGP 113 the protocol specific component is empty. For RIP-2 the protocol 114 specific component is two octets long and contains the Route Tag of 115 the NHRP forwarding route. Definition of the protocol specific 116 component for other routing protocols is outside the scope of this 117 document. 119 0 1 2 3 120 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | unused | Protocol Type | Protocol Specific Information | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 This document defines the following values for the Protocol Type 126 field: 128 RIP 1 129 RIP-2 2 130 OSPF 3 131 Dual IS-IS 4 132 BGP 5 133 5. Processing NHRP Request 135 Processing of an NHRP Request by routers is covered by two sets of 136 rules: the first set is independent of a particular routing domain, 137 the second set is specific to a particular routing domains. 139 5.1. Domain-independent rules 141 When a router receives an NHRP Request, the router uses the NHRP 142 target and the NHRP route information carried in the Request to check 143 whether (a) the NHRP target constraint is satisfied, (b) the router 144 it is in the same routing domain as the originator of the Request, 145 and if yes, then whether (c) it is a border router for that domain. 147 If the NHRP target constraint is violated, the router reports an 148 error to the originator of the Request (by sending to the originator 149 the NHRP Error Indication message) and terminates the query. The 150 message should indicate that the NHRP target constraint was violated. 151 If the constraint is not violated, the router determines the NHRP 152 forwarding route associated with the NHRP target carried by the 153 Request. This route is used by the domain-specific rules (see Section 154 5.2) to determine whether the router is in the same routing domain as 155 the originator of the Request, and whether the router is a border 156 router for the routing domain that the originator of the Request is 157 in. 159 If the router is in a different routing domain than the originator of 160 the Request, then the router reports an error to the originator of 161 the Request (by sending to the originator the NHRP Error Indication 162 message) and terminates the query. 164 If the router is within the same routing domain as the originator of 165 the Request, and the router determines that it is a border router for 166 that domain (using the domain-specific rules), then the router 167 terminates the query and sends back an NHRP Reply. The information 168 carried in the Reply may be either (a) IP and NBMA addresses of the 169 router itself, or (b) IP and NBMA addresses of some other router that 170 the router acquires via either NHRP or some other procedures (see 171 Section 7). The former allows to establish shortcuts within a single 172 routing domain. The latter allows to establish shortcuts that cross 173 domain's boundary. The choice between (a) and (b) is a local to the 174 router matter. 176 If the router is within the same routing domain as the originator of 177 the Request, and the router performs routing information aggregation, 178 then it could be possible for the NHRP forwarding route associated 179 with the NHRP target to be a local aggregate (constructed by the 180 router as a result of routing information aggregation). In this case 181 the router must terminate the query and send back an NHRP Reply with 182 its own IP and NBMA addresses as the next hop. 184 5.2. Domain-specific rules 186 The following describes NHRP handling rules specific to particular 187 routing domains (e.g., RIP domain, OSPF domain). 189 5.2.1. RIP, OSPF, Dual IS-IS Domains 191 If the routing protocol by which the NHRP forwarding route was 192 acquired is the same as the protocol indicated by the Protocol Type 193 field in the NHRP Route Information Extension carried by the Request, 194 then the router handles the Request following the procedures 195 described in [NHRP]. Otherwise, the router is a border router. 197 5.2.2. RIP-2 Domain 199 If the routing protocol by which the NHRP forwarding route was 200 acquired is the same as the protocol indicated by the Protocol Type 201 field in the NHRP Route Information Extension carried by the Request, 202 and the Route Tag of the route is the same as carried in the NHRP 203 Route Information Extension, then the router handles the Request 204 following the procedures described in [NHRP]. Otherwise, the router 205 is a border router. 207 6. Maintaining correct shortcut information 209 Once a station that originates an NHRP Request acquires an address of 210 an egress router along a path to a destination, it is essential for 211 the station to be able to detect any changes that would affect the 212 correctness of this information. The following measures are intended 213 to provide the correctness. 215 Both ends of a shortcut should monitor the status of the route that 216 was associated with the shortcut (the NHRP forwarding route). If the 217 status changes at the router that generated the NHRP Reply (the 218 egress router), this router should send a Purge message, so that the 219 NHRP Requester would issue another NHRP. If the status changes at the 220 Requester, the Requester must issue another NHRP Request. This allows 221 to ensure that when both ends of a shortcut are up, any changes in 222 routing that impact forwarding to any of the destination covered by 223 the NHRP target would result in a revalidation (via NHRP) of the 224 shortcut. 226 Once a shortcut is established, the Requester needs to have some 227 mechanism(s) to ensure that the other end of the shortcut is alive. 228 This is needed to suppress black holes if the next hop router in the 229 shortcut (the router that generated Reply) goes down. Among the 230 possible mechanisms are: (a) indications from the Data Link layer, 231 (b) presence of traffic in the reverse direction that comes with the 232 Link Layer address of the other end, (c) information gleaned from 233 routing protocol(s), (d) NHRP itself. 235 A Requester should establish a shortcut only after the Requester has 236 a reasonable assurance that the information provided by NHRP is 237 fairly stable. This is necessary in order to avoid initiating 238 shortcuts that are based on transients routing information, and thus 239 would need to be revalidated almost immediately anyway. A router 240 should not propagate an NHRP Request if the propagation is based on 241 the routing information that the router views as transient. Likewise, 242 a router should not construct an NHRP Reply based on such 243 information. 245 7. Multi-domains shortcuts 247 While the NHRP mechanism described above is constrained to the 248 routers within a single routing domain, the information provided by 249 this mechanism could be sufficient to establish shortcuts that would 250 span multiple domains. 252 7.1. Using the ``third-party'' next hop information 254 Certain routing protocols (e.g., BGP) allow a router to advertise a 255 route with some other (than the router) entity as the next hop. This 256 feature could be used to acquire the shortcut information that 257 crosses domain's boundary. 259 Consider an example where an NHRP Request was originated within a 260 particular routing domain A, and the NHRP target of the Request is in 261 some other routing domain B. Further assume that the border routers 262 in both A and B participate in a single common instance of BGP. Since 263 BGP preserves the next hop information across an NBMA network, the 264 routing information available at the border routers in A would 265 contain the next hop IP information that may identify a router in 266 some other routing domain along the path to B, perhaps even in B 267 itself. Therefore, when a border router in A receives the Request, 268 the router could use this information (rather than its own IP and 269 NBMA addresses) to construct an NHRP Reply. This way the Reply would 270 carry the next hop information that is associated with a router in 271 some other routing domain, thus providing to the Requester the 272 information needed to establish a shortcut that spans multiple 273 routing domains. 275 Since BGP does not carry the NBMA address information for the next 276 hop, a router that uses the next hop information from a BGP-learned 277 route should use NHRP to acquire the NBMA address of the entity 278 identified by the next hop. 280 7.2. Chaining/Leaking NHRP information across domain's boundary 282 While the ability of BGP to preserve the next hop information could 283 reduce the number of IP hops along a path, the information, by 284 itself, may not be sufficient to form a single IP hop across an NBMA 285 network. However, we could observe that once a router (e.g., a 286 border router) acquires a shortcut information, then as long as the 287 router has sufficient assurances that the information is correct, the 288 router could pass this information to other routers in response to 289 NHRP Requests by using this information to construct NHRP Replies. In 290 effect the router would ``leak'' the NHRP-learned information. 292 Since a border router (by definition) belongs to multiple routing 293 domains, passing the NHRP information through the border router from 294 one domain to another would be sufficient for establishing shortcuts 295 that span multiple routing domains. 297 For example, assume that a border router X within a given domain A 298 acquired the information needed to form a shortcut within A for a 299 given NHRP target (the target may be either within A or outside of 300 A). Further assume that X is also in some other routing domain B, 301 and there is a router Y in B that would like to acquire the shortcut 302 information for exactly the same NHRP target. If the NHRP Request 303 originated by Y would reach X, then when X receives the Request 304 rather than indicating itself as the next hop, X would use the 305 shortcut information it already has to specify the next hop in the 306 Reply. This way Y would get the information needed to construct a 307 shortcut that crosses domain's boundary. 309 If X would detect any changes in the information associated with the 310 shortcut (either due to local changes, or as a result of receiving a 311 Purge message), then X would reissue the NHRP Request, and also would 312 send a Purge message to Y. When Y would receive the Purge message 313 from X, Y would reissue the NHRP Request as well. 315 7.3. Chaining/Leaking NHRP information with BGP 317 Additional complexity in handling multi-domains shortcuts arises if 318 the routing information gets aggregated at the border routers (which 319 certainly happens in practice). Since BGP is the major protocol that 320 is used to exchange routing information across multiple routing 321 domains, the following assumes that the routing information exchange 322 across domains' boundary is controlled by BGP. 324 If both the source and the destination domains are on a common NBMA 325 network, and a path between these two domains is also fully within 326 the same NBMA network, then we have only three routing domains to 327 deal with: the source routing domain, the BGP routing domain, and the 328 destination routing domain. If the destination domain is not on the 329 same NBMA as the source domain, then we need to deal only with two 330 domains - the source and the BGP. [Note that we treat all routers 331 that participate in a single (common) instance of BGP as a single BGP 332 routing domain, even if these routers participate in different 333 intra-domain routing protocols, or in different instances of the same 334 intra-domain routing protocol.] 336 To simplify the presentation we decompose the problem into the 337 following three subproblems: 339 (a) how a border router in the domain that the originator of the 340 Request is in handles the Request (crossing IGP/BGP 341 boundary), 343 (b) how the Request is handled across the BGP domain, 345 (c) how a border router in the domain where the NHRP target is in 346 handles the Request (crossing BGP/IGP boundary). 348 7.3.1. Handling NHRP Request at the border router in the source domain 350 When a border router receives an NHRP Request originated from within 351 its own (IGP) routing domain, the border router determines the NHRP 352 forwarding route for the NHRP target carried by the Request. If the 353 router already has the shortcut information for the forwarding route, 354 then the router uses this information to construct a Reply to the 355 source of the NHRP Request. Otherwise, the router originates its own 356 NHRP Request. The Request contains exactly the same NHRP target, as 357 was carried by the original (received) Request; the NHRP Route 358 Information extension contains the Protocol Type (BGP) of the NHRP 359 forwarding route. The newly originated Request is sent to the next 360 hop of the NHRP forwarding route. Once the border router receives a 361 Reply to its own Request, the border router uses the next hop 362 information from the Reply to construct its own Reply to the source 363 of the original NHRP Request. 365 If later on the border router receives a Purge message for the NHRP 366 forwarding route, the border router treats this event as if there was 367 a local change to the NHRP forwarding route (even if the there was no 368 changes to the route). 370 7.3.2. Handling NHRP Request within the BGP domain 372 When a BGP router (e.g., a border router at the source domain) 373 originates an NHRP Request, this Request would be sent to a router 374 that is either: 376 (a) an egress router from an NBMA network (since in the absence 377 of aggregation BGP preserves the next hop information), or 379 (b) a border router within the domain that contains all the 380 destinations carried by the NHRP target, or 382 (c) a router that aggregates NLRI carried by the NHRP route 383 information of the Request. 385 With case (a) when the router receives the Request, the router sends 386 back an NHRP Reply and terminates the query. Case (b) is handled as 387 described in the next section. 389 With case (c) when a router that receives a Request determines that 390 it performs routing information aggregation for the NHRP target, the 391 router could either (i) initiate another NHRP Request, and use the 392 information received in response to this Request to construct an NHRP 393 Reply for the original Request, or (ii) find the NHRP forwarding 394 route associated with the NHRP target and forward the Request to the 395 next hop of the NHRP forwarding route. The choice between options (i) 396 and (ii) is a local to the router matter. 398 If the router selects option (i), then when the router receives the 399 Request, the router determines the NHRP forwarding route for the NHRP 400 target carried by the Request and originates its own NHRP Request. 401 The Request contains exactly the same NHRP target, as was carried by 402 the original request; the NHRP route information contains the 403 Protocol Type (BGP) of the NHRP forwarding route. The newly 404 originated Request is sent to the next hop of the NHRP forwarding 405 route. Once the router receives a Reply to its own Request, the 406 router uses the next hop information from the Reply to construct its 407 own Reply to the source of the original NHRP Request. If the router 408 later on receives a Purge message for the NHRP forwarding route, the 409 router treats this event as if there was a change to the NHRP 410 forwarding route (even if the there was no changes to the route). 412 7.3.3. Handling NHRP Request at the destination domain border router 414 When a border router receives an NHRP Request from a BGP speaker, and 415 the border router determines that all the destinations covered by the 416 NHRP target of the Request are within the (IGP) domain of that border 417 router, the border router determines the NHRP forwarding route for 418 the NHRP target carried by the Request. The newly formed Request 419 contains exactly the same NHRP target as the received Request; the 420 NHRP route information contains the Protocol Type of the NHRP 421 forwarding route. The newly originated Request is sent to the next 422 hop of the NHRP forwarding route. Once the border router receives a 423 Reply to its own Request, the border router uses the next hop 424 information from the Reply to construct its own Reply to the source 425 of the original NHRP Request. 427 If the border router later on receives a Purge message for the NHRP 428 forwarding route, the border router treats this event as if there was 429 a change to the NHRP forwarding route (even if the there was no 430 changes to the route). 432 7.4. Tradeoffs between state, messages, and path optimality 434 It should be possible to reduce the number of Purge messages and 435 subsequent NHRP messages (caused by the Purge messages) by 436 maintaining more state on the border routers at the source and 437 destination domains, and the BGP routers that perform routing 438 information aggregation along the path from the source to the 439 destination. 441 Specifically, on each such router it would be necessary to keep the 442 information about all the NHRP targets for which the router maintains 443 the shortcut information. This way when the router determines that 444 the NHRP forwarding route (for which the router maintains the 445 shortcut information) changes due to some local routing changes, the 446 router could check whether these local changes impact forwarding to 447 the destinations covered by the NHRP targets. The router would send 448 Purge messages only for the targets that are impacted by the changes. 450 Upon some introspection one could realize that the shortcut 451 information across a BGP domain could be used for as long as the NHRP 452 forwarding route at both ends of the shortcut stays the same (even in 453 the presence of aggregation along the shortcut). Such information 454 would provide loop-free forwarding, but may result in a potentially 455 suboptimal path (if a router that performs aggregation along the path 456 selects another (better) route for forming the aggregate). This way 457 there is no need to maintain an additional state on the BGP routers 458 that perform routing information aggregation, and there will be no 459 additional NHRP traffic when these routers change the way they 460 construct their aggregates, provided that the aggregated routes would 461 stay the same. 463 8. Security Considerations 465 Security issues are not discussed in this document. 467 9. References 469 [NHRP] Katz, D., Piscitello, D., Cole, B., Luciani, J., ``NBMA Next 470 Hop Resolution Protocol (NHRP)'', Internet Draft, December 1995 472 10. Acknowledgements 474 To be supplied. 476 11. Author Information 478 Yakov Rekhter 479 cisco Systems, Inc. 480 170 Tasman Dr. 481 San Jose, CA 95134 482 Phone: (914) 528-0090 483 email: yakov@cisco.com