idnits 2.17.1 draft-ietf-l1vpn-bgp-auto-discovery-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 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 14, 2008) is 5820 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) == Outdated reference: A later version (-04) exists of draft-ietf-softwire-bgp-te-attribute-00 == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-16 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hamid Ould Brahim 3 Internet Draft Don Fedyk 4 Intended status: Standards Track (Nortel) 5 Expires: November 2008 Yakov Rekhter 6 (Juniper Networks) 8 May 14, 2008 10 BGP-based Auto-Discovery for Layer-1 VPNs 12 draft-ietf-l1vpn-bgp-auto-discovery-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire in August 2008. 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in RFC 2119. 43 Abstract 45 The purpose of this document is to define a BGP-based auto-discovery 46 mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for 47 L1VPNs allows the provider network devices to dynamically discover 48 the set of PEs having ports attached to CE members of the same VPN. 49 That information is necessary for completing the signaling phase of 50 L1VPN connections. One main objective of a L1VPN auto-discovery 51 mechanism is to support the "single-end provisioning" model, where 52 addition of a new port to a given L1VPN would involve configuration 53 changes only on the PE that has this port and on the CE that is 54 connected to the PE via this port. 56 1. Introduction 58 The purpose of this document is to define a BGP-based auto-discovery 59 mechanism for Layer-1 VPNs (L1VPNs) [L1VPN-FRMK]. The auto-discovery 60 mechanism for L1VPNs allows the provider network devices to 61 dynamically discover the set of PEs having ports attached to CE 62 members of the same VPN. That information is necessary for completing 63 the signaling phase of L1VPN connections. One main objective of a 64 L1VPN auto-discovery mechanism is to support the "single-end 65 provisioning" model, where addition of a new port to a given L1VPN 66 would involve configuration changes only on the PE that has this port 67 and on the CE that is connected to the PE via this port. 69 The auto-discovery mechanism proceeds by having a PE advertise to 70 other PEs, at a minimum, its own IP address and the list of tuples local to that PE. Once that 72 information is received, the remote PEs will identify the list of VPN 73 members they have in common with the advertising PE, and use the 74 information carried within the discovery mechanism to perform address 75 resolution during the signaling phase of Layer-1 VPN connections. 77 Figure 1 highlights the network reference for using BGP-based auto- 78 discovery mechanism for Layer-1 VPNs. For the purpose of auto- 79 discovery mechanism, BGP is running only on the provider network. The 80 PEs maintain per VPN information tables called Port Information Table 81 (PIT) related to information. 82 More information on the PIT tables is described in section 2. 84 PE1 PE2 85 +---------+ +--------------+ 86 +--------+ | +------+| | +----------+ | +--------+ 87 | VPN-A | | |VPN-A || | | VPN-A | | | VPN-A | 88 | CE1 |--| |PIT || BGP route | | PIT | |-| CE2 | 89 +--------+ | | ||<----------->| | | | +--------+ 90 | +------+| Distribution| +----------+ | 91 | | | | 92 +--------+ | +------+| | +----------+ | +--------+ 93 | VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B | 94 | CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 | 95 +--------+ | | || (Backbone ) | | | | +--------+ 96 | +------+| --------- | +----------+ | 97 | | | | 98 +--------+ | +-----+ | | +----------+ | +--------+ 99 | VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C | 100 | CE1 |--| |PIT | | | | PIT | |-| CE2 | 101 +--------+ | | | | | | | | +--------+ 102 | +-----+ | | +----------+ | 103 +---------+ +--------------+ 104 Figure 1 BGP auto-discovery for L1VPN 106 [L1VPN-FRMK] describes two modes of operation for a L1VPN: the basic 107 mode and the enhanced mode. This document describes an auto-discovery 108 mechanism for the basic mode only. 110 2. Procedures 112 In the context of L1VPNs, a CE is connected to a PE via one or more 113 ports, where each port may consist of one or more channels or sub- 114 channels. Each port on a CE that connects the CE to a PE has an 115 identifier that is unique within that L1VPN (but need not be unique 116 across several L1VPNs). We refer to this identifier as the customer 117 port identifier (CPI). Each port on a PE also has an identifier that 118 is unique within the provider network. We refer to this identifier as 119 the provider port identifier (PPI). Note that IP addresses used for 120 CPIs or PPIs could be either IPv4 or IPv6 addresses. 122 For each L1VPN that has at least one port configured on a PE, the PE 123 maintains a Port Information Table (PIT). A PIT contains a list of 124 tuples for all the ports within its L1VPN. Note that a PIT 125 may also hold routing information (for example when CPIs are learnt 126 using a routing protocol). 128 A PIT on a given PE is populated with two types of information. 130 - Information related to the CEs' ports attached to the ports on the 131 PE. This information could be locally configured at the PE or could 132 be received from the CEs. 134 - Information received from other PEs through the auto-discovery 135 mechanism. 137 We refer to the former as local information, and to the latter as 138 remote information. Propagation of local information to other PEs is 139 accomplished by using BGP multiprotocol extensions [RFC4760]. To 140 restrict the flow of this information to only the PITs within a given 141 L1VPN, we use BGP route filtering based on the Route Target Extended 142 Community [BGP-COMM], as follows. 144 Each PIT on a PE is configured with one or more Route Target 145 Communities, called "export Route Targets", that are used for tagging 146 the local information when it is exported into the provider's BGP. 147 The granularity of such tagging could be as fine as a single pair. In addition, each PIT on a PE is configured (at 149 provisioning time) with one or more Route Target Communities, called 150 "import Route Targets", that restrict the set of routes that could be 151 imported from provider's BGP into the PIT to only the routes that 152 have at least one of these Communities. 154 When a service provider adds a new L1VPN port to a particular PE (at 155 provisioning time), this port is associated at provisioning time with 156 a PIT on that PE, and this PIT is associated (again at provisioning 157 time) with that L1VPN. 159 Note that since the protocol used to populate a PIT with remote 160 information is BGP, since BGP works across multiple autonomous 161 systems, it follows that the mechanism described in this document 162 could support L1VPNs that span multiple autonomous systems. 164 Although multi-AS L1VPNs are currently out of scope for the Basic 165 Mode, the mechanisms defined in this document appear to be easily 166 applicable to a multi-AS scenario should such a need arise in the 167 future. At that time additional work may be required to examine 168 various aspects including security. 170 3. Carrying L1VPN information in BGP 172 The mapping is carried using the Multiprotocol Extensions 173 to BGP [RFC4760]. [RFC4760] defines the format of two BGP attributes, 174 MP_REACH_NLRI and MP_UNREACH_NLRI that can be used to announce and 175 withdraw the announcement of reachability information. We introduce a 176 new subsequent address family identifier, called Layer-1 VPN auto- 177 discovery information (to be assigned by the IANA), and also a new 178 NLRI format for carrying the CPI and PPI information. 180 One or more tuples could be carried in the above mentioned 181 BGP attributes. 183 The format of the NLRI is described in figure 2. 185 +---------------------------------------+ 187 | Length (1 octet) | 189 +---------------------------------------+ 191 | Auto-discovery info (variable) | 193 +---------------------------------------+ 195 Figure 2 Encoding of the NLRI 197 Note that the encoding of the auto-discovery information is described 198 in [L1VPN-BM] and note also that if the value of the Length of the 199 Next Hop field (of the MP_REACH_NLRI attribute) is 4, then the Next 200 Hop contains an IPv4 address. If this value is 16, then the Next Hop 201 contains an IPv6 address. 203 4. Carrying L1VPN Traffic Engineering Information in BGP 205 In addition to reachability information, the auto-discovery mechanism 206 MAY carry Traffic Engineering information used for the purpose of 207 egress path selection. For example a PE may learn the switching 208 capability and the maximum LSP bandwidth of remote L1VPN interfaces 209 from the remote PEs. This document uses the BGP Traffic Engineering 210 Attribute [BGP-TE-ATTRIBUTE] to carry such information. 212 5. Scalability 214 Recall that the Service Provider network consists of (a) PEs, (b) BGP 215 Route Reflectors, (c) P nodes (which are neither PEs nor Route 216 Reflectors), and, in the case of multi-provider VPNs, (d) ASBRs. 218 A PE router, unless it is a Route Reflector, does not retain L1VPN- 219 related information unless it has at least one VPN with an Import 220 Target identical to one of the VPN-related information Route Target 221 attributes. If a PE does not have a VPN with a matching Import Route 222 Target it MUST then discard received l1VPN information. Inbound 223 filtering MUST be used to cause such information to be discarded. If 224 a new Import Target is later added to one of the PE's VPNs (a "VPN 225 Join" operation), it MUST then acquire the VPN-related information it 226 previously has discarded. 228 In this case the refresh mechanism described in [BGP-RFSH] MUST be 229 used. The outbound route filtering mechanism of [BGP-ORF], [BGP-CONS] 230 can also be used to advantage to make the filtering more dynamic. 232 Similarly, if a particular Import Target is no longer present in any 233 of a PE's VPN (as a result of one or more "VPN Prune" operations), 234 the PE MAY discard all VPN-related information which, as a result, no 235 longer have any of the PE's VPN Import Targets as one of their Route 236 Target attributes. 238 Note that VPN Join and Prune operations are non-disruptive, and do 239 not require any BGP connections to be brought down, as long as the 240 refresh mechanism of [BGP-RFSH] is used. 242 As a result of these distribution rules, no one PE ever needs to 243 maintain all routes for all L1VPNs; this is an important scalability 244 consideration. 246 Route reflectors can be partitioned among VPNs so that each partition 247 carries routes for only a subset of the L1VPNs supported by the 248 Service Provider. Thus no single route reflector is required to 249 maintain VPN-related information for all VPNs. 251 For inter-provider VPNs, if multi-hop EBGP is used, then the ASBRs 252 need not maintain and distribute VPN-related information at all. P 253 routers do not maintain any VPN-related information. 255 As a result, no single component within the Service Provider network 256 has to maintain all the VPN-related information for all the VPNs. So 257 the total capacity of the network to support increasing numbers of 258 VPNs is not limited by the capacity of any individual component. 260 An important consideration to remember is that one may have any 261 number of INDEPENDENT BGP systems carrying VPN-related information. 262 This is unlike the case of the Internet, where the Internet BGP 263 system MUST carry all the Internet routes. Thus one significant (but 264 perhaps subtle) distinction between the use of BGP for the Internet 265 routing and the use of BGP for distributing VPN-related information, 266 as described in this document is that the former is not amenable to 267 partition, while the latter is. 269 6. Security Considerations 271 This document describes a BGP-based auto-discovery mechanism which 272 enables a PE that attaches to a particular L1VPN to discover the set 273 of other PE routers that attach to the same VPN. Each PE router that 274 is attached to a given VPN uses BGP to advertise that fact. Other PE 275 routers which attach to the same VPN receive these BGP 276 advertisements. This allows that set of PEs to discover each other. 277 Note that a PE will not always receive these advertisements directly 278 from the remote PEs; the advertisements can be received from 279 "intermediate" BGP speakers. 281 It is of critical importance that a particular PE MUST NOT be 282 "discovered" to be attached to a particular VPN unless that PE really 283 is attached to that VPN, and indeed is properly authorized to be 284 attached to that VPN. If any arbitrary node on the Internet could 285 start sending these BGP advertisements, and if those advertisements 286 were able to reach the PE nodes, and if the PE nodes accepted those 287 advertisements, then anyone could add any site to any L1VPN. Thus 288 the auto-discovery procedures described here presuppose that a 289 particular PE trusts its BGP peers to be who they appear to be, and 290 further that it can trust those peers to be properly securing their 291 local attachments. (That is, a PE MUST trust that its peers are 292 attached to, and are authorized to be attached to, the L1VPNs to 293 which they claim to be attached.) 295 If a particular remote PE is a BGP peer of the local PE, then the BGP 296 authentication procedures of RFC 2385 SHOULD be used to ensure that 297 the remote PE is who it claims to be, i.e., that it is a PE that is 298 trusted. 300 If a particular remote PE is not a BGP peer of the local PE, then the 301 information it is advertising is being distributed to the local PE 302 through a chain of BGP speakers. The local PE MUST trust that its 303 peers only accept information from peers that they trust in turn, and 304 this trust relation MUST be transitive. BGP does not provide a way 305 to determine that any particular piece of received information 306 originated from a BGP speaker that was authorized to advertise that 307 particular piece of information. Hence the procedures of this 308 document MUST be used only in environments where adequate trust 309 relationships exist among the BGP speakers (such as the case of using 310 the auto-discovery mechanism within a single provider network). 312 7. IANA Considerations 314 This document requires assignment of a new SAFI, called Layer-1 VPN 315 auto-discovery information (see Section 3). This assignment has to be 316 done from the Subsequent Address Family Identifier (SAFI) registry 317 using the Standards Action allocation procedures. Suggested value is 318 69. 320 8. References 322 8.1. Normative References 324 [RFC4760] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 325 Extensions for BGP4", January 2007, RFC 4760. 327 [BGP-RFSH] Chen, A., "Route Refresh Capability for BGP-4", RFC 2918, 328 October 2000. 330 8.2. Informative References 332 [BGP-TE-ATTRIBUTE] Ould-Brahim, H., Fedyk, D., Rekhter, Y., 333 "Traffic Engineering Attribute", draft-ietf-softwire-bgp- 334 te-attribute-00.txt, work in progress. 336 [BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering 337 Capability for BGP-4", draft-ietf-idr-route-filter-16.txt, 338 Work in Progress. 340 [BGP-CONS] Marques, P., et al., "Constrained VPN route 341 distribution", RFC4684. 343 [BGP-COMM] Ramachandra, Tappan, et al., "BGP Extended Communities 344 Attribute", RFC4360. 346 [L1VPN-FRMK] Tomonori Takeda, et al., "Framework and Requirements 347 for Layer 1 Virtual Private Networks", RFC4847. 349 [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic Mode", 350 draft-ietf-l1vpn-basic-mode, work in progress. 352 9. Acknowledgment 354 We would like to thank Adrian Farrel for the useful comments. 356 10. Authors' Addresses 358 Hamid Ould-Brahim 359 Nortel 360 P O Box 3511 Station C 361 Ottawa ON K1Y 4H7 Canada 362 Phone: +1 (613) 763 4730 363 Email: hbrahim@nortel.com 365 Yakov Rekhter 366 Juniper Networks 367 1194 N. Mathilda Avenue 368 Sunnyvale, CA 94089 369 Email: yakov@juniper.net 371 Don Fedyk 372 Nortel 373 600 Technology Park 374 Billerica, Massachusetts 375 01821 U.S.A 376 Phone: +1 (978) 288 3041 377 Email: dwfedyk@nortel.com 379 Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at ietf- 400 ipr@ietf.org. 402 Copyright (C) The IETF Trust (2008). 404 This document is subject to the rights, licenses and restrictions 405 contained in BCP 78, and except as set forth therein, the authors 406 retain all their rights. 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 411 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 412 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 413 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.