idnits 2.17.1 draft-ietf-l3vpn-bgpvpn-auto-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 766. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 749. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 755. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 15) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([VPN-VR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 6982 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: 'RFC-3031' is mentioned on line 368, but not defined == Unused Reference: 'BGP-MP' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC-3107' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'TLS-TISSA' is defined on line 618, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-COMM' ** Obsolete normative reference: RFC 2283 (ref. 'BGP-MP') (Obsoleted by RFC 2858) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 3392 (Obsoleted by RFC 5492) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-VR' -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- No information found for draft-tsenevir-bgpl2vpn - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-rt-constrain-01 Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN WG Hamid Ould-Brahim 3 Internet Draft Nortel Networks 4 Expiration Date: August 2005 5 Eric C. Rosen 6 Cisco Systems 8 Yakov Rekhter 9 Juniper Networks 11 (Editors) 13 February 2005 15 Using BGP as an Auto-Discovery 16 Mechanism for Layer-3 and Layer-2 VPNs 18 draft-ietf-l3vpn-bgpvpn-auto-05.txt 20 Status of this Memo 22 This document is an Internet-Draft and is subject to all provisions 23 of section 3 of RFC 3667. By submitting this Internet-Draft, each 24 author represents that any applicable patent or other IPR claims of 25 which he or she is aware have been or will be disclosed, and any of 26 which he or she become aware will be disclosed, in accordance with 27 RFC 3668. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 In any Layer-3 and Layer-2 VPN scheme, the Provider Edge (PE) 47 devices attached to a common VPN must exchange certain information 48 as a prerequisite to establish VPN-specific connectivity. The 49 purpose of this draft is to define a BGP based auto-discovery 50 mechanism for layer-2 VPN architectures and Virtual router-based 51 layer-3 VPNs [VPN-VR]. This mechanism is based on the approach used 52 by BGP/MPLS-IP-VPN [BGP/MPLS-IP-VPN] for distributing VPN routing 53 information within the service provider(s). In the context of 54 L2VPNs, an auto-discovery mechanism enables a PE to determine the 55 set of other PEs having VPN members in common along with information 56 relative to each specific L2VPN endpoints such as attachment circuit 57 identifier, topology information, etc. Each VPN scheme uses the 58 mechanism to automatically discover the information needed by that 59 particular scheme. 61 1. Introduction 63 In any Layer-2 and Layer-3 VPN scheme, the Provider Edge (PE) 64 devices attached to a common VPN must exchange certain information 65 as a prerequisite to establish VPN-specific connectivity. The 66 purpose of this draft is to define a BGP based auto-discovery 67 mechanism for layer-2 VPNs (i.e., [VPLS-BGP], [L2VPN-ROSEN], [VPLS- 68 LDP]) and layer-3 VPNs based on Virtual Router(VR [VPN-VR]) 69 solution. This mechanism is based on the approach used by BGP/MPLS- 70 IP-VPN for distributing VPN routing information within the service 71 provider(s). Each VPN scheme uses the mechanism to automatically 72 discover the information needed by that particular scheme. 74 In BGP/MPLS-IP-VPN, VPN-specific routes are exchanged, along with 75 the information needed to enable a PE to determine which routes 76 belong to which VRFs. 78 In VR model, virtual router (VR) addresses must be exchanged, along 79 with the information needed to enable the PEs to determine which VRs 80 are in the same VPN ("membership"), and which of those VRs are to 81 have VPN connectivity ("topology"). Once the VRs are reachable 82 through the tunnels, routes ("reachability") are then exchanged by 83 running existing routing protocols per VPN basis. 85 In the context of L2VPNs, an auto-discovery mechanism enables a PE 86 to determine the set of other PEs having VPN members in common along 87 with information relative to each specific L2VPN endpoints such as 88 attachment circuit identifier, topology information, etc. 90 The BGP-4 multiprotocol extensions are used to carry various 91 information about VPNs for both layer-2 and layer-3 VPN 92 architectures. VPN-specific information associated with the NLRI is 93 encoded either as attributes of the NLRI, or as part of the NLRI 94 itself, or both. 96 2. Provider-Provisioned VPN Reference Model 98 Both the layer-2 and layer-3 vpn architectures ([VPLS-BGP],[VPLS- 99 LDP], [L2VPN-ROSEN], [VPN-VR], [BGP/MPLS-IP-BPN]) are using a 100 network reference model as illustrated in figure 1. 102 PE PE 103 +--------------+ +--------------+ 104 +--------+ | +----------+ | | +----------+ | +--------+ 105 | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | 106 | Sites |--| |Database /| | BGP route | | Database/| |-| sites | 107 +--------+ | |Processing| |<----------->| |Processing| | +--------+ 108 | +----------+ | Distribution| +----------+ | 109 | | | | 110 +--------+ | +----------+ | | +----------+ | +--------+ 111 | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | 112 | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | 113 +--------+ | |Processing| | -------- | |Processing| | +--------+ 114 | +----------+ | | +----------+ | 115 | | | | 116 +--------+ | +----------+ | | +----------+ | +--------+ 117 | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | 118 | Sites |--| |Database /| | | | Database/| |-| sites | 119 +--------+ | |Processing| | | |Processing| | +--------+ 120 | +----------+ | | +----------+ | 121 +--------------+ +--------------+ 123 Figure 1: Network based VPN Reference Model 125 It is assumed that the PEs can use BGP to distribute information to 126 each other. This may be via direct IBGP peering, via direct EBGP 127 peering, via multihop BGP peering, through intermediaries such as 128 Route Reflectors, through a chain of intermediate BGP connections, 129 etc. It is assumed also that the PE knows what architecture it is 130 supporting. 132 3. Carrying VPN information in BGP Multi-Protocol (BGP-MP) Attributes 134 The BGP-4 multiprotocol extensions are used to carry various 135 information about VPNs for both layer-2 and layer-3 VPN 136 architectures. VPN-specific information associated with the NLRI is 137 encoded either as attributes of the NLRI, or as part of the NLRI 138 itself, or both. The addressing information in the NLRI field is 139 ALWAYS within the VPN address space, and therefore MUST be unique 140 within the VPN. The address specified in the BGP next hop attribute, 141 on the other hand, is in the service provider addressing space. 143 3.1 Carrying Layer-3 VPN Information in BGP-MP 145 This is done as follows. The NLRI is a VPN-IP address or a labeled 146 VPN-IP address. 148 In the case of the virtual router, the NLRI address prefix is an 149 address of one of the virtual routers configured on the PE. Thus 150 this mechanism allows the virtual routers to discover each other, to 151 set up adjacencies and tunnels to each other, etc. In the case of 152 BGP/MPLS-IP-VPN, the NLRI prefix represents a route to an arbitrary 153 system or set of systems within the VPN. 155 3.2 Carrying Layer-2 VPN Information in BGP-MP 157 The NLRI carries VPN layer-2 addressing information called VPN-L2 158 address. A VPN-L2 address is composed of a quantity beginning with 159 an 8 bytes Route Distinguisher (RD) field and a variable length 160 quantity (see section 5 for specific encodings of this quantity). 162 Different layer-2 VPN solutions use the same common AFI, but 163 different SAFI. The AFI indicates that the NLRI is carrying a VPN-l2 164 address, while the SAFI indicates solution-specific semantics and 165 syntax of the VPN-l2 address that goes after the RD. The RD must be 166 chosen so as it ensures that each NLRI is globally unique (i.e., the 167 same NLRI does not appear in two VPNs). 169 BGP Route target extended community is used to constrain route 170 distribution between PEs. The BGP Next hop carries the service 171 provider tunnel endpoint address. 173 This draft doesn't preclude the use of additional extended 174 communities for encoding specific l2vpn parameters. 176 4. Interpretation of VPN Information in Layer-3 VPNs 178 4.1 Interpretation of VPN Information in the BGP/MPLS-IP-VPN Model 180 For details see [BGP/MPLS-IP-VPN]. 182 4.2 Interpretation of VPN Information in the VR Model 184 4.2.1 Membership Discovery 186 The VPN-ID format as defined in [RFC-2685] is used to identify a 187 VPN. All virtual routers that are members of a specific VPN share 188 the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses 189 of VRs globally unique. Making these addresses globally unique is 190 necessary if one uses BGP for VRs' auto-discovery. 192 4.2.1.1 Encoding of the VPN-ID in the NLRI 194 For the virtual router model, the VPN-ID is carried within the route 195 distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the 196 first byte of RD type field is used to indicate the existence of the 197 VPN-ID format. A value of 0x80 in the first byte of RD's type field 198 indicates that the RD field is carrying the VPN-ID format. In this 199 case, the type field range 0x8000-0x80ff will be reserved for the 200 virtual router case. 202 4.2.1.2 VPN-ID Extended Community 204 A new extended community is used to carry the VPN-ID format. This 205 attribute is transitive across the Autonomous system boundary. The 206 type field of the VPN-ID extended community is of regular type to be 207 assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID 208 value field as per [RFC-2685]. The BGP UPDATE message will carry 209 information for a single VPN. It is the VPN-ID Extended Community, 210 or more precisely route filtering based on the Extended Community 211 that allows one VR to find out about other VRs in the same VPN. 213 4.2.2 VPN Topology Information 215 A new extended community is used to indicate different VPN topology 216 values. This attribute is transitive across the Autonomous system 217 boundary. The value of the type field for extended type is assigned 218 by IANA. The first two bytes of the value field (of the remaining 6 219 bytes) are reserved. The actual topology values are carried within 220 the remaining four bytes. The following topology values are defined: 222 Value Topology Type 224 1 "Hub" 225 2 "Spoke" 226 3 "Mesh" 228 Arbitrary values can also be used to allow specific topologies to be 229 constructed. 231 In a hub and spoke topology, spoke VRs (i.e., PE having VRs as 232 spokes within the VPN) will advertise their BGP information with 233 VPN topology extended community with value of "2". Spoke VRs will 234 only be allowed to connect to hub VRs. Hence spoke VR-based PEs will 235 not import VPN information with VPN topology information set to "2". 236 Hub sites can connect to both hub and spoke sites (i.e., Hub VRs can 237 import VPN topology of both values "1", "2", or "3". In a mesh 238 topology, mesh sites connect to each other, each VR will advertise 239 VPN topology information of "3". 241 Furthermore, in the presence of both hub and spoke and mesh 242 topologies within the same VPN, mesh sites can as well connect to 243 hub sites and vice versa. 245 5. Interpretation of VPN Information in Layer-2 VPNs 246 The interpretation of the VPN information for L2VPN solutions is 247 described in the following sections. 249 5.1 Single-sided Provisioning with Discovery Point-to-Point L2VPNs 251 As described in [L2VPN-ROSEN], the single-sided provisioning model 252 with discovery model for point-to-point L2VPNs requires that each 253 Attachment Circuit of a point-to-point L2VPN must be provisioned 254 with a local name. The local name consists of a Attachment Group 255 Identifier (AGI) (which can represent a VPN-ID) and an Attachment 256 Individual Identifier which is unique relative to the AGI. If two 257 Attachment circuits are to be connected by a PW, only one of them 258 needs to be provisioned with a remote name (which of course is the 259 local name of the other Attachment Circuit). Neither needs to be 260 provisioned with the address of the remote PE, but both must have 261 the same VPN-id. 263 As part of an auto-discovery procedure, each PE advertises its pairs. Each PE compares its local pairs with the pairs advertised by the 266 other PEs. If PE1 has a local pair with value 267 , and PE2 has a local pair with value 268 , PE1 will thus be able to discover that it needs to connect 269 to PE2. When signaling, it will use "fred" as the TAII, and will 270 use V as he AGI. PE1's local name for the Attachment Circuit is 271 sent as the SAII. 273 5.2 Colored Pools 275 In the "Colored Pools" model of operation, each PE may contain 276 several pools of Attachment Circuits, each pool associated with a 277 particular VPN. A PE may contain multiple pools per VPN, as each 278 pool may correspond to a particular CE device. It may be desired to 279 create one pseudowire between each pair of pools that are in the 280 same VPN; the result would be to create a full mesh of CE-CE VCs for 281 each VPN. 283 In order to use BGP-based auto-discovery, the color associated with 284 a colored pool must be encodable as both an RT (Route Target) and an 285 RD (Route Distinguisher). The globally unique identifier of a pool 286 must be encodable as NLRI; the color would be encoded as the RD and 287 the pool identifier as a four-byte quantity which is appended to the 288 RD to create the NLRI. 290 Auto-discovery procedures by having each PE distribute, via BGP, the 291 NLRI for each of its pools, with itself as the BGP next hop, and 292 with the RT that encodes the pool's color. If a given PE has a pool 293 with a particular color (RT), it must receive, via BGP, all NLRI 294 with that same color (RT). Typically, each PE would be a client of 295 a small set of BGP route reflectors, which would redistribute this 296 information to the other clients. 298 If a PE has a pool with a particular color, it can then receive all 299 the NLRI which have that same color, and from the BGP next hop 300 attribute of these NLRI will learn the IP addresses of the other PE 301 routers which have pools switches with the same color. It also 302 learns the unique identifier of each such remote pool, as this is 303 encoded in the NLRI. The remote pool's relative identifier can be 304 extracted from the NLRI and used in the signaling, as specified 305 below. 307 5.3 VPLS 309 In order to use BGP-based auto-discovery for VPLS-based VPNs where 310 discovery and signaling are separate components such as [VPLS-LDP] 311 solutions, the globally unique identifier associated with a VPLS 312 must be encodable as an 8-byte Route Distinguisher (RD). If the 313 globally unique identifier for a VPLS is an RFC2685 VPN-id, it can 314 be encoded as an RD as specified in section 4.2.1.1. However, any 315 other method of assigning a unique identifier to a VPLS and encoding 316 it as an RD (using the encoding techniques of [BGP/MPLS-IP-VPN]) 317 will do. 319 Each VSI needs to have a unique identifier, which can be encoded as 320 a BGP NLRI. This is formed by prepending the RD (from the previous 321 paragraph) to an IP address of the PE containing the virtual LAN 322 switch (VSI). Note that it is not strictly necessary for all the 323 VSIs in the same VPLS to have the same RD, all that is really 324 necessary is that the NLRI uniquely identify a virtual LAN switch. 326 Each VSI needs to be associated with one or more Route Target (RT) 327 Extended Communities. These control the distribution of the NLRI, 328 and hence will control the formation of the overlay topology of 329 pseudowires that constitutes a particular VPLS. 331 Auto-discovery proceeds by having each PE distribute, via BGP, the 332 NLRI for each of its VSIs, with itself as the BGP next hop, and with 333 the appropriate RT for each such NLRI. Typically, each PE would be 334 a client of a small set of BGP route reflectors, which would 335 redistribute this information to the other clients. 337 If a PE has a VSI with a particular RT, it can then receive all the 338 NLRI which have that same RT, and from the BGP next hop attribute of 339 these NLRI will learn the IP addresses of the other PE routers which 340 have VSIs with the same RT. 342 If a particular VPLS is meant to be a single fully connected LAN, 343 all its VSIs will have the same RT, in which case the RT could be 344 (though it need not be) an encoding of the VPN-id. If a particular 345 VPLS consists of multiple VLANs, each VLAN must have its own unique 346 RT. A VSI can be placed in multiple VLANS (or even in multiple 347 VPLSes) by assigning it multiple RTs. 349 Note that hierarchical VPLS can be set up by assigning multiple RTs 350 to some of the virtual LAN switches; the RT mechanism allows one to 351 have complete control over the pseudowire overlay which constitutes 352 the VPLS topology. 354 5.3.1 VPLS using BGP as a signaling Mechanism 356 The interpretation of VPN information for VPLS services using BGP as 357 the signaling component is described in [VPLS-BGP]. Note that this 358 solution complies with procedures described in section 3.2. 360 6. Tunnel Discovery 362 Layer-3 VPNs and Layer-2 VPNs must be implemented through some form 363 of tunneling mechanism, where the packet formats and/or the 364 addressing used within the VPN can be unrelated to that used to 365 route the tunneled packets across the backbone. There are numerous 366 tunneling mechanisms that can be used by a network based VPN (e.g., 367 IP/IP [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS 368 tunnels [RFC-3031]). Each of these tunnels allows for opaque 369 transport of frames as packet payload across the backbone, with 370 forwarding disjoint from the address fields of the encapsulated 371 packets. A provider edge router may terminate multiple types of 372 tunnels and forward packets between these tunnels and other network 373 interfaces in different ways. 375 BGP can be used to carry tunnel endpoint addresses between edge 376 routers. For scalability purposes, this draft recommends the use of 377 tunneling mechanisms with demultiplexing capabilities such as IPSec, 378 MPLS, and GRE (with respect to using GRE -the key field, it is no 379 different than just MPLS over GRE, however there is no specification 380 on how to exchange the key field, while there is a specification and 381 implementations on how to exchange the label). Note that IP in IP 382 doesn't have demultiplexing capabilities. 384 The BGP next hop will carry the service provider tunnel endpoint 385 address. As an example, if IPSec is used as tunneling mechanism, the 386 IPSec tunnel remote address will be discovered through BGP, and the 387 actual tunnel establishment is achieved through IPSec signaling 388 protocol. 390 When MPLS tunneling is used, the label carried in the NLRI field is 391 associated with an address of a VR, where the address is carried in 392 the NLRI and is encoded as a VPN-IP address. 394 The auto-discovery mechanism should convey minimum information for 395 the tunnels to be setup. The means of distributing multiplexors must 396 be defined either via some sort of tunnel-protocol-specific signaling 397 mechanism, or via additional information carried by the 398 auto-discovery protocol. That information may or may not be 399 used directly within the specific signaling protocol. On one end of 400 the spectrum, the combination of IP address (such as BGP next hop and 401 IP address carried within the NLRI) and the label and/or VPN-ID 402 provides sufficient information for a PE to setup per VPN tunnels or 403 shared tunnels per set of VPNs. On another end of the spectrum 404 additional specific tunnel related information can be carried within 405 the discovery process if needed. 407 7. Scalability Considerations 409 In this section, we briefly summarize the main characteristics of 410 our model with respect to scalability. 412 Recall that the Service Provider network consists of (a) PE routers, 413 (b) BGP Route Reflectors, (c) P routers (which are neither PE 414 routers nor Route Reflectors), and, in the case of multi-provider 415 VPNs, (d) ASBRs. 417 A PE router, unless it is a Route Reflector should not retain 418 VPN-related information unless it has at least one VPN with an 419 Import Target identical to one of the VPN-related information Route 420 Target attributes. Inbound filtering should be used to cause such 421 information to be discarded. If a new Import Target is later added 422 to one of the PE's VPNs (a "VPN Join" operation), it must then 423 acquire the VPN-related information it may previously have 424 discarded. 426 This can be done using the refresh mechanism described in [BGP- 427 RFSH]. 429 The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] can 430 also be used to advantage to make the filtering more dynamic. 432 Similarly, if a particular Import Target is no longer present in 433 any of a PE's VPNs (as a result of one or more "VPN Prune" 434 operations), the PE may discard all VPN-related information which, 435 as a result, no longer have any of the PE's VPN's Import Targets as 436 one of their Route Target Attributes. 438 Note that VPN Join and Prune operations are non-disruptive, and do 439 not require any BGP connections to be brought down, as long as the 440 refresh mechanism of [BGP-RFSH] is used. 442 As a result of these distribution rules, no one PE ever needs to 443 maintain all routes for all VPNs; this is an important scalability 444 consideration. 446 Route reflectors can be partitioned among VPNs so that each 447 partition carries routes for only a subset of the VPNs supported by 448 the Service Provider. Thus no single route reflector is required to 449 maintain VPN-related information for all VPNs. 451 For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs 452 need not maintain and distribute VPN-related information at all. 454 P routers do not maintain any VPN-related information. In order 455 to properly forward VPN traffic, the P routers need only maintain 456 routes to the PE routers and the ASBRs. 458 As a result, no single component within the Service Provider network 459 has to maintain all the VPN-related information for all the VPNs. 460 So the total capacity of the network to support increasing numbers 461 of VPNs is not limited by the capacity of any individual component. 463 An important consideration to remember is that one may have any 464 number of INDEPENDENT BGP systems carrying VPN-related information. 465 This is unlike the case of the Internet, where the Internet BGP 466 system must carry all the Internet routes. Thus one significant 467 (but perhaps subtle) distinction between the use of BGP for the 468 Internet routing and the use of BGP for distributing VPN-related 469 information, as described in this document is that the former is not 470 amenable to partition, while the latter is. 472 8. Security Considerations 474 This document describes a BGP-based auto-discovery mechanism which 475 enables a PE router that attaches to a particular VPN to discover 476 the set of other PE routers that attach to the same VPN. Each PE 477 router that is attached to a given VPN uses BGP to advertise that 478 fact. Other PE routers which attach to the same VPN receive these 479 BGP advertisements. This allows that set of PE routers to discover 480 each other. Note that a PE will not always receive these 481 advertisements directly from the remote PEs; the advertisements may 482 be received from "intermediate" BGP speakers. 484 It is of critical importance that a particular PE should not be 485 "discovered" to be attached to a particular VPN unless that PE 486 really is attached to that VPN, and indeed is properly authorized to 487 be attached to that VPN. If any arbitrary node on the Internet 488 could start sending these BGP advertisements, and if those 489 advertisements were able to reach the PE routers, and if the PE 490 routers accepted those advertisements, then anyone could add any 491 site to any VPN. Thus the auto-discovery procedures described here 492 presuppose that a particular PE trusts its BGP peers to be who they 493 appear to be, and further that it can trusts those peers to be 494 properly securing their local attachments. (That is, a PE must 495 trust that its peers are attached to, and are authorized to be 496 attached to, the VPNs to which they claim to be attached.). 498 If a particular remote PE is a BGP peer of the local PE, then the 499 BGP authentication procedures of RFC 2385 can be used to ensure that 500 the remote PE is who it claims to be, i.e., that it is a PE that is 501 trusted. 503 If a particular remote PE is not a BGP peer of the local PE, then 504 the information it is advertising is being distributed to the local 505 PE through a chain of BGP speakers. The local PE must trust that 506 its peers only accept information from peers that they trust in 507 turn, and this trust relation must be transitive. BGP does not 508 provide a way to determine that any particular piece of received 509 information originated from a BGP speaker that was authorized to 510 advertise that particular piece of information. Hence the 511 procedures of this document should be used only in environments 512 where adequate trust relationships exist among the BGP speakers. 514 Some of the VPN schemes which may use the procedures of this 515 document can be made robust to failures of these trust 516 relationships. That is, it may be possible to keep the VPNs secure 517 even if the auto-discovery procedures are not secure. For example, 518 a VPN based on the VR model can use IPsec tunnels for transmitting 519 data and routing control packets between PE routers. An 520 illegitimate PE router which is discovered via BGP will not have the 521 shared secret which makes it possible to set up the IPsec tunnel, 522 and so will not be able to join the VPN. Similarly, [IPSEC-2547] 523 describes procedures for using IPsec tunnels to secure VPNs based on 524 the BGP/MPLS-IP-VPN model. The details for using IPsec to secure a 525 particular sort of VPN depend on that sort of VPN and so are out of 526 scope of the current document. 528 9. IANA Considerations 530 9.1 IANA Considerations for L2VPNs 532 New AFI value to be assigned by IANA to indicate that the NLRI is 533 carrying VPN-L2 Address as described in section 3.2. 535 New SAFI number is required for single-sided Point-to-point L2VPN 536 solutions. 538 New SAFI number for Colored pools L2VPNs 540 New SAFI number for VPLS-based L2VPNs solutions using LDP-based 541 signalling. 543 9.2 IANA Considerations for VR-based L3VPNs 545 SAFI number "129" for indicating that the NLRI is carrying 546 information for VR-based solution. 548 SAFI number "140" for indicating that the NLRI is carrying 549 information for VR for non-labeled prefixes. 551 New Extended Community to be assigned by IANA and used for Topology 552 values for VR-based L3VPN solution see section 4.2.2. 554 New Extended Community to be assigned by IANA for carrying VPN-ID 555 format based on RFC2685 format (see section 4.2.1.2) 557 10. Use of BGP Capability Advertisement 559 A BGP speaker that uses VPN information as described in this 560 document with multiprotocol extensions should use the Capability 561 Advertisement procedures [RFC-3392] to determine whether the speaker 562 could use Multiprotocol Extensions with a particular peer. 564 11. Acknowledgement 566 The authors would like to acknowledge Benson Schliesser, and Thomas 567 Narten for the constructive and fruitful comments. 569 12. Normative References 571 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities 572 Attribute", June 2001, work in progress 574 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 575 Extensions for BGP4", February 1998, RFC 2283 577 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in 578 BGP4", January 2000, RFC3107 580 [BGP/MPLS-IP-VPN] Rosen E., et al, "BGP/MPLS VPNs", Work in 581 Progress. 583 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 584 2685, September 1999. 586 [RFC-3392] Chandra, R., et al., "Capabilities Advertisement with 587 BGP-4", RFC3392, May 2002. 589 [VPN-VR] Knight, P., Ould-Brahim H., Gleeson, B., "Network based IP 590 VPN Architecture using Virtual Routers", Work in Progress. 592 13. Informative References 594 [L2VPN-ROSEN] Rosen, E., Radoaca, V., "Provisioning Models and 595 Endpoint Identifiers in L2VPN Signaling", Work in Progress. 597 [VPLS-BGP] Kompella, K., et al., "Virtual Private LAN Service", 598 Work in Progress. 600 [VPLS-LDP] Kompella, V., Lasserre, M., et al., "Virtual Private LAN 601 Services over MPLS", Work in Progress. 603 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 604 Routing Encapsulation (GRE)", RFC 1701, October 1994. 606 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC2003, 607 October 1996. 609 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 610 3", RFC2026, October 1996. 612 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 613 Internet Protocol", RFC2401, November 1998. 615 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", RFC 2119, March 1997. 618 [TLS-TISSA] "BGP/MPLS Layer-2 VPN", draft-tsenevir-bgpl2vpn-01.txt, 619 work in progress, July 2001. 621 [IPSEC-2547] Rosen, E., et al., "Use of PE-PE IPsec in RFC2547 622 VPNs", Work in Progress. 624 [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC2918, 625 September 2000. 627 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 628 Capability for BGP-4", Work in Progress. 630 [BGP-CONS] Marques, P., et al., "Constrained VPN route distribution" 631 work in progress, draft-ietf-l3vpn-rt-constrain-01.txt 633 14. Annex: Auto-Discovery in VR and MPLS-IP-VPN Interworking Scenarios 635 Two interwoking scenarios are considered when the network is using 636 both virtual routers and BGP/MPLS-IP-VPN. The first scenario is a 637 CE-PE relationship between a PE (implementing BGP/MPLS-IP-VPN), and 638 a VR appearing as a CE to the PE. The connection between the VR, and 639 the PE can be either direct connectivity, or through a tunnel (e.g., 640 IPSec). 642 The second scenario is when a PE is implementing both architectures. 643 In this particular case, a single BGP session configured on the 644 service provider network can be used to advertise either BGP/MPLS- 645 IP-VPN VPN information or the virtual router related VPN 646 information. From the VR and the BGP/MPLS-IP-VPN point of view there 647 is complete separation from data path and addressing schemes. 648 However the PE's interfaces are shared between both architectures. 650 A PE implementing only BGP/MPLS-IP-VPN will not import routes from a 651 BGP UPDATE message containing the VPN-ID extended community. On the 652 other hand, a PE implementing the virtual router architecture will 653 not import routes from a BGP UPDATE message containing the route 654 target extended community attribute. 656 The granularity at which the information is either BGP/MPLS-IP-VPN 657 related or VR-related is per BGP UPDATE message. Different SAFI 658 numbers are used to indicate that the message carried in BGP 659 multiprotocol extension attributes is to be handled by the VR or 660 BGP/MPLS-IP-VPN architectures. SAFI number of 128 is used for 661 BGP/MPLS-IP-VPN related format. A value of 129 for the SAFI number is 662 for the virtual router (where the NLRI are carrying a labeled 663 prefixes), and a SAFI value of 140 is for non labeled addresses. 665 15. Contributors 667 Bryan Gleeson 668 Tahoe Networks 669 3052 Orchard Drive 670 San Jose, CA 95134 USA 671 Email: bryan@tahoenetworks.com 673 Peter Ashwood-Smith 674 Nortel Networks 675 P.O. Box 3511 Station C, 676 Ottawa, ON K1Y 4H7, Canada 677 Phone: +1 613 763 4534 678 Email: petera@nortelnetworks.com 680 Luyuan Fang 681 AT&T 682 200 Laurel Avenue 683 Middletown, NJ 07748 684 Email: Luyuanfang@att.com 685 Phone: +1 (732) 420 1920 687 Jeremy De Clercq 688 Alcatel 689 Francis Wellesplein 1 690 B-2018 Antwerpen, Belgium 691 Phone: +32 3 240 47 52 692 Email: jeremy.de_clercq@alcatel.be 694 Riad Hartani 695 Caspian Networks 696 170 Baytech Drive 697 San Jose, CA 95143 698 Phone: 408 382 5216 699 Email: riad@caspiannetworks.com 701 Tissa Senevirathne 702 Force10 Networks 704 draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 706 1440 McCarthy Blvd, 707 Milpitas, CA 95035. 708 Phone: 408-965-5103 709 Email: tsenevir@hotmail.com 711 17. Authors Information 713 Hamid Ould-Brahim 714 Nortel Networks 715 P O Box 3511 Station C 716 Ottawa, ON K1Y 4H7, Canada 717 Email: hbrahim@nortelnetworks.com 719 Eric C. Rosen 720 Cisco Systems, Inc. 721 1414 Massachusetts Avenue 722 Boxborough, MA 01719 723 E-mail: erosen@cisco.com 725 Yakov Rekhter 726 Juniper Networks 727 1194 N. Mathilda Avenue 728 Sunnyvale, CA 94089 729 Email: yakov@juniper.net 731 draft-ietf-l3vpn-bgpvpn-auto-05.txt February 2005 733 Intellectual Property Statement 735 The IETF takes no position regarding the validity or scope of any 736 Intellectual Property Rights or other rights that might be 737 claimed to pertain to the implementation or use of the technology 738 described in this document or the extent to which any license 739 under such rights might or might not be available; nor does it 740 represent that it has made any independent effort to identify any 741 such rights. Information on the procedures with respect to 742 rights in RFC documents can be found in BCP 78 and BCP 79. 744 Copies of IPR disclosures made to the IETF Secretariat and any 745 assurances of licenses to be made available, or the result of an 746 attempt made to obtain a general license or permission for the 747 use of such proprietary rights by implementers or users of this 748 specification can be obtained from the IETF on-line IPR 749 repository at http://www.ietf.org/ipr. 751 The IETF invites any interested party to bring to its attention 752 any copyrights, patents or patent applications, or other 753 proprietary rights that may cover technology that may be required 754 to implement this standard. Please address the information to 755 the IETF at ietf-ipr@ietf.org. 757 Disclaimer of Validity 759 This document and the information contained herein are provided 760 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 761 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 762 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 763 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 764 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 765 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 766 FOR A PARTICULAR PURPOSE. 768 Copyright Statement 770 Copyright (C) The Internet Society (2005). This document is 771 subject to the rights, licenses and restrictions contained in BCP 772 78, and except as set forth therein, the authors retain all their 773 rights.