idnits 2.17.00 (12 Aug 2021) /tmp/idnits45430/draft-ouldbrahim-bgpvpn-auto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([VPN-VR], [RFC2547-bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 131: '...e, and therefore MUST be unique within...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2001) is 7737 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) == Unused Reference: 'BGP-COMM' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'BGP-MP' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'BGP-MPLS' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'MPLS-ENCAPS' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'VPN-BGP' is defined on line 322, 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'BGP-MPLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-ENCAPS' ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-VR' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provider Provisioned VPN WG Hamid Ould-Brahim 3 Internet Draft Bryan Gleeson 4 draft-ouldbrahim-bgpvpn-auto-01.txt Peter Ashwood-Smith 5 Expiration Date: September 2001 Nortel Networks 7 Eric C. Rosen 8 Cisco Systems 10 Yakov Rekhter 11 Juniper Networks 13 Luyuan Fang 14 AT&T 16 Jeremy De Clercq 17 Alcatel 19 March 2001 21 Using BGP as an Auto-Discovery 22 Mechanism for Network-based VPNs 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026 [RFC-2026]. 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 Network-Based VPN (NBVPN) scheme, the Provider Edge (PE) 47 routers attached to a common VPN must exchange certain information 48 as a prerequisite to establish VPN-specific connectivity. In 49 [RFC2547-bis], VPN-specific routes are exchanged, along with the 50 information needed to enable a PE to determine which routes belong 51 to which VPNs. In [VPN-VR], VR addresses must be exchanged, along 52 with the information needed to enable the PEs to determine which VRs 53 are in the same VPN ("membership"), and which of those VRs are to 54 have VPN connectivity ("topology"). Once the VRs are reachable 55 through the tunnels, routes ("reachability") are then exchanged by 56 running existing routing protocol per VPN basis. The purpose of this 57 draft is to define a common BGP based auto-discovery mechanism used 58 for both the virtual router [VPN-VR] and [RFC2547-bis] 59 architectures. Each scheme uses the mechanism to automatically 60 discover the information needed by that particular scheme. 61 Interworking scenarios between [RFC2547-bis] and the virtual router 62 models are also discussed. 64 1. Introduction 66 In any Network-Based VPN (NBVPN) scheme, the Provider Edge (PE) 67 routers attached to a common VPN must exchange certain information 68 as a prerequisite to establish VPN-specific connectivity. In 69 [RFC2547-bis], VPN-specific routes are exchanged, along with the 70 information needed to enable a PE to determine which routes belong 71 to which VPNs. In [VPN-VR], virtual router (VR) addresses must be 72 exchanged, along with the information needed to enable the PEs to 73 determine which VRs are in the same VPN ("membership"), and which of 74 those VRs are to have VPN connectivity ("topology"). Once the VRs 75 are reachable through the tunnels, routes ("reachability") are then 76 exchanged by running existing routing protocols per VPN basis. 78 The purpose of this draft is to define a common BGP based auto- 79 discovery mechanism used for both the virtual router [VPN-VR] and 80 [RFC2547-bis] architectures. Each scheme uses the mechanism to 81 automatically discover the information needed by that particular 82 scheme. The BGP multiprotocol extension attributes are used to carry 83 either the virtual router or the RFC2547 auto-discovery information. 84 Interworking scenarios between [RFC2547-bis] and the virtual router 85 models are also discussed. 87 2. Network Based VPNs Reference Model 88 Both the virtual router and [RFC2547-bis] architectures are using a 89 network reference model as illustrated in figure 1. 91 PE PE 92 +--------------+ +--------------+ 93 +--------+ | +----------+ | | +----------+ | +--------+ 94 | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | 95 | Sites |--| |Database /| | BGP route | | Database/| |-| sites | 96 +--------+ | |Processing| |<----------->| |Processing| | +--------+ 97 | +----------+ | Distribution| +----------+ | 98 | | | | 99 +--------+ | +----------+ | | +----------+ | +--------+ 100 | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | 101 | Sites |--| |Database /| |-(Backbones)-| | Database/| |-| sites | 102 +--------+ | |Processing| | -------- | |Processing| | +--------+ 103 | +----------+ | | +----------+ | 104 | | | | 105 +--------+ | +----------+ | | +----------+ | +--------+ 106 | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | 107 | Sites |--| |Database /| | | | Database/| |-| sites | 108 +--------+ | |Processing| | | |Processing| | +--------+ 109 | +----------+ | | +----------+ | 110 +--------------+ +--------------+ 112 Figure 1: Network based VPN Reference Model 114 It is assumed that the PE routers can use BGP to distribute 115 information to each other. This may be via direct IBGP peering, via 116 direct EBGP peering, via multihop BGP peering, through 117 intermediaries such as Route Reflectors, through a chain of 118 intermediate BGP connections, etc. It is assumed also that the PE 119 knows what architecture it is supporting (either the virtual router, 120 or [RFC2547-bis] architectures, or both). 122 3. Carrying VPN information in BGP Multi-Protocol Extension Attributes 124 The BGP-4 multiprotocol extensions are used to carry various 125 information about VPNs for both architectures. This is done as 126 follows. The NLRI is a VPN-IP address or a labeled VPN-IP address. 127 VPN-specific information associated with the NLRI is encoded either 128 as attributes of the NLRI, or as part of the NLRI itself, or both. 130 The address prefix in the NLRI field is ALWAYS within the VPN 131 address space, and therefore MUST be unique within the VPN. The 132 address specified in the BGP next hop attribute, on the other hand, 133 is in the service provider addressing space. 135 In the case of the virtual router, the NLRI address prefix is an 136 address of one of the virtual routers configured on the PE. Thus 137 this mechanism allows the virtual routers to discover each other, to 138 set up adjacencies and tunnels to each other, etc. In the case of 139 [RFC2547-bis], the NLRI prefix represents a route to an arbitrary 140 system or set of systems within the VPN. 142 4. Interpretation of VPN Information in the [RFC2547-bis] model 144 The [RFC2547-bis] model interprets the NLRI reachability 145 information. The BGP attributes (in particular, the Route Target 146 Extended Community) are used by the PE routers to assign the routes 147 to particular VPN database/processing contexts, and hence implicitly 148 determine the topology. The BGP Next Hop attribute specifies the 149 remote end point of the tunnel to be used when sending packets whose 150 destination addresses match the corresponding NLRI. For details, see 151 [RFC2547-bis]. 153 5. Interpretation of VPN Information in the [VPN-VR] model 155 5.1 Membership Discovery 157 The VPN-ID format as defined in [RFC-2685] is used to identify a 158 VPN. All virtual routers that are members of a specific VPN share 159 the same VPN-ID. A VPN-ID is carried in the NLRI in order to 160 associate a particular VR address to the VPN. 162 5.1.1 Encoding of the VPN-ID in the NLRI 164 For the virtual router model, the VPN-ID is carried within the route 165 distinguisher (RD) field. In order to hold the 7-bytes VPN-ID, the 166 first byte of RD type field is used to indicate the existence of the 167 VPN-ID format. A value of 0x80 in the first byte of RD's type field 168 indicates that the RD field is carrying the VPN-ID format. In this 169 case, the type field range 0x8000-0x80ff will be reserved for the 170 virtual router case. 172 5.1.2 VPN-ID Extended Community 174 A new extended community is used to carry the VPN-ID. The first byte 175 of the VPN-ID extended community will be used to indicate the 176 presence of the VPN-ID format. A value of 0x20 indicates that the 177 remaining 7 bytes following the first byte of the type field holds a 178 VPN-ID value. In this case an extended community with type field in 179 the range of 0x2000-0x20ff will be used exclusively for the virtual 180 router case. The BGP UPDATE message will carry information for a 181 single VPN (when used with a VPN-ID extended community). The use of 182 VPN-ID extended community allows a PE to perform route filtering per 183 VPN basis. 185 5.2 VPN Topology Information 187 A new extended community is used to indicate different VPN topology 188 values. A type 0x0020 represents the VPN topology field. The first 189 two bytes (of the remaining 6 bytes) are reserved. The actual 190 topology values are carried within the remaining four bytes. The 191 following topology values are defined: 193 Value Topology Type 195 1 "Hub" 196 2 "Spoke" 197 3 "Mesh" 199 Arbitrary values can also be used to allow specific topologies to be 200 constructed. VPN connectivity between two VRs within the same VPN is 201 achieved if and only if at least one of them is a hub (the other is 202 a hub or a spoke), or if both VRs are part of a full mesh VPN 203 topology. 205 5.3 Tunnel Discovery 207 Network-based VPNs must be implemented through some form of 208 tunneling mechanism, where the packet formats and/or the addressing 209 used within the VPN can be unrelated to that used to route the 210 tunneled packets across the backbone. There are numerous tunneling 211 mechanisms that can be used by a network based VPN (e.g., IP/IP 212 [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC-2401], and MPLS 213 tunnels [MPLS-ARCH]). Each of these tunnels allows for opaque 214 transport of frames as packet payload across the backbone, with 215 forwarding disjoint from the address fields of the encapsulated 216 packets. A provider edge router may terminate multiple type of 217 tunnels and forward packets between these tunnels and other network 218 interfaces in different ways. 220 BGP can be used to carry tunnel endpoint addresses between edge 221 routers. Depending on the type of tunneling mechanism used on a PE, 222 tunnel endpoint addresses can be used to establish either IPSec, IP 223 in IP, or GRE tunnels. 225 The BGP next hop will carry the service provider tunnel endpoint 226 address. As an example, if IPSec is used as tunneling mechanism, the 227 IPSec tunnel remote address will be discovered through BGP, and the 228 actual tunnel establishment is achieved through IPSec signaling 229 protocol. 231 When MPLS tunneling is used, a label carried in the NLRI will 232 indicate which VR can be reached through the address carried in the 233 NLRI. A single service provider tunnel endpoint address can be used 234 to reach multiple VRs (therefore multiple VPNs). 236 6. Virtual Router and [RFC2547-bis] Interworking Scenarios 238 Two interwoking scenarios are considered when the network is using 239 both virtual routers and [RFC2547-bis]. The first scenario is a CE- 240 PE relationship between a PE (implementing [RFC2547-bis]), and a VR 241 appearing as a CE to the PE. The connection between the VR, and the 242 PE can be either direct connectivity, or through a tunnel (e.g., 243 IPSec). 245 The second scenario is when a PE is implementing both architectures. 246 In this particular case, a single BGP session configured on the 247 service provider network can be used to advertise either [RFC2547- 248 bis] VPN information or the virtual router related VPN information. 249 From the VR and the [RFC2547-bis] point of view there is complete 250 separation from data path and addressing schemes. However the PE's 251 interfaces are shared between both architectures. 253 A PE implementing only [RFC2547-bis] will not import routes from a 254 BGP UPDATE message containing the VPN-ID extended community. On the 255 other hand, a PE implementing the virtual router architecture will 256 not import routes from a BGP UPDATE message containing the route 257 target extended community attribute. 259 The granularity at which the information is either [RFC2547-bis] 260 related or VR-related is per BGP UPDATE message. Different SAFI 261 numbers are used to indicate that the message carried in BGP 262 multiprotocol extension attributes is to be handled by the VR or 263 [RFC2547-bis] architectures. SAFI number of 128 is used for [RFC2547- 264 bis] related format. A value of 129 for the SAFI number is for the 265 virtual router (where the NLRI are carrying a labeled prefixes), and 266 a SAFI value of 140 is for non labeled addresses. 268 7. Use of BGP Capability Advertisement 270 A BGP speaker that uses VPN information as described in this 271 document with multiprotocol extensions should use the Capability 272 Advertisement procedures to determine whether the speaker could use 273 Multiprotocol Extensions with a particular peer. The Capability Code 274 field is set to 1 (which indicates Multiprotocol Extensions 275 capabilities). 277 8. Security Considerations 279 This draft does not introduce any new security considerations to 280 either [VPN-VR] or [RFC2547-bis]. 282 9. References 284 [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities 285 Attribute", February 2000, work in progress 287 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol 288 Extensions for BGP4", February 1998, RFC 2283 290 [BGP-MPLS] Rekhter Y, Rosen E., "Carrying Label Information in 291 BGP4", January 2000, work in progress 293 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label 294 Switching Architecture", August 1999, work in progress 296 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and 297 Conta, "MPLS Label Stack Encoding", October 1999,work in progress 299 [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic 300 Routing Encapsulation (GRE)", RFC 1701, October 1994. 302 [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 303 October 1996. 305 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 306 3", RFC2026, October 1996. 308 [RFC-2401] Kent S., Atkinson R., "Security Architecture for the 309 Internet Protocol", RFC2401, November 1998. 311 [RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", RFC 2119, March 1997. 314 [RFC2547-bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. 316 [RFC-2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 317 2685, September 1999. 319 [VPN-VR] Ould-Brahim H., et al., "Network based IP VPN Architecture 320 using Virtual Routers", work in progress. 322 [VPN-BGP] Ould-Brahim H., et al., "BGP/VPN: VPN Information 323 Discovery for Network-based VPNs", work in progress. 325 10. Acknowledgments 327 to be supplied. 329 11. Author's Addresses 331 Hamid Ould-Brahim 332 Nortel Networks 333 P O Box 3511 Station C 334 Ottawa, ON K1Y 4H7, Canada 335 Email: hbrahim@nortelnetworks.com 336 Phone: +1 613 765 3418 338 Bryan Gleeson 339 Nortel Networks 340 2305 Mission College Blvd 341 Santa Clara CA 95054 342 Phone: +1 (505) 565 2625 343 Email: bgleeson@shastanets.com 345 Peter Ashwood-Smith 346 Nortel Networks 347 P.O. Box 3511 Station C, 348 Ottawa, ON K1Y 4H7, Canada 349 Phone: +1 613 763 4534 350 Email: petera@nortelnetworks.com 352 Eric C. Rosen 353 Cisco Systems, Inc. 354 250 Apollo drive 355 Chelmsford, MA, 01824 356 E-mail: erosen@cisco.com 358 Yakov Rekhter 359 Juniper Networks 360 1194 N. Mathilda Avenue 361 Sunnyvale, CA 94089 362 Email: yakov@juniper.net 364 Luyuan Fang 365 AT&T 367 200 Laurel Avenue 368 Middletown, NJ 07748 369 Email: Luyuanfang@att.com 371 draft-ouldbrahim-bgpvpn-auto-01.txt September 2001 373 Phone: +1 (732) 420 1920 375 Jeremy De Clercq 376 Alcatel 377 Francis Wellesplein 1 378 B-2018 Antwerpen, Belgium 379 Phone: +32 3 240 47 52 380 Email: jeremy.de_clercq@alcatel.be 382 draft-ouldbrahim-bgpvpn-auto-01.txt September 2001 384 Full Copyright Statement 386 Copyright (C) The Internet Society (date). All Rights Reserved. This 387 document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published 390 and distributed, in whole or in part, without restriction of any 391 kind, provided that the above copyright notice and this paragraph 392 are included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns.