idnits 2.17.1 draft-ietf-l3vpn-bgpvpn-auto-06.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.5 on line 712. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 701. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 (June 2005) is 6890 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 323, but not defined == Unused Reference: 'BGP-MP' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC-3107' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC-2026' is defined on line 558, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'TLS-TISSA' is defined on line 567, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-idr-bgp-ext-communities-08 ** 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) == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-vpn-vr-02 ** Downref: Normative reference to an Informational draft: draft-ietf-l3vpn-vpn-vr (ref. 'VPN-VR') == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-03 == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-vpls-bgp-05 == Outdated reference: A later version (-09) exists of draft-ietf-l2vpn-vpls-ldp-06 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- No information found for draft-tsenevir-bgpl2vpn - is the name correct? == Outdated reference: A later version (-05) exists of draft-ietf-l3vpn-gre-ip-2547-03 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-11 == Outdated reference: A later version (-02) exists of draft-ietf-l3vpn-rt-constrain-01 Summary: 9 errors (**), 0 flaws (~~), 18 warnings (==), 8 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 4 Expiration Date: December 2005 5 Eric C. Rosen 6 Cisco Systems 8 Yakov Rekhter 9 Juniper Networks 11 (Editors) 13 June 2005 15 Using BGP as an Auto-Discovery 16 Mechanism for Layer-3 and Layer-2 VPNs 18 draft-ietf-l3vpn-bgpvpn-auto-06.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79." 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 In any Layer-3 and Layer-2 VPN scheme, the Provider Edge (PE) 45 devices attached to a common VPN must exchange certain information 46 as a prerequisite to establish VPN-specific connectivity. The main 47 purpose of an auto-discovery mechanism is to enable a PE to 48 dynamically discover the set of remote PEs having VPN members in 49 common. The auto-discovery mechanism proceeds by having a PE 50 advertises to other PEs, at a minimum, its own IP address and the 51 list of VPN members configured on that PE. Once that information is 52 received the remote PEs will then identify the list of VPN members 53 they have in common with the advertising PE, and use the information 54 carried within the discovery mechanism to either establish layer-2/3 55 VPN connectivity or to learn remote site VPN routes. This draft 56 defines a BGP based auto-discovery mechanism for layer-2 VPN 57 architectures and Virtual router-based layer-3 VPNs. This mechanism 58 is based on the approach used by BGP/MPLS-IP-VPN for distributing 59 VPN routing information within the service provider(s). In the 60 context of L2VPNs, an auto-discovery mechanism enables a PE to 61 determine the set of other PEs having VPN members in common along 62 with information relative to each specific L2VPN endpoints such as 63 attachment circuit identifier, topology information, etc. Each VPN 64 scheme uses the mechanism to automatically discover the information 65 needed by that particular scheme. 67 1. Introduction 69 In any Layer-2 and Layer-3 VPN scheme, the Provider Edge (PE) 70 devices attached to a common VPN must exchange certain information 71 as a prerequisite to establish VPN-specific connectivity. An auto- 72 discovery mechanism allows a PE to dynamically discover the set of 73 remote PEs having VPN members in common. The auto-discovery 74 mechanism proceeds by having a PE advertises to other PEs, at a 75 minimum, its own IP address and the list of VPN members configured 76 on that PE. Once that information is received the remote PEs will 77 then identify the list of VPN members they have in common with the 78 advertising PE, and use the information carried within the discovery 79 mechanism to either establish layer-2/3 VPN connectivity or to learn 80 remote site VPN routes. 82 The purpose of this draft is to define a BGP based auto-discovery 83 mechanism for layer-2 VPNs (i.e., [VPLS-BGP], [L2VPN-ROSEN], [VPLS- 84 LDP]) and layer-3 VPNs based on Virtual Router (VR) [VPN-VR] 85 solution. This mechanism is based on the approach used by [BGP/MPLS- 86 IP-VPN] for distributing VPN routing information within the service 87 provider(s). Each VPN scheme uses the mechanism to automatically 88 discover the information needed by that particular scheme. Layer-2 89 and layer-3 VPN solutions that plan to use BGP-based auto-discovery 90 must comply with the general encoding proposed in this document. 92 In [BGP/MPLS-IP-VPN], VPN-specific routes are exchanged, along with 93 the information needed to enable a PE to determine which routes 94 belong to which VRFs. 96 In VR model, virtual router (VR) addresses must be exchanged, along 97 with the information needed to enable the PEs to determine which VRs 98 are in the same VPN ("membership"), and which of those VRs are to 99 have VPN connectivity ("topology"). Once the VRs are reachable 100 through the tunnels, routes ("reachability") are then exchanged by 101 running existing routing protocols per VPN basis. 103 In the context of L2VPNs, an auto-discovery mechanism enables a PE 104 to determine the set of other PEs having VPN members in common along 105 with information relative to each specific L2VPN endpoints such as 106 attachment circuit identifier, topology information, etc. 108 The BGP-4 multiprotocol extensions are used to carry various 109 information about VPNs for both layer-2 and layer-3 VPN 110 architectures. VPN-specific information associated with the NLRI is 111 encoded either as attributes of the NLRI, or as part of the NLRI 112 itself, or both. 114 2. Provider-Provisioned VPN Reference Model 116 Both the layer-2 and layer-3 vpn architectures ([VPLS-BGP],[VPLS- 117 LDP], [L2VPN-ROSEN], [VPN-VR], [BGP/MPLS-IP-VPN]) are using a 118 network reference model as illustrated in figure 1. 120 PE PE 121 +--------------+ +--------------+ 122 +--------+ | +----------+ | | +----------+ | +--------+ 123 | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | 124 | Sites |--| |Database /| | BGP route | | Database/| |-| sites | 125 +--------+ | |Processing| |<----------->| |Processing| | +--------+ 126 | +----------+ | Distribution| +----------+ | 127 | | | | 128 +--------+ | +----------+ | | +----------+ | +--------+ 129 | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | 130 | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | 131 +--------+ | |Processing| | -------- | |Processing| | +--------+ 132 | +----------+ | | +----------+ | 133 | | | | 134 +--------+ | +----------+ | | +----------+ | +--------+ 135 | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | 136 | Sites |--| |Database /| | | | Database/| |-| sites | 137 +--------+ | |Processing| | | |Processing| | +--------+ 138 | +----------+ | | +----------+ | 139 +--------------+ +--------------+ 141 Figure 1: Network based VPN Reference Model 143 It is assumed that the PEs can use BGP to distribute information to 144 each other. This may be via direct IBGP peering, via direct EBGP 145 peering, via multihop BGP peering, through intermediaries such as 146 Route Reflectors, through a chain of intermediate BGP connections, 147 etc. It is assumed also that the PE knows what VPN architecture it 148 is supporting. 150 3. Carrying VPN information in BGP Multi-Protocol (BGP-MP) Attributes 152 The BGP-4 multiprotocol extensions are used to carry various 153 information about VPNs for both layer-2 and layer-3 VPN 154 architectures. VPN-specific information associated with the NLRI is 155 encoded either as attributes of the NLRI, or as part of the NLRI 156 itself, or both. The addressing information in the NLRI field is 157 ALWAYS within the VPN address space, and therefore MUST be unique 158 within the VPN. The address specified in the BGP next hop attribute, 159 on the other hand, is in the service provider addressing space. 161 3.1 Carrying Layer-3 VPN Information in BGP-MP 163 This is done as follows. The NLRI is a VPN-IP address or a labeled 164 VPN-IP address. In the case of the virtual router, the NLRI address 165 prefix is an address of one of the virtual routers configured on the 166 PE. That address is used by the VRs to establish routing adjacencies 167 and tunnel to each other [VPN-VR]. In the case of BGP/MPLS-IP-VPN, 168 the NLRI prefix represents a route to an arbitrary system or set of 169 systems within the VPN. 171 3.2 Carrying Layer-2 VPN Information in BGP-MP 173 The NLRI in BGP-MP attribute carries Layer-2 VPN information, 174 which we will refer to as VPN-L2 information. A VPN-L2 information 175 carried in the NLRI is composed of a quantity beginning with 176 an 8 bytes Route Distinguisher (RD) field and a variable length 177 quantity (see section 5 for specific encodings of this quantity). 179 Different layer-2 VPN solutions use the same common AFI, but 180 different SAFI. The AFI indicates that the NLRI is carrying a VPN-L2 181 information, while the SAFI indicates solution-specific semantics 182 and syntax of the VPN-l2 address that goes after the RD. The RD must 183 be chosen so as it ensures that each NLRI is globally unique (i.e., 184 the same NLRI does not appear in two VPNs). 186 BGP Route target extended community is used to constrain route 187 distribution between PEs. The BGP Next hop carries the service 188 provider tunnel endpoint address. 190 This draft doesn't preclude the use of additional extended 191 communities for encoding specific l2vpn parameters. 193 4. Interpretation of VPN Information in Layer-3 VPNs 195 4.1 Interpretation of VPN Information in the BGP/MPLS-IP-VPN Model 196 For details see [BGP/MPLS-IP-VPN]. 198 4.2 Interpretation of VPN Information in the VR Model 200 4.2.1 Membership Discovery 202 The VPN-ID format as defined in [RFC-2685] is used to identify a 203 VPN. All virtual routers that are members of a specific VPN share 204 the same VPN-ID. A VPN-ID is carried in the NLRI to make addresses 205 of VRs globally unique. Making these addresses globally unique is 206 necessary if one uses BGP for VRs' auto-discovery. 208 4.2.1.1 Encoding of the VPN-ID in the NLRI 210 For the virtual router model, the VPN-ID is carried within the route 211 distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the 212 first byte of RD type field is used to indicate the existence of the 213 VPN-ID format. A value of 0x80 in the first byte of RD's type field 214 indicates that the RD field is carrying the VPN-ID format. In this 215 case, the type field range 0x8000-0x80ff will be reserved for the 216 virtual router case. 218 4.2.1.2 VPN-ID Extended Community 220 A new extended community is used to carry the VPN-ID format. This 221 attribute is transitive across the Autonomous system boundary. The 222 type field of the VPN-ID extended community is of regular type to be 223 assigned by IANA [BGP-COMM]. The remaining 7 bytes hold the VPN-ID 224 value field as per [RFC-2685]. The BGP UPDATE message will carry 225 information for a single VPN. It is the VPN-ID Extended Community, 226 or more precisely route filtering based on the Extended Community 227 that allows one VR to find out about other VRs in the same VPN. 229 4.2.2 VPN Topology Information 231 A new extended community is used to indicate different VPN topology 232 values. This attribute is transitive across the Autonomous system 233 boundary. The value of the type field for extended type is assigned 234 by IANA. The first two bytes of the value field (of the remaining 6 235 bytes) are reserved. The actual topology values are carried within 236 the remaining four bytes. The following topology values are defined: 238 Value Topology Type 240 1 "Hub" 241 2 "Spoke" 242 3 "Mesh" 244 Arbitrary values can also be used to allow specific topologies to be 245 constructed. 247 In a hub and spoke topology, spoke VRs (i.e., PE having VRs as 248 spokes within the VPN) will advertise their BGP information with 249 VPN topology extended community with value of "2". Spoke VRs will 250 only be allowed to connect to hub VRs and therefore spoke VR-based 251 PEs will just import VPN information from BGP that is set of "1". 252 Hub sites can connect to both hub and spoke sites (i.e., Hub VRs can 253 import VPN topology of both values "1", "2", or "3". In a mesh 254 topology, mesh sites connect to each other, each VR will advertise 255 VPN topology information of "3". 257 Furthermore, in the presence of both hub and spoke and mesh 258 topologies within the same VPN, mesh sites can as well connect to 259 hub sites and vice versa. 261 5. Interpretation of VPN Information in VPLS 263 The interpretation of the VPN information for VPLS solutions is 264 described in the following sections. 266 5.1 VPLS 268 In order to use BGP-based auto-discovery for VPLS-based VPNs 269 where discovery and signaling are separate components such as 270 [VPLS-LDP] solutions each VSI needs to have an identifier, which 271 can be encoded as a BGP NLRI. This identifier MUST be unique 272 across all VPLSs, and MAY be unique across all VSIs (in all 273 VPLSs). This document uses Route Distinguishers (RDs) to construct 274 such identifiers. If several VSIs of a given VPLS use the same 275 RD, then the unique identifier could be constructed by prepending 276 the RD to an IP address of the PE containing the virtual LAN 277 switch (VSI). Note that it is not strictly necessary for all 278 the VSIs in the same VPLS to have the same RD, all that is really 279 necessary is that the NLRI uniquely identify a virtual LAN switch. 280 If all VSIs have their own unique RDs, then these RDs alone could 281 be used as VSIs' identifiers. Any method of constructing unique 282 RDs (e.g., using the encoding techniques of [BGP/MPLS-IP-VPN]) 283 will do. 285 Each VSI needs to be associated with one or more Route Target 286 (RT) Extended Communities. These control the distribution of 287 the NLRI, and hence will control the formation of the overlay 288 topology of pseudowires that constitutes a particular VPLS. Any 289 method of constructing unique RTs (e.g., using the encoding 290 techniques of [BGP/MPLS-IP-VPN]) will do. 292 Auto-discovery proceeds by having each PE distribute, via BGP, 293 the NLRI for each of its VSIs, with itself as the BGP next hop, 294 and with the appropriate RT for each such NLRI. Typically, each 295 PE would be a client of a small set of BGP route reflectors, 296 which would redistribute this information to the other clients. 298 If a PE has a VSI with a particular RT, it can then receive all 299 the NLRI which have that same RT, and from the BGP next hop 300 attribute of these NLRI will learn the IP addresses of the other 301 PE routers which have VSIs with the same RT. 303 If a particular VPLS is meant to be a single fully connected 304 LAN, all its VSIs will have the same RT. If a particular VPLS 305 consists of multiple VLANs, each VLAN must have its own unique 306 RT. A VSI can be placed in multiple VLANS (or even in multiple 307 VPLSs) by assigning it multiple RTs. 309 5.1.1 VPLS using BGP as a signaling Mechanism 311 The interpretation of VPN information for VPLS services using BGP as 312 the signaling component is described in [VPLS-BGP]. Note that this 313 solution complies with procedures described in section 3.2. 315 6. Tunnel Discovery 317 Layer-3 VPNs and Layer-2 VPNs must be implemented through some form 318 of tunneling mechanism, where the packet formats and/or the 319 addressing used within the VPN can be unrelated to that used to 320 route the tunneled packets across the backbone. There are numerous 321 tunneling mechanisms that can be used by a network based VPN (e.g., 322 IP/IP [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS 323 tunnels [RFC-3031]). Each of these tunnels allows for opaque 324 transport of frames as packet payload across the backbone, with 325 forwarding disjoint from the address fields of the encapsulated 326 packets. A provider edge router may terminate multiple type of 327 tunnels and forward packets between these tunnels and other network 328 interfaces in different ways. 330 BGP can be used to carry tunnel endpoint addresses between edge 331 routers. 333 The BGP next hop will carry the service provider tunnel endpoint 334 address. As an example, if IPSec is used as tunneling mechanism, the 335 IPSec tunnel remote address will be discovered through BGP, and the 336 actual tunnel establishment is achieved through IPSec signaling 337 protocol. 339 When MPLS tunneling is used, the label carried in the NLRI field is 340 associated with an address of a VR, where the address is carried in 341 the NLRI and is encoded as a VPN-IP address. 343 The auto-discovery mechanism should convey minimum information for 344 the tunnels to be setup. The means of distributing multiplexors must 345 be defined either via some sort of tunnel-protocol-specific signaling 346 mechanism, or via additional information carried by the 347 auto-discovery protocol. That information may or may not be 348 used directly within the specific signaling protocol. On one end of 349 the spectrum, the combination of IP address (such as BGP next hop and 350 IP address carried within the NLRI) and the label and/or VPN-ID 351 provides sufficient information for a PE to setup per VPN tunnels or 352 shared tunnels per set of VPNs. On another end of the spectrum 353 additional specific tunnel related information can be carried within 354 the discovery process if needed. 356 7. Scalability Considerations 358 In this section, we briefly summarize the main characteristics of 359 our model with respect to scalability. 361 Recall that the Service Provider network consists of (a) PE routers, 362 (b) BGP Route Reflectors, (c) P routers (which are neither PE 363 routers nor Route Reflectors), and, in the case of multi-provider 364 VPNs, (d) ASBRs. 366 A PE router, unless it is a Route Reflector should not retain 367 VPN-related information unless it has at least one VPN with an 368 Import Target identical to one of the VPN-related information Route 369 Target attributes. Inbound filtering should be used to cause such 370 information to be discarded. If a new Import Target is later added 371 to one of the PE's VPNs (a "VPN Join" operation), it must then 372 acquire the VPN-related information it may previously have 373 discarded. 375 This can be done using the refresh mechanism described in [BGP- 376 RFSH]. 378 The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] can 379 also be used to advantage to make the filtering more dynamic. 381 Similarly, if a particular Import Target is no longer present in 382 any of a PE's VPNs (as a result of one or more "VPN Prune" 383 operations), the PE may discard all VPN-related information which, 384 as a result, no longer have any of the PE's VPN's Import Targets as 385 one of their Route Target Attributes. 387 Note that VPN Join and Prune operations are non-disruptive, and do 388 not require any BGP connections to be brought down, as long as the 389 refresh mechanism of [BGP-RFSH] is used. 391 As a result of these distribution rules, no one PE ever needs to 392 maintain all routes for all VPNs; this is an important scalability 393 consideration. 395 Route reflectors can be partitioned among VPNs so that each 396 partition carries routes for only a subset of the VPNs supported by 397 the Service Provider. Thus no single route reflector is required to 398 maintain VPN-related information for all VPNs. 400 For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs 401 need not maintain and distribute VPN-related information at all. 403 P routers do not maintain any VPN-related information. In order 404 to properly forward VPN traffic, the P routers need only maintain 405 routes to the PE routers and the ASBRs. 407 As a result, no single component within the Service Provider network 408 has to maintain all the VPN-related information for all the VPNs. 409 So the total capacity of the network to support increasing numbers 410 of VPNs is not limited by the capacity of any individual component. 412 An important consideration to remember is that one may have any 413 number of INDEPENDENT BGP systems carrying VPN-related information. 414 This is unlike the case of the Internet, where the Internet BGP 415 system must carry all the Internet routes. Thus one significant 416 (but perhaps subtle) distinction between the use of BGP for the 417 Internet routing and the use of BGP for distributing VPN-related 418 information, as described in this document is that the former is not 419 amenable to partition, while the latter is. 421 8. Security Considerations 423 This document describes a BGP-based auto-discovery mechanism which 424 enables a PE router that attaches to a particular VPN to discover 425 the set of other PE routers that attach to the same VPN. Each PE 426 router that is attached to a given VPN uses BGP to advertise that 427 fact. Other PE routers which attach to the same VPN receive these 428 BGP advertisements. This allows that set of PE routers to discover 429 each other. Note that a PE will not always receive these 430 advertisements directly from the remote PEs; the advertisements may 431 be received from "intermediate" BGP speakers. 433 It is of critical importance that a particular PE should not be 434 "discovered" to be attached to a particular VPN unless that PE 435 really is attached to that VPN, and indeed is properly authorized to 436 be attached to that VPN. If any arbitrary node on the Internet 437 could start sending these BGP advertisements, and if those 438 advertisements were able to reach the PE routers, and if the PE 439 routers accepted those advertisements, then anyone could add any 440 site to any VPN. Thus the auto-discovery procedures described here 441 presuppose that a particular PE trusts its BGP peers to be who they 442 appear to be, and further that it can trusts those peers to be 443 properly securing their local attachments. (That is, a PE must 444 trust that its peers are attached to, and are authorized to be 445 attached to, the VPNs to which they claim to be attached.). 447 If a particular remote PE is a BGP peer of the local PE, then the 448 BGP authentication procedures of RFC 2385 can be used to ensure that 449 the remote PE is who it claims to be, i.e., that it is a PE that is 450 trusted. 452 If a particular remote PE is not a BGP peer of the local PE, then 453 the information it is advertising is being distributed to the local 454 PE through a chain of BGP speakers. The local PE must trust that 455 its peers only accept information from peers that they trust in 456 turn, and this trust relation must be transitive. BGP does not 457 provide a way to determine that any particular piece of received 458 information originated from a BGP speaker that was authorized to 459 advertise that particular piece of information. Hence the 460 procedures of this document should be used only in environments 461 where adequate trust relationships exist among the BGP speakers. 463 Some of the VPN schemes which may use the procedures of this 464 document can be made robust to failures of these trust 465 relationships. That is, it may be possible to keep the VPNs secure 466 even if the auto-discovery procedures are not secure. For example, 467 a VPN based on the VR model can use IPsec tunnels for transmitting 468 data and routing control packets between PE routers. An 469 illegitimate PE router which is discovered via BGP will not have the 470 shared secret which makes it possible to set up the IPsec tunnel, 471 and so will not be able to join the VPN. Similarly, [IP-GRE] 472 describes procedures for using IPsec tunnels to secure VPNs based on 473 the BGP/MPLS-IP-VPN model. The details for using IPsec to secure a 474 particular sort of VPN depend on that sort of VPN and so are out of 475 scope of the current document. 477 9. IANA Considerations 479 9.1 IANA Considerations for L2VPNs 481 New AFI value to be assigned by IANA to indicate that the NLRI is 482 carrying VPN-L2 information as described in section 3.2. 484 New SAFI number for VPLS-based L2VPNs solutions using LDP-based 485 signalling. 487 9.2 IANA Considerations for VR-based L3VPNs 489 SAFI number "129" for indicating that the NLRI is carrying 490 information for VR-based solution. 492 SAFI number "140" for indicating that the NLRI is carrying 493 information for VR for non-labeled prefixes. 495 New Extended Community to be assigned by IANA and used for Topology 496 values for VR-based L3VPN solution see section 4.2.2. 498 New Extended Community to be assigned by IANA for carrying VPN-ID 499 format based on RFC2685 format (see section 4.2.1.2) 501 10. Use of BGP Capability Advertisement 503 A BGP speaker that uses VPN information as described in this 504 document with multiprotocol extensions should use the Capability 505 Advertisement procedures [RFC-3392] to determine whether the speaker 506 could use Multiprotocol Extensions with a particular peer. 508 11. Acknowledgement 510 The authors would like to acknowledge Benson Schliesser, and Thomas 511 Narten for the constructive and fruitful comments. 513 12. Normative References 515 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities 516 Attribute", draft-ietf-idr-bgp-ext-communities-08.txt, 517 August 2005, work in progress. 519 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 520 Extensions for BGP4", February 1998, RFC 2283. 522 [RFC-3107] Rekhter Y, Rosen E., "Carrying Label Information in 523 BGP4", January 2000, RFC3107. 525 [BGP/MPLS-IP-VPN] Rosen E., et al, "BGP/MPLS VPNs", draft-ietf- 526 l3vpn-rfc2547bis-03.txt, October 2004, Work in Progress. 528 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", 529 RFC 2685, September 1999. 531 [RFC-3392] Chandra, R., et al., "Capabilities Advertisement with 532 BGP-4", RFC3392, May 2002. 534 [VPN-VR] Knight, P., Ould-Brahim H., Gleeson, B., "Network based IP 535 VPN Architecture using Virtual Routers", 536 draft-ietf-l3vpn-vpn-vr-02.txt, April 2004, Work in Progress. 538 13. Informative References 540 [L2VPN-ROSEN] Rosen, E., Radoaca, V., "Provisioning Models and 541 Endpoint Identifiers in L2VPN Signaling", 542 draft-ietf-l2vpn-signaling-03.txt, February 2005, 543 Work in Progress. 545 [VPLS-BGP] Kompella, K., et al., "Virtual Private LAN Service", 546 draft-ietf-l2vpn-vpls-bgp-05, April 2005, Work in Progress. 548 [VPLS-LDP] Kompella, V., Lasserre, M., et al., "Virtual Private LAN 549 Services over MPLS", draft-ietf-l2vpn-vpls-ldp-06.txt, 550 February 2005, Work in Progress. 552 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 553 Routing Encapsulation (GRE)", RFC 1701, October 1994. 555 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 556 October 1996. 558 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 559 3", RFC 2026, October 1996. 561 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 562 Internet Protocol", RFC 2401, November 1998. 564 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 565 Requirement Levels", RFC 2119, March 1997. 567 [TLS-TISSA] "BGP/MPLS Layer-2 VPN", draft-tsenevir-bgpl2vpn-01.txt, 568 work in progress, July 2001. 570 [IP-GRE] Rosen, E., et al., "Use of PE-PE GRE or IP in BGP/MPLS IP 571 Virtual Private Networks", draft-ietf-l3vpn-gre-ip-2547-03.txt, 572 October 2004, Work in Progress. 574 [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC 2918, 575 September 2000. 577 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 578 Capability for BGP-4", draft-ietf-idr-route-filter-11.txt, 579 December 2004, Work in Progress. 581 [BGP-CONS] Marques, P., et al., "Constrained VPN route distribution" 582 draft-ietf-l3vpn-rt-constrain-01.txt, September 2004, work in 583 progress 585 14. Annex: Auto-Discovery in VR and MPLS-IP-VPN Interworking Scenarios 587 Two interwoking scenarios are considered when the network is using 588 both virtual routers and BGP/MPLS-IP-VPN. The first scenario is a 589 CE-PE relationship between a PE (implementing BGP/MPLS-IP-VPN), and 590 a VR appearing as a CE to the PE. The connection between the VR, and 591 the PE can be either direct connectivity, or through a tunnel (e.g., 592 IPSec). 594 The second scenario is when a PE is implementing both architectures. 595 In this particular case, a single BGP session configured on the 596 service provider network can be used to advertise either BGP/MPLS- 597 IP-VPN VPN information or the virtual router related VPN 598 information. From the VR and the BGP/MPLS-IP-VPN point of view there 599 is complete separation from data path and addressing schemes. 600 However the PE's interfaces are shared between both architectures. 602 A PE implementing only BGP/MPLS-IP-VPN will not import routes from a 603 BGP UPDATE message containing the VPN-ID extended community. On the 604 other hand, a PE implementing the virtual router architecture will 605 not import routes from a BGP UPDATE message containing the route 606 target extended community attribute. 608 The granularity at which the information is either BGP/MPLS-IP-VPN 609 related or VR-related is per BGP UPDATE message. Different SAFI 610 numbers are used to indicate that the message carried in BGP 611 multiprotocol extension attributes is to be handled by the VR or 612 BGP/MPLS-IP-VPN architectures. SAFI number of 128 is used for 613 BGP/MPLS-IP-VPN related format. A value of 129 for the SAFI number is 614 for the virtual router (where the NLRI are carrying a labeled 615 prefixes), and a SAFI value of 140 is for non labeled addresses. 617 15. Contributors 619 Bryan Gleeson 620 Tahoe Networks 621 3052 Orchard Drive 622 San Jose, CA 95134 USA 623 Email: bryan@tahoenetworks.com 625 Peter Ashwood-Smith 626 Nortel Networks 627 P.O. Box 3511 Station C, 628 Ottawa, ON K1Y 4H7, Canada 629 Phone: +1 613 763 4534 630 Email: petera@nortelnetworks.com 632 Luyuan Fang 633 AT&T 634 200 Laurel Avenue 635 Middletown, NJ 07748 636 Email: Luyuanfang@att.com 637 Phone: +1 (732) 420 1920 639 Jeremy De Clercq 640 Alcatel 641 Francis Wellesplein 1 642 B-2018 Antwerpen, Belgium 643 Phone: +32 3 240 47 52 644 Email: jeremy.de_clercq@alcatel.be 646 Riad Hartani 647 Caspian Networks 648 170 Baytech Drive 649 San Jose, CA 95143 650 Phone: 408 382 5216 651 Email: riad@caspiannetworks.com 653 Tissa Senevirathne 654 Force10 Networks 655 1440 McCarthy Blvd, 656 Milpitas, CA 95035. 657 Phone: 408-965-5103 658 Email: tsenevir@hotmail.com 660 17. Author' Addresses 662 Hamid Ould-Brahim 663 Nortel Networks 664 P O Box 3511 Station C 665 Ottawa, ON K1Y 4H7, Canada 666 Email: hbrahim@nortelnetworks.com 668 Eric C. Rosen 669 Cisco Systems, Inc. 670 1414 Massachusetts Avenue 671 Boxborough, MA 01719 672 E-mail: erosen@cisco.com 674 Yakov Rekhter 675 Juniper Networks 676 1194 N. Mathilda Avenue 677 Sunnyvale, CA 94089 678 Email: yakov@juniper.net 679 Intellectual Property Statement 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be 683 claimed to pertain to the implementation or use of the technology 684 described in this document or the extent to which any license 685 under such rights might or might not be available; nor does it 686 represent that it has made any independent effort to identify any 687 such rights. Information on the procedures with respect to 688 rights in RFC documents can be found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the 693 use of such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR 695 repository at http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention 698 any copyrights, patents or patent applications, or other 699 proprietary rights that may cover technology that may be required 700 to implement this standard. Please address the information to 701 the IETF at ietf-ipr@ietf.org. 703 Disclaimer of Validity 705 This document and the information contained herein are provided 706 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 707 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 708 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 709 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 710 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 711 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 712 FOR A PARTICULAR PURPOSE. 714 Copyright Statement 716 Copyright (C) The Internet Society (2005). This document is 717 subject to the rights, licenses and restrictions contained in BCP 718 78, and except as set forth therein, the authors retain all their 719 rights.