idnits 2.17.1 draft-ietf-idr-bgp4ospf-interact-07.txt: 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-03-29) 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. ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 an Authors' Addresses Section. ** There are 40 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 178: '...ion of BGP/IDRP OSPF exchange MUST not...' RFC 2119 keyword, line 181: '... 2.1, bullet 3), MUST merge the PATH i...' RFC 2119 keyword, line 183: '...ion (section 3), MUST set the OSPF tag...' RFC 2119 keyword, line 198: '...he administrator MUST be able to selec...' RFC 2119 keyword, line 202: '...filter mechanism MUST support such con...' (56 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 659 has weird spacing: '...eserved for ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A minimal implementation of BGP/IDRP OSPF exchange MUST not advertise a route containing a set of reachable destinations when none of the destinations in the address/mask pair is reachable via OSPF (section 2.1, bullet 3), MUST merge the PATH into a SET when multiple exit points exist within the same autonomous system for the same external destination (section 3), MUST set the OSPF tag accurately (section 4). This subset is chosen so as to cause minimal havoc to the Internet at large. It is strongly recommended that implementors implement more than a minimalistic specification. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 2. An address/mask pair having a non-contiguous mask MUST not be exported to BGP/IDRP. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3. Information learned via BGP/IDRP from peers within the same AS MUST not be imported into OSPF. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: These are imported by a border router, which is running BGP/IDRP to a stub domain, and not running BGP/IDRP to other ASBRs in the same autonomous system. This causes a truncation of the PATH. These destinations MUST not be re-exported into BGP/IDRP at another ASBR. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: These destinations MUST not be exported into BGP/IDRP because these are destinations that are already imported from BGP/IDRP into the OSPF RD. Hence, it is assumed that the BGP/IDRP speaker will convey these routes to other BGP/IDRP speakers within the same autonomous system via BGP/IDRP. An ASBR learning of such a destination MUST wait for the BGP update from its internal neighbours before advertising it to external BGP/IDRP peers. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: _e_x_p_o_r_t These routes MUST not be exported into BGP/IDRP. -- 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 (August 18, 1994) is 10816 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) -- Missing reference section? 'RFC1654' on line 816 looks like a reference -- Missing reference section? 'IDRP' on line 825 looks like a reference -- Missing reference section? 'RFC1583' on line 813 looks like a reference -- Missing reference section? 'ROUTE-LEAKING' on line 819 looks like a reference -- Missing reference section? 'NEXT-HOP' on line 822 looks like a reference -- Missing reference section? 'RFC1267' on line 140 looks like a reference -- Missing reference section? 'RFC1122' on line 798 looks like a reference -- Missing reference section? 'RFC1123' on line 801 looks like a reference -- Missing reference section? 'IS10747' on line 828 looks like a reference -- Missing reference section? 'RFC1247' on line 814 looks like a reference -- Missing reference section? 'RFC1058' on line 795 looks like a reference -- Missing reference section? 'RFC888' on line 792 looks like a reference -- Missing reference section? 'RFC827' on line 789 looks like a reference -- Missing reference section? 'RFC1403' on line 807 looks like a reference -- Missing reference section? 'RFC1519' on line 809 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Varadhan 2 INTERNET DRAFT OARnet & USC/ISI 3 S. Hares 4 NSFnet/Merit 5 Y. Rekhter 6 T.J. Watson Research Center, IBM Corp. 7 August 18, 1994 9 BGP4/IDRP for IP---OSPF Interaction 11 Table of Contents 13 1. Introduction .................................................... 2 14 2. Reachability Information Exchange ............................... 4 15 2.1. Exporting OSPF information into BGP/IDRP ..................... 5 16 2.2. Importing BGP/IDRP information into OSPF ...................... 6 17 3. BGP/IDRP Identifier and OSPF router ID .......................... 7 18 4. Setting OSPF tags, ORIGIN and PATH attributes ................... 9 19 4.1. Configuration parameters for setting the OSPF tag ............. 10 20 4.2. Manually configured tags ...................................... 11 21 4.3. Automatically generated tags .................................. 11 22 4.3.1. Tag = ......... 11 23 4.3.2. Tag = ......... 12 24 4.3.3. Tag = ......... 12 25 4.3.4. Tag = ......... 13 26 4.3.5. Tag = ......... 13 27 4.3.6. Tag = ......... 14 28 4.4. Miscellaneous tag settings .................................... 14 29 5. Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 14 30 6. Changes from the BGP 3 - OSPF interactions document ............. 15 31 7. Security Considerations ......................................... 16 32 8. Acknowledgements ................................................ 16 33 9. Bibliography .................................................... 17 34 10. Appendix ....................................................... 18 35 11. Author's Present Addresses ..................................... 19 37 Status of this Memo 39 This document is an Internet Draft, and can be found as draft-ietf- 40 bgp-bgp4ospf-interact-07.txt in any standard internet drafts 41 repository. Internet Drafts are working documents of the Internet 42 Engineering Task Force (IETF), its Areas, and its Working Groups. 43 Note that other groups may also distribute working documents as 44 Internet Drafts. 46 Internet Drafts are draft documents valid for a maximum of six 48 INTERNET DRAFT (Expires January 1995) August 94 50 months. Internet Drafts may be updated, replaced, or obsoleted by 51 other documents at any time. It is not appropriate to use Internet 52 Drafts as reference material or to cite them other than as a 53 ``working draft'' or ``work in progress.'' 55 Please check the I-D abstract listing contained in each Internet 56 Draft directory to learn the current status of this or any other 57 Internet Draft. 59 Abstract 61 This memo defines the various criteria to be used when designing an 62 Autonomous System Border Router (ASBR) that will run either BGP4 or 63 IDRP for IP with other ASBRs external to the AS and OSPF as its IGP. 65 1. Introduction 67 This document defines the various criteria to be used when designing 68 an Autonomous System Border Router (ASBR) that will run BGP4[RFC1654] 69 or IDRP for IP[IDRP] with other ASBRs external to the AS, and 70 OSPF[RFC1583] as its IGP. 72 All future references of BGP in this document will refer to BGP 73 version 4, as defined in [RFC1654]. All reference to IDRP are 74 references to the Inter-Domain Routing Protocol (ISO 10747) which has 75 been defined by the IDRP for IP document [IDRP] for use in Autonomous 76 Systems. 78 This document defines how the following fields in OSPF and attributes 79 in BGP/IDRP are to be set when interfacing between BGP/IDRP and OSPF 80 at an ASBR: 82 IDRP came out of the same work as BGP, and may be consider a follow 83 on to BGP-3 and BGP-4. Most fields defined in the interaction 84 between BGP and IDRP are named the same. Where different, the IDRP 85 fields are shown separately. 87 BGP/IDRP MULTI_EXIT_DISC 89 BGP ORIGIN and AS_PATH/AS_SET vs. OSPF tag 90 IDRP EXT_INFO and RD_PATH/RD_SET 92 BGP/IDRP NEXT_HOP vs. OSPF Forwarding Address> 94 BGP/IDRP LOCAL_PREF vs. OSPF cost and type 96 IDRP contains RD_PATH and RD_SET fields which serves the same purpose 97 as AS_PATH and AS_SET fields for IDRP for IP. In this document, we 99 INTERNET DRAFT (Expires January 1995) August 94 101 will use the terms PATH and SET to refer to the BGP AS_PATH and 102 AS_SET, or the IDRP RD_PATH and RD_SET fields respectively, depending 103 on the context of the protocol being used. 105 Both IDRP and BGP provide a mechanism to indicate whether the routing 106 information was originated via IGP, or some other means. In IDRP, if 107 route information is originated by means other than an IGP, then the 108 EXT_INFO attribute is present. Likewise, in BGP, if a route 109 information is originated by means other than an IGP, then the ORIGIN 110 attribute is set to or . For the purpose of this 111 document, we need to distinguish between the two cases: 113 (a) Route information was originated via IGP 115 (b) Route information was originated by some other means. 117 The former case is realized in IDRP by not including the EXT_INFO 118 attribute, and in BGP by setting the BGP ORIGIN=; The latter 119 case is realized by including the EXT_INFO attribute in IDRP, and by 120 setting the BGP ORIGIN=. For the rest of the document, we will 121 use the BGP ORIGIN= to refer to the former scenario, and BGP 122 ORIGIN= to refer to the latter. 124 One other difference between IDRP and BGP remains. IDRP for IP 125 identifies an autonomous system by an identifier of variable length 126 that is syntactically identical to an NSAP address prefix, and 127 explicitly embeds the autonomous system number[IDRP]. BGP identifies 128 an autonomous system just by an autonomous system number. Since 129 there is a one-to-one mapping between how an autonomous system is 130 identified in IDRP and in BGP, in this document, we shall identify an 131 autonomous system by its autonomous system number. 133 For a more general treatise on routing and route exchange problems, 134 please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist. 136 This document uses the two terms ``Autonomous System'' and ``Routing 137 Domain.'' The definitions for the two are below: 139 The term Autonomous System is the same as is used in the BGP 140 RFC[RFC1267], given below: 142 ``The use of the term Autonomous System here stresses the fact 143 that, even when multiple IGPs and metrics are used, the 144 administration of an AS appears to other ASs to have a single 145 coherent interior routing plan and presents a consistent picture of 146 what destinations are reachable through it. From the standpoint of 147 exterior routing, an AS can be viewed as monolithic: reachability 148 to destinations directly connected to the AS must be equivalent 150 INTERNET DRAFT (Expires January 1995) August 94 152 from all border gateways of the AS.'' 154 The term Routing Domain was first used in [ROUTE-LEAKING] and is 155 given below: 157 ``A Routing Domain is a collection of routers which coordinate 158 their routing knowledge using a single [instance of a] routing 159 protocol.'' 161 By definition, a Routing Domain forms a single Autonomous System, 162 but an Autonomous System may be composed of a collection of Routing 163 Domains. 165 BGP, IDRP and OSPF have the concept of a set of reachable 166 destinations. This set is called NLRI or Network Layer 167 Reachability Information. The set can be represented either as an 168 IP address prefix, or an address, mask pair. Note that if the mask 169 is contiguous in the latter, then the two representations are 170 equivalent. In this document, we use the term `address/mask pair'' 171 in the context of OSPF, and ``destination'' or ``set of reachable 172 destinations'' in the context of BGP or IDRP. 174 This document follows the conventions embodied in the Host 175 Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST", 176 "SHOULD," and "MAY" for the various requirements. 178 A minimal implementation of BGP/IDRP OSPF exchange MUST not 179 advertise a route containing a set of reachable destinations when 180 none of the destinations in the address/mask pair is reachable via 181 OSPF (section 2.1, bullet 3), MUST merge the PATH into a SET when 182 multiple exit points exist within the same autonomous system for 183 the same external destination (section 3), MUST set the OSPF tag 184 accurately (section 4). This subset is chosen so as to cause 185 minimal havoc to the Internet at large. It is strongly recommended 186 that implementors implement more than a minimalistic specification. 188 2. Reachability Information Exchange 190 This section discusses the constraints that must be met to exchange 191 the set of reachable destinations between an external BGP/IDRP peer 192 from another AS and internal OSPF address/mask pairs. 194 INTERNET DRAFT (Expires January 1995) August 94 196 2.1. Exporting OSPF information into BGP 198 1. The administrator MUST be able to selectively export 199 address/mask pairs into BGP/IDRP via an appropriate filter 200 mechanism. 202 This filter mechanism MUST support such control with the 203 granularity of an address/mask pair. 205 This filter mechanism will be the primary method of 206 aggregation of OSPF internal and type 1 and type 2 external 207 routes within the AS into BGP/IDRP. 209 Additionally, the administrator MUST be able to filter based 210 on the OSPF tag and the various sub-fields of the OSPF tag. 211 The settings of the tag and the sub-fields are defined in 212 section 4 in more detail. 214 o The default MUST be to export no routes from OSPF into 215 BGP/IDRP. A single configuration parameter MUST permit 216 all OSPF inter-area and intra-area address/mask pairs to 217 be exported into BGP/IDRP. 219 OSPF external address/mask pairs of type 1 and type 2 220 MUST never be exported into BGP/IDRP unless they are 221 explicitly configured. 223 2. An address/mask pair having a non-contiguous mask MUST not be 224 exported to BGP/IDRP. 226 3. When configured to export an address/mask pair from OSPF into 227 BGP/IDRP, the ASBR MAY advertise the route containing the set 228 of reachable destinations via BGP/IDRP as soon as at least 229 one of the destinations in the address/mask pair is 230 determined to be reachable via OSPF; it MUST stop advertising 231 the route containing the set of reachable destinations when 232 none of the destinations in the address/mask pair is 233 reachable via OSPF. 235 4. The network administrator MUST be able to statically 236 configure the BGP/IDRP attribute MULTI_EXIT_DISC attribute to 237 be used for any route. 239 o The default MUST be to omit the MULTI_EXIT_DISC in the 240 route advertised via BGP/IDRP. 242 INTERNET DRAFT (Expires January 1995) August 94 244 5. An implementation of BGP/IDRP and OSPF on an ASBR MUST have a 245 mechanism to set up a minimum amount of time that must elapse 246 between the learning of a new address/mask pair via OSPF and 247 subsequent advertisement of the address/mask pair via 248 BGP/IDRP to the external neighbours. 250 o The default value for this setting MUST be 0, indicating 251 that the address/mask pair is to be advertised to the 252 neighbour BGP/IDRP peers instantly. 254 Note that BGP and IDRP mandate a mechanism to dampen the 255 inbound advertisements from adjacent neighbours. See 256 the variable MinRouteAdvertisementInterval in section 257 9.2.3.1, [RFC1654] or in section 7.17.3.1, [IS10747]. 259 6. LOCAL_PREF is not used when exporting OSPF information into 260 BGP/IDRP. 262 2.2. Importing BGP/IDRP information into OSPF 264 1. BGP/IDRP implementations SHOULD allow an AS to control 265 announcements of BGP/IDRP learned set of reachable 266 destinations into OSPF. Implementations SHOULD support such 267 control with the granularity of a single destination. 269 Implementations SHOULD also support such control with the 270 granularity of an autonomous system, where the autonomous 271 system may be either the autonomous system that originated 272 the information or the autonomous system that advertised the 273 information to the local system (adjacent autonomous system). 275 o The default MUST be to import nothing from BGP/IDRP into 276 OSPF. Administrators must configure every destination 277 they wish to import. 279 A configuration parameter MAY allow an administrator to 280 configure an ASBR to import all the set of reachable 281 destinations from BGP/IDRP into the OSPF routing domain. 283 2. The administrator MUST be able to configure the OSPF cost and 284 the OSPF metric type of every destination imported into OSPF. 285 The OSPF metric type MUST default to type 2. If the 286 LOCAL_PREF value is used to construct the OSPF cost, one must 287 be extremely careful with such a conversion. In OSPF the 288 lower cost is preferred, while in BGP/IDRP the higher value 289 of the LOCAL_PREF is preferred. In addition, the OSPF cost 290 ranges between 1 and 2^24, while the LOCAL_PREF value ranges 291 between 0 and 2^32. Note that if ASBRs within a domain are 293 INTERNET DRAFT (Expires January 1995) August 94 295 configured to correlate BGP/IDRP and OSPF information (as 296 described in Section 3), then the route selection by the 297 ASBRs is determined solely by the OSPF cost, and the value 298 carried by the LOCAL_PREF attribute has no impact on the 299 route selection. 301 3. Information learned via BGP/IDRP from peers within the same 302 AS MUST not be imported into OSPF. 304 4. The ASBR MUST never generate a default destination into the 305 OSPF routing domain unless explicitly configured to do so. 307 A default destination is a set of all possible destinations. 308 By convention, it is represented as a prefix of 0 length or a 309 mask of all zeroes. 311 A possible criterion for generating default into an IGP is to 312 allow the administrator to specify a set of (set of reachable 313 destinations, PATH, default cost, default type) tuples. If 314 the ASBR learns of at least one of the destinations in the 315 set of reachable destinations, with the corresponding PATH, 316 then it generates a default destination into the OSPF routing 317 domain, with the appropriate cost and type. The lowest cost 318 route will then be injected into the OSPF routing domain. 320 This is the recommended method for originating default 321 destinations in the OSPF routing domain. 323 5. Note that [RFC1247] requires the network number to be used as 324 the Link State ID. This will produce a conflict if the ASBR 325 tries to import two destinations, differing only in their 326 prefix length. This problem is fixed in [RFC1583], which 327 obsoletes [RFC1247]. 329 An implementation conforming to the older [RFC1247] MUST, in 330 this case, drop the more specific route, i.e. the route 331 corresponding to the longer prefix in the reachability 332 information. 334 6. MULTI_EXIT_DISC is not used to import BGP/IDRP information 335 into OSPF. 337 3. BGP/IDRP Identifier and OSPF router ID 339 The BGP/IDRP identifier MUST be the same as the OSPF router id at all 340 times that the router is up. 342 Note that [RFC1654] requires that the BGP identifier be an address 344 INTERNET DRAFT (Expires January 1995) August 94 346 assigned to the BGP speaker. 348 In the case of IDRP, the IDRP protocol does not explicitly carry the 349 identity of the IDRP speaker. An implicit notion of the identity of 350 the IDRP speaker can be obtained by examining the source address in 351 the IP packets carrying the IDRP information. Therefore, all IDRP 352 speakers participating in the OSPF protocol MUST bind the IDRP 353 identifier to be the address of the OSPF router id. 355 This characteristic makes it convenient for the network administrator 356 looking at an ASBR to correlate different BGP/IDRP and OSPF 357 information based on the identifier. There is another more important 358 reason for this characteristic. 360 Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3, belong to 361 the same autonomous system. 363 +-----+ 364 | RT3 | 365 +-----+ 366 | 368 Autonomous System running OSPF 370 / \ 372 +-----+ +-----+ 373 | RT1 | | RT2 | 374 +-----+ +-----+ 376 Both RT1 and RT2 can reach an external destination X and import this 377 information into the OSPF routing domain. RT3 is advertising this 378 information about destination X to other external BGP/IDRP speakers. 379 The following rule specifies how RT3 can generate the correct 380 advertisement. 382 RT3 MUST determine which ASBR(s) it is using to reach destination X 383 by matching the OSPF router ID for its route to destination with the 384 BGP identifier of the ASBR(s), or the IP source address of the IDRP 385 protocol packet from the ASBR(s). 387 o If RT3 has equal cost routes to X through RT1 and RT2, then, 388 RT3 MUST merge the PATH through RT1 and RT2 into a SET. 390 o Otherwise, RT3 MAY merge the PATH through RT1 and RT2. 392 INTERNET DRAFT (Expires January 1995) August 94 394 It MAY then generate the corresponding network layer reachability 395 information for further advertisement to external BGP/IDRP peers. 397 4. Setting OSPF tags, ORIGIN and PATH attributes 399 The OSPF external route tag is a ``32-bit field attached to each 400 external route . . . It may be used to communicate information 401 between AS boundary routers; the precise nature of such information 402 is outside the scope of [the] specification.''[RFC1583] 404 We use the external route tag field in OSPF to intelligently set the 405 ORIGIN and PATH attributes in BGP/IDRP. These attributes are well- 406 known, mandatory attributes in BGP/IDRP. The exact mechanism for 407 setting the tags is defined in sections 4.2 and 4.3. Every 408 combination of tag bits is described in two parts: 410 _i_m_p_o_r_t This describes when an ASBR imports an AS external LSA into 411 the OSPF domain with the given tag setting. 413 _e_x_p_o_r_t This indicates how the BGP/IDRP path attribues should be 414 formatted when an ASBR, having a given type 1 or type 2 415 OSPF external route in its routing table, decides to export 416 according to the considerations in section 2.1. 418 The tag is broken up into sub-fields shown below. The various 419 sub-fields specify the characteristics of the set of reachable 420 destinations imported into the OSPF routing domain. 422 The high bit of the OSPF tag is known as the ``Automatic'' bit. 423 Setting this bit indicates that the tag has been generated 424 automatically by an ASBR. 426 When the network administrator configures the tag, this bit MUST be 427 0. This setting is the default tag setting, and is described in 428 section 4.2. 430 When the tag is automatically generated, this bit is set to 1. The 431 other bits are defined below: 433 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 |1|c|p l| ArbitraryTag | AutonomousSystem | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 INTERNET DRAFT (Expires January 1995) August 94 441 c 1 bit of Completeness information, set when the ORIGIN of the 442 route is either or . 444 pl 2 bits of PathLength information; this field is set depending 445 on the length of the PATH that the protocol would have carried 446 if it could have carried the PATH, when importing the 447 reachability information into the OSPF routing domain. 449 ArbitraryTag 450 12 bits of tag information, defaults to 0 but can be 451 configured to anything else. 453 AutonomousSystem (or ``AS'') 454 16 bits, indicating the AS number corresponding to the set of 455 reachable destinations, 0 if the set of reachable destinations 456 is to be considered as part of the local AS. 458 local_AS: The AS number of the local OSPF routing domain. 460 next_hop_AS: The AS number of an external BGP peer. 462 4.1. Configuration parameters for setting the OSPF tag 464 o There MUST be a mechanism to enable automatic generation of 465 the tag characteristic bits. 467 o Configuration of an ASBR running OSPF MUST include the 468 capability to associate a tag value, for the ArbitraryTag, or 469 LocalInfo sub-field of the OSPF tag, with each instance of a 470 routing domain. 472 o Configuration of an ASBR running OSPF MUST include the 473 capability to associate an AS number with each instance of a 474 routing domain. 476 Associating an AS number with an instance of an IGP is 477 equivalent to flagging those set of reachable destinations 478 imported from the IGP to be external destinations outside the 479 local autonomous system. 481 Specifically, when the IGP is RIP[RFC1058], it SHOULD be 482 possible to associate a tag and/or an AS number with every 483 interface running RIP on the ASBR. 485 INTERNET DRAFT (Expires January 1995) August 94 487 4.2. Manually configured tags 489 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |0| LocalInfo | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 _i_m_p_o_r_t This tag setting corresponds to the administrator manually 496 setting the OSPF tag bits. 498 _e_x_p_o_r_t The route SHOULD be exported into BGP with the attributes 499 ORIGIN=, PATH=. 501 Nothing MUST inferred about the characteristics of the set of 502 reachable destinations corresponding to this tag setting. 504 For backward compatibility with existing implementations of OSPF 505 currently deployed in the field, this MUST be the default setting 506 for importing destinations into the OSPF routing domain. There 507 MUST be a mechanism to enable automatic tag generation for 508 imported destinations. 510 4.3. Automatically generated tags 512 4.3.1. Tag = 514 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |1|0|0|0| ArbitraryTag | AutonomousSystem | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 _i_m_p_o_r_t These are reachable destinations imported from routing 521 protocols with incomplete path information and cannot 522 or may not carry the neighbour AS or AS path (and hence 523 the IDRP RD_PATH) as part of the routing information. 525 This setting SHOULD be used to import reachable 526 destinations from an IGP that the network administrator 527 has configured as external routes, without specifying 528 the next_hop_AS. 530 _e_x_p_o_r_t The route SHOULD be exported into BGP/IDRP with the 531 attributes ORIGIN=, PATH=. 533 INTERNET DRAFT (Expires January 1995) August 94 535 4.3.2. Tag = 537 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 |1|0|0|1| ArbitraryTag | AutonomousSystem | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 _i_m_p_o_r_t These are reachable destinations imported from routing 544 protocols with incomplete path information. The 545 neighbour AS (and therefore IDRP RD) is carried in the 546 routing information. 548 This setting SHOULD be used for importing reachable 549 destinations from EGP into the OSPF routing domain. 550 This setting MAY also be used when importing reachable 551 destinations from BGP/IDRP whose ORIGIN= and 552 PATH=; if the BGP/IDRP learned route has 553 no other transitive attributes, then its propagation 554 via BGP/IDRP to ASBRs internal to the autonomous system 555 MAY be suppressed. 557 _e_x_p_o_r_t The route SHOULD be exported into BGP/IDRP with 558 ORIGIN= and PATH=. 560 4.3.3. Tag = 562 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 |1|0|1|0| ArbitraryTag | AutonomousSystem | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 _i_m_p_o_r_t These are reachable destinations imported from routing 569 protocols with truncated path information. 571 These are imported by a border router, which is running 572 BGP/IDRP to a stub domain, and not running BGP/IDRP to 573 other ASBRs in the same autonomous system. This causes 574 a truncation of the PATH. These destinations MUST not 575 be re-exported into BGP/IDRP at another ASBR. 577 _e_x_p_o_r_t The route MUST never be exported into BGP/IDRP. 579 INTERNET DRAFT (Expires January 1995) August 94 581 4.3.4. Tag = 583 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |1|1|0|0| ArbitraryTag | AutonomousSystem | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 _i_m_p_o_r_t These are reachable destinations imported from routing 590 protocols with either complete path information or are 591 known to be complete through means other than that 592 carried by the routing protocol. 594 This setting SHOULD be used for importing reachable 595 destinations into OSPF from an IGP. 597 _e_x_p_o_r_t The route SHOULD be exported to BGP/IDRP with 598 ORIGIN=, PATH=. 600 4.3.5. Tag = 602 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 |1|1|0|1| ArbitraryTag | AutonomousSystem | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 _i_m_p_o_r_t These are reachable destinations imported from routing 609 protocols with either complete path information, or are 610 known to be complete through means other than that 611 carried by the routing protocol. The routing protocol 612 also has additional information about the next hop AS 613 or RD, the destination was learned from. 615 This setting SHOULD be used when the administrator 616 explicitly associates an AS number with an instance of 617 an IGP. This setting MAY also be used when importing 618 reachable destinations from BGP/IDRP whose ORIGIN= 619 and PATH=; if the BGP/IDRP learned route 620 has no other transitive attributes, then its 621 propagation via BGP/IDRP to other ASBRs internal to the 622 autonomous system MAY be suppressed. 624 _e_x_p_o_r_t OSPF routes with this tag setting SHOULD be exported 625 with the BGP/IDRP attributes, ORIGIN=, 626 PATH=. 628 INTERNET DRAFT (Expires January 1995) August 94 630 4.3.6. Tag = 632 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 |1|1|1|0| ArbitraryTag | AutonomousSystem | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 _i_m_p_o_r_t These are reachable destinations imported from routing 639 protocols with complete path information and carry the 640 AS path information as part of the routing information. 642 These destinations MUST not be exported into BGP/IDRP 643 because these are destinations that are already 644 imported from BGP/IDRP into the OSPF RD. Hence, it is 645 assumed that the BGP/IDRP speaker will convey these 646 routes to other BGP/IDRP speakers within the same 647 autonomous system via BGP/IDRP. An ASBR learning of 648 such a destination MUST wait for the BGP update from 649 its internal neighbours before advertising it to 650 external BGP/IDRP peers. 652 _e_x_p_o_r_t These routes MUST not be exported into BGP/IDRP. 654 4.4. Miscellaneous tag settings 656 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |1|x|1|1| Reserved for future use | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 The value of PathLength=11 is reserved during automatic tag 663 generation. Routers must not generate such a tag when importing 664 reachable destinations into the OSPF routing domain. ASBRs must 665 ignore tags which indicate a PathLength=11. 667 5. Setting OSPF Forwarding Address and BGP/IDRP NEXT_HOP attribute 669 Forwarding addresses are used to avoid extra hops between multiple 670 routers that share a common network and that speak different routing 671 protocols with each other on the common network. 673 Both BGP/IDRP and OSPF have equivalents of forwarding addresses. In 674 BGP and IDRP, the NEXT_HOP attribute is a well-known, mandatory 675 attribute. OSPF has a Forwarding address field. We will discuss how 676 these are to be filled in various situations. 678 INTERNET DRAFT (Expires January 1995) August 94 680 Consider the 4 router situation below: 682 RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another. 683 RT1 and RT3 are talking BGP/IDRP with each other. RT3 and RT4 are 684 talking OSPF with each other. 686 +-----+ +-----+ 687 | RT1 | | RT2 | 688 +-----+ +-----+ 689 | | common network 690 ---+-----------------------+-------------------------- 691 | | 692 +-----+ +-----+ 693 | RT3 | | RT4 | 694 +-----+ +-----+ 696 - Importing a reachable destination into OSPF: 697 When importing a destination from BGP/IDRP into OSPF, RT3 MUST 698 always fill the OSPF Forwarding Address with the BGP/IDRP 699 NEXT_HOP attribute for the destination. 701 - Exporting a reachable destination into BGP: 702 When exporting set of reachable destinations internal to the 703 OSPF routing domain from OSPF to BGP/IDRP, if all the 704 destinations in the set of reachable destinations are through 705 RT4, then RT3 MAY fill the NEXT_HOP attribute for the set of 706 reachable destinations with the address of RT4. This is to 707 avoid requiring packets to take an extra hop through RT3 when 708 traversing the AS boundary. This is similar to the concept of 709 indirect neighbour support in EGP[RFC888, RFC827]. 711 6. Changes from the BGP 3 - OSPF interactions document 713 o The use of the term "route" has attained a more complicated 714 structure in BGP 4. This document follows the constraint in 715 the manner shown below: 717 - The term "set of reachable destinations" is called a NLRI 718 in [RFC1654]. 720 - The term "route" in the BGP context refers to a set of 721 reachable destinations, and the associated attributes for 722 the set. 724 - The term "route" in the OSPF context refers to the set of 725 reachable destinations, and the cost and the type to 727 INTERNET DRAFT (Expires January 1995) August 94 729 reach destinations. This is to keep the definitions 730 consistent in the document. 732 o The notion of exchanging reachability information between BGP 733 4 and OSPF has been updated to handle variable length net mask 734 information. 736 o The previous term INTER_AS_METRIC in BGP 3 has now been 737 changed to MULTI_EXIT_DISC. 739 o The default metric to be used for importing BGP information 740 into the OSPF RD is now the LOCAL_PREF attribute, instead of a 741 constant value. 743 o Section 3 which requires an ASBR to match the OSPF tag 744 corresponding to a route to the BGP Identifier, can cause 745 potential loops if the AS has equal cost multipath routing 746 amongst the ASBRs. This scenario is outlined in the Appendix 747 below. This is fixed in BGP4 by requiring the ASBR seeing 748 equal cost multi-path routes to merge the PATHs through the 749 various ASBRs into appropriate SETs. 751 o BGP 4 requires that the BGP identifier be an address assigned 752 to the BGP speaker. This is dealt with in section 3. 754 o Section 5 on setting NEXT_HOP attributes and Forwarding 755 Address field has been updated to account for variable length 756 net information. 758 o This section, 6, has been added. 760 7. Security Considerations 762 Security considerations are not discussed in this memo. 764 8. Acknowledgements 766 We would like to thank Jeff Honig (Cornell University), John Moy 767 (Cascade Communications Corp.), Tony Li (cisco Systems), Rob Coltun 768 (Consultant), Dennis Ferguson (ANS, Inc.), and Phil Almquist 769 (Consultant) for their help and suggestions in writing this document. 770 Cengiz Aleattinoglu (USC/ISI) and Steve Hotz (USC/ISI) provided fresh 771 insights into the packet looping problem described in the appendix. 773 We would also like to thank the countless number of people from the 774 OSPF and BGP working groups who have offered numerous suggestions and 775 comments on the different stages of this document. 777 INTERNET DRAFT (Expires January 1995) August 94 779 Thanks also to Bob Braden (ISI), whose suggestions on the earlier 780 BGP-OSPF document, [RFC1403] were useful even for this one, and have 781 been carried through. 783 We would also like to thank OARnet, where one of the authors did most 784 of his work on this document, before moving to USC to resurrect his 785 PhD. 787 9. Bibliography 789 [RFC827] Rosen, Eric C., ``Exterior Gateway Protocol (EGP)'', October 790 1982. 792 [RFC888] Seamonson, Linda J.; and Rosen, Eric C., ``'STUB' Exterior 793 Gateway Protocol'', January 1984. 795 [RFC1058] Hedrick, Charles, L., ``Routing Information Protocol'', June 796 1988. 798 [RFC1122] Braden, R.T., ed., ``Requirements for Internet hosts - 799 communication layers'', October 1989. 801 [RFC1123] Braden, R.T., ed., ``Requirements for Internet hosts - 802 application and support'', October 1989. 804 [RFC1247] Moy, John, ``The OSPF Specification Version 2'', January 805 1991. 807 [RFC1403] Varadhan, Kannan; ``BGP OSPF Interaction''; January 1993. 809 [RFC1519] Fuller, Vince; Li, Tony; Yu, Jessica; Varadhan, Kannan, 810 ``Supernetting: an Address Assignment and Aggregation Strategy'', 811 September 1993. 813 [RFC1583] Moy, John, ``The OSPF Specification Version 2'', (Obsoletes 814 [RFC1247]) March 1994. 816 [RFC1654] Rekhter, Yakov; and Li, Tony, Editors ``A Border Gateway 817 Protocol 4 (BGP-4)'', July 1994. 819 [ROUTE-LEAKING] Almquist, Philip, ``Ruminations on Route Leaking'', in 820 preparation. 822 [NEXT-HOP] Almquist, Philip, ``Ruminations on the Next Hop'', in 823 preparation. 825 [IDRP] Hares, Susan; ``IDRP for IP'', in preparation 826 INTERNET DRAFT (Expires January 1995) August 94 828 [IS10747] ISO/IEC IS 10747 - Information Processing Systems - 829 Telecommunications and Information Exchange between Systems - 830 Protocol for Exchange of Inter-domain Routeing Information among 831 Intermediate Systems to Support Forwarding of ISO 8473 PDUs, 1993. 833 10. Appendix 835 This is an example of how the two routing protocols, BGP/IDRP and 836 OSPF, might both be consistent in their behaviour, and yet packets 837 from a source domain, S, to a destination in domain X might be stuck 838 in a forwarding loop. 840 +--------+ 841 X ----------| C1 | 842 | |Domain C| 843 | | C3 C2 | 844 | +--------+ 845 B / \ 846 \ / \ 847 \ / S 848 \ / / 849 \ / / 850 +--------+ / 851 | A1 A2 | / 852 |Domain A| / 853 | A3 |-/ 854 +--------+ 856 Given the domains, X, A, B, C and S, let domains A and C be running 857 OSPF, and ASBRs A3 and C3 have equal cost multipath routes to A1, A2 858 and C1, C2 respectively. The picture above shows the internal 859 structure of domains A and C only. 861 During steady state, the following are the route advertisements: 863 o Domain B advertises to A path 865 o ASBR A3 in domain A advertises path to domain C, at 866 ASBR C2. 868 o Domain C has two equal cost paths to X: one direct , and 869 another through A 871 o BR C3 in domain C advertises to A2 path 873 o Domain A has two equal cost paths to X: and 875 INTERNET DRAFT (Expires January 1995) August 94 877 Both C1 and C2 inject a route to X within the domain C, and 878 likewise A1 and A2 inject a route to X within the domain A. Since 879 A3 and C3 see equal cost routes to X through A1, A2 and C1, C2 880 respectively, a stable loop through ASBRs 881 exists. 883 Section 4 specifies that A3 and C3 that advertise a PATH to 884 destination X, MUST aggregate all the PATHs through A1 and A2, and 885 C1 and C2 respectively. This has the consequence of constraining 886 the BGP/IDRP speaker in either domain A or domain C from choosing 887 multiple routes to destination X, and importing only one route into 888 OSPF. This breaks the multiple paths seen in one domain. The 889 exact domain in which the multiple paths are broken is 890 nondeterministic. 892 11. Author's Present Addresses 894 Kannan Varadhan 895 USC/Information Sciences Institute 896 4676, Admiralty Way, 897 Marina Del Ray, Ca 9XXXXX 898 Phone: (310) 822-1511 x 402 899 e-mail: kannan@isi.edu 901 Susan Hares 902 e-mail: skh@merit.edu 904 Yakov Rekhter 905 T.J. Watson Research Center, IBM Corporation 906 P.O. Box 218 907 Yorktown Heights, NY 10598 908 Phone: (914) 945-3896 909 e-mail: yakov@watson.ibm.com