idnits 2.17.1 draft-ietf-l3vpn-generic-reqts-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 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.) ** There are 18 instances of too long lines in the document, the longest one being 8 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 44 has weird spacing: '... are to be in...' == Line 145 has weird spacing: '...traffic manag...' == Line 147 has weird spacing: '...service provi...' == Line 152 has weird spacing: '...ey need to be...' == Line 156 has weird spacing: '...nternet routi...' == (3 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2004) is 7375 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-2026' is mentioned on line 15, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 45, but not defined == Missing Reference: 'L3 FRAMEWORK' is mentioned on line 306, but not defined == Missing Reference: 'RFC3198' is mentioned on line 589, but not defined == Missing Reference: 'VPN-SEC' is mentioned on line 989, but not defined == Unused Reference: 'RFC2026' is defined on line 1045, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 1047, but no explicit reference was found in the text == Unused Reference: 'L3FRAMEWORK' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC 3198' is defined on line 1072, but no explicit reference was found in the text Summary: 3 errors (**), 0 flaws (~~), 19 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Ananth Nagarajan 3 Expiration Date: August 2004 Juniper Networks 4 Category: Informational (Editor) 5 February 2004 7 Generic Requirements for Provider Provisioned Virtual 8 Private Networks 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of [RFC-2026]. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. Internet- 19 Drafts are draft documents valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 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 describes generic requirements for Provider Provisioned 33 Virtual Private Networks (PPVPN). The requirements are categorized into 34 service requirements, provider requirements and engineering 35 requirements. These requirements are not specific to any particular 36 type of PPVPN technology, but rather apply to all PPVPN technologies. 37 All PPVPN technologies are expected to meet the umbrella set of 38 requirements described in this document. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 43 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in [RFC-2119]. 46 Table of Contents 48 1. Introduction .................................... 3 49 1.1. Problem Statement ............................... 3 50 1.2. Deployment Scenarios ............................ 4 51 1.3. Outline of this document ........................ 5 52 2. Contributing Authors ............................ 6 53 3. Definitions and Taxonomy ........................ 7 54 4. Service Requirements ............................ 8 55 4.1. Availability .................................... 8 56 4.2. Stability ....................................... 9 57 4.3. Traffic types ................................... 9 58 4.4. Data Isolation .................................. 9 59 4.5. Security ........................................ 10 60 4.5.1. User data security .............................. 10 61 4.5.2. Access Control .................................. 10 62 4.5.3. Site authentication and authorization ........... 11 63 4.5.4. Inter domain security ........................... 11 64 4.6. Topology ........................................ 11 65 4.7. Addressing ...................................... 12 66 4.8. Quality of Service .............................. 12 67 4.9. Service Level Agreement and Service Level 68 Specification Monitoring and Reporting .......... 13 69 4.10. Network Resource Partitioning and Sharing 70 between VPNs .................................... 14 71 5. Provider requirements ........................... 15 72 5.1. Scalability ..................................... 15 73 5.1.1. Service Provider Capacity Sizing Projections .... 15 74 5.1.2. VPN Scalability aspects ......................... 16 75 5.1.3. Solution-Specific Metrics ....................... 18 76 5.2. Management ...................................... 19 77 5.2.1. Customer Management of a VPN .................... 19 78 6. Engineering requirements ........................ 20 79 6.1. Forwarding plane requirements ................... 20 80 6.2. Control plane requirements ...................... 21 81 6.3. Control Plane Containment ....................... 22 82 6.4. Requirements related to commonality of PPVPN 83 mechanisms with each other and with generic 84 Internet mechanisms ............................. 22 85 6.5. Interoperability ................................ 22 86 7. Security Considerations ......................... 23 87 8. References ...................................... 25 88 8.1. Normative References ............................ 25 89 8.2. Informative References .......................... 25 90 9. Acknowledgements ................................ 26 91 10. Editor's Address ................................ 26 92 11. Full Copyright Statement ........................ 26 94 1. Introduction 96 This document is an output of the design team formed to develop 97 requirements for PPVPNs in the Provider Provisioned Virtual Private 98 Networks (PPVPN) working group and provides requirements that are 99 generic to both Layer 2 Virtual Private Networks (L2VPN) and Layer 3 100 Virtual Private Networks (L3VPN). This document discusses generic 101 PPVPN requirements categorized as service, provider and engineering 102 requirements. These are independent of any particular type of PPVPN 103 technology. In other words, all PPVPN technologies are expected to 104 meet the umbrella set of requirements described in this document. 105 PPVPNs may be constructed across single or multiple provider networks 106 and/or Autonomous Systems (ASes). In most cases the generic 107 requirements described in this document are independent of the 108 deployment scenario. However, specific requirements that differ based 109 on whether the PPVPN is deployed across single or multiple providers 110 (and/or ASes) will be pointed out in the document. Specific 111 requirements related to Layer 3 PPVPNs are described in [L3REQTS]. 112 Similarly, requirements that are specific to layer 2 PPVPNs are 113 described in [L2REQTS]. 115 1.1. Problem Statement 117 Corporations and other organizations have become increasingly 118 dependent on their networks for telecommunications and data 119 communication. The data communication networks were originally built 120 as Local Area Networks (LAN). Over time the possibility to 121 interconnect the networks on different sites has become more and more 122 important. The connectivity for corporate networks has been supplied 123 by service providers, mainly as Frame Relay (FR) or Asynchronous 124 Transfer Mode (ATM) connections, and more recently as Ethernet and 125 IP-based tunnels. This type of network, interconnecting a number of 126 sites over a shared network infrastructure is called Virtual Private 127 Network (VPN). If the sites belong to the same organization, the VPN 128 is called an Intranet. If the sites belong to different 129 organizations that share a common interest, the VPN is called an 130 Extranet. 132 Customers are looking for service providers to deliver data and 133 telecom connectivity over one or more shared networks, with service 134 level assurances in the form of security, QoS and other parameters. 136 In order to provide isolation between the traffic belonging to 137 different customers, mechanisms such as Layer 2 connections or Layer 138 2/3 tunnels are necessary. When the shared infrastructure is an IP 139 network, the tunneling technologies that are typically used are 140 IPsec, MPLS, L2TP, GRE, IP-in-IP etc. 142 Traditional Internet VPNs have been based on IPsec to provide 143 security over the Internet. Service providers are now beginning to 144 deploy enhanced VPN services that provide features such as service 145 differentiation, traffic management, Layer 2 and Layer 3 146 connectivity, etc. in addition to security. Newer tunneling 147 mechanisms have certain features that allow the service providers to 148 provide these enhanced VPN services. 150 The VPN solutions we define now MUST be able to accommodate the 151 traditional types of VPNs as well as the enhanced services now being 152 deployed. They need to be able to run in a single service provider's 153 network, as well as between a set of service providers and across the 154 Internet. In doing so the VPNs SHOULD NOT be allowed to violate basic 155 Internet design principles or overload the Internet core routers or 156 accelerate the growths of the Internet routing tables. Specifically, 157 Internet core routers SHALL NOT be required to maintain VPN-related 158 information, regardless of whether the Internet routing protocols are 159 used to distribute this information or not. In order to achieve this, 160 the mechanisms used to develop various PPVPN solutions SHALL be as 161 common as possible with generic Internet infrastructure mechanisms 162 like discovery, signaling, routing and management. At the same time, 163 existing Internet infrastructure mechanisms SHALL NOT be overloaded. 165 Another generic requirement from a standardization perspective is to 166 limit the number of different solution approaches. For example, for 167 service providers that need to support multiple types of VPN 168 services, it may be undesirable to require a completely different 169 solution approach for each type of VPN service. 171 1.2. Deployment Scenarios 173 There are three different deployment scenarios that need to be 174 considered for PPVPN services: 176 1. Single-provider, single-AS: This is the least complex scenario, 177 where the PPVPN service is offered across a single service provider 178 network spanning a single Autonomous System. 180 2. Single-provider, multi-AS: In this scenario, a single provider may 181 have multiple Autonomous Systems (for e.g., a global Tier-1 ISP with 182 different ASes depending on the global location, or an ISP that has 183 been created by mergers and acquisitions of multiple networks). This 184 scenario involves the constrained distribution of routing information 185 across multiple Autonomous Systems. 187 3. Multi-provider: This scenario is the most complex, wherein trust 188 negotiations need to be made across multiple service provider 189 backbones in order to meet the security and service level agreements 190 for the PPVPN customer. This scenario can be generalized to cover the 191 Internet, which comprises of multiple service provider networks. It 192 should be noted that customers can construct their own VPNs across 193 multiple providers. However such VPNs are not considered here as 194 they would not be "Provider-provisioned". 196 A fourth scenario, "Carrier's carrier" VPN may also be considered. In 197 this scenario, a service provider (for example, a Tier 1 service 198 provider) provides VPN service to another service provider (for 199 example, a Tier 2 service provider), which in turn provides VPN 200 service on its VPN to its customers. In the example given above, the 201 Tier 2 provider's customers are contained within the Tier 2 202 provider's network, and the Tier 2 provider itself is a customer of 203 the Tier 1 provider's network. Thus, this scenario is not treated 204 separately in the document, because all of the single provider 205 requirements would apply equally to this case. 207 It is expected that many of the generic requirements described in 208 this document are independent of the three deployment scenarios 209 listed above. However, specific requirements that are indeed 210 dependent on the deployment scenario will be pointed out in this 211 document. 213 1.3. Outline of this document 215 This document describes generic requirements for Provider Provisioned 216 Virtual Private Networks (PPVPN). The document contains several 217 sections, with each set representing a significant aspect of PPVPN 218 requirements. 220 Section 2 lists authors who contributed to this document. Section 3 221 defines terminology and presents a taxonomy of PPVPN technologies. 222 The taxonomy contains two broad classes, representing Layer 2 and 223 Layer 3 VPNs. Each top level VPN class contains subordinate classes. 224 For example, the Layer 3 VPN class contains a subordinate class of 225 PE-based Layer 3 VPNs. 227 Sections 4, 5, 6 describe generic PPVPN requirements. 229 The requirements are broadly classified under the following 230 categories: 232 1) Service requirements - Service attributes that the customer can 233 observe or measure. For example, does the service forward frames or 234 route datagrams? What security guarantees does the service provide? 235 Availability and stability are key requirements in this category. 237 2) Provider requirements - Characteristics that Service Providers use 238 to determine the cost-effectiveness of a PPVPN service. Scaling and 239 management are examples of Provider requirements. 241 3) Engineering requirements - Implementation characteristics that 242 make service and provider requirements achievable. These can be 243 further classified as: 245 3a) Forwarding plane requirements - e.g., requirements related to 246 router forwarding behavior. 248 3b) Control plane requirements - e.g., requirements related to 249 reachability and distribution of reachability information. 251 3c) Requirements related to the commonality of PPVPN mechanisms with 252 each other and with generic Internet mechanisms. 254 2. Contributing Authors 256 This document was the combined effort of several individuals that 257 were part of the Service Provider focus group whose intentions were 258 to present Service Provider view on the general requirements for 259 PPVPN. A significant set of requirements were directly taken from 260 previous work by the PPVPN WG to develop requirements for Layer 3 261 PPVPN [L3REQTS]. The existing work in the L2 requirements area has 262 also influenced the contents of this document [L2REQTS]. 264 Besides the editor, the following are the authors that contributed to 265 this document: 267 Loa Andersson (loa@pi.se) 268 Ron Bonica (ronald.p.bonica@mci.com) 269 Dave McDysan (dave.mcdysan@mci.com) 270 Junichi Sumimoto (sumimoto.junichi@lab.ntt.co.jp) 271 Muneyoshi Suzuki (suzuki.muneyoshi@lab.ntt.co.jp) 272 David Meyer (dmm@1-4-5.net) 273 Marco Carugi (marco.carugi@nortelnetworks.com) 274 Yetik Serbest (yetik_serbest@labs.sbc.com) 275 Luyuan Fang (luyuanfang@att.com) 276 Javier Achirica (achirica@telefonica.net) 278 3. Definitions and Taxonomy 280 The terminology used in this document is defined in [TERMINOLOGY]. In 281 addition the following terminology is used: 283 Site: a geographical location with one or more users or one or more 284 servers or a combination of servers and users. 286 User: the end user equipment (hosts), e.g., a workstation. 288 PPVPN 289 ________________|__________________ 290 | | 291 Layer 2 (L2) Layer 3 (L3) 292 ______|_____ ______|________ 293 | | | | 294 PE-based CE-based PE-based CE-based 295 |__________| 296 ______|_____ 297 | | 298 P2P P2MP 300 The figure above presents a taxonomy of PPVPN technologies. PE-based 301 and CE-based Layer 2 VPNs may also be further classified as point-to- 302 point (P2P) or point-to-multipoint (P2MP). It is also the intention 303 of the working group to have a limited number of solutions, and this 304 goal must be kept in mind when proposing solutions that meet the 305 requirements specified in this document. Definitions for CE-based and 306 PE-based PPVPNs can be obtained from [L3 FRAMEWORK]. Layer 2 307 specific definitions can be obtained from [L2FRAMEWORK]. 309 4. Service requirements 311 These are the requirements that a customer can observe or measure, in 312 order to verify if the PPVPN service that the Service Provider (SP) 313 provides is satisfactory. As mentioned before, each of these 314 requirements apply equally across each of the three deployment 315 scenarios unless stated otherwise. 317 4.1. Availability 319 VPN services MUST have high availability. VPNs that are distributed 320 over several sites require connectivity to be maintained even in the 321 event of network failures or degraded service. 323 This can be achieved via various redundancy techniques such as: 325 1. Physical Diversity 327 A single site connected to multiple CEs (for CE-based PPVPNs) or PEs 328 (for PE-based PPVPNs), or different POPs, or even different service 329 providers 331 2. Tunnel redundancy 333 Redundant tunnels may be set up between the PEs (in a PE-based PPVPN) 334 or the CEs (in a CE-based PPVPN) so that if one tunnel fails, VPN 335 traffic can continue to flow across the other tunnel that has already 336 been set-up in advance. 338 Tunnel redundancy may be provided over and above physical diversity. 339 For example, a single site may be connected to two CEs (for CE-based 340 PPVPNs) or two PEs (for PE-based PPVPNs). Tunnels may be set up 341 between each of the CEs (or PEs as the case may be) across different 342 sites. 344 Of course, redundancy means additional resources being used, and 345 consequently, management of additional resources, which would impact 346 the overall scaling of the service. 348 It should be noted that it is difficult to guarantee high 349 availability when the VPN service is across multiple providers, 350 unless there is a negotiation between the different service providers 351 to maintain the service level agreement for the VPN customer. 353 4.2. Stability 355 In addition to availability, VPN services MUST also be stable. 356 Stability is a function of several components such as VPN routing, 357 signaling and discovery mechanisms, in addition to tunnel stability. 358 For example, in the case of routing, route flapping or routing loops 359 MUST be avoided in order to ensure stability. Stability of the VPN 360 service is directly related to the stability of the mechanisms and 361 protocols used to establish the service. It SHOULD also be possible 362 to allow network upgrades and maintenance procedures without 363 impacting the VPN service. 365 4.3. Traffic types 367 VPN services MUST support unicast (or point to point) traffic and 368 SHOULD support any-to-any or point-to-multipoint traffic including 369 multicast and broadcast traffic. In the broadcast model, the network 370 delivers a stream to all members of a subnetwork, regardless of their 371 interest in that stream. In the multicast model, the network delivers 372 a stream to a set of destinations that have registered interest in 373 the stream. All destinations need not belong to the same subnetwork. 374 Multicast is more applicable to L3 VPNs while broadcast is more 375 applicable to L2VPNs. It is desirable to support multicast limited 376 in scope to an intranet or extranet. The solution SHOULD be able to 377 support a large number of such intranet or extranet specific 378 multicast groups in a scalable manner. 380 All PPVPN approaches SHALL support both IPv4 and IPv6 traffic. 381 Specific L2 traffic types (e.g., ATM, Frame Relay and Ethernet) SHALL 382 be supported via encapsulation in IP or MPLS tunnels in the case of 383 L2VPNs. 385 4.4. Data isolation 387 The PPVPN MUST support forwarding plane isolation. The network MUST 388 never deliver user data across VPN boundaries unless the two VPNs 389 participate in an intranet or extranet. 391 Furthermore, if the provider network receives signaling or routing 392 information from one VPN, it MUST NOT reveal that information to 393 another VPN unless the two VPNs participate in an intranet or 394 extranet. It should be noted that the disclosure of any 395 signaling/routing information across an extranet MUST be filtered per 396 the extranet agreement between the organizations participating in the 397 extranet. 399 4.5. Security 401 A range of security features SHOULD be supported by the suite of 402 PPVPN solutions in the form of securing customer flows, providing 403 authentication services for temporary, remote or mobile users, and 404 the need to protect service provider resources involved in supporting 405 a PPVPN. These security features SHOULD be implemented based on the 406 framework outlined in [VPN SEC]. Each PPVPN solution SHOULD state 407 which security features it supports and how such features can be 408 configured on a per customer basis. Protection against Denial of 409 Service (DoS) attacks is a key component of security mechanisms. 410 Examples of DoS attacks include attacks to the PE or CE CPUs, access 411 connection congestion, TCP SYN attacks and ping attacks. 413 Some security mechanisms (such as use of IPsec on a CE-to-CE basis) 414 may be equally useful regardless of the scope of the VPN. Other 415 mechanisms may be more applicable in some scopes than in others. For 416 example, in some cases of single-provider single-AS VPNs, the VPN 417 service may be isolated from some forms of attack by isolating the 418 infrastructure used for supporting VPNs from the infrastructure used 419 for other services. However, the requirements for security are common 420 regardless of the scope of the VPN service. 422 4.5.1. User data security 424 PPVPN solutions that support user data security SHOULD use standard 425 methods (e.g., IPsec) to achieve confidentiality, integrity, 426 authentication and replay attack prevention. Such security methods 427 MUST be configurable between different end points, such as CE-CE, PE- 428 PE, and CE-PE. It is also desirable to configure security on a per- 429 route or per-VPN basis. User data security using encryption is 430 especially desirable in the multi-provider scenario. 432 4.5.2. Access control 434 A PPVPN solution may also have the ability to activate the 435 appropriate filtering capabilities upon request of a customer. A 436 filter provides a mechanism so that access control can be invoked at 437 the point(s) of communication between different organizations 438 involved in an extranet. Access control can be implemented by a 439 firewall, access control lists on routers, cryptographic mechanisms 440 or similar mechanisms to apply policy-based access control. Access 441 control MUST also be applicable between CE-CE, PE-PE and CE-PE. Such 442 access control mechanisms are desirable in the multi-provider 443 scenario. 445 4.5.3. Site authentication and authorization 447 A PPVPN solution requires authentication and authorization of the 448 following: 450 - temporary and permanent access for users connecting to sites 451 (authentication and authorization BY the site) 453 - the site itself (authentication and authorization FOR the site) 455 4.5.4. Inter domain security 457 The VPN solution MUST have appropriate security mechanisms to prevent 458 the different kinds of Distributed Denial of Service (DDoS) attacks 459 mentioned earlier, misconfiguration or unauthorized accesses in inter 460 domain PPVPN connections. This is particularly important for multi- 461 service provider deployment scenarios. However, this will also be 462 important in single-provider multi-AS scenarios. 464 4.6. Topology 466 A VPN SHOULD support arbitrary, customer-defined inter-site 467 connectivity, ranging, for example, from hub-and-spoke, partial mesh 468 to full mesh topology. These can actually be different from the 469 topology used by the service provider. To the extent possible, a 470 PPVPN service SHOULD be independent of the geographic extent of the 471 deployment. 473 Multiple VPNs per customer site SHOULD be supported without requiring 474 additional hardware resources per VPN. This SHOULD also include a 475 free mix of L2 and L3 VPNs. 477 To the extent possible, the PPVPN services SHOULD be independent of 478 access network technology. 480 4.7. Addressing 482 Each customer resource MUST be identified by an address that is 483 unique within its VPN. It need not be identified by a globally unique 484 address. 486 Support for private addresses as described in RFC 1918, as well as 487 overlapping customer addresses SHALL be supported. One or more VPNs 488 for each customer can be built over the same infrastructure without 489 requiring any of them to renumber. The solution MUST NOT use NAT on 490 the customer traffic to achieve that goal. Interconnection of two 491 networks with overlapping IP addresses is outside the scope of this 492 document. 494 A VPN service SHALL be capable of supporting non-IP customer 495 addresses via encapsulation techniques, if it is a Layer 2 VPN (e.g., 496 Frame Relay, ATM, Ethernet). Support for non-IP Layer 3 addresses 497 may be desirable in some cases, but is beyond the scope of VPN 498 solutions developed in the IETF, and therefore, this document. 500 4.8. Quality of Service 502 A technical approach for supporting VPNs SHALL be able to support QoS 503 via IETF standardized mechanisms such as Diffserv. Support for best- 504 effort traffic SHALL be mandatory for all PPVPN types. The extent to 505 which any specific VPN service will support QoS is up to the service 506 provider. In many cases single-provider single-AS VPNs will offer QoS 507 guarantees. Support of QoS guarantees in the multi-service-provider 508 case will require cooperation between the various service providers 509 involved in offering the service. 511 It should be noted that QoS mechanisms in the multi-provider scenario 512 REQUIRES each of the participating providers to support the 513 mechanisms being used, and as such, this is difficult to achieve. 515 Note that all cases involving QoS may require that the CE and/or PE 516 perform shaping and/or policing. 518 The need to provide QoS will occur primarily in the access network, 519 since that will often be the bottleneck. This is likely to occur 520 since the backbone effectively statistically multiplexes many users, 521 and is traffic engineered or includes capacity for restoration and 522 growth. Hence in most cases PE-PE QoS is not a major issue. As far as 523 access QoS is concerned, there are two directions of QoS management 524 that may be considered in any PPVPN service regarding QoS: 526 - From the CE across the access network to the PE 527 - From the PE across the access network to CE 529 PPVPN CE and PE devices SHOULD be capable of supporting QoS across at 530 least the following subset of access networks, as applicable to the 531 specific type of PPVPN (L2 or L3). However, to the extent possible, 532 the QoS capability of a PPVPN SHOULD be independent of the access 533 network technology: 535 - ATM Virtual Connections (VCs) 536 - Frame Relay Data Link Connection Identifiers (DLCIs) 537 - 802.1d Prioritized Ethernet 538 - MPLS-based access 539 - Multilink Multiclass PPP 540 - QoS-enabled wireless (e.g., LMDS, MMDS) 541 - Cable modem 542 - QoS-enabled Digital Subscriber Line (DSL) 544 Different service models for QoS may be supported. Examples of PPVPN 545 QoS service models are: 547 - Managed access service: Provides QoS on the access connection 548 between CE and the customer facing ports of the PE. No QoS support 549 is required in the provider core network in this case. 551 - Edge-to-edge QoS: Provides QoS across the provider core, either 552 between CE pairs or PE pairs, depending on the tunnel demarcation 553 points. This scenario requires QoS support in the provider core 554 network. As mentioned above, this is difficult to achieve in a multi- 555 provider VPN offering. 557 4.9. Service Level Agreement and Service Level Specification Monitoring 558 and Reporting 560 A Service Level Specification (SLS) may be defined per access network 561 connection, per VPN, per VPN site, and/or per VPN route. The service 562 provider may define objectives and the measurement interval for at 563 least the SLS using the following Service Level Objective (SLO) 564 parameters: 566 - QoS and traffic parameters for the Intserv flow or Diffserv 567 class [Y.1541] 569 - Availability for the site, VPN, or access connection 571 - Duration of outage intervals per site, route or VPN 572 - Service activation interval (e.g., time to turn up a new site) 574 - Trouble report response time interval 576 - Time to repair interval 578 - Total traffic offered to the site, route or VPN 580 - Measure of non-conforming traffic for the site, route or VPN 582 - Delay and delay variation (jitter) bounds 584 - Packet ordering, at least when transporting L2 services 585 sensitive to reordering (e.g., ATM). 587 The above list contains items from [Y.1241], as well as other items 588 typically part of SLAs for currently deployed VPN services [FRF.13]. 589 See [RFC3198] for generic definitions of SLS, SLA, and SLO. 591 The provider network management system SHALL measure, and report as 592 necessary, whether measured performance meets or fails to meet the 593 above SLS objectives. 595 In many cases the guaranteed levels for Service Level Objective (SLO) 596 parameters may depend upon the scope of the VPN. For example, one 597 level of guarantee might be provided for service within a single AS. 598 A different (generally less stringent) guarantee might be provided 599 within multiple ASs within a single service provider. At the current 600 time, in most cases specific guarantees are not offered for multi- 601 provider VPNs, and if guarantees were offered they might be expected 602 to be less stringent still. 604 The service provider and the customer may negotiate a contractual 605 arrangement that includes a Service Level Agreement (SLA) regarding 606 compensation if the provider does not meet an SLS performance 607 objective. Details of such compensation are outside the scope of this 608 document. 610 4.10. Network Resource Partitioning and Sharing between VPNs 612 Network resources such as memory space, FIB table, bandwidth and CPU 613 processing SHALL be shared between VPNs and, where applicable, with 614 non-VPN Internet traffic. Mechanisms SHOULD be provided to prevent 615 any specific VPN from taking up available network resources and 616 causing others to fail. SLAs to this effect SHOULD be provided to the 617 customer. 619 Similarly, resources used for control plane mechanisms are also 620 shared. When the service provider's control plane is used to 621 distribute VPN specific information and provide other control 622 mechanisms for VPNs, there SHALL be mechanisms to ensure that control 623 plane performance is not degraded below acceptable limits when 624 scaling the VPN service, or during network events such as failure, 625 routing instabilities etc. Since a service provider's network would 626 also be used to provide Internet service, in addition to VPNs, 627 mechanisms to ensure the stable operation of Internet services and 628 other VPNs SHALL be made in order to avoid adverse effects of 629 resource hogging by large VPN customers. 631 5. Provider requirements 633 This section describes operational requirements for a cost-effective, 634 profitable VPN service offering. 636 5.1. Scalability 638 The scalability for VPN solutions has many aspects. The list below is 639 intended to comprise of the aspects that PPVPN solutions SHOULD 640 address. Clearly these aspects in absolute figures are very different 641 for different types of VPNs - i.e., a point to point service has only 642 two sites, while a VPLS or L3VPN may have a larger number of sites. 643 It is also important to verify that PPVPN solutions not only scales 644 on the high end, but also on the low end - i.e., a VPN with three 645 sites and three users should be as viable as a VPN with hundreds of 646 sites and thousands of users. 648 5.1.1. Service Provider Capacity Sizing Projections 650 A PPVPN solution SHOULD be scalable to support a very large number of 651 VPNs per Service Provider network. The estimate is that a large 652 service provider will require support for O(10^4) VPNs within four 653 years. 655 A PPVPN solution SHOULD be scalable to support a wide range of number 656 of site interfaces per VPN, depending on the size and/or structure of 657 the customer organization. The number of site interfaces SHOULD range 658 from a few site interfaces to over 50,000 site interfaces per VPN. 660 A PPVPN solution SHOULD be scalable to support of a wide range of 661 number of routes per VPN. The number of routes per VPN may range from 662 just a few to the number of routes exchanged between ISPs (O(10^5)), 663 with typical values being in the O(10^3) range. The high end number 664 is especially true considering the fact that many large ISPs may 665 provide VPN services to smaller ISPs or large corporations. 666 Typically, the number of routes per VPN is at least twice the number 667 of site interfaces. 669 A PPVPN solution SHOULD support high values of the frequency of 670 configuration setup and change, e.g., for real-time provisioning of 671 an on-demand videoconferencing VPN or addition/deletion of sites. 673 Approaches SHOULD articulate scaling and performance limits for more 674 complex deployment scenarios, such as single-provider multi-AS VPNs, 675 multi-provider VPNs and carriers' carrier. Approaches SHOULD also 676 describe other dimensions of interest, such as capacity requirements 677 or limits, number of interworking instances supported as well as any 678 scalability implications on management systems. 680 A PPVPN solution SHOULD support a large number of customer interfaces 681 on a single PE (for PE-based PPVPN) or CE (for CE-based PPVPN) with 682 current Internet protocols. 684 5.1.2. VPN Scalability aspects 686 This section describes the metrics for scaling PPVPN solutions, 687 points out some of the scaling differences between L2 and L3 VPNs. It 688 should be noted that the scaling numbers used in this document must 689 be treated as typical examples as seen by the authors of this 690 document. These numbers are only representative and different service 691 providers may have different requirements for scaling. Further 692 discussion on service provider sizing projections is in Section 693 5.1.1. Please note that the terms "user" and "site" are as defined 694 in Section 3. It should also be noted that the numbers given below 695 would be different depending on whether the scope of the VPN is 696 single-provider single-AS, single-provider multi-AS, or multi- 697 provider. Clearly, the larger the scope, the larger the numbers that 698 may need to be supported. However, this also means more management 699 issues. The numbers below may be treated as representative of the 700 single-provider case. 702 5.1.2.1. Number of users per site 704 The number of users per site follows the same logic as for users per 705 VPN. Further, it must be possible to have single user sites connected 706 to the same VPN as very large sites are connected to. 708 L3 VPNs SHOULD scale from 1 user per site to O(10^4) per site. L2 709 VPNs SHOULD scale from 1 user to O(10^3) per site for point-to-point 710 VPNs and to O(10^4) for point-to-multipoint VPNs. 712 5.1.2.2. Number of sites per VPN 714 The number of sites per VPN clearly depends on the number of users 715 per site. VPNs SHOULD scale from 2 to O(10^3) sites per VPN. These 716 numbers are usually limited by device memory. 718 5.1.2.3. Number of PEs and CEs 720 The number of PEs that supports the same set of VPNs, i.e., the 721 number of PEs that needs to directly exchange information on VPN de- 722 multiplexing information is clearly a scaling factor in a PE-based 723 VPN. Similarly, in a CE-based VPN, the number of CEs is a scaling 724 factor. This number is driven by the type of VPN service, and also by 725 whether the service is within a single AS/domain or involves a multi- 726 SP or multi-AS network. Typically, this number SHOULD be as low as 727 possible in order to make the VPN cost effective and manageable. 729 5.1.2.4. Number of sites per PE 731 The number of sites per PE needs to be discussed based on several 732 different scenarios. On the one hand there is a limitation to the 733 number of customer facing interfaces that the PE can support. On the 734 other hand the access network may aggregate several sites connected 735 on comparatively low bandwidth on to one single high bandwidth 736 interface on the PE. The scaling point here is that the PE SHOULD be 737 able to support a few or even a single site on the low end and 738 O(10^4) sites on the high end. This number is also limited by device 739 memory. Implementations of PPVPN solutions may be evaluated based on 740 this requirement, because it directly impacts cost and manageability 741 of a VPN. 743 5.1.2.5. Number of VPNs in the network 745 The number of VPNs SHOULD scale linearly with the size of the access 746 network and with the number of PEs. As mentioned in Section 5.1.1, 747 the number of VPNs in the network SHOULD be O(10^4). This requirement 748 also effectively places a requirement on the number of tunnels that 749 SHOULD be supported in the network. For a PE-based VPN, the number of 750 tunnels is of the same order as the number of VPNs. For a CE-based 751 VPN, the number of tunnels in the core network may be fewer, because 752 of the possibility of tunnel aggregation or multiplexing across the 753 core. 755 5.1.2.6. Number of VPNs per customer 757 In some cases a service provider may support multiple VPNs for the 758 same customer of that service provider. For example, this may occur 759 due to differences in services offered per VPN (e.g., different QoS, 760 security levels, or reachability) as well as due to the presence of 761 multiple workgroups per customer. It is possible that one customer 762 will run up to O(100) VPNs. 764 5.1.2.7. Number of addresses and address prefixes per VPN 766 Since any VPN solution SHALL support private customer addresses, the 767 number of addresses and address prefixes are important in evaluating 768 the scaling requirements. The number of address prefixes used in 769 routing protocols and in forwarding tables specific to the VPN needs 770 to scale from very few (for smaller customers) to very large numbers 771 seen in typical Service Provider backbones. The high end is 772 especially true considering that many Tier 1 SPs may provide VPN 773 services to Tier 2 SPs or to large corporations. For a L2 VPN this 774 number would be on the order of addresses supported in typical native 775 Layer 2 backbones. 777 5.1.3. Solution-Specific Metrics 779 Each PPVPN solution SHALL document its scalability characteristics in 780 quantitative terms. A VPN solution SHOULD quantify the amount of 781 state that a PE and P device has to support. This SHOULD be stated in 782 terms of the order of magnitude of the number of VPNs and site 783 interfaces supported by the service provider. Ideally, all VPN- 784 specific state SHOULD be contained in the PE device for a PE-based 785 VPN. Similarly, all VPN-specific state SHOULD be contained in the CE 786 device for a CE-based VPN. In all cases, the backbone routers (P 787 devices) SHALL NOT maintain VPN-specific state as far as possible. 789 Another metric is that of complexity. In a PE-based solution the PE 790 is more complex in that it has to maintain tunnel-specific 791 information for each VPN, but the CE is simpler since it does not 792 need to support tunnels. On the other hand, in a CE-based solution, 793 the CE is more complex since it has to implement routing across a 794 number of tunnels to other CEs in the VPN, but the PE is simpler 795 since it has only one routing and forwarding instance. Thus, the 796 complexity of the PE or CE SHOULD be noted in terms of their 797 processing and management functions. 799 5.2. Management 801 A service provider MUST have a means to view the topology, 802 operational state, service order status, and other parameters 803 associated with each customer's VPN. Furthermore, the service 804 provider MUST have a means to view the underlying logical and 805 physical topology, operational state, provisioning status, and other 806 parameters associated with the equipment providing the VPN service(s) 807 to its customers. 809 In the multi-provider scenario, it is unlikely that participating 810 providers would provide each other a view to the network topology and 811 other parameters mentioned above. However, each provider MUST ensure 812 via management of their own networks that the overall VPN service 813 offered to the customers are properly managed. In general the support 814 of a single VPN spanning multiple service providers requires close 815 cooperation between the service providers. One aspect of this 816 cooperation involves agreement on what information about the VPN will 817 be visible across providers, and what network management protocols 818 will be used between providers. 820 VPN devices SHOULD provide standards-based management interfaces 821 wherever feasible. 823 5.2.1. Customer Management of a VPN 825 A customer SHOULD have a means to view the topology, operational 826 state, service order status, and other parameters associated with his 827 or her VPN. 829 All aspects of management information about CE devices and customer 830 attributes of a PPVPN manageable by an SP SHOULD be capable of being 831 configured and maintained by the customer after being authenticated 832 and authorized. 834 A customer SHOULD be able to make dynamic requests for changes to 835 traffic parameters. A customer SHOULD be able to receive real-time 836 response from the SP network in response to these requests. One 837 example of such as service is a "Dynamic Bandwidth management" 838 capability, that enables real-time response to customer requests for 839 changes of allocated bandwidth allocated to their VPN(s). A possible 840 outcome of giving customers such capabilities is Denial of Service 841 attacks on other VPN customers or Internet users. This possibility is 842 documented in the Security Considerations section. 844 6. Engineering requirements 846 These requirements are driven by implementation characteristics that 847 make service and provider requirements achievable. 849 6.1. Forwarding plane requirements 851 VPN solutions SHOULD NOT pre-suppose or preclude the use of IETF 852 developed tunneling techniques such as IP-in-IP, L2TP, GRE, MPLS or 853 IPsec. The separation of VPN solution and tunnels will facilitate 854 adaptability with extensions to current tunneling techniques or 855 development of new tunneling techniques. It should be noted that the 856 choice of the tunneling techniques may impact the service and scaling 857 capabilities of the VPN solution. 859 It should also be noted that specific tunneling techniques may not be 860 feasible depending on the deployment scenario. In particular, there 861 is currently very little use of MPLS in the inter-provider scenario. 862 Thus, native MPLS support may be needed between the service 863 providers, or it would be necessary to run MPLS over IP or GRE. It 864 should be noted that if MPLS is run over IP or GRE, some of the other 865 capabilities of MPLS, such as Traffic Engineering, would be impacted. 866 Also note that a service provider MAY optionally choose to use a 867 different encapsulation for multi-AS VPNs than is used for single AS 868 VPNs. Similarly, a group of service providers may choose to use a 869 different encapsulation for multi-service provider VPNs than for VPNs 870 within a single service provider. 872 For Layer 2 VPNs, solutions SHOULD utilize the encapsulation 873 techniques defined by the Pseudo-Wire Emulation Edge-to-Edge (PWE3) 874 Working Group, and SHOULD NOT impose any new requirements on these 875 techniques. 877 PPVPN solutions MUST NOT impose any restrictions on the backbone 878 traffic engineering and management techniques. Conversely, backbone 879 engineering and management techniques MUST NOT affect the basic 880 operation of a PPVPN, apart from influencing the SLA/SLS guarantees 881 associated with the service. The SP SHOULD, however, be REQUIRED to 882 provide per-VPN management, tunnel maintenance and other maintenance 883 required in order to meet the SLA/SLS. 885 By definition, VPN traffic SHOULD be segregated from each other, and 886 from non-VPN traffic in the network. After all, VPNs are a means of 887 dividing a physical network into several logical (virtual) networks. 888 VPN traffic separation SHOULD be done in a scalable fashion. However, 889 safeguards SHOULD be made available against misbehaving VPNs to not 890 affect the network and other VPNs. 892 A VPN solution SHOULD NOT impose any hard limit on the number of VPNs 893 provided in the network. 895 6.2. Control plane requirements 897 The plug and play feature of a VPN solution with minimum 898 configuration requirements is an important consideration. The VPN 899 solutions SHOULD have mechanisms for protection against customer 900 interface and/or routing instabilities so that they do not impact 901 other customers' services or impact general Internet traffic handling 902 in any way. 904 A VPN SHOULD be provisioned with minimum number of steps. For 905 instance, a VPN need not be configured in every PE. For this to be 906 accomplished, an auto-configuration and an auto-discovery protocol, 907 which SHOULD be as common as possible to all VPN solutions, SHOULD be 908 defined. However, these mechanisms SHOULD NOT adversely affect the 909 cost, scalability or stability of a service by being overly complex, 910 or by increasing layers in the protocol stack. 912 Mechanisms to protect the SP network from effects of misconfiguration 913 of VPNs SHOULD be provided. This is especially of importance in the 914 multi-provider case, where misconfiguration could possibly impact 915 more than one network. 917 6.3. Control Plane Containment 919 The PPVPN control plane MUST include a mechanism through which the 920 service provider can filter PPVPN related control plane information 921 as it passes between Autonomous Systems. For example, if a service 922 provider supports a PPVPN offering, but the service provider's 923 neighbors do not participate in that offering, the service provider 924 SHOULD NOT leak PPVPN control information into neighboring networks. 925 Neighboring networks MUST be equipped with mechanisms that filter 926 this information should the service provider leak it. This is 927 important in the case of multi-provider VPNs as well as single- 928 provider multi-AS VPNs. 930 6.4. Requirements related to commonality of PPVPN mechanisms with each 931 other and with generic Internet mechanisms 933 As far as possible, the mechanisms used to establish a VPN service 934 SHOULD re-use well-known IETF protocols, limiting the need to define 935 new protocols from scratch. It should, however, be noted that the use 936 of Internet mechanisms for the establishment and running of an 937 Internet-based VPN service, SHALL NOT affect the stability, 938 robustness, and scalability of the Internet or Internet services. In 939 other words, these mechanisms SHOULD NOT conflict with the 940 architectural principles of the Internet, nor SHOULD it put at risk 941 the existing Internet systems. For example, IETF-developed routing 942 protocols SHOULD be used for routing of L3 PPVPN traffic, without 943 adding VPN-specific state to the Internet core routers. Similarly, 944 well-known L2 technologies SHOULD be used in VPNs offering L2 945 services, without imposing risks to the Internet routers. A solution 946 MUST be implementable without requiring additional functionality to 947 the P devices in a network, and minimal functionality to the PE in a 948 PE-based VPN and CE in a CE-based VPN. 950 In addition to commonality with generic Internet mechanisms, 951 infrastructure mechanisms used in different PPVPN solutions (both L2 952 and L3), e.g., discovery, signaling, routing and management, SHOULD 953 be as common as possible. 955 6.5. Interoperability 957 Each technical solution is expected to be based on interoperable 958 Internet standards. 960 Multi-vendor interoperability at network element, network and service 961 levels among different implementations of the same technical solution 962 SHOULD be ensured (that will likely rely on the completeness of the 963 corresponding standard). This is a central requirement for SPs and 964 customers. 966 The technical solution MUST be multi-vendor interoperable not only 967 within the SP network infrastructure, but also with the customer's 968 network equipment and services making usage of the PPVPN service. 970 Customer access connections to a PPVPN solution may be different at 971 different sites (e.g., Frame Relay on one site and Ethernet on 972 another). 974 Interconnection of a L2VPN over an L3VPN as if it were a customer 975 site SHALL be supported. However, interworking of Layer 2 976 technologies is not required, and is outside the scope of the working 977 group, and therefore, of this document. 979 Inter-domain interoperability - It SHOULD be possible to deploy a 980 PPVPN solution across domains, Autonomous Systems, or the Internet. 982 7. Security Considerations 984 Security requirements for Provider Provisioned VPNs have been 985 described in Section 4.5. In addition, the following considerations 986 need to be kept in mind when a provider provisioned VPN service is 987 provided across a public network infrastructure that is also used to 988 provide Internet connectivity. In general, the security framework 989 described in [VPN-SEC] SHOULD be used as far as it is applicable to 990 the given type of PPVPN service. 992 The PE device has a lot of functionality required for the successful 993 operation of the VPN service. The PE device is frequently also part 994 of the backbone providing Internet services, and is therefore 995 susceptible to security and denial of service attacks. The PE 996 control plane CPU is vulnerable from this point of view, and it may 997 impact not only VPN services but also general Internet services if 998 not adequately protected. In addition to VPN configuration, if 999 mechanisms such as QoS are provisioned on the PE, it is possible for 1000 attackers to recognize the highest priority traffic or customers and 1001 launch directed attacks. Care SHOULD be taken to prevent such 1002 attacks whenever any value added services such as QoS are offered. 1004 When a service such as "Dynamic Bandwidth Management" as described in 1005 Section 5.2.1 is provided, it allows customers to dynamically request 1006 for changes to their bandwidth allocation. The provider MUST take 1007 care to authenticate such requests and detect and prevent possible 1008 Denial-of-Service attacks. These DoS attacks are possible when a 1009 customer maliciously or accidentally may cause a change in bandwidth 1010 allocation that may impact the bandwidth allocated to other VPN 1011 customers or Internet users. 1013 Different choices of VPN technology have different assurance levels 1014 of the privacy of a customer's network. For example, CE-based 1015 solutions may enjoy more privacy than PE-based VPNs by virtue of 1016 tunnels extending from CE to CE, even if the tunnels are not 1017 encrypted. In a PE-based VPN, a PE has many more sites than those 1018 attached to a CE in a CE-based VPN. A large number of these sites may 1019 use RFC 1918 addresses. Provisioning mistakes and PE software bugs 1020 may make traffic more prone to being misdirected as opposed to a CE- 1021 based VPN. Care MUST be taken to prevent misconfiguration in all 1022 kinds of PPVPNs, but more care MUST be taken in the case of PE-based 1023 VPNs, as this could impact other customers and Internet services. 1024 Similarly, there SHOULD be mechanisms to prevent the flooding of 1025 Internet routing tables whenever there is a misconfiguration or 1026 failure of PPVPN control mechanisms that use Internet routing 1027 protocols for relay of VPN-specific information. 1029 Different deployment scenarios also dictate the level of security 1030 that may be needed for a VPN. For example, it is easier to control 1031 security in a single provider, single AS VPN and therefore, expensive 1032 encryption techniques may not be used in this case, as long as VPN 1033 traffic is isolated from the Internet. There is a reasonable amount 1034 of control possible in the single provider, multi AS case, although 1035 care SHOULD be taken to ensure the constrained distribution of VPN 1036 route information across the ASes. Security is more of a challenge 1037 in the multi-provider case, where it may be necessary to adopt 1038 encryption techniques in order to provide the highest level of 1039 security. 1041 8. References 1043 8.1. Normative References 1045 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 1046 3", BCP 9, RFC 2026, October 1996. 1047 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1048 Requirement Levels", BCP 14, RFC 2119, March 1997. 1050 8.2. Informative References 1052 [TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider 1053 Provisioned Virtual Private Networks", 1054 , work in progress. 1055 [L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for 1056 Layer 3 Provider Provisioned Virtual Private Networks", 1057 , work in progress. 1058 [L2FRAMEWORK] Andersson, L., et al. "A Framework for Layer 2 Provider 1059 Provisioned Virtual Private Networks", 1060 , work in progress. 1061 [L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements 1062 for Layer 3 Provider Provisioned Virtual Private 1063 Networks", , work in progress. 1064 [L2REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements 1065 for Layer 2 Provider Provisioned Virtual Private 1066 Networks", , work in progress. 1067 [Y.1241] "IP Transfer Capability for the support of IP based 1068 Services", Y.1241 ITU-T Draft Recommendation, March 2000. 1069 [Y.1311] Knightson, K. (editor), "Network based IP VPN Service 1070 - Generic Framework and Service Requirements ", Y.1311 1071 ITU-T Recommendation, January, 2002. 1072 [RFC 3198] A. Westerinen et al, "Terminology for Policy-Based 1073 Management," November, 2001. 1074 [VPN SEC] L. Fang et al, "Security Framework for Provider Provisioned 1075 Virtual Private Networks," 1076 , work in progress. 1077 [FRF.13] Frame Relay Forum, "Service Level Definitions 1078 Implementation Agreement," August, 1998. 1079 [Y.1541] "Network Performance Objectives for IP-based 1080 Services," Y.1541, ITU-T Recommendation. 1082 9. Acknowledgements 1084 This work was done in consultation with the entire design team for 1085 PPVPN requirements. A lot of the text was adapted from the Layer 3 1086 requirements document produced by the Layer 3 requirements design 1087 team. The authors would also like to acknowledge the constructive 1088 feedback from Scott Bradner, Alex Zinin, Steve Bellovin, Thomas 1089 Narten and other IESG members, and the detailed comments from Ross 1090 Callon. 1092 10. Editor's Address 1094 Ananth Nagarajan 1095 Juniper Networks 1096 E-mail: ananth@juniper.net 1098 11. Full Copyright Statement 1100 Copyright (C) The Internet Society (2004). All Rights Reserved. 1102 This document and translations of it may be copied and furnished to 1103 others, and derivative works that comment on or otherwise explain it 1104 or assist in its implementation may be prepared, copied, published 1105 and distributed, in whole or in part, without restriction of any 1106 kind, provided that the above copyright notice and this paragraph are 1107 included on all such copies and derivative works. However, this 1108 document itself may not be modified in any way, such as by removing 1109 the copyright notice or references to the Internet Society or other 1110 Internet organizations, except as needed for the purpose of 1111 developing Internet standards in which case the procedures for 1112 copyrights defined in the Internet Standards process must be 1113 followed, or as required to translate it into languages other than 1114 English. 1116 The limited permissions granted above are perpetual and will not be 1117 revoked by the Internet Society or its successors or assigns. 1119 This document and the information contained herein is provided on an 1120 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1121 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1122 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1123 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1124 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.