idnits 2.17.1 draft-ietf-l3vpn-ospf-2547-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2003) is 7738 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: 'OSPF-DNbit' is mentioned on line 268, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-06 == Outdated reference: A later version (-04) exists of draft-ietf-ospf-2547-dnbit-03 == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Peter Psenak 4 Expiration Date: August 2003 Cisco Systems, Inc. 6 Padma Pillay-Esnault 7 Juniper Networks, Inc. 9 February 2003 11 OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs 13 draft-ietf-l3vpn-ospf-2547-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 other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document specifies procedures to be used when a Service Provider 38 (SP) provides "BGP/MPLS IP VPN" service to a customer, and the 39 customer uses OSPF to advertise its routes to the SP. 41 Table of Contents 43 1 Specification of Requirements ........................ 2 44 2 Introduction ......................................... 2 45 3 Requirements ......................................... 3 46 4 BGP/OSPF Interaction Procedures for PE routers ....... 5 47 4.1 Overview ............................................. 5 48 4.2 Details .............................................. 7 49 4.2.1 General .............................................. 7 50 4.2.2 Handling LSAs from the CE ............................ 9 51 4.2.3 Sham Links ........................................... 12 52 4.2.3.1 Intra-Area Routes .................................... 12 53 4.2.3.2 Creating Sham Links .................................. 12 54 4.2.3.3 Treatment of Sham Links .............................. 14 55 4.2.4 VPN-IP routes received via BGP ....................... 14 56 4.2.4.1 Routes from Different Domains ........................ 15 57 4.2.4.2 Other External Routes ................................ 16 58 4.2.4.3 Summary Routes ....................................... 16 59 5 Acknowledgments ...................................... 17 60 6 Authors' Addresses ................................... 17 61 7 Normative References ................................. 17 62 8 Intellectual Property Notice ......................... 18 63 9 Copyright Notice ..................................... 18 65 1. Specification of Requirements 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119. 71 2. Introduction 73 [VPN] describes a method by which a Service Provider (SP) can use its 74 IP backbone to provide a VPN service to customers. In that method, a 75 customer's edge devices (CE devices) are connected to the provider's 76 edge routers (PE routers). If the CE device is a router, then the PE 77 router may become a routing peer of the CE router (in some routing 78 protocol), and may as a result learn the routes which lead to the 79 CE's site and which need to be distributed to other PE routers that 80 attach to the same VPN. 82 The PE routers which attach to a common VPN use BGP to distribute the 83 VPN's routes to each other. A CE router can then learn the routes to 84 other sites in the VPN by peering with its attached PE router in a 85 routing protocol. CE routers at different sites do not, however, 86 peer with each other. 88 It can be expected that many VPNs will use OSPF as their internal 89 routing protocol. This does not necessarily mean that the PE routers 90 need to use OSPF to peer with the CE routers. Each site in a VPN can 91 use OSPF as its intra-site routing protocol, while using, e.g., BGP 92 or RIP to distribute routes to a PE router. However, it is certainly 93 convenient, when OSPF is being used intra-site, to use it on the PE- 94 CE link as well, and [VPN] explicitly allows this. 96 Like anything else, the use of OSPF on the PE-CE link has advantages 97 and disadvantages. The disadvantage to using OSPF on the PE-CE link 98 is that it gets the PE router involved in a VPN site's IGP, however 99 peripherally. The advantages though are: 101 - The administrators of the CE router need not have any expertise 102 in any routing protocol other than OSPF. 104 - The CE routers do not need to have support for any routing 105 protocols other than OSPF. 107 - If a customer is transitioning his network from a traditional 108 OSPF backbone to the VPN service described in [VPN], the use of 109 OSPF on the PE-CE link eases the transitional issues. 111 It seems likely that some SPs and their customers will resolve these 112 trade-offs in favor of the use of OSPF on the PE-CE link. Thus we 113 need to specify the procedures which must be implemented by a PE 114 router in order to make this possible. (No special procedures are 115 needed in the CE router though; CE routers just run whatever OSPF 116 implementations they may have.) 118 3. Requirements 120 Consider a set of VPN sites which are thought of as a common "OSPF 121 domain". These will almost certainly be a set of sites which 122 together constitute an "intranet", and each of which runs OSPF as its 123 intra-site routing protocol. 125 Per [VPN], the VPN routes are distributed among the PE routers by 126 BGP. If the PE uses OSPF to distribute routes to the CE router, the 127 standard procedures governing BGP/OSPF interactions [OSPF] would 128 cause routes from one site to be delivered to another as AS-external 129 routes (in type 5 LSAs). This is undesirable; it would be much 130 better to deliver such routes in type 3 LSAs (as inter-area routes), 131 so that they can be distinguished from any "real" AS-external routes 132 that may be circulating in the VPN. (That is, so that they can be 133 distinguished by OSPF from routes which really do not come from 134 within the VPN.) Hence it is necessary for the PE routers to 135 implement a modified version of the BGP/OSPF interaction procedures. 137 In fact, we would like to have a very general set of procedures which 138 allows a customer to easily replace a legacy private OSPF backbone 139 with the VPN service. We would like this procedure to meet the 140 following set of requirements: 142 - The procedures should not make assumptions about the OSPF 143 topology. In particular, it should not be assumed that customer 144 sites are OSPF stub sites or NSSA sites. Nor should it be 145 assumed that a customer site contains only one OSPF area, or that 146 it has no area 0 routers. 148 - If VPN sites A and B are in the same OSPF domain, then routes 149 from one should be presented to the other as OSPF intra-network 150 routes. In general, this can be done by presenting such routes 151 as inter-area routes, in type 3 LSAs. 153 Note that this allows two VPN sites to be connected via an "OSPF 154 backdoor link". That is, one can have an OSPF link between the 155 two sites which is used only when the VPN backbone is 156 unavailable. (This would not be possible with the ordinary 157 BGP/OSPF interaction procedures. The ordinary procedures would 158 present routes via the VPN backbone as AS-external routes, and 159 these could never be preferred to intra-network routes.) This 160 may be very useful during a period of transition from a legacy 161 OSPF backbone to a VPN backbone. 163 - It should be possible to make use of an "OSPF backdoor link" 164 between two sites, even if the two sites are in the same OSPF 165 area, and neither of the routers attached to the inter-site 166 backdoor link is an area 0 router. This can also be very useful 167 during a transition period, and eliminates any need to 168 reconfigure the sites' routers to be ABRs. 170 Assuming that it is desired to have the route via the VPN 171 backbone be preferred to the backdoor route, the VPN backbone 172 itself must be presented to the CE routers at each site as a link 173 between the two PE routers to which the CE routers are 174 respectively attached. 176 - CE routers, connected to PE routers of the VPN service, may 177 themselves function as OSPF backbone (area 0) routers. An OSPF 178 backbone may even consist of several "segments" which are 179 interconnected themselves only via the VPN service. In such a 180 scenario, full intercommunication between sites connected to 181 different segments of the OSPF backbone should still be possible. 183 - The transition from the legacy private OSPF backbone to the VPN 184 service must be simple and straightforward. The transition is 185 likely to be phased, such that customer sites are migrated one by 186 one from the legacy private OSPF backbone to the VPN service. 187 During the transition, any given site might be connected to the 188 VPN service, to the legacy OSPF backbone, or to both. Complete 189 connectivity among all such sites must be maintained. 191 Since the VPN service is to replace the legacy backbone, it must 192 be possible, by suitable adjustment of the OSPF metrics, to make 193 OSPF prefer routes which traverse the SP's VPN backbone to 194 alternative routes which do not. 196 - The OSPF metric assigned to a given route should be carried 197 transparently over the VPN backbone. 199 Routes from sites which are not in the same OSPF domain will appear 200 as AS-external routes. 202 We presuppose familiarity with the contents of [OSPF], including the 203 OSPF LSA types, and will refer without further exegesis to type 1, 2, 204 3, etc., LSAs. Familiarity with [VPN] is also presupposed. 206 4. BGP/OSPF Interaction Procedures for PE routers 208 4.1. Overview 210 [VPN] defines the notion of a Per-Site Routing and Forwarding Table, 211 or VRF. A PE router must be capable of running multiple instances of 212 OSPF, where each instance is associated with a particular VRF. 213 (Whether these instances are realized as separate processes, or 214 merely as separate contexts of a common process, is an implementation 215 matter.) 217 BGP is used to distribute routes among the set of PE routers that 218 attach to a single OSPF domain. Per [VPN], these routes are 219 distributed as VPN-IP routes. Import/export to/from particular VRFs 220 is governed via Route Targets. To meet the above requirements, a PE 221 which imports a particular route into a particular VRF needs to know 222 whether that route comes from the same OSPF domain and the same OSPF 223 area as the CEs to which it is attached. Our procedure is to encode 224 this information as BGP Extended Communities attributes [EXT], and 225 have BGP distribute it along with the VPN-IP route. The OSPF metric 226 of a route is also carried as a BGP attribute of the route. 228 If two PEs attach to different VPN sites that are in the same OSPF 229 area (as indicated by the OSPF area number), the PE/CE links to those 230 site MAY be treated as links within that area. In addition, each PE 231 MAY flood, into that area, a type 1 LSA advertising a link to the 232 other PE. If this procedure is followed, two VPN sites in the same 233 OSPF area will see the VPN backbone as a link within that area, a 234 link between the two PE routers. We refer to this link as a "sham 235 link". This allows routes from one site to the other to be treated 236 as intra-area routes. The procedures governing the use of sham links 237 are specified in Section 4.2.3. 239 Every PE attached to a particular OSPF network MUST function as an 240 OSPF area 0 router. This allows it to distribute inter-area routes to 241 the CE via Type 3 LSAs. The CE router might or might not be an area 242 0 router, and the PE/CE link might or might not be an area 0 link. 244 If the OSPF domain has any area 0 routers (other than the PE 245 routers), then at least one of those MUST be a CE router, and MUST 246 have an area 0 link to at least one PE router. This adjacency MAY be 247 via an OSPF virtual link. This is necessary to ensure that inter-area 248 routes and AS-external routes can be leaked between the PE routers 249 and the non-PE OSPF backbone. 251 When a type 3 LSA is sent from a PE router to a CE router, the DN bit 252 [OSPF-DNbit] in the LSA Options field MUST be set. This is used to 253 ensure that if any CE router sends this type 3 LSA to a PE router, 254 the PE router will not further redistribute it. 256 Two sites which are not in the same OSPF area will see the VPN 257 backbone as being an integral part of the OSPF backbone. However, if 258 there are area 0 routers which are NOT PE routers, then the VPN 259 backbone actually functions as a sort of higher level backbone, 260 providing a third level of hierarchy above area 0. This allows a 261 legacy OSPF backbone to become disconnected during a transition 262 period, as long as the various segments all attach to the VPN 263 backbone. 265 When a PE router needs to distribute to a CE router a route which 266 comes from a site outside the latter's OSPF domain, the PE router 267 presents itself as an ASBR, and distributes the route in a type 5 268 LSA. The DN bit [OSPF-DNbit] MUST be set in these LSAs, to ensure 269 that they will be ignored by any other PE routers that receive them. 271 There are deployed implementations which do not set the DN bit, but 272 instead use OSPF route tagging to ensure that a type 5 LSA generated 273 by a PE router will be ignored by any other PE router that may 274 receive it. A special OSPF route tag, which we will call the VPN 275 Route Tag (see section 4.2.1), is used for this purpose. To ensure 276 backwards compatibility, all implementations adhering to this 277 specification MUST by default support the VPN Route Tag procedures 278 specified in sections 4.2.1 and 4.2.2. Support for the VPN Route Tag 279 procedures MAY be disabled, when it is no longer necessary. 281 4.2. Details 283 4.2.1. General 285 If a PE and a CE are communicating via OSPF, the PE MUST create, and 286 MUST flood to the CE, a type 1 LSA advertising its link to the CE. 287 The PE MUST have an OSPF router id which is valid (i.e., unique) 288 within the OSPF domain. The PE MUST also be configured to know which 289 OSPF area the link is in. 291 A PE-CE link may be in any area, including area 0; this is a matter 292 of the OSPF configuration. 294 Whether or not the PE-CE link is an area 0 link, the PE MUST function 295 as an OSPF area 0 router. That is, the link state topology from a 296 site will NOT be passed along by the PE. 298 The PE MUST support at least one OSPF instance for each OSPF domain 299 to which it attaches. Each instance of OSPF MUST be associated with 300 a single VRF. If n CEs associated with that VRF are running OSPF on 301 their respective PE/CE links, then those n CEs are OSPF adjacencies 302 of the PE in the corresponding instance of OSPF. Generally, though 303 not necessarily, if the PE attaches to several CEs in the same OSPF 304 domain, it will associate the interfaces to those PEs with a single 305 VRF. 307 If the OSPF domain has any area 0 routers (other than the PE 308 routers), then at least one of those MUST be a CE router, and MUST 309 have an area 0 link to at least one PE router. This adjacency MAY be 310 via an OSPF virtual link. 312 Each OSPF domain MUST be associated with a Domain Identifier. This 313 MUST be configurable, and the default value (if none is configured) 314 SHOULD be NULL. More precisely, each VRF associated with an OSPF 315 instance will either be configured with one or more Domain 316 Identifiers, or else will use NULL as its Domain Identifier. 318 A VRF MAY be configured with several Domain Identifier values. In 319 this case, one of these is considered to be the "primary" Domain 320 Identifier; this MUST be determinable by configuration. If a VRF has 321 exactly one Domain Identifier configured, this is of course its 322 primary Domain Identifier. If a VRF is configured with more than one 323 Domain Identifiers, the NULL Domain Identifier MUST NOT be one of 324 them. 326 With respect to the set of VRFs in a given OSPF domain, one of the 327 following two conditions MUST hold: 329 1. They all have the NULL Domain Identifier, OR 331 2. Each VRF is configured with a set of Domain Identifiers, and in 332 this set is the primary Domain Identifier of every other VRF in 333 the domain. 335 A Domain Identifier is an eight-byte quantity which is a valid BGP 336 Extended Communities attribute, as specified in section 4.2.2. If a 337 particular VRF has a single non-NULL Domain Identifier, when routes 338 from that VRF are distributed as by BGP as VPN-IPv4 routes, the 339 routes MUST carry the corresponding Domain Identifier Extended 340 Communities attribute. If the VRF has more than one Domain 341 Identifier, the routes MUST carry the the Domain Identifier Extended 342 Communities attribute corresponding to the VRF's primary Domain 343 Identifier. If the VRF's Domain Identifier is NULL, the Domain 344 Identifier Extended Communities attribute MAY be omitted when routes 345 from that VRF are distributed; alternatively, a value of the Domain 346 Identifier Extended Communities attribute which represents NULL (see 347 section 4.2.2) MAY be carried with the route. 349 If a particular OSPF domain has the NULL Domain Identifier, care must 350 be taken to avoid having routes from that OSPF domain and routes from 351 another OSPF domain imported into the same VRF. 353 If a particular VRF in a PE is associated with an instance of OSPF, 354 then by default it MUST be configured with a special OSPF route tag 355 value, which we call the VPN Route Tag. By default, this route tag 356 MUST be included in the Type 5 LSAs which the PE originates (as the 357 result of receiving a BGP-distributed VPN-IP route, see section 358 4.2.4) and sends to any of the attached CEs. 360 The configuration and inclusion of the VPN Route Tag is required for 361 backwards compatibility with deployed implementations that do not set 362 the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag MAY be 363 disabled, if it has been determined that it is no longer needed for 364 backwards compatibility. 366 The value of the VPN Route Tag is arbitrary, but must be distinct 367 from any OSPF Route Tag being used within the OSPF domain. Its value 368 MUST therefore be configurable. If the Autonomous System number is 369 two bytes long, the default value SHOULD be an automatically computed 370 tag based on the Autonomous System number of the VPN backbone: 372 Tag = 374 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 375 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 180 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |1|1|0|1| ArbitraryTag | AutonomousSystem | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_ 382 If the Autonomous System number is four bytes long, then a Route Tag 383 value MUST be configured, and it MUST be distinct from any Route Tag 384 used within the VPN itself. 386 If a PE router needs to use OSPF to distribute to a CE router a route 387 which comes from a site outside the CE router's OSPF domain, the PE 388 router SHOULD present itself to the CE router as an Autonomous System 389 Border Router (ASBR), and SHOULD report such routes as AS-external 390 routes. That is, these PE routers originate Type 5 LSAs reporting 391 the extra-domain routes as AS-external routes. Each such Type 5 LSA 392 MUST contain an OSPF route tag whose value is that of the VPN Route 393 Tag. This tag identifies the route as having come from a PE router. 394 The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated 395 by a PE router is not redistributed through the OSPF area to another 396 PE router. 398 4.2.2. Handling LSAs from the CE 400 This section specifies the way in which a PE router handles the OSPF 401 LSAs it receives from a CE router. 403 When a PE router receives, from a CE router, any LSA with the DN bit 404 [OSPF-DN] set, the information from that LSA MUST NOT be used by the 405 SPF computation. If a Type 5 LSA is received from the CE, and if it 406 has an OSPF route tag value equal to the VPN Route Tag (see section 407 4.2.1), then the information from that LSA MUST NOT be used by the 408 SPF computation. 410 Otherwise, the PE must examine the corresponding VRF. For every 411 address prefix which appears there, the PE must create a VPN-IPv4 412 route in BGP. Each such route will have some of the following 413 Extended Community attributes: 415 - The OSPF Domain Identifier Extended Communities attribute. This 416 MUST be present, UNLESS the VRF has a NULL Domain Identifier, in 417 which case it MAY be omitted. This attribute is encoded with a 418 two-byte type field, and its type is either 0005, 0105, or 0205. 419 For backwards compatibility, the type 8005 MAY be used as well, 420 and is treated as if it were 0005. If the VRF has a NULL Domain 421 Identifier, and the OSPF Domain Identifier Extended Communities 422 attribute is NOT omitted, then the attribute's value field must 423 be all zeroes, and its type field may be any of 0005, 0105, 0205, 424 or 8005. 426 - OSPF Route Type Extended Communities Attribute. This attribute 427 MUST be present. It is encoded with a two-byte type field, and 428 its type is 0306. The type 8000 SHOULD be accepted as well, to 429 ensure backwards compatibility. The remaining six bytes of the 430 Attribute are encodes as follows: 432 * Area Number: 4 bytes, encoding a 32-bit area number. For AS- 433 external routes, the value is 0. A non-zero value identifies 434 the route as being internal to the OSPF domain, and as being 435 within the identified area. Area numbers are relative to a 436 particular OSPF domain. 438 * OSPF Route Type: 1 byte, encoded as follows: 440 ** 1 or 2 for intra-area routes (depending on whether the 441 route came from a type 1 or a type 2 LSA -- however this 442 difference is not significant to the procedures 443 specified herein) 445 ** 3 for summary routes 447 ** 5 for external routes (area number must be 0) 449 ** 7 for NSSA routes. 451 ** 129 for Sham Link Endpoint Addresses. See section 452 4.2.3.2 for the specification of when this value must be 453 used. 455 * Options: 1 byte. Currently this is only used if the route 456 type is 5 or 7. Setting the least significant bit in the 457 field indicates that the route carries a type 2 metric. 459 - OSPF Router Id Extended Communities Attribute. This OPTIONAL 460 attribute specifies the OSPF Router Id of the system that is 461 identified in the BGP Next Hop attribute. More precisely, it 462 specifies the Router Id of the particular VRF from which this 463 route was exported. This attribute is encoded with a two-byte 464 type field, and its type is 0107, with the router id itself 465 carried in the first 4 bytes of the value field. The type 8001 466 SHOULD be accepted as well, to ensure backwards compatibility, 467 and should be treated as if it were 0107. 469 - MED. By default, this SHOULD be set to the value of the OSPF 470 distance associated with the route, plus 1. 472 The intention of all this is the following. OSPF Routes from one site 473 are converted to BGP, distributed across the VPN backbone, and 474 possibly converted back to OSPF routes before being distributed into 475 another site. With these attributes, BGP carries enough information 476 about the route to enable the route to be converted back into OSPF 477 "transparently", just as if BGP had not been involved. 479 Routes which a PE receives in type 4 LSAs MUST be ignored. 481 The attributes specified above are in addition to any other 482 attributes which routes must carry in accord with the [VPN]. 484 The Site of Origin attribute, which is usually required by [VPN], is 485 OPTIONAL for routes which a PE learns from a CE via OSPF. 487 Use of the Site of Origin attribute would, in the case of a multiply 488 homed site (i.e., a site attached to several PE routers), prevent an 489 intra-site route from being reinjected into a site from the VPN 490 backbone. Such a reinjection would not harm the routing, because the 491 route via the VPN backbone would be advertised in a type 3 LSA, and 492 hence would appear to be an inter-area route; the real intra-area 493 route would be preferred. But unnecessary overhead would be 494 introduced. On the other hand, if the Site of Origin attribute is not 495 used, a partitioned site will find itself automatically repaired, 496 since traffic from one partition to the other will automatically 497 travel via the VPN backbone. Therefore the use of a Site of Origin 498 attribute is optional, so that a trade-off can be made between the 499 cost of the increased overhead and the value of automatic partition 500 repair. 502 4.2.3. Sham Links 504 4.2.3.1. Intra-Area Routes 506 Suppose there are two sites in the same OSPF area. Each site is 507 attached to a different PE router, and there is also an intra-area 508 OSPF link connecting the two sites. 510 It is possible to treat these two sites as a single VPN site which 511 just happens to be multihomed to the backbone. This is in fact the 512 simplest thing to do, and is perfectly adequate, providing that the 513 preferred route between the two sites is via the intra-area OSPF link 514 (a "backdoor link"), rather than via the VPN backbone. There will be 515 routes between sites that go through the PE routers, but these routes 516 will appear to be inter-area routes, and OSPF will consider them to 517 be less preferable than the intra-area routes through the backdoor 518 link. 520 If it is desired to have OSPF prefer the routes through the backbone 521 over the routes through the backdoor link, then the routes through 522 the backbone must be appear to be intra-area routes. To make a route 523 through the backbone appear to be an intra-area route, it is 524 necessary to make it appear as if there is an intra-area link 525 connecting the two PE routers. This is what we refer to as a "sham 526 link". (If the two sites attach to the same PE router, this of 527 course is not necessary.) 529 A sham link can be thought of as a relation between two VRFs. If two 530 VRFs are to be connected by a sham link, each VRF must be associated 531 with a "Sham Link Endpoint Address", a /32 address which is treated 532 as an address of the PE router containing that VRF. The Sham Link 533 Endpoint Address associated with a VRF MUST be configurable, and it 534 MAY default to the VRF's router id. The Sham Link Endpoint Address 535 is an address in the VPN's address space, not the SP's address space. 537 A VRF needs only a single Sham Link Endpoint Address, no matter how 538 many sham links it has. It MUST be distributed by BGP as a VPN-IPv4 539 address, and it MAY be distributed by OSPF. 541 4.2.3.2. Creating Sham Links 543 Sham links may be manually configured, or they may be auto- 544 configured. 546 Each VRF that is associated with a PE-CE link on which OSPF is 547 running MUST be configurable as to whether auto-configuration of sham 548 links to/from that VRF is allowed. The default MUST be "manual 549 configuration". 551 If a VRF is configured for manual configuration of the sham links, it 552 will never initiate auto-configuration of a sham link, nor will it 553 ever create a sham link as the result of a remotely initiated auto- 554 configuration procedure. If a VRF is configured for auto- 555 configuration of sham links, manual configuration of particular sham 556 links is still allowed. In any event, no more than one sham link 557 with the same pair of sham link endpoint addresses will ever be 558 created. 560 To manually configure a sham link between two VRFs, each VRF has to 561 be configured to create a sham link to the other, where the "other" 562 is identified by its sham link endpoint address. Procedures for 563 single-ended manual configuration of the sham link are for further 564 study. 566 IF a VRF is configured for auto-configuration of sham links, it MUST 567 distribute, via BGP, a VPN-IP route corresponding to the Sham Link 568 Endpoint Address. This route MUST have the OSPF Route Type Extended 569 Community attribute, with the OSPF Route Type field set to "Sham Link 570 Endpoint Address". 572 When a PE receives such a route, with a RT value that allows the 573 route to be imported into a particular VRF, then if 575 - that route has an OSPF Domain Identifier Extended Communities 576 attribute which is identical to one of the VRF's Domain 577 Identifiers, or the route has no OSPF Domain Identifier Extended 578 Communities attribute and the VRF has a NULL Domain Identifier, 579 AND 581 - that route has an OSPF area number which matches that of the VRF, 583 then a sham link may be created from the local VRF to the VRF 584 identified by the sham link endpoint address. 586 When comparing two OSPF Domain Identifier Extended Communities 587 attributes for equality, all eight bytes of the Extended Communities 588 attribute must be compared. The two attributes are regarded as equal 589 only if they are identical in all eight bytes, or if the lower order 590 six bytes are identical, and one attribute has two high order bytes 591 of 0005 and the other has two high order bytes of 8005. 593 If all VRFs are configured for auto-configuration of sham links, a 594 full mesh of sham links will be created among all the sites which are 595 in the same OSPF area. This may not be what is desired. To obtain 596 more control over the set of sham links which are created, some or 597 all of the VRFs can be configured to disable auto-configuration of 598 the sham links. 600 Note that sham links may be created for any area, including area 0. 602 4.2.3.3. Treatment of Sham Links 604 Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This 605 means that LSAs will be flooded over them, but periodic refresh 606 traffic is avoided. Note that, as long as the backdoor link is up, 607 flooding the LSAs over the sham link serves no purpose. However, if 608 the backdoor link goes down, OSPF does not have mechanisms enabling 609 the routers in one site to rapidly flush the LSAs from the other 610 site. Therefore it is still necessary to maintain synchronization 611 among the LSA databases at the two sites, hence the flooding over the 612 sham link. 614 The sham link is an unnumbered point-to-point intra-area link, and is 615 advertised by means of a type 1 LSA. 617 The OSPF metric associated with a sham link must be configurable (and 618 there must be a configurable default). Whether traffic between the 619 sites flows via a backdoor link or via the VPN backbone (i.e., via 620 the sham link) depends on the settings of the OSPF link metrics. The 621 metrics can be set so that the backdoor link is not used unless 622 connectivity via the VPN backbone fails, for example. 624 The default Hello Interval for sham links is 10 seconds, and the 625 default Router Dead Interval for sham links is 40 seconds. 627 If a PE determines that a particular route traverses the sham link, 628 then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 629 route. 631 4.2.4. VPN-IP routes received via BGP 633 This section describes how the PE router handles VPN-IP routes 634 received via BGP. 636 If a received BGP VPN-IP route is not installed in the VRF, nothing 637 is reported to the CE. A received route will not be installed into 638 the VRF if some other route is preferable. (Note that a route which 639 is not installed in the VRF may still cause the PE to create an OSPF 640 link to another PE as specified in the previous section.) 641 Note that according to the usual OSPF route preference rules, intra- 642 area routes, as computed by the OSPF, will be installed in the VRF in 643 preference to any other routes received over BGP. This means that the 644 CE will simply not hear about inter-area or external routes to 645 address prefixes for which there is an intra-area route. 647 In the following, we specify what is reported, in OSPF LSAs, by the 648 PE to the CE, assuming that the PE is not configured to do any 649 further summarization or filtering of the routing information before 650 reporting it to the CE. 652 4.2.4.1. Routes from Different Domains 654 To determine how to process an a received VPN-IP route, it is 655 necessary to compare the OSPF Domain Identifier Extended Communities 656 attribute carried by the route (if any) with the OSPF Domain 657 Identifier Extended Communities attribute(s) with which the VRF has 658 been configured (if any). In general, when two such attributes are 659 compared, all eight bytes must be compared. Thus two OSPF Domain 660 Identifier Extended Communities attributes are regarded as equal if 661 and only if one of the following three conditions holds: 663 1. They are identical in all eight bytes. 665 2. They are identical in their lower order six bytes (value 666 field), but one attribute has two high order bytes (type field) 667 of 0005 and the other has two high order bytes (type field) of 668 8005. (This condition is for backwards compatibility.) 670 3. The lower order six bytes (value field) of both attributes 671 consist entirely of zeroes. In this case, the two attributes 672 are considered to be identical irrespective of their type 673 fields, and they are regarded as representing the NULL Domain 674 Identifier. 676 If one of the following three conditions holds, a VPN-IP route 677 received via BGP is regarded as being from a different domain than 678 the VRF into which the route is being installed. 680 1. The VRF has a non-NULL OSPF Domain Identifier, but either 682 a) the route has no OSPF Domain Identifier Extended 683 Communities attribute, or 685 b) the route has an OSPF Domain Identifier Extended 686 Communities attribute whose value field consists of all 687 zeroes 689 2. the route has an OSPF Domain Identifier Extended Communities 690 attribute whose value field does not consist of all zeroes, and 691 the VRF is configured with the NULL Domain Identifier (or with 692 any encoding of the NULL Domain Identifier as specified above) 694 3. the router has an OSPF Domain Identifier Extended Communities 695 attribute which is not identical to any of the OSPF Domain 696 Identifiers associated with the VRF. 698 If any of these three conditions holds, the route is distributed to 699 the CE in a type 5 LSA. The VPN Route Tag (see section 4.2.1) MUST 700 be placed in the LSA. By default, a type 2 metric value is included 701 in the LSA, and by default, its value is taken from the MED attribute 702 of the VPN-IP route. If the MED is not present, a default metric 703 value is used. 705 4.2.4.2. Other External Routes 707 If the route has an OSPF route type of external route, it MUST be 708 advertised to the CE in a type 5 LSA. The VPN Route Tag (see section 709 4.2.1) MUST be placed in the LSA. By default, the MED, if present, 710 is converted to a type 1 or type 2 metric, as determined by the 711 external route property of the VPN-IPv4 route. If no MED is present, 712 a default type 2 metric value is used. 714 Note that this way of handling AS-external routes makes every PE 715 appear to be an ASBR attached to all the AS-external routes. In a 716 multihomed site, this can result in a number of type 5 LSAs 717 containing the same information. 719 4.2.4.3. Summary Routes 721 If the conditions of the previous two sections do not hold, then the 722 route should be treated as if it had been received in an OSPF type 3 723 LSA. This means that the PE will report the route in a type 3 LSA to 724 the CE. (Note that this case is possible even if the VPN-IP route 725 carries an area number identical to that of the CE router. This 726 means that if an area is "partitioned" such that the two pieces are 727 connected only via the VPN backbone, it appears to be two areas, with 728 inter-area routes between them.) 730 5. Acknowledgments 732 Significant contributions to this work have been made by Derek Yeung 733 and Yakov Rekhter. 735 Thanks to Ross Callon and Ajay Singhal for their comments. 737 6. Authors' Addresses 739 Eric C. Rosen 740 Cisco Systems, Inc. 741 1414 Massachusetts Avenue 742 Boxborough, MA 01719 744 E-mail: erosen@cisco.com 746 Peter Psenak 747 Parc Pegasus, 748 De Kleetlaan 6A 749 1831 Diegem 750 Belgium 752 E-mail: ppsenak@cisco.com 754 Padma Pillay-Esnault 755 Juniper Networks 756 1194 N. Mathilda Avenue 757 Sunnyvale, CA 94089 759 E-mail: padma@juniper.net 761 7. Normative References 763 [EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- 764 communities-06.txt, Sangli, S., Tappan, D., Rekhter, Y., August 2003 766 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 768 [OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP 769 VPNs", draft-ietf-ospf-2547-dnbit-03.txt, Rosen, Psenak, Pillay- 770 Esnault, January 2004 772 [VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, 773 Rekhter, et. al. September 2003 775 8. Intellectual Property Notice 777 The IETF takes no position regarding the validity or scope of any 778 intellectual property or other rights that might be claimed to 779 pertain to the implementation or use of the technology described in 780 this document or the extent to which any license under such rights 781 might or might not be available; neither does it represent that it 782 has made any effort to identify any such rights. Information on the 783 IETF's procedures with respect to rights in standards-track and 784 standards-related documentation can be found in BCP-11. Copies of 785 claims of rights made available for publication and any assurances of 786 licenses to be made available, or the result of an attempt made to 787 obtain a general license or permission for the use of such 788 proprietary rights by implementors or users of this specification can 789 be obtained from the IETF Secretariat. 791 The IETF invites any interested party to bring to its attention any 792 copyrights, patents or patent applications, or other proprietary 793 rights which may cover technology that may be required to practice 794 this standard. Please address the information to the IETF Executive 795 Director. 797 9. Copyright Notice 799 "Copyright (C) The Internet Society (2004). All Rights Reserved. 801 This document and translations of it may be copied and furnished to 802 others, and derivative works that comment on or otherwise explain it 803 or assist in its implementation may be prepared, copied, published 804 and distributed, in whole or in part, without restriction of any 805 kind, provided that the above copyright notice and this paragraph are 806 included on all such copies and derivative works. However, this 807 document itself may not be modified in any way, such as by removing 808 the copyright notice or references to the Internet Society or other 809 Internet organizations, except as needed for the purpose of 810 developing Internet standards in which case the procedures for 811 copyrights defined in the Internet Standards process must be 812 followed, or as required to translate it into languages other than 813 English. 815 The limited permissions granted above are perpetual and will not be 816 revoked by the Internet Society or its successors or assigns. 818 This document and the information contained herein is provided on an 819 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 820 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 821 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 822 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 823 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."