idnits 2.17.00 (12 Aug 2021) /tmp/idnits2476/draft-belotti-app-statement-l1vpn-em-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2013) is 3264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ali-ccamp-rc-objective-function-metric-bound-02 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-rsvp-te-srlg-collect-02 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-te-metric-recording-01 -- No information found for draft-fedyk-ccamp-uni-extension - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sergio Belotti 2 Internet Draft Don Fedyk 3 Intended status: Informational Dimitri Papadimitriou 4 Alcatel-Lucent 5 Daniele Ceccarelli 6 Ericsson 7 Fatai Zhang 8 Huawei Technologies 9 Yuji Tochio 10 Fujitsu 12 Expires: Dec 2013 June 6, 2013 14 Applicability Statement for Layer 1 Virtual Private Network (L1VPN) 15 Enhanced Mode 16 draft-belotti-app-statement-l1vpn-em-02.txt 18 Abstract 20 This document provides an applicability statement on the use of 21 Generalized Multiprotocol Label Switching (GMPLS) protocols and 22 mechanisms to satisfy the requirements of the Layer 1 Virtual 23 Private Network (L1VPN) Enhanced Mode. 25 L1VPNs provide customer services and connectivity at layer 1 over 26 layer 1 networks. The operation of L1VPNs is divided into the Basic 27 Mode and the Enhanced Mode, where the Enhanced Mode of operation may 28 also include exchange of routing information between the layer 1 29 network and the customer domain. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that 38 other groups may also distribute working documents as Internet- 39 Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress". 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 Copyright Notice and License Notice 54 Copyright (c) 2012 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction................................................3 70 2. Conventions Used in This Document............................4 71 3. Terminology.................................................4 72 4. Existing Solutions..........................................4 73 5. General Guidelines..........................................4 74 6. Overlay Extension Service Model..............................6 75 6.1. Overview of the Service Model...........................6 76 6.2. Applicability of Existing Solutions.....................6 77 6.3. Incremental protocol extensions.........................7 78 7. Virtual Node Service Model...................................7 79 7.1. Overview of the Service Model...........................7 80 7.2. Applicability of Existing Solutions.....................8 81 8. Virtual Link Service Model...................................8 82 8.1. Overview of the Service Model...........................8 83 8.2. Applicability of Existing Solutions.....................8 84 9. Per-VPN Peer Service Model...................................8 85 9.1. Overview of the Service Model...........................8 86 9.2. Applicability of Existing Solutions.....................9 87 10. Manageability Considerations................................9 88 11. Security Considerations....................................9 89 12. IANA Considerations........................................9 90 13. References................................................10 91 13.1. Normative References..................................10 92 13.2. Informative References................................10 93 14. Acknowledgments...........................................12 94 15. Author's Addresses........................................12 96 1. Introduction 98 This document provides an applicability statement on the use of 99 existing Generalized Multiprotocol Label Switching (GMPLS) protocols 100 and mechanisms to the Layer 1 Virtual Private Network (L1VPN) 101 Enhanced Mode. 103 In particular, this document shows section by section (from Section 104 5 to 8) the applicability of GMPLS protocols and mechanisms to each 105 sub-model of the Enhanced Mode mentioned in [RFC4847]. 107 Note that discussion in this document is limited to areas where 108 GMPLS protocols and mechanisms are relevant. 110 As will be described in this document, support of the Overlay 111 Extension service model and the Virtual Node service model are well 112 covered by existing protocol mechanisms already described in other 113 documents, with only minor protocol extensions required. The Virtual 114 Link service model and the Per-VPN Peer service model are not 115 explicitly covered by existing documents, and would require 116 extension of current GMPLS protocols and mechanisms 118 Solutions should be scalable and manageable per RFC 4847. Solutions 119 should not require L1VPN state to be maintained on the P devices as 120 much as possible. 122 2. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC-2119 [RFC2119]. 128 3. Terminology 130 The reader is assumed to be familiar with the terminology in 131 [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC4026] and 132 [RFC4847], [RFC4874], [RFC5251], [RFC5253], [RFC5252] and [RFC4208]. 134 4. Existing Solutions 136 This section lists existing solution documents that describe how the 137 L1VPN Enhanced Mode may be constructed using the mechanisms of 138 GMPLS. This document draws on those solutions and explains their 139 applicability with respect to the framework described in [RFC4847]. 140 Further solution documents may be listed in a future version of this 141 document. 143 - [RFC5251] addresses L1VPN Basic Mode signaling. 144 - [RFC4208] addresses the application of GMPLS to the Overlay model. 145 - [RFC5252] describes OSPF based autodiscovery mechanisms. 147 Note that although [RFC5251] specifies signaling mechanisms for 148 L1VPN Basic Mode, it is applicable to the L1VPN Enhanced Mode, 149 unless otherwise specified. 151 5. General Guidelines 153 This section provides general guidelines for L1VPN solutions. Note 154 that applicability to specific sub-models will be separately 155 described in following sections. One important general design 156 guideline is that protocol mechanisms should be re-used where 157 possible. This means that solutions should be incremental, building 158 on existing protocol mechanisms rather than developing wholly new 159 protocols. Further, as service models are extended or developed 160 resulting in the requirement for additional functionalities, deltas 161 should be added to the protocol mechanisms rather than developing 162 new techniques. [RFC4847] describes how the service models can be 163 seen to provide "cascaded" functionality, and this should be 164 leveraged to achieve re-use of protocol extensions so that, for 165 example, it is highly desirable that the same signaling protocols 166 and extensions are used in both the Basic Mode and the Enhanced 167 Mode. 169 In addition, the following are general guidelines: 171 - The support of L1VPNs should not necessitate any change to core 172 (P)devices. Therefore, any protocol extensions made to facilitate 173 L1VPNs need to be made in a backward compatible way allowing GMPLS 174 aware P devices to continue to function. 175 - Customer (C) devices not directly involved in providing L1VPN 176 - Services should also be protected from protocol extensions made to 177 support L1VPNs. Again, such protocol extensions need to be 178 backwards compatible. Note however, that some L1VPN service models 179 allow for VPN connectivity between C devices rather than between 180 CE devices: in this case, the C devices may need to be aware of 181 protocol extensions. 182 - Solutions should aim to minimize the protocol extensions on CE 183 devices. 184 - Solutions should be scalable and manageable per RFC 4847. 185 Solutions should not require L1VPN state to be maintained on the P 186 devices as much as possible. 187 - Solutions should be secure. Providers should be able to screen and 188 protect information based on their operational policies per RFC 189 4847. 190 - Solutions should provide an operational view of the L1VPN for the 191 customer and provider. There should be a common operational and 192 management perspective in regard to other (L2 and L3) VPN services 193 per RFC 4847. 195 6. Overlay Extension Service Model 197 6.1. Overview of the Service Model 199 This service model complements the Basic Mode and may assume all of 200 the requirements, solutions and work items for that model. 202 In this service model, a CE receives from its attached PEs a list of 203 TE link addresses to which it can request a VPN connection (i.e., 204 membership information). 206 The CE may also receive some TE information concerning these CE-PE 207 links within the VPN (e.g., switching type). 209 Further information may be found in [draft-fedyk-ccamp-l1vpn-extnd- 210 overlay]. 212 The CE does not receive any of the following from the PE: 214 - Routing information about the core provider network. 215 - Information about P device addresses. 216 - Information about P-P, PE-P or PE-PE TE links. 217 - Routing information about other customer sites. The CE may have 218 access to routing information about the remainder of the VPN (C-C 219 and CE-C links), but this is exchanged by control plane tunneling 220 on the CE-CE connections and is not passed to the CE in the 221 control plane exchange between PE and CE. 223 6.2. Applicability of Existing Solutions 225 The following are required in this service model (in addition to 226 requirements in the L1VPN Basic Mode: 228 - Interactions between an edge node (CE) and it's adjacent (at the 229 data plane) core-node (PE). 230 - VPN membership information exchange between a CE and PE. 231 - CE-PE TE link information exchange between a CE and a PE. 233 RFC 4208 addresses RSVP-TE procedures between an edge-node and a 234 core-node in the overlay model. RFC5252 enables PE devices using 235 OSPF to dynamically learn about the existence of each other, and 236 attributes of configured CE links and their association with L1VPNs. 237 Furthermore, [RFC5252] allows the exchange of CE-PE TE link 238 information between a CE and a PE. 240 6.3. Incremental protocol extensions 242 It can be useful for the ingress node to be able to convey TE 243 metrics (e.g., IGP metric, TE metric, hop counts, latency, etc.) 244 that the path computation algorithm (at the remote node performing 245 route computation or expansion) can optimize for. Similarly, it can 246 be useful for the ingress node to be able to indicate a TE metric 247 bound for the loose segment being expanded by the remote node, 248 (e.g., [DRAFT-TE-METRIC-BOUND]). 249 In a similar manner, as described in [DRAFT-TE-METRIC-RECORD], there 250 are RSVP-TE requirements for the support of the automatic discovery 251 of cost, latency and latency variation attributes of an LSP. These 252 requirements are very similar to the requirement for discovering the 253 Shared Risk Link Groups (SRLGs) associated with the route taken by 254 an LSP (e.g., [DRAFT-SRLG-RECORDING]). 255 It is also possible to improve route diversity for single-homed and 256 dual-homed customer LSPs, which is a common requirement. This may 257 be achieved via signaling extensions that provide shared constraint 258 information for path diversity. Specifically, mechanisms that 259 enable communication to the node computing/expanding the LSP 260 signaled, information to exclude the route taken by a particular LSP 261 or the route taken by all LSPs belonging to a single tunnel(e.g., 262 [DRAFT-DIV-LATENCY-EXT]). 264 7. Virtual Node Service Model 266 7.1. Overview of the Service Model 268 In this service model, there is a private routing exchange between 269 the CE and the PE, or to be more precise between the CE routing 270 protocol instance and the VPN routing protocol instance running on 271 the PE. The provider network is considered as one private node from 272 the customer's perspective. The routing information exchanged 273 between the CE and the PE includes CE-PE TE link information, 274 customer network (i.e., remote CE sites), and may include TE links 275 (Forwarding Adjacencies) connecting CEs (or Cs) across the provider 276 network as well as control plane topology information from the 277 customer network (i.e., CE sites). 279 7.2. Applicability of Existing Solutions 281 The following are required in this service model: 283 - VPN routing 284 - CE-CE Label Switching Path (LSP) setup, deletion, and modification 285 signaling. 287 It is possible to use IGP-based auto-discovery (based on [RFC5252]). 289 Signaling mechanisms are covered by [RFC5251]. 291 8. Virtual Link Service Model 293 8.1. Overview of the Service Model 295 In this service model, virtual links are established between PEs. A 296 virtual link is assigned to each VPN and disclosed to the 297 corresponding CEs. The routing information exchanged between the CE 298 and the PE includes CE-PE TE links, customer network (i.e., remote 299 CE sites), virtual links (i.e., PE-PE links) assigned to each VPN, 300 and may include CE-CE (or C-C) Forwarding Adjacencies as well as 301 control plane topology from the customer network (i.e., CE sites). 303 NOTE - Resource management for a dedicated data plane is a 304 mandatory requirement for the Virtual Link service model. This 305 could be realized by assigning pre-configured FA-LSPs to each VPN 306 routing protocol instance (no protocol extensions needed) in order 307 to instantiate the necessary FAs. 309 8.2. Applicability of Existing Solutions 311 Currently, there is no solution document for this type of service 312 model. 314 9. Per-VPN Peer Service Model 316 9.1. Overview of the Service Model 318 In this service model, the provider partitions TE links within the 319 provider network per VPN. The routing information exchanged between 320 the CE and the PE includes CE-PE TE links, customer network (i.e., 321 remote CE sites), as well as partitioned portions of the provider 322 network, and may include CE-CE (or C-C) Forwarding Adjacencies and 323 control plane topology from customer network (i.e., CE sites). Note 324 that PEs may abstract routing information about the provider network 325 and advertise it to CEs. 327 Note scalability must be carefully considered for advertising 328 provider network routing information to the CE [RFC4726]. 330 9.2. Applicability of Existing Solutions 332 Currently, there is no solution document for this type of service 333 model. 335 10. Manageability Considerations 337 Section 11 of [RFC4847] describes manageability considerations for 338 L1VPNs. 340 This document defines a following new manageability requirement 341 specific for the L1VPN Enhanced Mode. 343 MIB modules MUST be available for any protocol extensions for the 344 L1VPN Enhanced Mode. 346 A future revision of this document may cover more aspects. 348 11. Security Considerations 350 Section 12 of [RFC4847] describes security considerations for 351 L1VPNs. This document defines a following new security requirements 352 specific for the L1VPN Enhanced Mode. 354 In the L1VPN Enhanced Mode, since there is a routing adjacency 355 between a CE and a PE, care must be taken whether the provider 356 network's control plane topology information is leaked to the CE. 357 Due to security concerns, this is not recommended in general, and 358 there must be a mechanism to prevent such operation. A future 359 revision of this document may cover more aspects. 361 12. IANA Considerations 363 This document requires no IANA actions. 365 13. References 367 13.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC4208] Swallow, G., et al., "Generalize Multiprotocol Label 373 Switching(GMPLS) User-Network Interface: Resource 374 ReserVation Protocol-Traffic Engineering(RSVP-TE) 375 Support for the Overlay Model," RFC 4208, October 376 2005. 378 [RFC4847] Takeda, T., Editor "Framework and Requirements Layer 379 1 Virtual Private Networks", RFC 4847, 381 [RFC5251] Fedyk, D., et al., "Layer 1 VPN Basic Mode", RFC 382 5251, July 2008. 384 [RFC5252] Bryskin, I., Berger, L., "OSPF-Based Layer 1 VPN 385 Auto-Discovery", RFC 5252, July 2008. 387 [RFC5253] Takeda, T. et al., "Applicability Statement for Layer 388 1 Virtual Private Network (L1VPN) Basic Mode", RFC 389 5253, July 2008. 391 13.2. Informative References 393 [Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic 394 requirements and architecture elements, ITU-T 395 Recommendation, September 2003. 397 [Y.1313] Y.1313 - Layer 1 Virtual Private Network service and 398 network architectures, ITU-T Recommendation, July 399 2004. 401 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, 402 "Multiprotocol label switching Architecture", RFC 403 3031, January 2001. 405 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., 406 Srinivasan, V. and G. Swallow, "RSVP-TE Extensions 407 to RSVP for LSP Tunnels", RFC 3209, December 2001. 409 [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol 410 Label Switching (GMPLS) Signaling Functional 411 Description", RFC 3471, January 2003. 413 [RFC3473] Berger, L., Editor "Generalized Multi-Protocol 414 Label Switching (GMPLS) Signaling - Resource 415 ReserVation Protocol-Traffic Engineering (RSVP-TE) 416 Extensions", RFC 3473, January 2003. 418 [RFC4202] Kompella, K., et al., "Routing Extensions in Support 419 of Generalized Multi-Protocol Label Switching 420 (GMPLS)", RFC 4202, October 2005. 422 [RFC4026] Anderssion, L., and Madsen, T., "Provider 423 Provisioned Virtual Private Network (VPN) 424 Terminology", RFC 4026, March 2005. 426 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 427 Routes - Extension to Resource ReserVation 428 Protocol-Traffic Engineering (RSVP-TE)", RFC 874, 429 April 2007. 431 [RFC4726] Farrel, A., et al., "A Framework for Inter-Domain 432 Multiprotocl Label Switching Traffic Engineering", 433 RFC 4726, November 2006. 435 [DRAFT-TE-METRIC-BOUND] Ali Z., et al., Resource ReserVation 436 Protocol - Traffic Engineering (RSVP-TE) extension 437 for signaling Objective Function and Metric Bound 438 draft-ali-ccamp-rc-objective-function-metric-bound- 439 02, work in progress 441 [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C. 442 Margaria. C, " RSVP-TE Extensions for Collecting 443 SRLG Information ", draft-ietf-ccamp-rsvp-te-srlg- 444 collect-02, work in progress. 446 [DRAFT-TE-METRIC-RECORD] ALI Z.,et al., "Resource ReserVation 447 Protocol- Traffic Engineering (RSVP-TE) extension 448 for recording TE Metric of a Label Switched Path", 449 draft-ietf-ccamp-te-metric-recording-01.txt, work 450 in progress. 452 [DRAFT-DIV-LATENCY-EXT] Fedyk D., et al., "Layer 1 VPN Enhanced 453 Mode - Overlay Extension Service Model", draft- 454 fedyk-ccamp-uni-extension-01, work in progress. 456 14. Acknowledgments 458 The authors would like to thank the editor and authors of draft- 459 ietf-l1vpn-applicability-enhanced-mode (Tomonori Takeda, Hamid Ould- 460 Brahim, Adrian Farrel, Deborah Brungard) and the members of the 461 L1VPN working group for their contribution, in recognition that most 462 of the text in this draft derives from their effort. 464 The authors would also like to thank Dieter Beller, Lieven Levrau, 465 and Eve Varma for their contributions to this work. 467 15. Author's Addresses 469 Sergio Belotti (Alcatel-Lucent) 470 VIA TRENTO 30 471 20059 Vimercate 472 Italy 473 Phone: +39 039 686 3033 474 sergio.belotti@alcatel-lucent.com 476 Don Fedyk (Alcatel-Lucent) 477 Groton,MA 01450 478 United States 479 Phone: +1 978 467 5645 480 Email: Donald.Fedyk@alcatel-lucent.com 482 Dimitri Papadimitriou (Alcatel-Lucent) 483 Copernicuslaan 50 484 2018 Antwerp 485 Belgium 486 Phone: +32 3 2408491 487 Email: dimitri.papadimitriou@alcatel-lucent.com 489 Daniele Ceccarelli (Ericsson) 490 Via A. Negrone 1/A 491 Genova - Sestri Ponente 492 Italy 493 Email: daniele.ceccarelli@ericsson.com 495 Fatai Zhang 496 Huawei Technologies 497 F3-5-B R&D Center, Huawei Base 498 Shenzhen 518129 P.R.China Bantian, Longgang District 499 Phone: +86-755-28972912 500 Email: zhangfatai@huawei.com 502 Yuji Tochio (Fujitsu) 503 4-1-1 Kamikodanaka, Nakahara-Ku 504 Kawasaki 505 Japan 506 Email: tochio@jp.fujitsu.com