Internet Engineering Task Force J. Sumimoto INTERNET-DRAFT NTT M. Carugi Expires December 2002 France Telecom (Co-editors) J. De Clercq Alcatel A. Nagarajan Sprint M. Suzuki NTT June 24, 2002 Guidelines of Applicability Statements for PPVPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document is expected to be guidelines to assist development of applicability statements for each PPVPN approach by providing a check-list which consists of requirements/metrics. This check-list is systematically composed of (i)requirements and metrics common to all PPVPNs, (ii)requirements and metrics common to L3 PPVPN approaches, (iii)requirements and metrics specific to L3 PE-based PPVPN Sumimoto, et al. Expires December 2002 [Page 1] INTERNET-DRAFT June 24, 2002 approaches, (iv)requirements and metrics specific to L3 CE-based PPVPN approaches and (v)requirements and metrics common to L2 PPVPN approaches, according to the classification of PPVPN approaches. 1. Summary for Sub-IP Area 1.1 Summary This document is expected to be guidelines to assist development of applicability statements of PPVPNs by providing a check-list which consists of requirements/metrics. PPVPNs are classified into multiple specific PPVPN approaches based on their characteristics. These PPVPN approaches closely relate each other by sharing a portion of the characteristics. Therefore, it is necessary to provide a check-list for developing applicability statements of each PPVPN approach by extracting requirements/metrics according to the mechanisms of PPVPN approaches out of the service requirements of the requirements documents. This document systematically provides such a check-list along with the classification of PPVPN approaches. 1.2 Where does it fit in the Picture of the Sub-IP Work This document fits in ppvpn WG. 1.3 Why is it Targeted at this WG The ppvpn charter clearly defines development of applicability statements documents for PPVPN approaches as a working item of ppvpn WG. Since this document is expected to assist these approach specific applicability statements documents, ppvpn WG is appropriate as the home of this document. (*)We do not need justification as this document directly fits in ppvpn WG. 2. Introduction *** Goal and Role (This comment is to be deleted) *** The term "PPVPNs"refers to Virtual Private Networks (VPNs) for which the service provider participates in management and provisioning of the VPN. PPVPNs can be classified into several PPVPN classes based on their characteristics, and these PPVPN classes closely relate each other by sharing some portion of the characteristics. Therefore, so as to make approach-specific applicability statements significant, it is necessary to systematically extract requirements/metrics directly relating to protocols/mechanisms out of the service requirements described in the requirements documents[PPVPN-REQ]. This document Sumimoto, et al. Expires December 2002 [Page 2] INTERNET-DRAFT June 24, 2002 provides a check-list which consists of the extracted requirements/metrics. Each metric in the list is intended to clearly point out what must be written in each approach specific applicability statements documents, thus detailed description with regard to the metric is out of scope of this document. *** Scope and Organization (This comment is to be deleted) *** PPVPN approaches for which applicability statements are to be developed are, - BGP MPLS VPNs[2547bis] and VR VPNs[VPN-VR, 2917bis] as L3 PE-based PPVPNs, - IPsec VPNs[VPN-IPsec] as L3 CE-based PPVPNs, - BGP signaled L2VPNs[], LDP signaled L2VPNs (with/without Directory)[], RSVP signaled L2VPNs[] as L2 PE-based PPVPNs. (To be updated) Definition and classification of PPVPN approaches are overviewed in Section 3. Section 4 provides list and outline of requirements/metrics systematically according to the classification of PPVPN approaches. Section 5 is for security considerations, and section 6 is for references. 3. PPVPN technical overview This section provides a brief overview on the various types of PPVPNs as an introductory guidance toward discussions in the rest of this document and in developing approach-specific applicability statements documents. Detailed description is provided in the framework document[PPVPN-FR]. PPVPNs can be classified into - L3 PPVPNs / L2 PPVPNs from the viewpoint of service layer for customers. On the other hand, PPVPNs can be classified into - PE based PPVPNs / CE-based PPVPNs by the terminating point of VPN tunnels. Since these two keys of classification are independent each other, four PPVPN classes are defined after all. The rest of this section briefly overview each of L3 PE-based VPNs, L3 CE-based VPNs, and L2 PE-based VPNs, out of the four classes, which is covered by the following sections of this document. - Layer 3 PE-based VPNs A layer 3 PE-based VPN is one in which PE devices in the SP network provide the VPN-specific functions and SP forwards packets based on layer 3 information. BGP MPLS and VR approach are included in this class. Sumimoto, et al. Expires December 2002 [Page 3] INTERNET-DRAFT June 24, 2002 - Layer 3 CE-based VPNs In CE-based VPNs, the VPN-specific functions (e.g. tunneling) are deployed in the CE devices, while the provider network has no VPN awareness on the data-plane level. SP forwards packets based on layer 3 information. IPsec VPN is included in this class. - Layer 2 PE-based VPNs A layer 2 PE-based VPN is one in which PE devices in the SP network provide the VPN-specific functions and SP forwards packets based on layer 2 information. BGP signaled L2VPNs, LDP signaled L2VPNs (with/without Directory), and RSVP signaled L2VPNs are included in this class. 4. List and outline of requirements and metrics for evaluating each PPVPN approach This section provides list and outline of requirements/metrics common to all PPVPNs (in Section 4.1), common to L3 PPVPN approaches (in Section 4.2), specific to L3 PE-based PPVPN approaches (in Section 4.3), specific to L3 CE-based PPVPN approaches (in Section 4.4) and common to L2 PE-based PPVPN approaches (in Section 4.5), according to the classification of PPVPN approaches. Note that requirements/metrics for a higher PPVPN class must apply to any inheriting lower PPVPN classes (maybe concurrently, if multiple lower PPVPN classes provisioned in an SP network concurrently). For example, VR approach must be checked not only by requirements/metrics for specific to L3 PE-based PPVPN approaches but also by requirements/metrics common to all PPVPNs and common to L3 PPVPN approaches. In this section, AS stands for Applicability Statements. 4.1 Requirements and metrics common to all PPVPNs 4.1.1 Isolated exchange of routing and data information Each specific AS document must clarify whether and how the following attributes are implemented by the concerned PPVPN approach. - Isolated data forwarding (mandatory) - Isolated routing (i.e. constrained distribution of reachability to only VPN sites) (internal topology of VPN should not be visible to the shared public network (Internet)) 4.1.2 Overlapping customer address space Each specific AS document must clarify whether and how the following Sumimoto, et al. Expires December 2002 [Page 4] INTERNET-DRAFT June 24, 2002 attributes are implemented by the concerned PPVPN approach. - Support of non-unique customer addresses - Support of private addresses Each specific AS document must also clarify constraints, if any. - Constraint 4.1.3 Management (To be updated: More detailed metrics required!) 4.1.3.1 Configuration/Provisioning 4.1.3.2 Monitoring 4.1.3.3 Customer Management 4.1.3.4 SLA Monitoring 4.1.3.5 Security 4.1.4 migration impacts Each specific AS document must clarify - Functions required to be added from the customers'/providers' point of view. 4.2 Requirements and metrics common to L3 PPVPN approaches 4.2.1 Security Each specific AS document must clarify whether and how the following attributes are supported by the concerned PPVPN approach. - Confidentiality - Integrity - Authentication - Replay attack prevention 4.2.2 Tunneling Each specific AS document must clarify the following attributes. - Kind of supported tunneling techniques - Tunnel termination points 4.2.3 QoS Sumimoto, et al. Expires December 2002 [Page 5] INTERNET-DRAFT June 24, 2002 Each specific AS document must clarify (1)whether supported or not, (2)which link/path/tunnel to be applied (CE-CE, PE-PE, etc.), (3)what kind of services/classes, (4)how to support/operate, for each of the following by the concerned PPVPN approach. - Intserv/RSVP, - Diffserv, - Point to point (if any), - Point to cloud (if any). 4.2.4 Scalability With regard to each of the folloing factors, each specific AS document must clarify (1)what resource is pressed by the factor (e.g. VFI's table size) and (2)how (in what order) the resource is pressed (e.g. O(n) or O(n^2) or ...). - Number of tunnels/VPN sessions, - Impact of addition of new site 4.3 Requirements and metrics specific to L3 PE-based PPVPN approaches 4.3.1 Scalability With regard to each of the folloing factors, each specific AS document must clarify (1)what resource is pressed by the factor (e.g. VFI's table size) and (2)how (in what order) is the resource pressed? (e.g. O(n) or O(n^2) or ...). - Number of VPNs, (Especially, influence toward VFI's table size / number of tunnels should be considered.) - Number of sites, (Especially, influence toward VFI's table size / number of tunnels should be considered.) - Number of VRFs/VRs and interfaces per VPN, (Especially, influence toward processing overhead of a PE should be considered.) - Number of tunnels, - Number of routes per VPN, - Rate of configuration changes / impact of adding new site, (Especially, influence toward increase of controling traffic / average convergence time should be considered.) - Statefulness of mechanisms used, - Impact on routing protocols, - Performance impacts, 4.3.2 Core network requirements Sumimoto, et al. Expires December 2002 [Page 6] INTERNET-DRAFT June 24, 2002 Each specific AS document must clarify the following attributes of concerned PPVPN approach. - Routing protocol requirements, (To be more specific?) - Core router awareness of mechanisms used 4.3.3 Addressing Each specific AS document must clarify the following attributes of concerned PPVPN approach. - Private addressing (rfc 19l8) support 4.3.4 Management (To be updated: More detailed metrics required!)) 4.1.3.1 Configuration/Provisioning 4.1.3.2 Monitoring 4.1.3.3 Customer Management 4.1.3.4 Security -- Should this be here or covered above? 4.3.5 QoS and SLAs (To be updated) 4.3.5.1 SLA Monitoring 4.3.6 Auto-discovery Each specific AS document must clarify - Whether any mechanism are supported or not. If supported, it must also clarify the following attributes. - Kind of mechanism, - What is discovered by the mechanism, - Information exchanged by the mechanism 4.4 Requirements and metrics specific to L3 CE-based PPVPN approaches (To be updated) 4.4.1 Scalability - similar to 4.3, also need to address scalability of key distribution system, impacts on performance due to encryption mechanisms 4.4.2 Access network requirements (may overlap with other sections, need suggestions on how to organize this)(access types supported, Sumimoto, et al. Expires December 2002 [Page 7] INTERNET-DRAFT June 24, 2002 access qos support, access security support 4.4.3 Management (To be updated: More detailed metrics required!) There should be a few subsections here: 4.1.3.1 Configuration/Provisioning 4.1.3.2 Monitoring 4.1.3.3 Customer Management 4.1.3.4 SLA Monitoring 4.1.3.5 Security 4.4.4 QoS (To be filled out.) 4.5 Requirements and metrics common to L2 PE-based PPVPN approaches (To be checked later.) 4.5.1 Layer 3 independence Each specific AS document must clarify the following point. - L3 protocol; IP only or not 4.5.2 Auto-discovery Each specific AS document must clarify - Whether any mechanism are supported or not. If supported, it must also clarify the following attributes. - Kind of mechanism - What is discovered by the mechanism - Information exchanged by the mechanism 4.5.3 Scalability With regard to each of the following factors, each specific AS document must clarify (1)what resource is pressed by the factor (e.g. VFI's table size) and (2)how (in what order) the resource is pressed (e.g. O(n) or O(n^2) or ...). - Number of VPNs, (Especially, influence toward VSI's table size / number of tunnels Sumimoto, et al. Expires December 2002 [Page 8] INTERNET-DRAFT June 24, 2002 should be considered.) - Number of sites, (Especially, influence toward VSI's table size / number of tunnels should be considered.) - Number of VSIs and interfaces per VPN, (Especially, influence toward processing overhead of a PE should be considered.) - Rate of configuration changes / impact of adding new site, (Especially, influence toward increase of controling traffic / average convergence time should be considered.) 4.5.4 Management (To be filled out.) 4.5.5 Multicast (Needed?) Other key reqs?? 5. Security considerations (To be filled out.) 6. Acknowledgments The authors of this document would like to acknowledge the suggestions and comments received from the entire Layer 3 Applicability Statement Design Team formed in the ppvpn WG. Besides the authors, the members of the design team include Luyuan Fang, Paul Knight, Dave McDysan, Thomas Nadeau, Olivier Paridaens, Yakov Rekhter, Eric Rosen, Chandru Sargor, Benson Schliesser, Cliff Wang and Rick Wilder. 7. References [PPVPN-FR] Callon, R. et al., "A Framework for Provider Provisioned Virtual Private Networks," work in progress. [PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider Provisioned Virtual Private Networks," work in progress. [2547bis] Rosen E. et al., "BGP/MPLS VPNs," work in progress. [VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture using Virtual Routers, " work in progress. [2917bis] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture, " work in progress. [VPN-IPsec] De Clercq, J. et al., "A Framework for Provider Provisioned CE-based Virtual Private Networks using IPsec," work in progress. Sumimoto, et al. Expires December 2002 [Page 9] INTERNET-DRAFT June 24, 2002 (*) Additional references to be provided here. 8. Authors' address Junichi Sumimoto (Co-editor) NTT Information Sharing Platform Labs. 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: sumimoto.junichi@lab.ntt.co.jp Marco Carugi (Co-editor) France Telecom Research and Development Technopole Anticipa -- 2, av. Pierre Marzin 22307 Lannion cedex, France Phone : + 33 2 96 05 36 17 Email : marco.carugi@francetelecom.com Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium Email: jeremy.de_clercq@alcatel.be Ananth Nagarajan Sprint 6220 Sprint Parkway, Overland Park, KS 66251, USA Email: ananth.nagarajan@mail.sprint.com Muneyoshi Suzuki NTT Information Sharing Platform Labs. 3-9-11, Midori-cho, Musashino-shi, Tokyo 180-8585, Japan Email: suzuki.muneyoshi@lab.ntt.co.jp Sumimoto, et al. Expires December 2002 [Page 10]