idnits 2.17.1 draft-sumimoto-ppvpn-applicability-guidelines-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 426 has weird spacing: '..., H. et al., ...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2002) is 8091 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPN-FR' -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPN-REQ' -- Possible downref: Non-RFC (?) normative reference: ref. '2547bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-VR' -- Possible downref: Non-RFC (?) normative reference: ref. '2917bis' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-IPsec' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Sumimoto 3 INTERNET-DRAFT NTT 4 M. Carugi 5 Expires September 2002 France Telecom 6 (Co-editors) 8 J. De Clercq 9 Alcatel 10 A. Nagarajan 11 Sprint 12 M. Suzuki 13 NTT 15 March 1, 2002 17 Guidelines of Applicability Statements for PPVPNs 19 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document is expected to be guidelines to assist development of 45 applicability statements for each PPVPN approach by providing a 46 check-list which consists of requirements/metrics. This check-list is 47 systematically composed of (i)requirements and metrics common to all 48 PPVPNs, (ii)requirements and metrics common to L3 PPVPN approaches, 49 (iii)requirements and metrics specific to L3 PE-based PPVPN 50 approaches, (iv)requirements and metrics specific to L3 CE-based 51 PPVPN approaches and (v)requirements and metrics common to L2 PPVPN 52 approaches, according to the classification of PPVPN approaches. 54 1. Summary for Sub-IP Area 56 1.1 Summary 58 This document is expected to be guidelines to assist development of 59 applicability statements of PPVPNs by providing a check-list which 60 consists of requirements/metrics. PPVPNs are classified into multiple 61 specific PPVPN approaches based on their characteristics. These PPVPN 62 approaches closely relate each other by sharing a portion of the 63 characteristics. Therefore, it is necessary to provide a check-list 64 for developing applicability statements of each PPVPN approach by 65 extracting requirements/metrics according to the mechanisms of PPVPN 66 approaches out of the service requirements of the requirements 67 documents. This document systematically provides such a check-list 68 along with the classification of PPVPN approaches. 70 1.2 Where does it fit in the Picture of the Sub-IP Work 72 This document fits in ppvpn WG. 74 1.3 Why is it Targeted at this WG 76 The ppvpn charter clearly defines development of applicability 77 statements documents for PPVPN approaches as a working item of ppvpn 78 WG. Since this document is expected to assist these approach specific 79 applicability statements documents, ppvpn WG is appropriate as the 80 home of this document. 82 (*)We do not need justification as this document directly fits in ppvpn 83 WG. 85 2. Introduction 87 *** Goal and Role (This comment is to be deleted) *** 89 The term "PPVPNs"refers to Virtual Private Networks (VPNs) for which 90 the service provider participates in management and provisioning of 91 the VPN. PPVPNs can be classified into several PPVPN classes based on 92 their characteristics, and these PPVPN classes closely relate each 93 other by sharing some portion of the characteristics. Therefore, so 94 as to make approach-specific applicability statements significant, it 95 is necessary to systematically extract requirements/metrics directly 96 relating to protocols/mechanisms out of the service requirements 97 described in the requirements documents[PPVPN-REQ]. This document 98 provides a check-list which consists of the extracted 99 requirements/metrics. Each metric in the list is intended to clearly 100 point out what must be written in each approach specific 101 applicability statements documents, thus detailed description with 102 regard to the metric is out of scope of this document. 104 *** Scope and Organization (This comment is to be deleted) *** 106 PPVPN approaches for which applicability statements are to be 107 developed are, 108 - BGP MPLS VPNs[2547bis] and VR VPNs[VPN-VR, 2917bis] as L3 109 PE-based PPVPNs, 110 - IPsec VPNs[VPN-IPsec] as L3 CE-based PPVPNs, 111 - BGP signaled L2VPNs[], LDP signaled L2VPNs (with/without 112 Directory)[], RSVP signaled L2VPNs[] as L2 PE-based PPVPNs. 113 (To be updated) 114 Definition and classification of PPVPN approaches are overviewed in 115 Section 3. Section 4 provides list and outline of 116 requirements/metrics systematically according to the classification 117 of PPVPN approaches. Section 5 is for security considerations, and 118 section 6 is for references. 120 3. PPVPN technical overview 122 This section provides a brief overview on the various types of PPVPNs 123 as an introductory guidance toward discussions in the rest of this 124 document and in developing approach-specific applicability statements 125 documents. Detailed description is provided in the framework 126 document[PPVPN-FR]. 128 PPVPNs can be classified into 129 - L3 PPVPNs / L2 PPVPNs 130 from the viewpoint of service layer for customers. On the other hand, 131 PPVPNs can be classified into 132 - PE based PPVPNs / CE-based PPVPNs 133 by the terminating point of VPN tunnels. Since these two keys of 134 classification are independent each other, four PPVPN classes are 135 defined after all. The rest of this section briefly overview each of 136 L3 PE-based VPNs, L3 CE-based VPNs, and L2 PE-based VPNs, out of the 137 four classes, which is covered by the following sections of this 138 document. 140 - Layer 3 PE-based VPNs 142 A layer 3 PE-based VPN is one in which PE devices in the SP network 143 provide the VPN-specific functions and SP forwards packets based on 144 layer 3 information. BGP MPLS and VR approach are included in this 145 class. 147 - Layer 3 CE-based VPNs 149 In CE-based VPNs, the VPN-specific functions (e.g. tunneling) are 150 deployed in the CE devices, while the provider network has no VPN 151 awareness on the data-plane level. SP forwards packets based on 152 layer 3 information. IPsec VPN is included in this class. 154 - Layer 2 PE-based VPNs 156 A layer 2 PE-based VPN is one in which PE devices in the SP network 157 provide the VPN-specific functions and SP forwards packets based on 158 layer 2 information. BGP signaled L2VPNs, LDP signaled L2VPNs 159 (with/without Directory), and RSVP signaled L2VPNs are included in 160 this class. 162 4. List and outline of requirements and metrics for evaluating each 163 PPVPN approach 165 This section provides list and outline of requirements/metrics common 166 to all PPVPNs (in Section 4.1), common to L3 PPVPN approaches (in 167 Section 4.2), specific to L3 PE-based PPVPN approaches (in Section 168 4.3), specific to L3 CE-based PPVPN approaches (in Section 4.4) and 169 common to L2 PE-based PPVPN approaches (in Section 4.5), according to 170 the classification of PPVPN approaches. Note that 171 requirements/metrics for a higher PPVPN class must apply to any 172 inheriting lower PPVPN classes (maybe concurrently, if multiple lower 173 PPVPN classes provisioned in an SP network concurrently). For 174 example, VR approach must be checked not only by requirements/metrics 175 for specific to L3 PE-based PPVPN approaches but also by 176 requirements/metrics common to all PPVPNs and common to L3 PPVPN 177 approaches. In this section, AS stands for Applicability Statements. 179 4.1 Requirements and metrics common to all PPVPNs 181 4.1.1 Isolated exchange of routing and data information 183 Each specific AS document must clarify whether and how the following 184 attributes are implemented by the concerned PPVPN approach. 186 - Isolated data forwarding (mandatory) 187 - Isolated routing (i.e. constrained distribution of reachability 188 to only VPN sites) 189 (internal topology of VPN should not be visible to the shared 190 public network (Internet)) 192 4.1.2 Overlapping customer address space 194 Each specific AS document must clarify whether and how the following 195 attributes are implemented by the concerned PPVPN approach. 197 - Support of non-unique customer addresses 198 - Support of private addresses 200 Each specific AS document must also clarify constraints, if any. 202 - Constraint 204 4.1.3 Management (To be updated: More detailed metrics required!) 206 4.1.3.1 Configuration/Provisioning 208 4.1.3.2 Monitoring 210 4.1.3.3 Customer Management 212 4.1.3.4 SLA Monitoring 214 4.1.3.5 Security 216 4.1.4 migration impacts 218 Each specific AS document must clarify 220 - Functions required to be added from the customers'/providers' 221 point of view. 223 4.2 Requirements and metrics common to L3 PPVPN approaches 225 4.2.1 Security 227 Each specific AS document must clarify whether and how the following 228 attributes are supported by the concerned PPVPN approach. 230 - Confidentiality 231 - Integrity 232 - Authentication 233 - Replay attack prevention 235 4.2.2 Tunneling 237 Each specific AS document must clarify the following attributes. 239 - Kind of supported tunneling techniques 240 - Tunnel termination points 242 4.2.3 QoS 243 Each specific AS document must clarify (1)whether supported or not, 244 (2)which link/path/tunnel to be applied (CE-CE, PE-PE, etc.), (3)what 245 kind of services/classes, (4)how to support/operate, for each of the 246 following by the concerned PPVPN approach. 248 - Intserv/RSVP, 249 - Diffserv, 250 - Point to point (if any), 251 - Point to cloud (if any). 253 4.2.4 Scalability 255 With regard to each of the folloing factors, each specific AS 256 document must clarify (1)what resource is pressed by the factor (e.g. 257 VFI's table size) and (2)how (in what order) the resource is pressed 258 (e.g. O(n) or O(n^2) or ...). 260 - Number of tunnels/VPN sessions, 261 - Impact of addition of new site 263 4.3 Requirements and metrics specific to L3 PE-based PPVPN approaches 265 4.3.1 Scalability 267 With regard to each of the folloing factors, each specific AS 268 document must clarify (1)what resource is pressed by the factor (e.g. 269 VFI's table size) and (2)how (in what order) is the resource pressed? 270 (e.g. O(n) or O(n^2) or ...). 272 - Number of VPNs, 273 (Especially, influence toward VFI's table size / number of tunnels 274 should be considered.) 275 - Number of sites, 276 (Especially, influence toward VFI's table size / number of tunnels 277 should be considered.) 278 - Number of VRFs/VRs and interfaces per VPN, 279 (Especially, influence toward processing overhead of a PE should 280 be considered.) 281 - Number of tunnels, 282 - Number of routes per VPN, 283 - Rate of configuration changes / impact of adding new site, 284 (Especially, influence toward increase of controling traffic / 285 average convergence time should be considered.) 286 - Statefulness of mechanisms used, 287 - Impact on routing protocols, 288 - Performance impacts, 290 4.3.2 Core network requirements 291 Each specific AS document must clarify the following attributes of 292 concerned PPVPN approach. 294 - Routing protocol requirements, (To be more specific?) 295 - Core router awareness of mechanisms used 297 4.3.3 Addressing 299 Each specific AS document must clarify the following attributes of 300 concerned PPVPN approach. 302 - Private addressing (rfc 19l8) support 304 4.3.4 Management (To be updated: More detailed metrics required!)) 306 4.1.3.1 Configuration/Provisioning 308 4.1.3.2 Monitoring 310 4.1.3.3 Customer Management 312 4.1.3.4 Security -- Should this be here or covered above? 314 4.3.5 QoS and SLAs (To be updated) 316 4.3.5.1 SLA Monitoring 318 4.3.6 Auto-discovery 320 Each specific AS document must clarify 322 - Whether any mechanism are supported or not. 324 If supported, it must also clarify the following attributes. 326 - Kind of mechanism, 327 - What is discovered by the mechanism, 328 - Information exchanged by the mechanism 330 4.4 Requirements and metrics specific to L3 CE-based PPVPN approaches 331 (To be updated) 333 4.4.1 Scalability - similar to 4.3, also need to address scalability 334 of key distribution system, impacts on performance due to encryption 335 mechanisms 337 4.4.2 Access network requirements (may overlap with other sections, 338 need suggestions on how to organize this)(access types supported, 339 access qos support, access security support 341 4.4.3 Management (To be updated: More detailed metrics required!) 343 There should be a few subsections here: 345 4.1.3.1 Configuration/Provisioning 347 4.1.3.2 Monitoring 349 4.1.3.3 Customer Management 351 4.1.3.4 SLA Monitoring 353 4.1.3.5 Security 355 4.4.4 QoS (To be filled out.) 357 4.5 Requirements and metrics common to L2 PE-based PPVPN approaches 358 (To be checked later.) 360 4.5.1 Layer 3 independence 362 Each specific AS document must clarify the following point. 364 - L3 protocol; IP only or not 366 4.5.2 Auto-discovery 368 Each specific AS document must clarify 370 - Whether any mechanism are supported or not. 372 If supported, it must also clarify the following attributes. 374 - Kind of mechanism 375 - What is discovered by the mechanism 376 - Information exchanged by the mechanism 378 4.5.3 Scalability 380 With regard to each of the folloing factors, each specific AS 381 document must clarify (1)what resource is pressed by the factor (e.g. 382 VFI's table size) and (2)how (in what order) the resource is pressed 383 (e.g. O(n) or O(n^2) or ...). 385 - Number of VPNs, 386 (Especially, influence toward VSI's table size / number of tunnels 387 should be considered.) 388 - Number of sites, 389 (Especially, influence toward VSI's table size / number of tunnels 390 should be considered.) 391 - Number of VSIs and interfaces per VPN, 392 (Especially, influence toward processing overhead of a PE should 393 be considered.) 394 - Rate of configuration changes / impact of adding new site, 395 (Especially, influence toward increase of controling traffic / 396 average convergence time should be considered.) 398 4.5.4 Management (To be filled out.) 400 4.5.5 Multicast (Needed?) 402 Other key reqs?? 404 5. Security considerations (To be filled out.) 406 6. Acknowledgments 408 The authors of this document would like to acknowledge the 409 suggestions and comments received from the entire Layer 3 410 Applicability Statement Design Team formed in the ppvpn WG. Besides 411 the authors, the members of the design team include Luyuan Fang, Paul 412 Knight, Dave McDysan, Thomas Nadeau, Olivier Paridaens, Yakov 413 Rekhter, Eric Rosen, Chandru Sargor, Benson Schliesser, Cliff Wang 414 and Rick Wilder. 416 7. References 418 [PPVPN-FR] Callon, R. et al., "A Framework for Provider Provisioned 419 Virtual Private Networks," work in progress. 421 [PPVPN-REQ] Carugi, M. et al., "Service Requirements for Provider 422 Provisioned Virtual Private Networks," work in progress. 424 [2547bis] Rosen E. et al., "BGP/MPLS VPNs," work in progress. 426 [VPN-VR] Ould-Brahim, H. et al., "Network based IP VPN Architecture 427 using Virtual Routers, " work in progress. 429 [2917bis] Muthukrishnan, K. et al., "A Core MPLS IP VPN Architecture, 430 " work in progress. 432 [VPN-IPsec] De Clercq, J. et al., "A Framework for Provider 433 Provisioned CE-based Virtual Private Networks using IPsec," work 434 in progress. 436 (*) Additional references to be provided here. 438 8. Authors' address 440 Junichi Sumimoto (Co-editor) 441 NTT Information Sharing Platform Labs. 442 3-9-11, Midori-Cho 443 Musashino-Shi, Tokyo 180-8585 Japan 444 Email: sumimoto.junichi@lab.ntt.co.jp 446 Marco Carugi (Co-editor) 447 France Telecom Research and Development 448 Technopole Anticipa -- 2, av. Pierre Marzin 449 22307 Lannion cedex, France 450 Phone : + 33 2 96 05 36 17 451 Email : marco.carugi@francetelecom.com 453 Jeremy De Clercq 454 Alcatel 455 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 456 Email: jeremy.de_clercq@alcatel.be 458 Ananth Nagarajan 459 Sprint 460 9300 Metcalf Ave, 461 Overland Park, KS 66212, USA 462 Email: ananth.nagarajan@mail.sprint.com 464 Muneyoshi Suzuki 465 NTT Information Sharing Platform Labs. 466 3-9-11, Midori-cho, 467 Musashino-shi, Tokyo 180-8585, Japan 468 Email: suzuki.muneyoshi@lab.ntt.co.jp