idnits 2.17.00 (12 Aug 2021) /tmp/idnits20467/draft-guichard-pe-ce-addr-03.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There is 1 instance of lines with non-ascii characters in the document. == 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 1) being 473 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 ([L3VPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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-2119' is mentioned on line 60, but not defined -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'L3VPN' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Jim Guichard, Editor 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: January, 2004 7 Document: draft-guichard-pe-ce-addr-03.txt July, 2003 9 Address Allocation for PE-CE links within a Provider Provisioned VPN 10 Network 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 Working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document proposes to allocate a block of globally unique IPv4 33 addresses for the exclusive use of Service Providers that provide 34 [L3VPN] based Services. The Service Provider may use these addresses 35 for the provisioning of IP addresses to the links that connect 36 Customer Edge (CE) routers with Provider Edge (PE) routers (PE-CE 37 links), and/or for the IP addressing of attached CE routers. 39 The main motivation for this proposal is to simplify the Service 40 Providers' operations in the scenario where they monitor PE-CE links, 41 and/or CE-routers, while at the same time conserving IPv4 address 42 space. 44 This addressing scheme is not intended for use by VPNs that span 45 more than one Service Provider, unless co-operation of addressing 46 structure is maintained to ensure uniqueness of addresses between 47 providers. Furthermore, although the main reference within this draft 48 is related to services provided by [L3VPN], the recommendations 50 Guichard, et. al 1 52 formulated herein may also apply to other Layer-2 or Layer-3 VPN 53 architectures. 55 1. Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in [RFC-2119]. 61 2. Contributing Authors 63 This document was the collective work of several. The editor, and co- 64 authors listed below, contributed the text and content of this 65 document. 67 Monique Morrow Cisco Systems Inc 68 Jeff Apcar Cisco Systems Inc 69 Jean Philippe Vasseur Cisco Systems Inc 70 Yakov Rekhter Juniper Networks Inc 71 Xavier Vinet EQUANT 72 Vincent Parfait EQUANT 73 Y. Reina Wang AT&T Labs 74 Fang, Luyuan AT&T Labs 75 Dr. Thomas Kuehne Arcor AG & Co 76 Lars Braeunig Arcor AG & Co 78 3. Motivation for an Additional IP Address Allocation Scheme 80 The [L3VPN] architecture provides a very flexible model for the 81 deployment of layer-3 based VPN services. The customer interface to 82 these services is typically via a CE router, and the Service Provider 83 may manage this router, or it may be under the control of the 84 attached customer. 86 The emergence of VPN services based on the [L3VPN] architecture, and 87 the significant experience gained from the deployment of these 88 services, has prompted the need for an additional IP address 89 allocation scheme. The primary use for this scheme would be the IP 90 address assignment of the links that connect CE routers with PE 91 routers (PE-CE links), and/or the IP address assignment of the CE 92 routers. 94 The need for this scheme is driven by the explosion of [L3VPN] based 95 services, each with many thousands of CE end-points, and a continuing 96 trend for the migration of existing VPN customers to this service. 98 When the Service Provider manages the CE router, it is typical for 99 the Service Provider to monitor this router from a central 100 management location that is within the Service Provider's premises. 101 The management of the CE router is useful for a number of reasons 102 including troubleshooting, statistics collection for SLA reporting, 104 Guichard et. al 2 106 configuration and so on. Using such a centralized monitoring policy 107 means that the Service Provider has to address each CE router with a 108 unique IP address so that they are able to identify each CE router 109 without any conflict with other CEs/VPNs. 111 Even when the Service Provider does not manage the CE router, but 112 just monitors PE-CE links from a central management location, it 113 still requires that the addresses assigned to all such links have to 114 be unique across all the links of all the VPNs provided by the 115 Service Provider. 117 Regardless of whether the [L3VPN] service is managed or not, there 118 are various approaches currently available to the Service Provider 119 when allocating IP addresses. There are various advantages and 120 disadvantages associated with each of these approaches, each of which 121 is explored in the following sections. 123 From the list of approaches, the most attractive one is discussed in 124 section 3.3 (where PE-CE links are numbered from the address space of 125 the Service Provider registered block). However, the major drawback 126 of this approach is that it results in consuming potentially a (very) 127 large amount of IPv4 address space that would not be used for the 128 purpose of connecting to the Internet. The proposal described in this 129 document aims at preserving most of the benefits of the model 130 described in section 3.3, while at the same time eliminating its 131 major drawbacks. 133 3.1. Address space from [RFC-1918] for PE-CE links 135 Pros: There is no requirement for Service Provider registered 136 addresses, which means that there is no need for the Service Provider 137 to obtain these addresses from one of the addressing registries. 139 Cons: This relies on case-by-case discussions with all customers who 140 use [RFC-1918] addresses to negotiate a target pool of [RFC-1918] 141 addresses for monitoring needs, which is very time-consuming and 142 intensive in terms of addressing management. Also, this approach is 143 not always possible with very large customers, due to the number of 144 [RFC-1918] addresses being used within the customers network. 146 3.2. Address space taken from the customer address block 148 Pros: There is no requirement for the Service Provider to use 149 registered addresses, and the customer is responsible for the 150 addressing plan. No need for the Service Provider to obtain these 151 addresses from one of the addressing registries. 153 Cons: Requires co-ordination of addressing plan between the Service 154 Provider and the customer. May be problematic if the customers' 155 addresses are from the [RFC-1918] range and the Service Provider has 156 also used [RFC-1918] address space, as there is the potential for an 158 Guichard et. al 3 160 address overlap between the Service Provider and the customer address 161 space. Also, if the Service Provider manages CE-PE links, then this 162 option requires the NMS used by the provider to deal with non-unique 163 addresses. 165 3.3. Address space from Service Provider registered block 167 Pros: Does not require any coordination with customer IP address 168 allocation, as no address conflict is likely. Addresses used for PE- 169 CE links are unique across all the PE-CE links for all the VPNs 170 supported by the Service Provider. Furthermore, each CE router is 171 guaranteed to have a unique address for management purposes. 173 Cons: The Service Provider has to obtain these addresses from one of 174 the addressing registries. This is a waste of globally unique 175 addresses for private usage. A separate /30 or /31 subnet is required 176 for each PE-CE connection, and/or a /32 for each CE router, which 177 results in a very high number of wasted addresses, especially when 178 there are VPNs with thousands of sites. 180 In order to save the number of required IP addresses, some specific 181 allocation techniques have been tentatively deployed by Service 182 Providers. However, the various solutions still present some 183 challenges as detailed in the following sections. 185 3.3.1. Unnumbered addressing for PE-CE links 187 Pros: Conservation of IP addresses. Only 1 IP address is required for 188 each PE-CE link instead of a /30 or /31 subnet. 190 Cons: Undesirable for Network Management purposes, as the network 191 management stations do not capture the management view of the PE-CE 192 links. This means that a separate network management loopback 193 interface is needed for each CE router. A further disadvantage is the 194 requirement for an additional loopback interface on the PE router for 195 each VRF, which may be taken from the Service Providers registered 196 address block, or from the customer address block, or from the [RFC- 197 1918] address block. In either case, the same set of pros and cons 198 apply, and the use of unnumbered links is not a long-term solution 199 for the conservation of address space due to the additional loopback 200 requirement at the CE routers. 202 3.3.2. Unique address block used for ALL VPNs 204 Pros: Address space can be saved as the same address block is used on 205 the PE-CE links of ALL VPNs. 207 Cons: Potential for address conflict when merging one VPN with 208 another as the same addresses may be used on the PE-CE links. Also, 209 if the Service Provider manages CE-PE links, then this option 211 Guichard et. al 4 213 requires NMS used by the provider to deal with non-unique addresses. 214 If these addresses are used for the CE routers also then an address 215 conflict may occur. 217 3.3.3. Unique address block used for ALL PE routers 219 Pros: Address space can be saved as the same address block is used 220 for each PE router in the network. This address block is used to 221 number all the CE-PE links of that PE router, irrespective of whether 222 these links belong to the same or different VPNs. 224 Cons: Potential for address conflict as two PE-CE links belonging to 225 the same VPN but attached to two different PE routers may have the 226 same /30 or /31 subnet assigned. Also, if the Service Provider 227 manages CE-PE links, then this option requires NMS used by the 228 provider to deal with non-unique addresses. If these addresses are 229 used for the CE routers also then an address conflict may occur. 231 4. Proposal 233 This document defines a /12 IPv4 address block that a Service 234 Provider could use for PE-CE addressing, CE router addressing, and/or 235 for local value-added services. The size of the IPv4 address block 236 has been determined through analysis of existing [L3VPN] deployments 237 and by tracking the continued trend for the migration of existing VPN 238 customers onto this service. 240 The results of this analysis have shown: 242 (1) assigning a /8 address block would provide a long term solution 243 with a lower risk of address conflicts between Service 244 Providers. However, there is no evidence at this time to suggest 245 a need for managing millions of PE-CE links and therefore a /8 246 is considered too large for the purposes laid out in this 247 proposal. 248 (2) At a time when large Service Providers have already connected in 249 excess of 40,000 CE endpoints, allocating a /16 which allows for 250 ~16,000 connections would clearly not be sufficient 252 Continuing with the aim of saving IPv4 address space, the proposed 253 approach is to request an address block to suit medium term needs, 254 and to issue a request for a new block when and if this becomes a 255 requirement. In this context a /12 appears to be a consensual choice. 257 5. Operational Considerations 259 Reserved addresses for [L3VPN] based services facilitate address 260 uniqueness for Service Providers within their own administrative 262 Guichard et. al 5 264 domain. The uniqueness of addresses is guaranteed even if the 265 Service Provider network consists of multiple Autonomous Systems. 267 Overlapping of these reserved addresses between Service Providers may 268 cause problems if a VPN client site CE router connects to two 269 different Service Provider PE routers, and the addresses used on the 270 PE-CE links are the same. 272 Private addressing [RFC-1918] is still available for use within a 273 Service Provider and customer environment. However, the most 274 important benefit of a dedicated address block for PE-CE connections, 275 CE router management, and local value-added services, is the 276 guarantee against address overlap between Service Provider and 277 customer address spaces, as well as the guarantee that all PE-CE 278 numbered links and CE routers will have addresses that are unique 279 within a Service Provider. This benefit impacts the service cost for 280 preventing address overlap and reduces the complexity in doing so. 282 For Service Providers who offer managed customer PE-CE connectivity, 283 this proposal facilitates Service Provider NMS operations by 284 guaranteeing unique addressing for the managed service thus 285 minimizing provisioning complexity attributed to administering non- 286 unique address space. This factor is a key benefit to Service 287 Providers who are developing and deploying managed [L3VPN] services. 288 One specific example of the benefit is that the Service Provider only 289 requires a single Management VPN (the Service Provider can import to 290 the management VPN the PE-CE address and CE router address blocks 291 using a route-map), the number of management workstations (or 292 instances of) is greatly reduced as there is no overlap. 294 6. Security Considerations 296 Security issues are not addressed in this memo. 298 7. IANA Considerations 300 IANA should allocate a /12 address block for sole use by [L3VPN] 301 Service Providers. The actual address block assignment is TBD. 303 8. References 305 [L3VPN], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- 306 rfc2547bis-01, July, 2002. 308 [RFC-1918], Rekhter, Y. et al. "Address Allocation for Private 309 Internets", RFC 1918, February 1996. 311 9. Authors' Address: 313 Guichard et. al 6 315 Jim Guichard 316 Cisco Systems, Inc. 317 300 Apollo Drive 318 Chelmsford, MA, 01824 319 Email: jguichar@cisco.com 321 Monique Jeanne Morrow 322 Cisco Systems, Inc. 323 Glatt-Com 324 CH-8301, Glattzentrum, Switzerland 325 Email: mmorrow@cisco.com 327 Jeff Apcar 328 Cisco Systems, Inc 329 201 Pacific Highway 330 St Leonards, NSW 2068 331 Australia 332 Email: japcar@cisco.com 334 JP Vasseur 335 Cisco Systems, Inc. 336 300 Apollo Drive 337 Chelmsford, MA, 01824 338 Email: jpv@cisco.com 340 Yakov Rekhter 341 Juniper Networks, Inc. 342 1194 N. Mathilda Ave. 343 Sunnyvale, CA 94089 344 Email: yakov@juniper.net 346 Xavier VINET 347 EQUANT 348 9 rue du Chˆne Germain - BP 80 349 35512 Cesson Sevigne cedex 350 FRANCE 351 Email: xavier.vinet@equant.com 353 Vincent Parfait 354 EQUANT 355 1041 route des Dolines - BP 347 356 06906 Sophia Antipolis Cedex 357 FRANCE 358 Email: Vincent.Parfait@equant.com 360 Y. Reina Wang 361 AT&T Labs 362 200 Laurel Ave 363 Middletown, NJ 07748 364 USA 366 Guichard et. al 7 368 Email: reinawang@att.com 370 Luyuan Fang 371 AT&T Labs 372 200 Laurel Avenue 373 Middletown, NJ 07748 374 USA 375 Email: luyuanfang@att.com 377 Dr. Thomas Kuehne 378 Arcor AG & Co. 379 Alfred-Herrhausen-Allee 1 380 65760 Eschborn 381 GERMANY 382 Email: thomas.kuehne@arcor.net 384 Lars Braeunig 385 Arcor AG & Co. 386 Alfred-Herrhausen-Allee 1 387 65760 Eschborn 388 GERMANY 389 Email: lars.Braeunig@arcor.net 391 Guichard et. al 8