idnits 2.17.1 draft-aguado-opsawg-l3sm-l3nm-00.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 69 characters in excess of 72. ** The abstract seems to contain references ([RFC8309], [RFC8299]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 367 has weird spacing: '...et-type rt-...' == Line 381 has weird spacing: '...vlan-id uin...' == Line 386 has weird spacing: '...vlan-id uin...' == Line 387 has weird spacing: '...vlan-id uin...' == Line 390 has weird spacing: '...vlan-id uin...' == (1 more instance...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 21, 2019) is 1795 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) == Missing Reference: 'RFC8453' is mentioned on line 205, but not defined == Missing Reference: 'I-D.evenwu-opsawg-yang-composed-vpn' is mentioned on line 125, but not defined == Missing Reference: 'RFC8340' is mentioned on line 133, but not defined == Missing Reference: 'RFC8466' is mentioned on line 271, but not defined Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Aguado 3 Internet-Draft O. Gonzalez de Dios, Ed. 4 Intended status: Standards Track V. Lopez 5 Expires: November 22, 2019 Telefonica 6 D. Voyer 7 Bell Canada 8 L. Munoz 9 Vodafone 10 May 21, 2019 12 Layer 3 VPN Network Model 13 draft-aguado-opsawg-l3sm-l3nm-00 15 Abstract 17 RFC 8299 [RFC8299] defines a L3VPN Service Model (L3SM) YANG data 18 model that can be used for communication between customers and 19 network operators. It assumes that there is a monolithic management 20 system with full control of transport resources. This approach (that 21 is valid for the customer to network operator conversation) limits 22 the usage of the model to the role of a Customer Service Model, 23 according to the terminology defined in RFC 8309 [RFC8309]. 25 There is a need for a YANG model for use between the entity that 26 interacts directly with the customer (service orchestrator) and the 27 entity in charge of network orchestration and control which, 28 according to RFC 8309 [RFC8309], can be referred as Service Delivery 29 Model. In some cases, the control of the network is further expanded 30 into per- domain control. 32 This document uses the L3SM model defined in RFC 8299 [RFC8299], and 33 extends it to facilitate communication between the service 34 orchestrator and transport orchestrator (MSDC), and an MDSC and 35 domain controllers. The resulting model is called the L3VPN Network 36 Model (L3NM). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 22, 2019. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 74 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 75 2. Reference architecture . . . . . . . . . . . . . . . . . . . 4 76 3. Yang model extensions . . . . . . . . . . . . . . . . . . . . 7 77 3.1. Bearer ethernet Encapsulation . . . . . . . . . . . . . . 8 78 3.2. Multi-Domain Resource Management . . . . . . . . . . . . 8 79 3.3. Remote Far-End Configuration . . . . . . . . . . . . . . 8 80 3.4. Provide Edge Identification Point . . . . . . . . . . . . 9 81 4. Design of the data model . . . . . . . . . . . . . . . . . . 9 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 87 8.2. Informative References . . . . . . . . . . . . . . . . . 12 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 90 1. Introduction 92 RFC 8299 [RFC8299] defines a L3VPN Service Model (L3SM) YANG data 93 model that can be used for communication between customers and 94 network operators. Although the intention to provide an abstracted 95 view of the customer's requested services is clear, the assumption is 96 that the model is applied at the top of a monolithic management 97 system with full control of transport resources. That assumption 98 substantially limits the usage of the L3SM to the role of a Customer 99 Service Model, according to the terminology defined in RFC 8309 100 [RFC8309]. 102 This document defines a set of extensions of the YANG model described 103 in RFC 8299 [RFC8299] via augmentation. The augmentations facilitate 104 the use the resulting model in communications with the transport 105 orchestrator, also known as the MDSC (Multi-Domain Service 106 Coordinator) in the terminology of the framework for Abstraction and 107 Control of TE Networks (ACTN) defined in RFC 8453 [RFC8453]. The 108 MDSC is functional component responsible for orchestration of the 109 network resources and instigate connections across the operator's 110 networks. 112 The data model defined in this document is called the L3VPN Network 113 Model (L3NM). It enables further capabilities, such as resource 114 management or to serve as a multi-domain orchestration interface, 115 where transport resources must be synchronized. 117 This document does not obsolete, but complements, the definitions in 118 RFC 8299 [RFC8299]. It aims to provide a wider scope for the L3SM 119 via augmentation, but does not attempt to address all deployment 120 cases especially those where the L3VPN connectivity is supported 121 through the coordination of different VPNs in different underlying 122 networks. More complex deployment scenarios involving the 123 coordination of different VPN instances and different technologies to 124 provide end-to-end VPN connectivity is out of scope of this document, 125 but is discussed in [I-D.evenwu-opsawg-yang-composed-vpn]. 127 1.1. Terminology 129 This document assumes that the reader is familiar with the contents 130 of RFC 6241 [RFC6241], RFC 7950 [RFC7950], RFC 8299 [RFC8299], 131 RFC 8309 [RFC8309], and [RFC8453] and uses terminology from those 132 documents. Tree diagrams used in this document follow the notation 133 defined in [RFC8340]. 135 1.2. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. Reference architecture 143 Figure 1 shows where the L3NM is used in a management stack. The 144 figure is an expansion of the architecture presented in Section 5 of 145 RFC 8299 [RFC8299] and decomposes the box marked "orchestration" in 146 that figure into three separate functional components called "Service 147 Orchestration", "Network Orchestration", and "Domain Orchestration". 149 At the same time, terminology from RFC 8309 [RFC8309] is introduced 150 to show the distinction between the "Customer Service Model", the 151 "Service Delivery Model", the "Network Configuration Model", and the 152 "Device Configuration Model". In that context, the "Domain 153 Orchestration" and "Config Manager" roles may be performed by 154 "Controllers". 156 +---------------+ 157 | Customer | 158 +---------------+ 159 Customer Service Model | 160 l3vpn-svc | 161 +---------------+ 162 | Service | 163 | Orchestration | 164 +---------------+ 165 Service Delivery Model | 166 l3nm-svc | 167 (l3vpn-svc + extensions) | 168 +---------------+ 169 | Network | 170 | Orchestration | 171 +---------------+ 172 Network Configuration Model | 173 __________|____________ 174 | | 175 +---------------+ +---------------+ 176 | Domain | | Domain | 177 | Orchestration | | Orchestration | 178 +---------------+ +---------------+ 179 Device | | | 180 Configuration | | | 181 Model | | | 182 +---------+ | | 183 | Config | | | 184 | Manager | | | 185 +---------+ | | 186 | | | 187 | NETCONF/CLI.................. 188 | | | 189 +------------------------------------------------+ 190 Network 192 +++++++ 193 + AAA + 194 +++++++ 196 ++++++++ Bearer ++++++++ ++++++++ ++++++++ 197 + CE A + ----------- + PE A + + PE B + ---- + CE B + 198 ++++++++ Connection ++++++++ ++++++++ ++++++++ 200 Site A Site B 202 Figure 1: L3SM and L3NM 204 The L3SM and L3NM may also be set in the context of the ACTN 205 architecture [RFC8453]. Figure 2 shows the Customer Network 206 Controller (CNC), the Multi-Domain Service Coordinator (MDSC), and 207 the Provisioning Network Controller (PNC). It also shows the 208 interfaces between these functional units: the CNC-MDSC Interface 209 (CMI), the MDSC-PNC Interface (MPI), and the Southbound Interface 210 (SBI). 212 ---------------------------------- 213 | Customer | 214 | ----------------------------- | 215 | | CNC | | 216 | ----------------------------- | 217 ----:-----------------------:----- 218 : : 219 : L3SM : L3SM 220 : : 221 ---------:--------- ------------------- 222 | MDSC : | | MDSC | 223 | --------------- | | (parent) | 224 | | Service | | ------------------- 225 | | Orchestration | | : 226 | --------------- | : L3NM 227 | : | : 228 | : L3NM | ------------------- 229 | : | | MDSC | 230 | --------------- | | (child) | 231 | | Network | | ------------------- 232 | | Orchestration | | : 233 | --------------- | : 234 ---------:--------- : 235 : : 236 : Network Configuration : 237 : : 238 ------------:------- ---------:------------ 239 | Domain : | | : Domain | 240 | Controller : | | : Controller | 241 | --------- | | --------- | 242 | | PNC | | | | PNC | | 243 | --------- | | --------- | 244 ------------:------- ---------:------------ 245 : : 246 : Device Configuration : 247 : : 248 -------- -------- 249 | Device | | Device | 250 -------- -------- 252 Figure 2: L3SM and L3NM in the Context of ACTN 254 3. Yang model extensions 256 The scenarios covered include: the integration of ethernet and 257 encapsulation parameters, the extension for transport resources (e.g. 258 RTs and RDs) to be orchestrated from the management system, far-end 259 configuration of PEs not managed by the management system and the 260 definition for PE identification. 262 3.1. Bearer ethernet Encapsulation 264 The definition of a L3 VPN is commonly defined not only at the IP 265 layer, but also requires to identify parameters at the Ethernet 266 layer, such as encapsulation (e.g. VLAN, QinQ, QinAny, VxLAN, etc). 267 This specification is not supported in [RFC8299], whilst it suggests 268 that any extension on this direction shall be implemented via 269 augmentation of the bearer container. The extension defined to cope 270 with these parameters uses the connection container inside the site- 271 network-access defined by the the [RFC8466]. This container defines 272 protocol parameters to enable connectivity at Layer 2. In the 273 context of L3SM, the augmentation includes only mandatory parameters 274 for the service configuration, which are mainly related to the 275 interface encapsulation. Other definitions from L2SM connection 276 container are left aside. For example, LAG information is not 277 required and it shall be configured prior to the service 278 configuration, being the aggregated interface identified in the model 279 as the bearer-reference, as discussed later in Section 4.4. 281 3.2. Multi-Domain Resource Management 283 The implementation of L3 VPN services which spans across 284 administratively separated domains (i.e. that under the 285 administration of different management systems or controllers) 286 requires some network resources to be synchronised between systems. 287 Particularly, there are two resources that must be orchestrated and 288 synchronised to avoid asymmetric (non-functional) configuration, or 289 the usage of unavailable resources. For example, RTs shall be 290 synchronised between PEs. When every PE is controlled by the same 291 management system, RT allocation can be performed by the system. In 292 cases where the service spans across multiple management systems, 293 this task shall be synchronised and, therefore, the service model 294 must allow this specification. In addition, RDs must be also 295 synchronised to avoid collisions in RD allocation between separated 296 systems. A incorrect allocation might lead into same RD and IP 297 prefixes being exported by different PE routers. 299 3.3. Remote Far-End Configuration 301 Depending on the control plane implementation, different network 302 scenarios might require additional information for the L3 VPN service 303 to be configured and active. For example, an L3 VPN Option C 304 service, if no reflection of IPv4 VPN routes is configured via ASBR 305 or route reflector, may require additional configuration (e.g. a new 306 BGP neighbour) to be coordinated between both management systems. 308 This definition requires for every management system participant on 309 the VPN to receive not just their own sites and site-network- 310 accesses, but also to receive information about external ones, 311 identified as an external site-network-access-type. In addition, 312 this particular site-network-access is augmented to include the 313 loopback address of the far-end (remote/external) PE router. 315 3.4. Provide Edge Identification Point 317 RFC8299 states that The "bearer-reference" parameter is used in cases 318 where the customer has already ordered a network connection to the SP 319 apart from the IP VPN site and wants to reuse this connection. The 320 string used is an internal reference from the SP and describe the 321 already-available connection. Oftenly, a client interface (either a 322 customer one or an interface used by the SP) is already in place and 323 connected, although it has not being used previously. In some other 324 cases (e.g. for stitching purposes), the termination of a VPN service 325 is done over logical terminations within a PE router. 327 The bearer-reference must serve as a strict unequivocal parameters to 328 identify the connection between a PE and a client (CE). This means 329 that, despite the type is maintained as a string and there is no 330 restriction in the way this data is formed, the bearer-reference must 331 serve as the unique way to identify the PE router and the client 332 interface. This, together with the encapsulation augments proposed 333 in 4.1, serves as the way to identify the client interface and 334 configure L2 specific parameters. 336 4. Design of the data model 338 The augments defined in this document are organised per scenario, as 339 per defined in Section 4. The case described 4.4 does not need any 340 further extension of the data model and only requires a more 341 restricted definition on how the data model is used for PE router and 342 client port identification, so no augment is implemented for this 343 scenario. 345 The augments implemented are distributed as follows. The first 346 augment implements the extensions for RT and RD definition for the L3 347 VPN, following the YANG definitions from BESS-L3VPN. The second 348 augment copes with the information from a remote PE not directly 349 under the management system supervision. This augment does not 350 follow any previously defined model and includes the loopback IP 351 address of the external router. The last augment includes 352 information below layer 3 that is required for the service. In 353 particular, we include information related to clients interface 354 encapsulation and aggregation. 356 The high-level model structure proposed by this document is as shown 357 below: 359 |-------------------- EXAMPLE --------------------| 361 module: ietf-l3vpn-svc-ext 362 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access: 363 +--rw transport 364 +--rw vpn-targets 365 +--rw vpn-target* [route-target] 366 | +--rw route-target rt-types:route-target 367 | +--rw route-target-type rt-types:route-target-type 368 +--rw route-policy? -> /rt-pol:routing-policy/policy-definitions/policy-definition/name 369 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access: 370 +--rw far-end 371 +--rw address? inet:ip-address 372 augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site/l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access/l3vpn-svc:bearer: 373 +--rw ethernet 374 +--rw connection 375 +--rw encapsulation-type? identityref 376 +--rw eth-inf-type? identityref 377 +--rw tagged-interface 378 | +--rw type? identityref 379 | +--rw dot1q-vlan-tagged {dot1q}? 380 | | +--rw tg-type? identityref 381 | | +--rw cvlan-id uint16 382 | +--rw priority-tagged 383 | | +--rw tag-type? identityref 384 | +--rw qinq {qinq}? 385 | | +--rw tag-type? identityref 386 | | +--rw svlan-id uint16 387 | | +--rw cvlan-id uint16 388 | +--rw qinany {qinany}? 389 | | +--rw tag-type? identityref 390 | | +--rw svlan-id uint16 391 | +--rw vxlan {vxlan}? 392 | +--rw vni-id uint32 393 | +--rw peer-mode? identityref 394 | +--rw peer-list* [peer-ip] 395 | +--rw peer-ip inet:ip-address 396 +--rw untagged-interface 397 | +--rw speed? uint32 398 | +--rw mode? neg-mode 399 | +--rw phy-mtu? uint32 400 | +--rw lldp? boolean 401 | +--rw oam-802.3ah-link {oam-3ah}? 402 | | +--rw enabled? boolean 403 | +--rw uni-loop-prevention? boolean 405 Figure 3 407 5. Acknowledgements 409 Thanks to Adrian Farrel and Miguel Cros for the suggestions on the 410 document 412 6. IANA Considerations 414 This memo includes no request to IANA. 416 7. Security Considerations 418 All the security considerations of RFC 8299 [RFC8299] apply to this 419 document. Subsequent versions will provide additional security 420 considerations. 422 8. References 424 8.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 8.2. Informative References 433 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 434 and A. Bierman, Ed., "Network Configuration Protocol 435 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 436 . 438 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 439 RFC 7950, DOI 10.17487/RFC7950, August 2016, 440 . 442 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 443 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 444 DOI 10.17487/RFC8299, January 2018, 445 . 447 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 448 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 449 . 451 Authors' Addresses 453 Alejandro Aguado 454 Telefonica 455 Madrid 456 ES 458 Email: alejandro.aguadomartin.ext@telefonica.com 460 Oscar Gonzalez de Dios (editor) 461 Telefonica 462 Madrid 463 ES 465 Email: oscar.gonzalezdedios@telefonica.com 467 Victor Lopez 468 Telefonica 469 Madrid 470 ES 472 Email: victor.lopezalvarez@telefonica.com 474 Daniel Voyer 475 Bell Canada 476 CA 478 Email: daniel.voyer@bell.ca 480 Luis Angel Munoz 481 Vodafone 482 ES 484 Email: luis-angel.munoz@vodafone.com