idnits 2.17.00 (12 Aug 2021) /tmp/idnits58380/draft-ietf-opsawg-sap-04.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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (11 April 2022) is 33 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) == Outdated reference: A later version (-05) exists of draft-ietf-bess-bgp-sdwan-usage-04 == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-l2nm-12 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG M. Boucadair, Ed. 3 Internet-Draft Orange 4 Intended status: Standards Track O. Gonzalez de Dios 5 Expires: 13 October 2022 S. Barguil 6 Telefonica 7 Q. Wu 8 Huawei 9 V. Lopez 10 Nokia 11 11 April 2022 13 A Network YANG Model for Service Attachment Points (SAPs) 14 draft-ietf-opsawg-sap-04 16 Abstract 18 This document defines a YANG data model for representing an abstract 19 view of the provider network topology that contains the points from 20 which its services can be attached (e.g., basic connectivity, VPN, 21 network slices). Also, the model can be used to retrieve the points 22 where the services are actually being delivered to customers 23 (including peer networks). 25 This document augments the 'ietf-network' data model by adding the 26 concept of Service Attachment Points (SAPs). The Service Attachment 27 Points are the network reference points to which network services, 28 such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual 29 Private Network (L2VPN), can be attached. Both User-Network 30 Interface (UNI) and Network-to-Network Interface (NNI) are supported 31 in the SAP data model. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 13 October 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. SAP Network Model Usage . . . . . . . . . . . . . . . . . . . 4 69 4. Relationship to Other YANG Data Models . . . . . . . . . . . 8 70 5. SAP Module Tree Structure . . . . . . . . . . . . . . . . . . 9 71 6. SAP YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 77 10.2. Informative References . . . . . . . . . . . . . . . . . 22 78 Appendix A. A Simplified SAP Network Example . . . . . . . . . . 24 79 Appendix B. A Simple Example of SAP Network Model: Node 80 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 Appendix C. An Example of NNI SAP: Inter-AS VPN Option A . . . . 32 82 Appendix D. An Example of Using the SAP Network Model in Service 83 Creation . . . . . . . . . . . . . . . . . . . . . . . . 35 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 86 1. Introduction 88 From the perspective of a service provider, the Service Attachment 89 Points (SAPs) are abstraction of the network reference points where 90 network services can be delivered to customers. The SAP is an 91 important architectural concept in many implementations and service 92 deployments, such as Virtual Private Networks (VPNs), Software- 93 Defined Wide Area Network (SDWAN) [I-D.ietf-bess-bgp-sdwan-usage], or 94 network slices [I-D.ietf-teas-ietf-network-slices]. For example, 95 this concept is used to decide where to attach and, thus, deliver the 96 service in the Layer 3 VPN Service Model (L3SM) [RFC8299] and the 97 Layer 2 VPN Service Model (L2SM) [RFC8466]. It can also be used to 98 retrieve where services, such as the Layer 3 VPN Network Model (L3NM) 99 [RFC9182], and the Layer 2 VPN Network Model (L2NM) 100 [I-D.ietf-opsawg-l2nm], are delivered to customers. 102 This document defines a YANG network model (Section 6) for 103 representing, managing, and controlling the SAPs. The data model 104 augments the 'ietf-network' module [RFC8345] by adding the concept of 105 SAPs. This document explains the scope and purpose of a SAP network 106 model and its relation with other models (Section 4). 108 Multiple service types can be associated with a given network. 109 Whether a SAP topology is dedicated to a specific service or shared 110 among many services is deployment specific. This document supports 111 both deployment schemes. 113 This document does not make any assumption about the service(s) 114 provided by a network to its users. VPN services (e.g., Layer 3 115 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network 116 (L2VPN)) are used for illustration purposes (Appendices A and B). 118 Both User-Network Interface (UNI) and Network-to-Network Interface 119 (NNI) SAPs are supported in the document. An example of NNI usage is 120 provided in Appendix C. 122 The YANG data model in Section 6 conforms to the Network Management 123 Datastore Architecture (NMDA) [RFC8342]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 This document assumes that the reader is familiar with the contents 134 of [RFC6241], [RFC7950], [RFC8345], and [RFC8309]. The document uses 135 terms from those documents. 137 The meanings of the symbols in tree diagrams are defined in 138 [RFC8340]. 140 This document uses the term "network model" defined in Section 2.1 of 141 [RFC8969]. 143 This document uses the following terms: 145 Service povider: The organization responsible for operating the 146 network that offers a service (e.g., a VPN) to customers. 148 Customer Edge (CE): An equipment that is dedicated to a particular 149 customer and is directly connected to one or more Provider Edges 150 (PEs) via attachment circuits (ACs). A CE is usually located at 151 the customer premises. A CE may be dedicated to a single service 152 (e.g., L3VPN), although it may support multiple VPNs if each one 153 has separate attachment circuits. A CE can be a router, a bridge, 154 a switch, etc. 156 Provider Edge (PE): An equipment owned and managed by the service 157 provider that can support multiple services (e.g., VPNs) for 158 different customers. A PE is directly connected to one or more 159 CEs via ACs. 161 Service Attachment Point (SAP): Describes the service's endpoint 162 characteristics and its reference to a Termination Point (TP). 164 3. SAP Network Model Usage 166 Management operations of a service provider network can be automated 167 using a variety of means such as interfaces based on YANG modules 168 [RFC8969]. From that standpoint, and considering the architecture 169 depicted in Figure 1, a goal of this document is to provide a 170 mechanism to show via a YANG-based interface an abstracted network 171 view from the network controller to the service orchestration layer 172 with a focus on where a service can be delivered to customers. The 173 model is also used to retrieve the network points where a service is 174 being delivered to customers. For services that require resources 175 from peer networks, the module can also be used to expose NNIs. 177 +-----------------+ 178 | Customer | 179 +--------+--------+ 180 Customer Service Models | 181 (e.g., L3SM, L2SM) | 182 +--------+--------+ 183 | Service | 184 | Orchestration | 185 +------+---+------+ 186 Network Models | | SAP Network Model 187 (e.g., L3NM, L2NM) | | 188 +------+---+------+ 189 | Network | 190 | Controller | 191 +--------+--------+ 192 | 193 +---------------------+---------------------+ 194 | Network | 195 +-------------------------------------------+ 197 Figure 1: SAP Network Model Usage 199 Let us consider the example of a typical service provider network 200 (Figure 2), with PE and P nodes. 202 .---------. .---------. 203 | PE1 | | PE2 | 204 '---------' '---------' 205 \ / 206 .------. 207 | P(s) | 208 '------' 209 / \ 210 .---------. .---------. 211 | PE3 | | PE4 | 212 '---------' '---------' 214 Figure 2: Sample Network Topology 216 The service orchestration layer does not need to know about the 217 internals of the underlying network (e.g., P nodes). Figure 3 shows 218 the abstract network view as seen by a service orchestrator. 219 However, this view is not enough to provide to the service 220 orchestration layer the information to create services in the 221 network. The service topology need is to be able to expose the set 222 of nodes and the attachment points associated with the nodes from 223 which network services can be grafted (delivered). 225 .---------. .---------. 226 | PE1 | | PE2 | 227 '---------' '---------' 229 .---------. .---------. 230 | PE3 | | PE4 | 231 '---------' '---------' 233 Figure 3: Abstract Network Topology 235 Typically, and focusing on the UNIs, the service orchestration layer 236 would see a set of PEs and a set of client-facing interfaces 237 (physical or logical) to which CEs can be connected (or are actually 238 connected). The service orchestration layer can use these interfaces 239 to setup the requested services or to commit the delivery of a 240 service. Figure 4 depicts a sample SAP network topology that is 241 maintained by the network controller and exposed to the service 242 orchestration. 244 .-+-. .-+-. .-+-. .-+-. .-+-. 245 .-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. 246 | '---' '---' '---' | | '---' '---' | 247 .---. | | | 248 |sap| PE1 | | PE2 | 249 '---' | | | 250 | | | | 251 '-------------------' '-------------------' 253 .-------------------. .-------------------. 254 | | | | 255 | | | .---. 256 | PE3 | | PE4 |sap| 257 | | | '---' 258 | .---. .---. .---. | | .---. .---. .---. | 259 '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' 260 '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' 262 Figure 4: SAP Network Topology 264 A single SAP network topology can be used for one or multiple service 265 types (e.g., L3VPN, Ethernet VPN (EVPN)). The network controller 266 can, then, expose the service type(s) and associated interfaces via 267 the SAPs. 269 As shown in Figure 5, the service orchestration layer will have also 270 access to a set of customer service model (e.g., the L3SM or the 271 L2SM) in the customer-facing interface and a set of network models 272 (e.g., the L3NM and network topology data models) in the resource- 273 facing interface. In this use case, it is assumed that the network 274 controller is unaware of what happens beyond the PEs towards the CEs; 275 it is only responsible for the management and control of the SAPs and 276 the network between PEs. In order to correlate between delivery 277 points expressed in service requests and SAPs, the SAP model may 278 include a peer customer point identifier. That identifier can be a 279 CE identifier, a site identifier, etc. 281 .---. 282 |CE2| 283 '-+-' 284 | 285 .-+-. .-+-. .-+-. .-+-. .-+-. 286 .-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. 287 | '---' '---' '---' | | '---' '---' | 288 .---. .---. | | | 289 |CE1+--+sap| PE1 | | PE2 | 290 '---' '---' | | | 291 | | | | 292 '-------------------' '-------------------' 294 .-------------------. .-------------------. 295 | | | | 296 | | | .---. .---. 297 | PE3 | | PE4 |sap+--+CE5| 298 | | | '---' '---' 299 | .---. .---. .---. | | .---. .---. .---. | 300 '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' 301 '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' 302 | | 303 .-+-. .-+-. 304 |CE3| |CE4| 305 '-+-' '-+-' 307 Figure 5: Network Topology with CEs and ACs 309 Refer to Appendix A for an example echoing the topology depicted in 310 Figure 5. 312 4. Relationship to Other YANG Data Models 314 The SAP network model can be seen as an inventory data associated 315 with SAPs. The model maintains an inventory of nodes contained in a 316 network relying upon [RFC8345]. 318 +-------------------------+ 319 | | 320 | Abstract Network Model | 321 | | 322 +------------+------------+ 323 | 324 +---------+---------+ 325 | | 326 +------V------+ +------V------+ 327 | Abstract | | Inventory | 328 | Network | | Model(s) | 329 | Topology | | e.g., SAP | 330 | Model | | Network | 331 | | | Model | 332 +-----+-------+ +-------------+ 333 | 334 +-----------+-----------+ 335 | | | 336 +----V----+ +----V----+ +----V----+ 337 |TE Topo | |L3 Topo | |L2 Topo | 338 | Model | | Model | | Model | ... 339 +---------+ +---------+ +---------+ 341 Figure 6: Relation of SAP Network Model to Other Models 343 Figure 6 depicts the relationship of the SAP network model to other 344 models. The SAP network model augments the Network model [RFC8345] 345 and imports the Network Topology model, while other technology- 346 specific topology models (e.g., Traffic Engineering (TE) Topologies 347 model [RFC8795] or Layer 3 Topologies model [RFC8346]) augment the 348 Network Topology model. 350 Also, the SAP is not a tunnel termination point (TTP) (Section 3.6 of 351 [RFC8795]) nor a link. 353 In the context of Software-Defined Networking (SDN) 354 [RFC7149][RFC7426], the SAP YANG data model can be used to exchange 355 information between control elements, so as to support VPN service 356 provision and resource management discussed in 357 [RFC9182][I-D.ietf-opsawg-l2nm]. Through this data model, the 358 service orchestration layer can learn the available endpoints (i.e., 359 SAPs) of interconnection resources of the underlying network. The 360 service orchestration layer can determine which interconnection 361 endpoints to add to an L2VPN or L3VPN service. With the help of 362 other data models (e.g., L3SM [RFC8299] or L2SM [RFC8466]), 363 hierarchical control elements can also assess the feasibility of an 364 end-to-end IP connectivity or L2VPN connectivity and, therefore, 365 derive the sequence of domains and the points of interconnection to 366 use. 368 Advanced low-level interface-specific data nodes are not exposed in 369 the SAP model. Filters based on the interface identifiers listed in 370 the SAP model can be used together with dedicated device models to 371 set or get such data. 373 5. SAP Module Tree Structure 375 The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network' 376 module [RFC8345] by augmenting the nodes with SAPs. 378 The structure of the 'ietf-sap-ntw' module is shown in Figure 7. 380 module: ietf-sap-ntw 381 augment /nw:networks/nw:network/nw:network-types: 382 +--rw sap-network! 383 +--rw service-type* identityref 384 augment /nw:networks/nw:network/nw:node: 385 +--rw service* [service-type] 386 +--rw service-type identityref 387 +--rw sap* [sap-id] 388 +--rw sap-id string 389 +--rw description? string 390 +--rw parent-termination-point? nt:tp-id 391 +--rw attachment-interface? string 392 +--rw interface-type? identityref 393 +--rw encapsulation-type? identityref 394 +--rw role? identityref 395 +--rw peer-sap-id? string 396 +--ro sap-status 397 | +--ro status? identityref 398 | +--ro last-change? yang:date-and-time 399 +--ro service-status 400 +--ro status? identityref 401 +--ro last-change? yang:date-and-time 403 Figure 7: SAP YANG Module Tree Structure 405 A SAP network topology can be used for one or multiple service types 406 ('service-type'). Examples of supported service types are as 407 follows: 409 * L3VPN [RFC4364], 411 * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762], 413 * Virtual Private Wire Service (VPWS) [RFC8214], 415 * BGP MPLS-Based Ethernet VPN [RFC7432], 417 * VPWS in Ethernet VPN [RFC8214], 419 * Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) 420 [RFC7623], 422 * VXLAN-based EVPN [RFC8365], 424 * Virtual Networks [RFC8453], 426 * Enhanced VPN (VPN+) [I-D.ietf-teas-enhanced-vpn], 428 * Network slice [I-D.ietf-teas-ietf-network-slices], 430 * SDWAN [I-D.ietf-bess-bgp-sdwan-usage], and 432 * Basic IP connectivity. 434 These service types build on the types that are already defined in 435 [RFC9181] and additional types that are defined in this document. 436 Other service types can be defined in future YANG modules, if needed. 438 Filters based on the service type can be used to access per-service 439 SAP topology. A example is depicted in Figure 11. 441 A node in the topology can support one or multiple service types 442 ('service-type') among those listed under the 'sap-network' 443 container. A list of SAPs are then bound to each service type that 444 is supported by a given node. Each SAP is characterized as follows: 446 'sap-id': Includes an identifier that uniquely identifies a SAP 447 within a node. 449 The same SAP may appear under distinct service types. In such a 450 case, the same identifier is used for these service types in 451 association. 453 SAPs that are associated with the interfaces that are directly 454 hosting services, interfaces that are ready to host per-service 455 sub-interfaces (but not yet activated), or service that are 456 already instantiated on sub-interfaces are listed as SAPs. 458 For example, 'sap-id' may be the VPN network access identifier in 459 Section 7.6 of [RFC9182]. An example to illustrate the use of 460 this attribute during service creation is provided in Appendix D. 462 'description': Includes a textual description of the SAP. 464 'parent-termination-point': Includes a reference to the parent 465 interface to which the SAP is bound (e.g., a physical port). 467 This attribute is used, e.g., to associate an interface with its 468 sub-interfaces as all these interfaces may be listed under the 469 SAPs of a node. It is also used to link a SAP with the physical 470 topology. 472 For example, this data node can be used to map the IETF Network 473 Slice endpoints ([I-D.ietf-teas-ietf-network-slices]) to the 474 service/tunnel/path endpoints in the underlay network. 476 'attachment-interface': Indicates a reference to the interface to 477 which the SAP is bound. The same interface may host multiple 478 services. 480 Whether the attachment identifier echoes the content of the 481 attachment interface is deployment specific. 483 For example, this reference may be any of the identifiers ('l2- 484 termination-point', 'local-bridge-reference', 'bearer-reference', 485 or 'lag-interface-id') defined in Section 7.6.1 of [RFC9182] or 486 'l3-termination-point' defined in Section 7.6.2 of [RFC9182]. It 487 is responsibility of the controller to ensure that consistent 488 references are used in the SAP and underlying device modes or any 489 other device inventory mechanism. 491 'interface-type': Indicates whether a SAP is bound to a physical 492 port, a loopback interface, a Link Aggregation Group (LAG) 493 interface, an Integrated Routing Bridge (IRB), a local bridge 494 reference, etc. 496 The mapping to the detailed interface types as per [RFC7224] is 497 maintained by the controller. That mapping is used, for example, 498 when the controller translates this SAP network module into device 499 modules. 501 'encapsulation-type': Indicates the encapsulation type for the 502 interface indicated in the 'attachment-interface' attribute. The 503 types are taken from [RFC9181]. 505 This data node can be used, for example, to decide whether an 506 existing SAP can be (re)used to host a service or if a new sub- 507 interface has to be instantiated. 509 'role': Specifies the role of a SAP (e.g., a UNI or NNI). 511 A SAP inherits the role of its parent interface ('parent- 512 termination-point'). 514 'peer-sap-id': Includes a reference to the remote endpoint of an 515 attachment circuit. 517 Examples of such a reference are: a site identifier (Section 6.3 518 of [RFC8299]), a Service Demarcation Point (SDP) identifier 519 (Section 2.1 of [I-D.ietf-teas-ietf-network-slices]), the IP 520 address of a peer Autonomous System Border Router (ASBR). 522 'sap-status': Indicates the operational status of a SAP. Values are 523 taken from the values defined in [RFC9181]. 525 When both a sub-interface and its parent interface are present, 526 the status of the parent interface takes precedence over the 527 status indicated for the sub-interface. 529 'service-status': Reports the operational status of service for a 530 given SAP. This information is particularly useful when many 531 services are enabled for the same SAP, but only a subset of them 532 are activated. 534 6. SAP YANG Module 536 This module imports types from [RFC8343], [RFC8345], and [RFC9181]. 538 The 'sap-information' is defined as a grouping for the reuse of these 539 nodes in service-specific YANG modules. 541 file "ietf-sap-ntw@2022-04-11.yang" 542 module ietf-sap-ntw { 543 yang-version 1.1; 544 namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw"; 545 prefix sap; 547 import ietf-network-topology { 548 prefix nt; 549 reference 550 "RFC 8345: A YANG Data Model for Network 551 Topologies, Section 6.2"; 552 } 553 import ietf-network { 554 prefix nw; 555 reference 556 "RFC 8345: A YANG Data Model for Network 557 Topologies, Section 6.1"; 558 } 559 import ietf-vpn-common { 560 prefix vpn-common; 561 reference 562 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 563 VPNs"; 564 } 566 organization 567 "IETF OPSA (Operations and Management Area) Working Group "; 568 contact 569 "WG Web: 570 WG List: 572 Editor: Mohamed Boucadair 573 575 Author: Oscar Gonzalez de Dios 576 578 Author: Samier Barguil 579 581 Author: Qin Wu 582 584 Author: Victor Lopez 585 "; 586 description 587 "This YANG module defines a model for representing, managing, 588 and controlling the Service Attachment Points (SAPs) in the 589 network topology. 591 Copyright (c) 2022 IETF Trust and the persons identified as 592 authors of the code. All rights reserved. 594 Redistribution and use in source and binary forms, with or 595 without modification, is permitted pursuant to, and subject to 596 the license terms contained in, the Revised BSD License set 597 forth in Section 4.c of the IETF Trust's Legal Provisions 598 Relating to IETF Documents 599 (https://trustee.ietf.org/license-info). 601 This version of this YANG module is part of RFC XXXX 602 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 603 for full legal notices."; 605 revision 2022-04-11 { 606 description 607 "Initial version"; 608 reference 609 "RFC XXXX: A Network YANG Model for Service Attachment 610 Points (SAPs)"; 611 } 613 identity virtual-network { 614 base vpn-common:service-type; 615 description 616 "Virtual network."; 617 reference 618 "RFC 8453: Framework for Abstraction and Control of TE 619 Networks (ACTN)"; 620 } 622 identity enhanced-vpn { 623 base vpn-common:service-type; 624 description 625 "Enhanced VPN (VPN+). VPN+ is an approach that is 626 based on existing VPN and Traffic Engineering (TE) 627 technologies but adds characteristics that specific 628 services require over and above traditional VPNs."; 629 reference 630 "draft-ietf-teas-enhanced-vpn: 631 A Framework for Enhanced Virtual Private Network 632 (VPN+) Services"; 633 } 635 identity network-slice { 636 base vpn-common:service-type; 637 description 638 "IETF network slice. An IETF network slice 639 is a logical network topology connecting a number of 640 endpoints using a set of shared or dedicated network 641 resources that are used to satisfy specific service 642 objectives."; 643 reference 644 "draft-ietf-teas-ietf-network-slices: 645 Framework for IETF Network Slices"; 646 } 648 identity sdwan { 649 base vpn-common:service-type; 650 description 651 "PE-based Software-Defined Wide Area Network (SDWAN)."; 652 reference 653 "draft-ietf-bess-bgp-sdwan-usage: BGP Usage for SDWAN 654 Overlay Network"; 655 } 657 identity basic-connectivity { 658 base vpn-common:service-type; 659 description 660 "Basic IP connectivity. This is, for example, a plain 661 connectivity offered to Enterprises over a dedicated 662 or shared MPLS infrastructure."; 663 } 665 identity interface-role { 666 description 667 "Base identity for the network role of an interface."; 668 } 670 identity uni { 671 base interface-role; 672 description 673 "User-Network Interface (UNI)."; 674 } 676 identity nni { 677 base interface-role; 678 description 679 "Network-to-Network Interface (NNI)."; 680 } 682 identity interface-type { 683 description 684 "Base identity for the interface type."; 685 } 687 identity phy { 688 base interface-type; 689 description 690 "Physical port."; 691 } 692 identity loopback { 693 base interface-type; 694 description 695 "Loopback interface."; 696 } 698 identity lag { 699 base interface-type; 700 description 701 "Link Aggregation Group (LAG) interface."; 702 } 704 identity irb { 705 base interface-type; 706 description 707 "Integrated Routing Bridge (IRB)."; 708 } 710 identity local-bridge { 711 base interface-type; 712 description 713 "A local bridge reference to accommodate, e.g., 714 implementations that require internal bridging. 715 When such a type is used, a reference to a local 716 bridge domain is used to identify the interface."; 717 } 719 identity logical { 720 base interface-type; 721 description 722 "Refers to a logical sub-interface that is typically 723 used to bind a service. This type is used only 724 if none of the other logical types can be used."; 725 } 727 grouping sap-information { 728 description 729 "Service Attachment Point (SAP) information."; 730 list sap { 731 key "sap-id"; 732 description 733 "The Service Attachment Points are abstraction of 734 the points where network services such as L3VPNs, 735 L2VPNs, or network slices can be attached to."; 736 leaf sap-id { 737 type string; 738 description 739 "Indicates an identifier that uniquely identifies 740 SAP within a node."; 741 } 742 leaf description { 743 type string; 744 description 745 "A textual description of the SAP."; 746 } 747 leaf parent-termination-point { 748 type nt:tp-id; 749 description 750 "Indicates the parent termination point to 751 which the SAP is attached to. A termination 752 point can be a physical port, an interface, etc."; 753 } 754 leaf attachment-interface { 755 type string; 756 description 757 "Indicates the interface to which the SAP is bound."; 758 } 759 leaf interface-type { 760 type identityref { 761 base interface-type; 762 } 763 description 764 "The type of the interface to which the SAP is bound."; 765 } 766 leaf encapsulation-type { 767 type identityref { 768 base vpn-common:encapsulation-type; 769 } 770 description 771 "Encapsulation type of the interface to which the 772 SAP is bound."; 773 } 774 leaf role { 775 type identityref { 776 base interface-role; 777 } 778 description 779 "Indicates the role of a SAP."; 780 } 781 leaf peer-sap-id { 782 type string; 783 description 784 "Indicates an identifier of the peer's termination 785 identifier (e.g., Customer Edge (CE)). This 786 information can be used for correlation purposes, 787 such as identifying the SAP that is attached to 788 an endpoint that is provided in a service request."; 789 } 790 container sap-status { 791 config "false"; 792 description 793 "Indicates the SAP status."; 794 uses vpn-common:oper-status-timestamp; 795 } 796 container service-status { 797 config "false"; 798 description 799 "Indicates the service status."; 800 uses vpn-common:oper-status-timestamp; 801 } 802 } 803 } 805 augment "/nw:networks/nw:network/nw:network-types" { 806 description 807 "Introduces a new network type for SAP network."; 808 container sap-network { 809 presence "Indicates SAP network type."; 810 description 811 "The presence of the container node indicates the 812 SAP network type."; 813 leaf-list service-type { 814 type identityref { 815 base vpn-common:service-type; 816 } 817 description 818 "Indicates the set of supported service types."; 819 } 820 } 821 } 823 augment "/nw:networks/nw:network/nw:node" { 824 when "../nw:network-types/sap:sap-network" { 825 description 826 "Augmentation parameters apply only for SAP 827 networks."; 828 } 829 description 830 "SAP parameters for the node level."; 831 list service { 832 key "service-type"; 833 description 834 "A list of supported service types for the node."; 835 leaf service-type { 836 type identityref { 837 base vpn-common:service-type; 838 } 839 description 840 "Indicates a service type."; 841 } 842 uses sap-information; 843 } 844 } 845 } 846 848 7. IANA Considerations 850 This document registers the following namespace URI in the "ns" 851 subregistry within the "IETF XML Registry" [RFC3688]: 853 URI: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 854 Registrant Contact: The IESG. 855 XML: N/A, the requested URI is an XML namespace. 857 This document registers the following YANG module in the YANG Module 858 Names registry [RFC6020] within the "YANG Parameters" registry: 860 name: ietf-sap-ntw 861 namespace: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 862 maintained by IANA? N 863 prefix: sap 864 reference: RFC XXXX 866 8. Security Considerations 868 The YANG module specified in this document defines schema for data 869 that is designed to be accessed via network management protocols such 870 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 871 is the secure transport layer, and the mandatory-to-implement secure 872 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 873 is HTTPS, and the mandatory-to-implement secure transport is TLS 874 [RFC8446]. 876 The Network Configuration Access Control Model (NACM) [RFC8341] 877 provides the means to restrict access for particular NETCONF or 878 RESTCONF users to a preconfigured subset of all available NETCONF or 879 RESTCONF protocol operations and content. 881 There are a number of data nodes defined in this YANG module that are 882 writable/creatable/deletable (i.e., config true, which is the 883 default). These data nodes may be considered sensitive or vulnerable 884 in some network environments. Write operations (e.g., edit-config) 885 to these data nodes without proper protection can have a negative 886 effect on network operations. These are the subtrees and data nodes 887 and their sensitivity/vulnerability: 889 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 891 This subtree specifies the configurations of the nodes in a SAP 892 network model. Unexpected changes to this subtree (e.g., 893 associating a SAP with another parent termination interface) could 894 lead to service disruption and/or network misbehavior. 896 Some of the readable data nodes in this YANG module may be considered 897 sensitive or vulnerable in some network environments. It is thus 898 important to control read access (e.g., via get, get-config, or 899 notification) to these data nodes. These are the subtrees and data 900 nodes and their sensitivity/vulnerability: 902 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 904 Unauthorized access to this subtree can disclose the operational 905 state information of the nodes in a SAP network model (e.g., 906 disclose the identity of a customer 'peer-sap-id'). 908 9. Acknowledgements 910 Thanks to Adrian Farrell and Daniel King for the suggestions on the 911 name used in a previous version. 913 Thanks to Dhruv Dhody, Benoit Claise, Bo Wu, Erez Segev, Raul Arco, 914 Joe Clarke, and Riyas Valiyapalathingal for the comments. 916 Thanks to Martin Bjoerklund for yang-doctors review. 918 10. References 920 10.1. Normative References 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, 924 DOI 10.17487/RFC2119, March 1997, 925 . 927 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 928 DOI 10.17487/RFC3688, January 2004, 929 . 931 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 932 the Network Configuration Protocol (NETCONF)", RFC 6020, 933 DOI 10.17487/RFC6020, October 2010, 934 . 936 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 937 and A. Bierman, Ed., "Network Configuration Protocol 938 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 939 . 941 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 942 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 943 . 945 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 946 RFC 7950, DOI 10.17487/RFC7950, August 2016, 947 . 949 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 950 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 951 . 953 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 954 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 955 May 2017, . 957 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 958 Access Control Model", STD 91, RFC 8341, 959 DOI 10.17487/RFC8341, March 2018, 960 . 962 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 963 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 964 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 965 2018, . 967 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 968 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 969 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 970 March 2018, . 972 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 973 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 974 . 976 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 977 O. Gonzalez de Dios, "YANG Data Model for Traffic 978 Engineering (TE) Topologies", RFC 8795, 979 DOI 10.17487/RFC8795, August 2020, 980 . 982 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 983 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 984 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 985 2022, . 987 10.2. Informative References 989 [I-D.ietf-bess-bgp-sdwan-usage] 990 Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem, 991 B., and D. Carrel, "BGP Usage for SDWAN Overlay Networks", 992 Work in Progress, Internet-Draft, draft-ietf-bess-bgp- 993 sdwan-usage-04, 18 October 2021, 994 . 997 [I-D.ietf-opsawg-l2nm] 998 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 999 Munoz, "A Layer 2 VPN Network YANG Model", Work in 1000 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 1001 November 2021, . 1004 [I-D.ietf-teas-enhanced-vpn] 1005 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1006 Framework for Enhanced Virtual Private Network (VPN+) 1007 Services", Work in Progress, Internet-Draft, draft-ietf- 1008 teas-enhanced-vpn-10, 6 March 2022, 1009 . 1012 [I-D.ietf-teas-ietf-network-slices] 1013 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 1014 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 1015 Network Slices", Work in Progress, Internet-Draft, draft- 1016 ietf-teas-ietf-network-slices-10, 27 March 2022, 1017 . 1020 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1021 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1022 2006, . 1024 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1025 LAN Service (VPLS) Using BGP for Auto-Discovery and 1026 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1027 . 1029 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1030 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1031 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1032 . 1034 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1035 Networking: A Perspective from within a Service Provider 1036 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1037 . 1039 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1040 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1041 . 1043 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1044 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1045 Defined Networking (SDN): Layers and Architecture 1046 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1047 2015, . 1049 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1050 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1051 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1052 2015, . 1054 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 1055 Henderickx, "Provider Backbone Bridging Combined with 1056 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 1057 September 2015, . 1059 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1060 Rabadan, "Virtual Private Wire Service Support in Ethernet 1061 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1062 . 1064 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1065 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1066 DOI 10.17487/RFC8299, January 2018, 1067 . 1069 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1070 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1071 . 1073 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1074 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1075 . 1077 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1078 and R. Wilton, "Network Management Datastore Architecture 1079 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1080 . 1082 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1083 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1084 . 1086 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1087 Uttaro, J., and W. Henderickx, "A Network Virtualization 1088 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1089 DOI 10.17487/RFC8365, March 2018, 1090 . 1092 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1093 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1094 DOI 10.17487/RFC8453, August 2018, 1095 . 1097 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1098 Data Model for Layer 2 Virtual Private Network (L2VPN) 1099 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1100 2018, . 1102 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1103 L. Geng, "A Framework for Automating Service and Network 1104 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1105 January 2021, . 1107 [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1108 Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model 1109 for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, 1110 February 2022, . 1112 Appendix A. A Simplified SAP Network Example 1114 An example of a SAP topology that is reported by a network controller 1115 is depicted in Figure 8. This example echoes the topology shown in 1116 Figure 5. Only a minimum set of information is provided for each 1117 SAP. 1119 { 1120 "ietf-network:networks": { 1121 "network": [ 1122 { 1123 "network-types": { 1124 "ietf-sap-ntw:sap-network": { 1125 "service-type": [ 1126 "ietf-vpn-common:l3vpn", 1127 "ietf-vpn-common:vpls" 1128 ] 1129 } 1130 }, 1131 "network-id": "foo:an-id", 1132 "node": [ 1133 { 1134 "node-id": "PE1", 1135 "ietf-sap-ntw:service": [ 1136 { 1137 "service-type": "ietf-vpn-common:l3vpn", 1138 "sap": [ 1139 { 1140 "sap-id": "sap#11", 1141 "peer-sap-id": "ce-1", 1142 "service-status": { 1143 "status": "ietf-vpn-common:op-up" 1144 } 1145 }, 1146 { 1147 "sap-id": "sap#12" 1148 }, 1149 { 1150 "sap-id": "sap#13" 1151 }, 1152 { 1153 "sap-id": "sap#14" 1154 } 1155 ] 1156 } 1157 ] 1158 }, 1159 { 1160 "node-id": "PE2", 1161 "ietf-sap-ntw:service": [ 1162 { 1163 "service-type": "ietf-vpn-common:l3vpn", 1164 "sap": [ 1165 { 1166 "sap-id": "sap#21" 1168 }, 1169 { 1170 "sap-id": "sap#22", 1171 "peer-sap-id": "ce-2", 1172 "service-status": { 1173 "status": "ietf-vpn-common:op-up" 1174 } 1175 } 1176 ] 1177 } 1178 ] 1179 }, 1180 { 1181 "node-id": "PE3", 1182 "ietf-sap-ntw:service": [ 1183 { 1184 "service-type": "ietf-vpn-common:l3vpn", 1185 "sap": [ 1186 { 1187 "sap-id": "sap#31" 1188 }, 1189 { 1190 "sap-id": "sap#32" 1191 }, 1192 { 1193 "sap-id": "sap#33", 1194 "peer-sap-id": "ce-3", 1195 "service-status": { 1196 "status": "ietf-vpn-common:op-up" 1197 } 1198 } 1199 ] 1200 } 1201 ] 1202 }, 1203 { 1204 "node-id": "PE4", 1205 "ietf-sap-ntw:service": [ 1206 { 1207 "service-type": "ietf-vpn-common:l3vpn", 1208 "sap": [ 1209 { 1210 "sap-id": "sap#41" 1211 }, 1212 { 1213 "sap-id": "sap#42", 1214 "peer-sap-id": "ce-4", 1215 "service-status": { 1216 "status": "ietf-vpn-common:op-up" 1217 } 1218 }, 1219 { 1220 "sap-id": "sap#43" 1221 }, 1222 { 1223 "sap-id": "sap#44", 1224 "peer-sap-id": "ce-5", 1225 "service-status": { 1226 "status": "ietf-vpn-common:op-up" 1227 } 1228 } 1229 ] 1230 } 1231 ] 1232 } 1233 ] 1234 } 1235 ] 1236 } 1237 } 1239 Figure 8: A Simplified SAP Network Example 1241 Appendix B. A Simple Example of SAP Network Model: Node Filter 1243 In the example shown in Figure 9, PE1 has two physical interfaces 1244 "GE0/6/1" and "GE0/6/4". Two sub-interfaces "GE0/6/4.1" and 1245 "GE0/6/4.2" are associated with the physical interface "GE0/6/4". 1246 Let us consider that four SAPs are exposed to the service 1247 orchestrator and mapped to these physical interfaces and sub- 1248 interfaces. 1250 .-------------------------. 1251 | GE0/6/4 | 1252 | PE1 .----+----. 1253 | |sap#2 |GE0/6/4.1 1254 | | .--+--. 1255 | | |sap#3| 1256 | | '--+--' 1257 | | |GE0/6/4.2 1258 | | .--+--. 1259 | | |sap#4| 1260 | | '--+--' 1261 | | | 1262 | +----+----+ 1263 | | 1264 | GE0/6/1| 1265 | .----+----. 1266 | |sap#1 | 1267 | '----+----' 1268 | | 1269 '-------------------------' 1271 Figure 9: An Example of a PE and its Physical/Logical Interfaces 1273 Let us assume that no service is enabled yet for the SAP associated 1274 with the physical interface "GE0/6/1". Also, let us assume that, for 1275 the SAPs that are associated with the physical interface "GE0/6/4", 1276 VPLS and L3VPN services are activated on the two sub-interfaces 1277 "GE0/6/4.1" and "GE0/6/4.2", respectively. 1279 A service orchestrator can query what services are provided on which 1280 SAPs of PE1 from the network controller by sending, e.g., a GET 1281 RESTCONF request. Figure 10 shows the body of the RESTCONF response 1282 that is received from the network controller. 1284 { 1285 "ietf-sap-ntw:service": [ 1286 { 1287 "service-type": "ietf-vpn-common:l3vpn", 1288 "sap": [ 1289 { 1290 "sap-id": "sap#1", 1291 "description": "Ready to host SAPs", 1292 "attachment-interface": "GE0/6/1", 1293 "interface-type": "ietf-sap-ntw:phy", 1294 "role": "ietf-sap-ntw:uni", 1295 "sap-status": { 1296 "status": "ietf-vpn-common:op-up" 1297 } 1299 }, 1300 { 1301 "sap-id": "sap#2", 1302 "description": "Ready to host SAPs", 1303 "attachment-interface": "GE0/6/4", 1304 "interface-type": "ietf-sap-ntw:phy", 1305 "role": "ietf-sap-ntw:uni", 1306 "sap-status": { 1307 "status": "ietf-vpn-common:op-up" 1308 } 1309 }, 1310 { 1311 "sap-id": "sap#3", 1312 "description": "A first SAP description", 1313 "parent-termination-point": "GE0/6/4", 1314 "attachment-interface": "GE0/6/4.1", 1315 "interface-type": "ietf-sap-ntw:logical", 1316 "encapsulation-type": "ietf-vpn-common:vlan-type", 1317 "sap-status": { 1318 "status": "ietf-vpn-common:op-up" 1319 }, 1320 "service-status": { 1321 "status": "ietf-vpn-common:op-up" 1322 } 1323 } 1324 ] 1325 }, 1326 { 1327 "service-type": "ietf-vpn-common:vpls", 1328 "sap": [ 1329 "sap-id": "sap#1", 1330 "description": "Ready to host SAPs", 1331 "attachment-interface": "GE0/6/1", 1332 "interface-type": "ietf-sap-ntw:phy", 1333 "role": "ietf-sap-ntw:uni", 1334 "sap-status": { 1335 "status": "ietf-vpn-common:op-up" 1336 } 1337 }, 1338 { 1339 "sap-id": "sap#2", 1340 "description": "Ready to host SAPs", 1341 "attachment-interface": "GE0/6/4", 1342 "interface-type": "ietf-sap-ntw:phy", 1343 "role": "ietf-sap-ntw:uni", 1344 "sap-status": { 1345 "status": "ietf-vpn-common:op-up" 1346 } 1348 }, 1349 { 1350 "sap-id": "sap#4", 1351 "description": "Another description", 1352 "parent-termination-point": "GE0/6/4", 1353 "attachment-interface": "GE0/6/4.2", 1354 "interface-type": "ietf-sap-ntw:logical", 1355 "encapsulation-type": "ietf-vpn-common:vlan-type", 1356 "sap-status": { 1357 "status": "ietf-vpn-common:op-up" 1358 }, 1359 "service-status": { 1360 "status": "ietf-vpn-common:op-up" 1361 } 1362 } 1363 ] 1364 } 1365 ] 1366 } 1368 Figure 10: An Example of a Response Body to a Request with a Node 1369 Filter 1371 Figure 11 shows the message body of a response that is received from 1372 the network controller if the request includes a filter on the 1373 service type for a particular node: 1375 { 1376 "ietf-sap-ntw:service": [ 1377 { 1378 "service-type": "ietf-vpn-common:l3vpn", 1379 "sap": [ 1380 { 1381 "sap-id": "sap#1", 1382 "description": "Ready to host SAPs", 1383 "attachment-interface": "GE0/6/1", 1384 "interface-type": "ietf-sap-ntw:phy", 1385 "role": "ietf-sap-ntw:uni", 1386 "sap-status": { 1387 "status": "ietf-vpn-common:op-up" 1388 } 1389 }, 1390 { 1391 "sap-id": "sap#2", 1392 "description": "Ready to host SAPs", 1393 "attachment-interface": "GE0/6/4", 1394 "interface-type": "ietf-sap-ntw:phy", 1395 "role": "ietf-sap-ntw:uni", 1396 "sap-status": { 1397 "status": "ietf-vpn-common:op-up" 1398 } 1399 }, 1400 { 1401 "sap-id": "sap#3", 1402 "description": "A first SAP description", 1403 "parent-termination-point": "GE0/6/4", 1404 "attachment-interface": "GE0/6/4.1", 1405 "interface-type": "ietf-sap-ntw:logical", 1406 "encapsulation-type": "ietf-vpn-common:vlan-type", 1407 "sap-status": { 1408 "status": "ietf-vpn-common:op-up" 1409 }, 1410 "service-status": { 1411 "status": "ietf-vpn-common:op-up" 1412 } 1413 } 1414 ] 1415 } 1416 ] 1417 } 1419 Figure 11: An Example of a Response Body to a Request with a 1420 Service Filter 1422 Appendix C. An Example of NNI SAP: Inter-AS VPN Option A 1424 Section 10 of [RFC4364] discuses several options to extend a VPN 1425 service beyond the scope of a single Autonomous System (AS). For 1426 illustration purposes, this section focuses on the so called "Option 1427 A" but similar examples can be considered for other options. 1429 In this option, an ASBR of an AS is directly connected to an ASBR of 1430 a neighboring AS. These two ASBRs are connected by multiple physical 1431 or logical interfaces. Also, at least one sub-interface is 1432 maintained by these ASBRs for each of the VPNs that require their 1433 routes to be passed from one AS to the other AS. Each ASBR behaves 1434 as a PE and treats the other as if it were a CE. 1436 Figure 12 shows a simplified (excerpt) topology of two ASes A and B 1437 with a focus on the interconnection links between these two ASes. 1439 .--------------------. .--------------------. 1440 | | | | 1441 | A .--+--. .--+--. A | 1442 | S | +================+ | S | 1443 | B | (VRF1)----(VPN1)----(VRF1) | B | 1444 | R | | | | R | 1445 | | (VRF2)----(VPN2)----(VRF2) | | 1446 | a | +================+ | b | 1447 | 1 '--+--' '--+--' 1 | 1448 | AS A | | AS B | 1449 | A .--+--. .--+--. A | 1450 | S | +================+ | S | 1451 | B | (VRF1)----(VPN1)----(VRF1) | B | 1452 | R | | | | R | 1453 | | (VRF2)----(VPN2)----(VRF2) | | 1454 | a | +================+ | b | 1455 | 2 '--+--' '--+--' 2 | 1456 | | | | 1457 '--------------------' '--------------------' 1459 Figure 12: An Example of Inter-AS VPN (Option A) 1461 Figure 13 shows an example of a message body that is received from 1462 the network controller of AS A (with a focus on the NNIs shown in 1463 Figure 12). 1465 { 1466 "ietf-network:networks": { 1467 "network": [ 1468 { 1469 "network-types": { 1470 "ietf-sap-ntw:sap-network": { 1471 "service-type": [ 1472 "ietf-vpn-common:l3vpn" 1473 ] 1474 } 1475 }, 1476 "network-id": "foo:an-id", 1477 "node": [ 1478 { 1479 "node-id": "asbr-a1", 1480 "ietf-sap-ntw:service": [ 1481 { 1482 "service-type": "ietf-vpn-common:l3vpn", 1483 "sap": [ 1484 { 1485 "sap-id": "sap#11", 1486 "description": "parent inter-as link#1", 1487 "role": "ietf-sap-ntw:nni", 1488 "peer-sap-id": "asbr-b1", 1489 "service-status": { 1490 "status": "ietf-vpn-common:op-up" 1491 } 1492 }, 1493 { 1494 "sap-id": "sap#12", 1495 "description": "parent inter-as link#2", 1496 "role": "ietf-sap-ntw:nni", 1497 "peer-sap-id": "asbr-b1", 1498 "service-status": { 1499 "status": "ietf-vpn-common:op-up" 1500 } 1501 }, 1502 { 1503 "sap-id": "sap#13", 1504 "description": "vpn1", 1505 "role": "ietf-sap-ntw:nni", 1506 "peer-sap-id": "asbr-b1", 1507 "service-status": { 1508 "status": "ietf-vpn-common:op-up" 1509 } 1510 }, 1511 { 1512 "sap-id": "sap#14", 1513 "description": "vpn2", 1514 "role": "ietf-sap-ntw:nni", 1515 "peer-sap-id": "asbr-b1", 1516 "service-status": { 1517 "status": "ietf-vpn-common:op-up" 1518 } 1519 } 1520 ] 1521 } 1522 ] 1523 }, 1524 { 1525 "node-id": "asbr-a2", 1526 "ietf-sap-ntw:service": [ 1527 { 1528 "service-type": "ietf-vpn-common:l3vpn", 1529 "sap": [ 1530 { 1531 "sap-id": "sap#11", 1532 "description": "parent inter-as link#1", 1533 "role": "ietf-sap-ntw:nni", 1534 "peer-sap-id": "asbr-b2", 1535 "service-status": { 1536 "status": "ietf-vpn-common:op-up" 1537 } 1538 }, 1539 { 1540 "sap-id": "sap#12", 1541 "description": "parent inter-as link#2", 1542 "role": "ietf-sap-ntw:nni", 1543 "peer-sap-id": "asbr-b2", 1544 "service-status": { 1545 "status": "ietf-vpn-common:op-up" 1546 } 1547 }, 1548 { 1549 "sap-id": "sap#21", 1550 "description": "vpn1", 1551 "role": "ietf-sap-ntw:nni", 1552 "peer-sap-id": "asbr-b2", 1553 "service-status": { 1554 "status": "ietf-vpn-common:op-up" 1555 } 1556 }, 1557 { 1558 "sap-id": "sap#22", 1559 "description": "vpn2", 1560 "role": "ietf-sap-ntw:nni", 1561 "peer-sap-id": "asbr-b2", 1562 "service-status": { 1563 "status": "ietf-vpn-common:op-up" 1564 } 1565 } 1566 ] 1567 } 1568 ] 1569 } 1570 ] 1571 } 1572 ] 1573 } 1574 } 1576 Figure 13: An Example of SAP Usage for NNI 1578 Appendix D. An Example of Using the SAP Network Model in Service 1579 Creation 1581 This section describes an example to illustrate the use of the SAP 1582 model for service creation purposes. 1584 An example of a SAP topology is presented in Figure 8. This example 1585 includes four PEs with their SAPs, as well as the customer 1586 information. 1588 Let us assume that an operator wants to create an L3VPN service 1589 between two PEs (PE3 and PE4) that are servicing two CEs (CE6 and 1590 CE7). To that aim, the operator would query the SAP topology and 1591 would obtain a response similar to what is depicted in Figure 8. 1592 That response indicates that the SAPs having "sap#31" and "sap#43" as 1593 attachment identifiers do not have any installed services. Once the 1594 "free" SAPs are identified, the 'interface-type' and 'encapsulation- 1595 type' are checked to see if the requested L3VPN service is compatible 1596 with the SAP characteristics. If they are compatible, as proposed in 1597 Section 5, the 'attachment-id' value can be used as the VPN network 1598 access identifier in an L3NM create query. 1600 Let us now assume that, instead of the L3VPN service, the operator 1601 wants to set up an L2VPN service. If the 'interface-type' is a 1602 physical port, a new logical SAP can be created using the SAP model 1603 to cope with the service needs (e.g., the 'encapsulation-type' 1604 attribute can be set to 'ietf-vpn-common:vlan-type'). Once the 1605 logical SAP is created, the 'attachment-id' of the new SAP is used to 1606 create an L2NM instance (Section 7.6 of [I-D.ietf-opsawg-l2nm]). 1608 Authors' Addresses 1610 Mohamed Boucadair (editor) 1611 Orange 1612 France 1613 Email: mohamed.boucadair@orange.com 1615 Oscar Gonzalez de Dios 1616 Telefonica 1617 Madrid 1618 Spain 1619 Email: oscar.gonzalezdedios@telefonica.com 1621 Samier Barguil 1622 Telefonica 1623 Madrid 1624 Spain 1625 Email: samier.barguilgiraldo.ext@telefonica.com 1627 Qin Wu 1628 Huawei 1629 101 Software Avenue, Yuhua District 1630 Nanjing 1631 Jiangsu, 210012 1632 China 1633 Email: bill.wu@huawei.com 1635 Victor Lopez 1636 Nokia 1637 Spain 1638 Email: victor.lopez@nokia.com