idnits 2.17.00 (12 Aug 2021) /tmp/idnits43752/draft-nagarajan-ppvpn-vrbased-applicability-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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 9) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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. ** There are 24 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 146 has weird spacing: '...mber of these...' == Line 249 has weird spacing: '...ts from custo...' -- 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 2002) is 7279 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-2026' is mentioned on line 23, but not defined == Unused Reference: 'RFC2764' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 555, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPNVR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASGUIDE' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRAMEWORK' -- Possible downref: Non-RFC (?) normative reference: ref. 'REQTS' ** Downref: Normative reference to an Informational RFC: RFC 2764 -- Possible downref: Non-RFC (?) normative reference: ref. 'COREVPN' ** Obsolete normative reference: RFC 2547 (Obsoleted by RFC 4364) -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-BGP' Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Provider Provisioned VPN WG Ananth Nagarajan 3 Internet Draft Sprint 4 draft-nagarajan-ppvpn-vrbased-applicability-01.txt 5 Expiration Date: December 2002 Junichi Sumimoto 6 Muneyoshi Suzuki 7 NTT Corporation 9 Paul Knight 10 Nortel Networks 12 Benson Schliesser 13 SAVVIS Communications 15 June 2002 17 Applicability Statement for Virtual Router-based Layer 3 PPVPN approaches 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC 2026 ([RFC-2026]). 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This document is submitted to the IETF's Provider Provisioned Virtual 40 Private Network (ppvpn) working group. Comments should be addressed 41 to WG's mailing list at ppvpn@ppvpn.francetelecom.com. The charter 42 may be found at http://www.ietf.org/html.charters/ppvpn-charter.html 44 Copyright (C) The Internet Society (2000). All Rights Reserved. 45 Distribution of this memo is unlimited. 47 Abstract 49 This document is an applicability statement for Layer 3 Provider 50 Provisioned VPNs (L3 PPVPNs) that is based on Virtual Router (VR) 51 approaches. This document describes how VR-based approaches meet 52 the key requirements that are outlined in the PPVPN Applicability 53 Statements Guideline document. 55 1. Summary for Sub-IP area 57 This document is an output of the design team formed to develop 58 applicability statements for Layer 3 PPVPNs in the PPVPN working 59 group. As such this work fits within the scope of the PPVPN 60 working group. This document discusses the applicability of 61 virtual router-based approaches for Layer 3 PPVPNs. 63 2. Introduction 65 The virtual router concept for L3 PPVPNs was first introduced in 66 [COREVPN]. This was generalized in [PPVPNVR]. A number of 67 autodiscovery mechanisms can be used with this approach to L3 PPVPNs, 68 and [COREVPN] represents one such approach using IP multicast. Based 69 on the taxonomy of PPVPNs described in [FRAMEWORK], Virtual Router 70 based approaches are classified as PE-based Layer 3 PPVPNs. 72 VR-based PPVPNs are used in the following situations: 74 - The customer wishes to outsource the maintenance and management of 75 inter-site VPN connectivity to the Service Provider (SP). 77 - The SP desires to provide VPN service without upgrading its core 78 network to support any specific technology (e.g., MPLS), i.e., the SP 79 can provide a Layer 3 VPN service over an existing IP routed or Layer 80 2 switched core network. 82 - The customer is not aware of the topology or mechanisms used in the 83 SP core network and is responsible for routing between customer 84 routers, which is independent of the routing used in the SP core. 85 Only the customer-facing sides of the PE devices in the SP network 86 are visible to the customer. 88 - The customer primarily sends IP traffic across the VPN, but may 89 also send non-IP traffic, provided these traffic types are supported 90 by the tunneling technologies used. It should be noted that the 91 support of Layer 2 VPNs using VR-based mechanisms is outside the 92 scope of this document. 94 This document describes how Virtual Router based approaches satisfy 95 key requirements and metrics identified in the PPVPN Applicability 96 Statements Guideline document [ASGUIDE]. These requirements are a 97 subset of the requirements listed in the PPVPN Service Requirements 98 document [REQTS]. This document is based on the guidelines 99 specified in [ASGUIDE]. 101 3. SP Provisioning Model 103 Virtual Routers (VR) have similar properties to physical routers, 104 except that they are instantiated on a single PE device. VPNs are 105 constructed via tunnels connecting VR pairs across the service 106 provider backbone network. Per-VR routing protocol instantiations 107 are run to distribute VPN reachability information. VPN membership 108 information distribution is treated separately, and is achieved via 109 sharing a VPN-ID, for example [RFC2685], between VRs that are members 110 of a specific VPN. This separation of reachability and membership 111 distribution functions is one of the key differences between the VR 112 model and the "piggy-backing" models such as [RFC2547bis]. In 113 [RFC2547bis], both reachability and membership information is 114 distributed via BGP extensions between PE devices, on a per-VPN 115 basis. The detailed VR model is described in [PPVPNVR]. 117 3.1. Auto Discovery 119 In the VR-based PPVPNS, various auto discovery mechanisms are 120 supported. VPN discovery can be achieved through directory servers, 121 explicit configuration via a management platform, using multicast 122 [COREVPN] or by piggybacking VPN membership and topology information 123 via routing protocols such as BGP [VPN-BGP]. A combination of these 124 mechanisms may also be used on a PE. For example, for some VPNs 125 topology discovery is done only through a management platform. For 126 others, dynamic topology discovery is achieved using existing routing 127 protocol. BGP-based auto-discovery is described in [VPN-BGP], and is 128 used for membership, toplogy and reachability discovery. 130 It is important to note that, for the VR architecture, the auto- 131 discovery mechanism is only used to automatically exchange control 132 VPN information between VRs. It is not intended for piggybacking VPN 133 private reachability information onto the backbone routing instance. 135 4. Supported Topology and Traffic Types 137 VR-based PPVPNs can be constructed using either MPLS tunnels in the 138 core network or IP tunnels (GRE, IP-in-IP, L2TP, IPSec), or Layer 2 139 connections such as ATM or Frame Relay. The choice of the tunneling 140 mechanism may impact other properties of the VPN itself, including 141 scalability, manageability, QoS, security etc. For example, the 142 use of IPSec tunnels for encryption may impact forwarding performance 143 as a result of sophisticated encryption mechanisms, and therefore 144 impact the number of routes per VPN, the number of VPNs per PE, etc. 145 Tunnels are created on a per-VPN basis. For transport across the 146 network, a number of these tunnels may be aggregated and carried 147 within a PE-PE tunnel. The topology of the VPN is not strictly defined. 148 It may be any arbitrary topology, including full-mesh, and arbitrary 149 partial-mesh. 151 5. Isolated exchange of routing and data information 153 By definition of a Virtual Private Network, the details of its 154 addressing, topology, connectivity, and reachability as well as the 155 data that it transports are implicitly considered to be private, and 156 should therefore be isolated from other networks, including others 157 that may be supported with the PPVPN infrastructure. [FRAMEWORK] 159 5.1. Isolation of routing information (constrained distribution of 160 reachability information) 162 In a PPVPN, routing is provisioned and managed by the SP, who is 163 responsible for maintaining isolation between networks except as 164 explicitly intended by the VPN owner. 166 The VR model of PPVPNs provides for isolation by instantiating 167 multiple Virtual Routers (VR) on a single physical platform to 168 support multiple VPNs. [PPVPNVR] Each VR has its own interfaces, 169 routing tables, forwarding tables, and routing protocol instances. 170 This provides for isolated topology, addressing, and reachability 171 for the VPN. 173 Addressing and Reachability includes the assignment, discovery, and 174 distribution of source and/or destination information for the PPVPN. 175 The isolation of this information implies that other networks, 176 including other VPNs and the Internet, will have no visibility into 177 the PPVPN except as explicitly configured. 179 Routing information carried between VRs is carried in the same 180 context/plane as data itself, and is therefore segregated from the 181 underlying backbone infrastructure by the same mechanisms that 182 segregate data between VPNs. 184 This model supports arbitrary routing architectures, including 185 support for back-door links or other potentially unique routing 186 architecture requirements. The support for arbitrary routing 187 architectures, however, is accompanied by scalability and 188 management issues. These issues are discussed later in this 189 document. 191 In the VR approach, virtual routers are connected to the CEs through 192 local links, and to each other across the backbone through tunneling 193 services provided by the service provider across the backbone. All 194 data traffic within the VR-based VPN is isolated from non-VPN traffic 195 by these mechanisms. 197 5.2. Isolation of data 199 Data for different VPNs in the VR model is segregated through the use 200 of different link-layer connections or tunnels over a common SP 201 backbone. [PPVPNVR] Examples of such tunnels include GRE, L2TP, 202 IPSec, MPLS or Layer 2 connections such as ATM or Frame Relay. It 203 should be noted that this isolation can be impacted by 204 misconfiguration. 206 6. Access Control and Authentication 208 CE-PE authentication has not been specified for VR-based VPNs and is 209 for further study. The customer must provide appropriate mechanisms 210 for CE-PE authentication. 212 In order for VR-based PPVPNs to support confidentiality, integrity, 213 authentication, and replay attack prevention, mechanisms such as 214 IPsec may be used as tunneling mechanism or used over VPN tunnels. 215 Even with the use of IPsec, the security level offered is dependent 216 on the scope of the IPsec security: encrypting on a CE-to-CE basis 217 (as in CE-based VPNs) will offer a higher level of protection than 218 encrypting on a PE-to-PE basis (as in PE-based VPNs). Policy-based 219 security and access control mechanisms or firewalls may be used 220 between sites in the same VPN. These can be implemented on the PE 221 router, or on the CE. 223 7. Security 225 7.1. Protection of user data 227 As described above, end-to-end (CE-to-CE) IPSec may be used to 228 protect user data. SPs may choose to provide CE-based IPSec as a 229 value added service. If the SP core network is also part of the 230 public Internet, the SP may choose to provide PE-to-PE IPSec as the 231 tunneling mechanism between VRs. 233 If inter-SP VPNs are to be provided, IPSec tunnels may be used. The 234 impact on QoS and SLAs in this case will have to be studied. 236 In general, user data is protected via the inherent isolation 237 provided by the inter-VR tunnels. Varying levels of security of user 238 data may be provided based on the type of tunnel that is used. 240 7.2. SP Security Measures 242 In general, the SP should ensure that non-VPN traffic does not 243 accidentally or maliciously enter a VPN. As such, the PE and P 244 devices should be protected against intrusion or denial of service 245 attacks. VR routing sessions must be authenticated. If BGP is used 246 as an auto- discovery mechanism between VRs, it should be further 247 authenticated using mechanisms such as TCP MD5. Filtering of data 248 entering the PE should be performed in order to prevent the 249 acceptance of unauthorized packets from customers or other SPs into 250 that PE. 252 8. Addressing 254 Virtual routers may provide any or all of the services which are 255 provided by a physical router, including Network Address Translation 256 (NAT), packet filtering, etc. These VR capabilities can simplify the 257 process of joining previously independent site networks, which may 258 have overlapping address spaces. NAT can be used to satisfy intra- 259 VPN non-unique addressing requirements. This facilitates the 260 construction of short-term or ad-hoc VPNS. It should be noted, 261 however, that NAT has accompanying scaling problems, and other 262 mechanisms are needed to ensure proper routing updates, when two 263 sites share the same routing domain. 265 Non-unique and private customer addresses may be supported by using 266 encapsulation within the tunneling mechanisms employed between VR 267 pairs (e.g., GRE, IP-in-IP etc.). As such, support for private 268 addressing as specified in [RFC1918] allows for non-unique addresses 269 between different VPNs. 271 9. Interoperability and Interworking 273 Interoperability and Interworking of VR-based VPNs with other L3 274 PPVPN mechanisms such as 2547bis is for further study. Since VRs 275 provide all IP router functionalities, various VR-based solutions 276 interwork and interoperate to the extent that IP networks 277 interoperate and interwork. 279 10. Network Access 281 10.1. Physical and Link Layer Topology 283 VR-based mechanisms do not affect the choice of physical and link 284 layer technologies or topologies. 286 10.2. Temporary Access 288 Temporary access for a dial-up user to a VR can be provided via PPP 289 and AAA, using a Remote Access Server. Other access mechanisms such 290 as IPSec can also be used. Thus, it is possible provide login and 291 password based access to a VR-based VPN from an authorized user 292 connected to the Internet. 294 10.3. Access Connectivity 296 Multi-homing of CEs to multiple VRs (within the same or different 297 PEs) is supported. The PEs (and consequently the VRs) may belong to 298 different SPs. In the case where multihoming of CEs is across 299 different SPs, care should be taken during traffic sharing across the 300 SPs. For example, traffic from a single ingress PE should not be 301 split in this case. 303 Load sharing based on IGP or other traffic engineering mechanisms 304 used in the SP core are naturally supported by VR-based VPNs. 306 11. Service Access 308 11.1. Internet Access 310 Simultaneous VPN and Internet Access can be supported via various 311 mechanisms. A specific VR may be assigned as a default VR that is 312 connected to the Internet. If a single VR is to be used to carry a 313 customer's VPN as well as Internet traffic, Internet traffic can be 314 distinguished from VPN traffic by associating a default VPN-ID with 315 Internet traffic and pointing it to a default route to the Internet. 316 This default route to the Internet need not be direct, but may 317 instead point to a firewall or other security device which may use 318 different interfaces for VPN access and Internet access. 320 11.2. Hosting, ASP, other services 322 All of the above "external" services can be supported by associating 323 a separate address for every service that is not being used within 324 the VPN. If a single server (for example, a web hosting server) is 325 used to provide a particular service to all VPNs, NAT may be used to 326 provide a unique address for clients to access that particular 327 service. NAT can be performed either at the customer site or can be 328 integrated into the PE. The scaling impacts of adding NAT to the PE 329 will have to be considered. 331 12. SP Routing 333 VR-based PPVPNs do not impose any additional requirements on the IGP 334 used in the service provider core network. However, the PE must 335 implement the IGP used in the customer VPN. The VR-based VPNs can use 336 the core routing protocols or may use different routing protocols 337 between VRs than the core network. 339 Fault handling is a specific problem when the timers used for the VR- 340 to-VR routing peering are shorter than the timers used for the 341 routing peering within the service provider(s) network. In this case 342 a single failure within a service provider network may look like a 343 collection of un-correlated failures in the VPN. 345 Moreover, since a VR doesn't really "know" what causes the failure, 346 the VR may react to such a failure by re-routing along some other 347 tunnel, while this other tunnel may be also affected by the same 348 failure. As a result, this would slow down routing convergence 349 within the VPN. 351 To avoid the problems mentioned above one may consider making the 352 timers used for the VR-to-VR peering longer than the timers used for 353 the routing peering within the service provider network (so that 354 failures within the service provider network would be "invisible" to 355 the VR-VR tunnels). But that has its own set of problems. While 356 this may be possible to accomplish within a single routing domain 357 (one needs to appropriately set the IGP timers within the domain), 358 doing this in a network that includes more than one routing domain 359 may be difficult (as timers include both IGP and BGP timers, and 360 moreover, timers include IGP timers in several routing domains). 361 Another consequence of making the timers used for the VR-to-VR 362 peering over the tunnels longer than the timers used for the routing 363 peering within the service provider network is that it would increase 364 the amount of traffic that will be "black holed" in the case of VR 365 failures. 367 12.1. Core router awareness of mechanisms used 369 Since tunnels are established between VR pairs, the core router (P 370 router) does not have any information of the mechanisms used to 371 construct the VPN. If MPLS is the tunneling mechanism that is used 372 between the VRs, the core routers may have to be MPLS enabled in 373 order to leverage the benefits of MPLS tunnels (e.g., traffic 374 engineering). As such, while the core routers are not aware of VPN- 375 specific information, they should support requirements to meet 376 relevant SLAs. (e.g., for guaranteed QoS, the core routers may need 377 to support appropriate QoS mechanisms). 379 13. Migration impacts 381 As VR approach makes use of standard routing protocols without any 382 extensions, any CE using the VR approach can access a PE similar to 383 the way it would access another CE router in a private network using 384 leased lines. Key design considerations include: 386 - The PEs will introduce extra router hops 388 - If the VR-VR backbone routing protocol differs from the sites, then 389 IGP metric implications should be carefully evaluated. This would be 390 particularly true for multihomed VPN sites. 392 Also, since the VR approach does not depend on the backbone 393 architecture in terms of routing protocols, a VR-based L3 PPVPN can 394 be offered on a service provider core network without the need for 395 specific core technologies. For example, the core network does not 396 need specific mechanisms like MPLS to be implemented on the P 397 routers. Similarly, if the core network is a Layer 2 network based 398 on ATM or Frame Relay, VR-based VPNs can still be constructed. 400 It should be noted, however, that core network mechanisms would 401 determine the overall properties and services that may be provided 402 over the VPN. For example, in order to support customer QoS SLAs, 403 the core network should be robustly engineered or should support QoS 404 mechanisms, in addition to SLA marking at the PE. 406 Thus, while migration impacts in the case of basic VPN functionality 407 using VR are minimal from the customers' or providers' point of view, 408 appropriate core mechanisms may be necessary for certain services. 410 14. Scalability 412 PE-based PPVPNs have better scalability than CE-based PPVPNs, because 413 the total number of VPN tunnels that need to be managed are far fewer 414 in the service provider backbone, than between CEs. Addition of a 415 new CE in a CE-based PPVPN would require O(N^2) tunnels to be set up 416 where N represents the total number of CEs. In comparison, addition 417 of a new CE for a specific customer, in the case of a PE-based PPVPN, 418 would simply require an additional connection between the new CE and 419 the PE, because inter-PE tunnels already exist per VPN. 421 VR is a technology for implementing logical routing instances in a PE 422 device. A PE device may contain more than one VR and a VR supports 423 one VPN. Therefore, scalability of a VR and conventional physical 424 router are basically the same, e.g., if different routing protocols 425 are used for customer and network sides of a VR or physical router, 426 the load is increased compared with the case when the same protocols 427 are used. However, the scalability depends on the theoretical limits 428 on address space, routing protocols, etc., within a single VPN. 430 The major factor contributing to scalability constraint in the VR 431 approach is the number of VRs which can be supported by a PE. This is 432 because, the number of VRs in a PE device is equal to the number of 433 VPNs which are supported by the PE. 435 Resources used by a VR instance include memory and processor 436 resources, used to support VPN tunnel mechanisms, routing protocol 437 instances, route tables, interface management, etc. The extent to 438 which these resources are utilized impact scalability. 440 Much of the resource utilization for a given VPN will be affected by 441 the topology of the VPN. For instance, a VPN with a full-mesh 442 topology will require that VRs have more peers for the VPN tunneling 443 mechanism, for routing protocol adjacencies, for security protocols, 444 and etc., while a hub-and-spoke model will constrain the resources 445 required for 'spoke' PE routers. 447 From a VR perspective, scalability also depends on whether the same 448 routing protocols are used between VRs as in the backbone network. 449 If the inter-VR routing protocols are different from the backbone IGP, 450 the scaling and management impacts for configuring routing protocols 451 on a per-VR basis may be significant. For example, it may be 452 necessary to maintain OSPF databases for the entire customer VPN 453 topology, as opposed to maintaining information for only directly 454 connected customer sites. Additionally, the customer IGP may need to 455 maintain information about the entire VR topology. Other concerns 456 include routing loop avoidance, route dedistribution, etc. Thus, 457 while the VR model allows separate routing protocols between 458 customers and between VRs than the backbone IGP, this flexibility is 459 accompanied by scalability concerns. Mechanisms such as OSPF areas 460 may be used to circumvent such scaling issues. 462 15. QoS/SLA 464 VR-based PPVPNs support any kind of QoS that the core network and the 465 tunneling mechanism used support. 467 QoS mechanisms developed for physical routers can be used with VRs, 468 on a per-VR basis. e.g., classification, policing, drop policies, 469 traffic shaping and scheduling/bandwidth reservation. The 470 architecture allows separate quality of service engineering of the 471 VPNs and the backbone. 473 VR-based VPNs can utilize different quality of service mechanisms. 474 QoS mechanisms developed for physical routers can be used with VRs, 475 on a per-VR basis. e.g. classification, policing, drop policies, 476 traffic shaping and scheduling/bandwidth reservation. The 477 architecture allows separate quality of service engineering of the 478 VPNs and the backbone. However, the tunneling mechanisms themselves 479 should support relevant QoS mechanisms. 481 15.1. SLA Monitoring 483 VR-based VPNs can implement a variety of methods to monitor 484 compliance with Service Level Agreements. Since the links between 485 VRs make use of tunnels across the underlying backbone network, the 486 SLA monitoring capabilities of the backbone network can be used to 487 monitor the performance of the inter-VR links. Performance to SLA 488 requirements within the PEs hosting the VRs is typically monitored 489 via internal processes to ensure compliance from end to end. In 490 addition, either the service provider or the VPN customer can use all 491 existing SLA tracking tools (round trip time measurement, traceroute 492 mapping, etc.) within the VR-based VPN. 494 16. Management 496 16.1. SP Management 498 [Note: This section will be completed in following versions of 499 this draft] 501 16.2. Customer Management 503 The SP may choose to manage the customer site (i.e., the CE devices) 504 for added revenue. If the SP uses a centralized customer management 505 system, care should be taken to uniquely identify various CEs 506 belonging to different VPNs, so that CE devices from different VPNs 507 do not reach each other. 509 The customer may desire to have access to the PE device for 510 monitoring purposes (e.g., ping, traceroute). Providing such access 511 is at the discretion of the SP. 513 Traffic statistics in order to prove SLAs to customers may be 514 provided on a periodic basis. Other statistics that can show 515 enhanced SP capabilities, including protection against Denial of 516 Service attacks, failure etc., can be provided to the customer. 518 17. Security considerations 520 There are no additional security considerations besides those 521 already addressed in the document. 523 18. Acknowledgments 525 The authors of this draft would like to acknowledge the suggestions 526 and comments received from the entire Layer 3 Applicability Statement 527 Design Team formed in the PPVPN working group. Besides the authors, 528 the members of the design team include Marco Carugi, Eric Rosen, 529 Jeremy De Clercq, Luyuan Fang, Dave McDysan, Cliff Wang, Olivier 530 Paridaens, Tom Nadeau, Yakov Rekhter and Rick Wilder. 532 19. REFERENCES 534 [PPVPNVR] Ould-Brahim, H., et al., "Network based IP VPN Architecture 535 using Virtual Routers", work in progress. 537 [ASGUIDE] Sumimoto, J., et al., "Guidelines of Applicability 538 Statements for PPVPNs," work in progress. 540 [FRAMEWORK] R. Callon, et al., "A Framework for Layer 3 Provider 541 Provisioned Virtual Private Networks," work in progress. 543 [REQTS] McDysan, D., et al., "Service requirements for Layer 3 544 Provider Provisioned Virtual Private Networks", work in progress. 546 [RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual 547 Private Networks", RFC 2764, February 2000. 549 [RFC1918] Rekhter, Y. et al., "Address Allocation for Private 550 Internets," RFC 1918, February 1996. 552 [RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 553 2685, September 1999. 555 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 556 3", RFC 2026, October 1996. 558 [COREVPN] Muthukrishnan, K., Malis, A., "Core MPLS IP VPN 559 Architecture", work in progress. 561 [RFC2547bis] Rosen E., et al, "BGP/MPLS VPNs", work in progress. 563 [VPN-BGP] Ould-Brahim, H., et al, "Using BGP as an Auto-Discovery 564 Mechanism for Network-based VPNs", work in progress. 566 20. Authors' Addresses 568 Ananth Nagarajan 569 Sprint 570 6220 Sprint Parkway 571 Overland Park, KS 66251 572 E-mail: ananth.nagarajan@mail.sprint.com 574 Muneyoshi Suzuki 575 Junichi Sumimoto 576 NTT Information Sharing Platform Labs. 577 3-9-11, Midori-cho, 578 Musashino-shi, Tokyo 180-8585, Japan 579 Email: suzuki.muneyoshi@lab.ntt.co.jp 580 Email: sumimoto.junichi@lab.ntt.co.jp 582 Paul Knight 583 Nortel Networks 584 600 Technology Park Drive 585 Billerica, MA 01821 586 E-mail: paknight@nortelnetworks.com 588 Benson Schliesser 589 SAVVIS Communications 590 717 Office Parkway 591 St. Louis, MO 63141 592 Phone: +1-314-468-7036 593 Email: bensons@savvis.net 595 21. Full Copyright Statement 597 Copyright (C) The Internet Society (2002). All Rights Reserved. 599 This document and translations of it may be copied and furnished to 600 others, and derivative works that comment on or otherwise explain it 601 or assist in its implementation may be prepared, copied, published 602 and distributed, in whole or in part, without restriction of any 603 kind, provided that the above copyright notice and this paragraph are 604 included on all such copies and derivative works. However, this 605 document itself may not be modified in any way, such as by removing 606 the copyright notice or references to the Internet Society or other 607 Internet organizations, except as needed for the purpose of 608 developing Internet standards in which case the procedures for 609 copyrights defined in the Internet Standards process must be 610 followed, or as required to translate it into languages other than 611 English. 613 The limited permissions granted above are perpetual and will not be 614 revoked by the Internet Society or its successors or assigns. 616 This document and the information contained herein is provided on an 617 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 618 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 619 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 620 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 621 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.