idnits 2.17.1 draft-ietf-l3vpn-applicability-guidelines-00.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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 375 has weird spacing: '...metrics are l...' == Line 426 has weird spacing: '..., A. 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 (June 27, 2003) is 7608 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) == Unused Reference: 'IPsecVPN AS' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'VR AS' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '2547BIS AS' is defined on line 429, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GEN REQTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'L3 REQTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2 REQTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TERMINOLOGY' -- Obsolete informational reference (is this intentional?): RFC 2547 (Obsoleted by RFC 4364) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 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 December 2003 Nortel Networks 6 (Co-editors) 8 J. De Clercq 9 Alcatel 10 A. Nagarajan 11 Consultant 12 M. Suzuki 13 NTT 15 June 27, 2003 17 Guidelines of Applicability Statements for PPVPNs 18 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Abstract 43 This document plays a role of guidelines to assist development of 44 applicability statements for each specific Layer 2 and Layer 3 PPVPN 45 approach. It provides a check-list which consists of metrics, each of 46 which is intended to clearly point out what must be evaluated and 47 written in each approach specific applicability statement document. 49 1. Introduction 50 The term Provider Provisioned Virtual Private Network (PPVPN) refers 51 to Virtual Private Networks (VPNs) for which the service provider 52 participates in management and provisioning of the VPN. PPVPNs can be 53 classified into various PPVPN types based on their characteristics, 54 and requirements for PPVPNs are described in three separate 55 documents, [GEN REQTS], [L3 REQTS], and [L2 REQTS]. This document 56 extracts metrics directly relating to protocols/mechanisms out of 57 provider/service/engineering requirements for PPVPNs described in the 58 three requirements documents so as to make approach specific 59 applicability statements significant. The extracted metrics in this 60 document form a check-list, each of which is intended to clearly 61 point out what must be evaluated and written in each approach 62 specific applicability statement document. Detailed description with 63 regard to the metrics is out of scope of this document. 64 Section 2 reviews taxonomy of PPVPN types for which metrics are 65 listed in this document. Section 3 provides list and outline of 66 metrics. Section 4 is for security considerations, Section 5 is for 67 acknowledgement and section 6 is for references. 69 2. Taxonomy of PPVPNs 71 The terminology used in this document is defined in [TERMINOLOGY]. 73 PPVPN 74 ________________|__________________ 75 | | 76 Layer 2 Layer 3 77 ______|_____ _______|________ 78 | | | | 79 P2P P2M PE-based CE-based 80 (VPWS) ___|______ _______|_____ | 81 | | | | | 82 VPLS IPLS RFC2547 Virtual IPsec 83 Style Router 85 Figure. 2.1 PPVPN taxonomy 87 The figure above presents taxonomy of PPVPN approaches. Note that 88 CE-based Layer 2 PPVPNs may also be further classified as point-to- 89 point (P2P) or point-to-multipoint (P2M), and P2M PPVPNs may also be 90 further classified as Virtual Private LAN Service (VPLS) and IP-only 91 LAN-like Service (IPLS). Definitions for layer 3 PPVPNs can be 92 obtained from [L3 FWK] and definitions for layer 2 PPVPNs can be 93 obtained from [L2 FWK]. 95 3. List and outline of metrics for evaluating each PPVPN approach 96 This section provides list and outline of metrics generic to L3 and 97 L2 PPVPN approaches (in Section 3.1), specific to L3 PPVPN approaches 98 (in Section 3.2) and specific to L2 PPVPN approaches (in Section 99 3.3). Each L3 PPVPN approach is to be evaluated by using both generic 100 and L3 specific metrics. Similarly, each L2 PPVPN approach is to be 101 evaluated by using both generic and L2 specific metrics. In this 102 document, AS stands for Applicability Statements. 104 3.1 Generic metrics 106 This section provides metrics generic to layer 3 and layer 2 PPVPN 107 approaches. 109 3.1.1 Isolated exchange of routing and data information 111 Each specific AS document must clarify whether and how the following 112 attributes are implemented by the concerned PPVPN approach. 114 - Isolated data forwarding (mandatory) 116 - Isolated routing (i.e. constrained distribution of reachability to 117 only VPN sites) 118 (Internal topology of VPN should not be visible to the shared 119 public network (Internet)) 121 3.1.2 Security 123 Each specific AS document must clarify whether and how the following 124 attributes of user security are supported by the concerned PPVPN 125 approach. 127 - Confidentiality 129 - Integrity 131 - Authentication 133 - Replay attack prevention 135 Additionally, each specific AS document must clarify how the 136 following security attributes with regard to setup/operation are 137 protected by the concerned PPVPN approach. 139 - Protocol attacks 141 - Unauthorized access 143 - Tampering with signaling 145 3.1.3 Tunneling 147 Each specific AS document must clarify the following attributes. 149 - Kind of supported tunneling techniques 151 - Tunnel termination points 153 3.1.4 QoS 155 Each specific AS document must clarify if the following types of QoS 156 are supported or not, and how they are supported. 158 - Intserv/RSVP (Customer usage/Provider usage) 160 - Diffserv (Customer usage/Provider usage) 162 - Point to point 164 - Point to cloud 166 3.1.5 Auto-discovery 168 Each specific AS document must clarify 170 - Whether any mechanism are supported or not 172 If supported, it must also clarify the following attributes. 174 - Kind of mechanism 176 - What is discovered by the mechanism 178 - Information exchanged by the mechanism 180 3.1.6 Scalability 182 With regard to each of the following factors, each specific AS 183 document must clarify (1) what resource is pressed by the factor 184 (e.g. VFI's table size) and (2) how (in what order) is the resource 185 pressed? (E.g. O(n) or O(n^2) or ...). VFI stands for Virtual 186 Forwarding Instance, and VSI stands for Virtual Switching Instance 187 (for more detail, see framework documents). 189 - Number of VPNs 190 (Especially, influence toward VFI/VSI's table size / number of 191 tunnels should be considered.) 193 - Number of sites 194 (Especially, influence toward VFI/VSI's table size / number of 195 tunnels should be considered.) 197 - Number of routes per VPN 199 - Rate of configuration changes / impact of adding new site 200 (Especially, influence toward increase of controlling traffic / 201 average convergence time should be considered.) 203 - Number of users per VPN 205 - Number of addresses per VPN 207 - Number of PEs and/or CEs 209 - Number of VRFs/VRs and interfaces per PE (for only PE-based L3 VPN 210 approaches), 211 (Especially, influence toward processing overhead of a PE should 212 be considered.) 214 - Number of tunnels 216 3.1.7 Management 218 Each specific AS document must clarify (1) whether each of the 219 following aspects of management are supported or not by the concerned 220 PPVPN approach, and (2) how they are supported. 222 - Configuration/Provisioning 223 VPN membership, tunnels, network access, routing protocols, etc. 225 - Performance/SLA 226 Monitoring/Accounting states and statistics. 228 - Security 229 Access control, authentication, etc. 231 - Fault 232 Detection, localization, and corrective actions. 234 - Customer Management 235 Capabilities of customers to view the topology, operational state, 236 order status, and other parameters associated with their VPN 238 3.1.8 Traffic types 240 Each specific AS document must clarify whether and how the following 241 types of traffic are supported or not. 243 - Unicast or point-to-point 245 - Multicast or point-to-multipoint 247 - Broadcast 249 3.1.9 Temporary access 251 Besides permanent access which is mandatory to all PPVPN approach, 252 each specific AS document must clarify (1) whether supported or not, 253 and (2) how to support, 255 - Temporary access 257 3.1.10 Migration impacts 259 Each specific AS document must clarify 261 - Functions required to be added to legacy devices from the 262 customers' and providers' point of view. 264 3.1.11 Interworking 266 Interworking scenarios among different solutions providing PPVPN 267 services is highly desirable. If any constraints exist in a PPVPN 268 approach, the corresponding specific AS document must show the 269 constraints and their influence. 271 3.2 Metrics specific to L3 PPVPN approaches 273 This section provides metrics specific to L3 PPVPN approaches. Each 274 specific L3 PPVPN approach must be checked by these L3 specific 275 metrics as well as generic metrics provided in the former sections. 277 3.2.1 Addressing 279 Each specific AS document must clarify whether overlapping customer 280 IP addresses in different VPNs are supported or not. 282 3.2.2 IP Routing Protocol Support for Customer 284 At least the following protocols must be supported between CE and PE 285 routers, or between CE routers: static routing, IGP, such as RIP, 286 OSPF, IS-IS, and BGP. If there exists any restriction in a PPVPN 287 approach, it must be described in the specific AS document concerning 288 the PPVPN approach. 290 3.2.3 Core network requirements 292 Each specific AS document must clarify the following attributes of 293 concerned PPVPN approach. 295 - Routing protocols applicable to SP network routing 297 - Core router awareness of mechanisms used 299 3.3 Metrics specific to L2 PPVPN approaches 301 This section provides metrics specific to L2 PPVPN approaches. Each 302 specific L2 PPVPN approach must be checked by these L2 specific 303 metrics as well as generic metrics provided in the former sections. 304 VPLS stands for Virtual Private LAN Service (for more detail, see [L2 305 FWK]). 307 3.3.1 Scope/Accuracy of Emulation 309 Each specific AS document must clarify the following attributes of 310 concerned PPVPN approach. 312 - Difference between L2 VPN protocol and specification at customer 313 interface and existing native protocols and specification (if 314 exists) 316 3.3.2 Addressing 318 Each specific AS document must clarify 320 - Whether overlapping customer L2 addresses in different VPNs 321 are supported or not 323 - Whether overlapping VLAN IDs for different customer are supported 324 or not (in case of VPLS supporting VLANs) 326 3.3.3 Loop Prevention of L2 topology 328 Each specific AS document must clarify 330 - Whether any mechanism are supported or not. (Especially, is STP 331 supported?) 333 If any mechanism supported, it must also clarify the following 334 attributes. 336 - Kind/scope of the mechanism. (Especially, is STP supported? 337 Is Split horizon scheme over mesh topology adopted?) 339 3.3.4 Packet re-ordering 341 Each specific AS document must clarify the following attributes. 343 - Possibility of packet re-ordering 345 - Influence of packet re-ordering 347 3.3.5 Minimum MTU 349 Each specific AS document must clarify the following attributes. 351 - Support of MTU specified for the layer 2 technology 352 (including consistency with inserting VLAN tag) 354 - Guarantee of prohibition of frame fragmentation 356 3.3.6 Support for MAC Services (only for VPLS) 358 Each specific AS document must clarify whether MAC services (see the 359 following examples) are supported or not by the concerned PPVPN 360 approach. 362 - Filtering of frames 364 - Flooding 366 - Creation of address table 368 - Aging of address table 370 If any constraints exist in a PPVPN approach, the corresponding 371 specific AS document must show the constraints and their influence. 373 3.3.7 Scalability 375 L2 specific scalability metrics are listed in this section. For 376 generic scalability metrics, see section 3.1.6. 378 Each specific AS document must clarify scalability concern specific 379 to L2 VPN control protocol including signaling. Especially, 380 scalability concern caused by use of STP must be clarified in case of 381 VPLS. 383 4. Security considerations 385 There are no additional security considerations besides those already 386 described in this document. 388 5. Acknowledgments 390 The authors of this document would like to acknowledge the 391 suggestions and comments received from the entire Layer 3 392 Applicability Statement Design Team formed in the ppvpn WG. Besides 393 the authors, the members of the design team include Luyuan Fang, Paul 394 Knight, Dave McDysan, Thomas Nadeau, Olivier Paridaens, Yakov 395 Rekhter, Eric Rosen, Chandru Sargor, Benson Schliesser, Cliff Wang 396 and Rick Wilder. 398 6. References 400 6.1 Normative References 402 [GEN REQTS] Nagarajan, A., "Generic Requirements for Provider 403 Provisioned VPN," Work in Progress. 405 [L3 REQTS] Carugi, M. et al., "Service Requirements for Provider 406 Provisioned Virtual Private Networks," work in progress. 408 [L2 REQTS] Augustyn, W., Serbest, Y., et al., "Service Requirements 409 for Layer 2 Provider Provisioned Virtual Private Networks", work 410 in progress 412 [TERMINOLOGY] Andersson, L., Madsen, T., "PPVPN Terminology", work in 413 progress. 415 6.2 Informative References 417 [L3 FWK] Callon, R. et al., "A Framework for Provider Provisioned 418 Virtual Private Networks," work in progress. 420 [L2 FWK] Andersson, L., et al., "L2VPN Framework", work in progress. 422 [IPsecVPN AS] De Clercq, J. et al., "Applicability Statement for 423 Provider Provisioned CE-based Virtual Private Networks using 424 IPsec," work in progress. 426 [VR AS] Nagarajan, A. et al., "Applicability Statement for Virtual 427 Router-based Layer 3 PPVPN approaches," work in progress. 429 [2547BIS AS] Rosen, E. et al., "Applicability Statement for VPNs 430 Based on rfc2547bis," work in progress. 432 7. Authors' address 434 Junichi Sumimoto (Co-editor) 435 NTT Information Sharing Platform Labs. 437 3-9-11, Midori-Cho 438 Musashino-Shi, Tokyo 180-8585 Japan 439 Email: sumimoto.junichi@lab.ntt.co.jp 441 Marco Carugi (Co-editor) 442 Nortel Networks S.A. 443 Parc d'activites de Magny - Les Jeunes Bois - Chateaufort 444 78928 YVELINES Cedex - FRANCE 445 Email: marco.carugi@nortelnetworks.com 447 Jeremy De Clercq 448 Alcatel 449 Fr. Wellesplein 1, 2018 Antwerpen, Belgium 450 Email: jeremy.de_clercq@alcatel.be 452 Ananth Nagarajan 453 Consultant 454 Email: ananth@maoz.com 456 Muneyoshi Suzuki 457 NTT Information Sharing Platform Labs. 458 3-9-11, Midori-cho, 459 Musashino-shi, Tokyo 180-8585, Japan 460 Email: suzuki.muneyoshi@lab.ntt.co.jp