idnits 2.17.00 (12 Aug 2021) /tmp/idnits1638/draft-ietf-opsawg-sap-03.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 (21 March 2022) is 61 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 == Outdated reference: A later version (-10) exists of draft-ietf-teas-ietf-network-slices-08 Summary: 0 errors (**), 0 flaws (~~), 4 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: 22 September 2022 S. Barguil 6 Telefonica 7 Q. Wu 8 Huawei 9 V. Lopez 10 Nokia 11 21 March 2022 13 A Network YANG Model for Service Attachment Points (SAPs) 14 draft-ietf-opsawg-sap-03 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 22 September 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 . . . . . . . . . . . . . . . . . . . . . . . 35 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 Network Topology model, while other technology-specific 346 topology models (e.g., Traffic Engineering (TE) Topologies model 347 [RFC8795] or Layer 3 Topologies model [RFC8346]) augment the Network 348 Topology. 350 In the context of Software-Defined Networking (SDN) 351 [RFC7149][RFC7426], the SAP YANG data model can be used to exchange 352 information between control elements, so as to support VPN service 353 provision and resource management discussed in 354 [RFC9182][I-D.ietf-opsawg-l2nm]. Through this data model, the 355 service orchestration layer can learn the available endpoints (i.e., 356 SAPs) of interconnection resources of the underlying network. The 357 service orchestration layer can determine which interconnection 358 endpoints to add to an L2VPN or L3VPN service. With the help of 359 other data models (e.g., L3SM [RFC8299] or L2SM [RFC8466]), 360 hierarchical control elements can also assess the feasibility of an 361 end-to-end IP connectivity or L2VPN connectivity and, therefore, 362 derive the sequence of domains and the points of interconnection to 363 use. 365 Advanced low-level interface-specific data nodes are not exposed in 366 the SAP model. Filters based on the interface identifiers listed in 367 the SAP model can be used together with dedicated device models to 368 set or get such data. 370 5. SAP Module Tree Structure 372 The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network' 373 module [RFC8345] by augmenting the nodes with SAPs, which anchor the 374 links and are contained in nodes. 376 The 'sap' attribute defined in the SAP network model is not a tunnel 377 termination point (TTP) (Section 3.6 of [RFC8795]) nor a link, but an 378 abstraction of the termination point defined in [RFC8345]. 380 The structure of the 'ietf-sap-ntw' module is shown in Figure 7. 382 module: ietf-sap-ntw 383 augment /nw:networks/nw:network/nw:network-types: 384 +--rw sap-network! 385 +--rw service-type* identityref 386 augment /nw:networks/nw:network/nw:node: 387 +--rw service* [service-type] 388 +--rw service-type identityref 389 +--rw sap* [sap-id] 390 +--rw sap-id string 391 +--rw description? string 392 +--rw parent-termination-point? nt:tp-id 393 +--rw attachment-interface? string 394 +--rw interface-type? identityref 395 +--rw encapsulation-type? identityref 396 +--rw role? identityref 397 +--rw peer-sap-id? string 398 +--ro sap-status 399 | +--ro status? identityref 400 | +--ro last-change? yang:date-and-time 401 +--ro service-status 402 +--ro status? identityref 403 +--ro last-change? yang:date-and-time 405 Figure 7: SAP YANG Module Tree Structure 407 A SAP network topology can be used for one or multiple service types 408 ('service-type'). Examples of supported service types are as 409 follows: 411 * L3VPN [RFC4364], 413 * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762], 415 * Virtual Private Wire Service (VPWS) [RFC8214], 417 * BGP MPLS-Based Ethernet VPN [RFC7432], 419 * VPWS in Ethernet VPN [RFC8214], 421 * Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) 422 [RFC7623], 424 * VXLAN-based EVPN [RFC8365], 426 * Virtual Networks [RFC8453], 428 * Enhanced VPN (VPN+) [I-D.ietf-teas-enhanced-vpn], 430 * Network slice [I-D.ietf-teas-ietf-network-slices], 432 * SDWAN [I-D.ietf-bess-bgp-sdwan-usage], and 434 * Basic IP connectivity. 436 These service types build on the types that are already defined in 437 [RFC9181] and additional types that are defined in this document. 438 Other service types can be defined in future YANG modules, if needed. 440 Filters based on the service type can be used to access per-service 441 SAP topology. A example is depicted in Figure 11. 443 A node in the topology can support one or multiple service types 444 ('service-type') among those listed under the 'sap-network' 445 container. A list of SAPs are then bound to each service type that 446 is supported by a given node. Each SAP is characterized as follows: 448 'sap-id': Includes an identifier that uniquely identifies a SAP 449 within a node. 451 The same SAP may appear under distinct service types. In such a 452 case, the same identifier is used for these service types in 453 association. 455 SAPs that are associated with the interfaces that are directly 456 hosting services, interfaces that are ready to host per-service 457 sub-interfaces (but not yet activated), or service that are 458 already instantiated on sub-interfaces are listed as SAPs. 460 For example, 'sap-id' may be the VPN network access identifier in 461 Section 7.6 of [RFC9182]. An example to illustrate the use of 462 this attribute during service creation is provided in Appendix D. 464 'description': Includes a textual description of the SAP. 466 'parent-termination-point': Includes a reference to the parent 467 interface to which the SAP is bound (e.g., a physical port). 469 This attribute is used, e.g., to associate an interface with its 470 sub-interfaces as all these interfaces may be listed under the 471 SAPs of a node. It is also used to link a SAP with the physical 472 topology. 474 For example, this data node can be used to map the IETF Network 475 Slice endpoints to the service/tunnel/path endpoints in the 476 underlay network as per Section 5.4 of 477 [I-D.ietf-teas-ietf-network-slices]. 479 'attachment-interface': Indicates a reference to the interface to 480 which the SAP is bound. The same interface may host multiple 481 services. 483 Whether the attachment identifier echoes the content of the 484 attachment interface is deployment specific. 486 For example, this reference may be any of the identifiers ('l2- 487 termination-point', 'local-bridge-reference', 'bearer-reference', 488 or 'lag-interface-id') defined in Section 7.6.1 of [RFC9182] or 489 'l3-termination-point' defined in Section 7.6.2 of [RFC9182]. It 490 is responsibility of the controller to ensure that consistent 491 references are used in the SAP and underlying device modes or any 492 other device inventory mechanism. 494 'interface-type': Indicates whether a SAP is bound to a physical 495 port, a loopback interface, a Link Aggregation Group (LAG) 496 interface, an Integrated Routing Bridge (IRB), a local bridge 497 reference, etc. 499 The mapping to the detailed interface types as per [RFC7224] is 500 maintained by the controller. That mapping is used, for example, 501 when the controller translates this SAP network module into device 502 modules. 504 'encapsulation-type': Indicates the encapsulation type for the 505 interface indicated in the 'attachment-interface' attribute. The 506 types are taken from [RFC9181]. 508 This data node can be used, for example, to decide whether an 509 existing SAP can be (re)used to host a service or if a new sub- 510 interface has to be instantiated. 512 'role': Specifies the role of a SAP (e.g., a UNI or NNI). 514 A SAP inherits the role of its parent interface ('parent- 515 termination-point'). 517 'peer-sap-id': Includes a reference to the remote endpoint of an 518 attachment circuit. 520 Examples of such a reference are: a site identifier (Section 6.3 521 of [RFC8299]), a CE identifier (Section 2.1 of 522 [I-D.ietf-teas-ietf-network-slices]), the IP address of a peer 523 Autonomous System Border Router (ASBR). 525 'sap-status': Indicates the operational status of a SAP. Values are 526 taken from the values defined in [RFC9181]. 528 When both a sub-interface and its parent interface are present, 529 the status of the parent interface takes precedence over the 530 status indicated for the sub-interface. 532 'service-status': Reports the operational status of service for a 533 given SAP. This information is particularly useful when many 534 services are enabled for the same SAP, but only a subset of them 535 are activated. 537 6. SAP YANG Module 539 This module imports types from [RFC8343], [RFC8345], and [RFC9181]. 541 The 'sap-information' is defined as a grouping for the reuse of these 542 nodes in service-specific YANG modules. 544 file "ietf-sap-ntw@2022-02-17.yang" 545 module ietf-sap-ntw { 546 yang-version 1.1; 547 namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw"; 548 prefix sap; 550 import ietf-network-topology { 551 prefix nt; 552 reference 553 "RFC 8345: A YANG Data Model for Network 554 Topologies, Section 6.2"; 555 } 556 import ietf-network { 557 prefix nw; 558 reference 559 "RFC 8345: A YANG Data Model for Network 560 Topologies, Section 6.1"; 561 } 562 import ietf-vpn-common { 563 prefix vpn-common; 564 reference 565 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 566 VPNs"; 567 } 569 organization 570 "IETF OPSA (Operations and Management Area) Working Group "; 571 contact 572 "WG Web: 573 WG List: 575 Editor: Mohamed Boucadair 576 578 Author: Oscar Gonzalez de Dios 579 581 Author: Samier Barguil 582 584 Author: Qin Wu 585 587 Author: Victor Lopez 588 "; 589 description 590 "This YANG module defines a model for representing, managing, 591 and controlling the Service Attachment Points (SAPs) in the 592 network topology. 594 Copyright (c) 2022 IETF Trust and the persons identified as 595 authors of the code. All rights reserved. 597 Redistribution and use in source and binary forms, with or 598 without modification, is permitted pursuant to, and subject to 599 the license terms contained in, the Revised BSD License set 600 forth in Section 4.c of the IETF Trust's Legal Provisions 601 Relating to IETF Documents 602 (https://trustee.ietf.org/license-info). 604 This version of this YANG module is part of RFC XXXX 605 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 606 for full legal notices."; 608 revision 2022-02-17 { 609 description 610 "Initial version"; 611 reference 612 "RFC XXXX: A Network YANG Model for Service Attachment 613 Points (SAPs)"; 614 } 616 identity virtual-network { 617 base vpn-common:service-type; 618 description 619 "Virtual network."; 620 reference 621 "RFC 8453: Framework for Abstraction and Control of TE 622 Networks (ACTN)"; 623 } 625 identity enhanced-vpn { 626 base vpn-common:service-type; 627 description 628 "Enhanced VPN (VPN+). VPN+ is an approach that is 629 based on existing VPN and Traffic Engineering (TE) 630 technologies but adds characteristics that specific 631 services require over and above traditional VPNs."; 632 reference 633 "draft-ietf-teas-enhanced-vpn: 634 A Framework for Enhanced Virtual Private Network 635 (VPN+) Services"; 636 } 638 identity network-slice { 639 base vpn-common:service-type; 640 description 641 "IETF network slice. An IETF network slice 642 is a logical network topology connecting a number of 643 endpoints using a set of shared or dedicated network 644 resources that are used to satisfy specific service 645 objectives."; 646 reference 647 "draft-ietf-teas-ietf-network-slices: 648 Framework for IETF Network Slices"; 649 } 651 identity sdwan { 652 base vpn-common:service-type; 653 description 654 "PE-based Software-Defined Wide Area Network (SDWAN)."; 655 reference 656 "draft-ietf-bess-bgp-sdwan-usage: BGP Usage for SDWAN 657 Overlay Network"; 658 } 660 identity basic-connectivity { 661 base vpn-common:service-type; 662 description 663 "Basic IP connectivity. This is, for example, a plain 664 connectivity offered to Enterprises over a dedicated 665 or shared MPLS infrastructure."; 666 } 668 identity interface-role { 669 description 670 "Base identity for the network role of an interface."; 671 } 673 identity uni { 674 base interface-role; 675 description 676 "User-Network Interface (UNI)."; 677 } 679 identity nni { 680 base interface-role; 681 description 682 "Network-to-Network Interface (NNI)."; 683 } 685 identity interface-type { 686 description 687 "Base identity for the interface type."; 688 } 690 identity phy { 691 base interface-type; 692 description 693 "Physical port."; 694 } 695 identity loopback { 696 base interface-type; 697 description 698 "Loopback interface."; 699 } 701 identity lag { 702 base interface-type; 703 description 704 "Link Aggregation Group (LAG) interface."; 705 } 707 identity irb { 708 base interface-type; 709 description 710 "Integrated Routing Bridge (IRB)."; 711 } 713 identity local-bridge { 714 base interface-type; 715 description 716 "A local bridge reference to accommodate, e.g., 717 implementations that require internal bridging. 718 When such a type is used, a reference to a local 719 bridge domain is used to identify the interface."; 720 } 722 identity logical { 723 base interface-type; 724 description 725 "Refers to a logical sub-interface that is typically 726 used to bind a service. This type is used only 727 if none of the other logical types can be used."; 728 } 730 grouping sap-information { 731 description 732 "Service Attachment Point (SAP) information."; 733 list sap { 734 key "sap-id"; 735 description 736 "The Service Attachment Points are abstraction of 737 the points where network services such as L3VPNs, 738 L2VPNs, or network slices can be attached to."; 739 leaf sap-id { 740 type string; 741 description 742 "Indicates an identifier that uniquely identifies 743 SAP within a node."; 744 } 745 leaf description { 746 type string; 747 description 748 "A textual description of the SAP."; 749 } 750 leaf parent-termination-point { 751 type nt:tp-id; 752 description 753 "Indicates the parent termination point to 754 which the SAP is attached to. A termination 755 point can be a physical port, an interface, etc."; 756 } 757 leaf attachment-interface { 758 type string; 759 description 760 "Indicates the interface to which the SAP is bound."; 761 } 762 leaf interface-type { 763 type identityref { 764 base interface-type; 765 } 766 description 767 "The type of the interface to which the SAP is bound."; 768 } 769 leaf encapsulation-type { 770 type identityref { 771 base vpn-common:encapsulation-type; 772 } 773 description 774 "Encapsulation type of the interface to which the 775 SAP is bound."; 776 } 777 leaf role { 778 type identityref { 779 base interface-role; 780 } 781 description 782 "Indicates the role of a SAP."; 783 } 784 leaf peer-sap-id { 785 type string; 786 description 787 "Indicates an identifier of the peer's termination 788 identifier (e.g., Customer Edge (CE)). This 789 information can be used for correlation purposes, 790 such as identifying the SAP that is attached to 791 an endpoint that is provided in a service request."; 792 } 793 container sap-status { 794 config "false"; 795 description 796 "Indicates the SAP status."; 797 uses vpn-common:oper-status-timestamp; 798 } 799 container service-status { 800 config "false"; 801 description 802 "Indicates the service status."; 803 uses vpn-common:oper-status-timestamp; 804 } 805 } 806 } 808 augment "/nw:networks/nw:network/nw:network-types" { 809 description 810 "Introduces a new network type for SAP network."; 811 container sap-network { 812 presence "Indicates SAP Network Type."; 813 description 814 "The presence of the container node indicates the 815 SAP network type."; 816 leaf-list service-type { 817 type identityref { 818 base vpn-common:service-type; 819 } 820 description 821 "Indicates the set of supported service types."; 822 } 823 } 824 } 826 augment "/nw:networks/nw:network/nw:node" { 827 description 828 "Parameters for the SAP level."; 829 list service { 830 key "service-type"; 831 description 832 "A list of supported service type for the node."; 833 leaf service-type { 834 type identityref { 835 base vpn-common:service-type; 836 } 837 description 838 "Indicates a service type."; 840 } 841 uses sap-information; 842 } 843 } 844 } 845 847 7. IANA Considerations 849 This document registers the following namespace URI in the "ns" 850 subregistry within the "IETF XML Registry" [RFC3688]: 852 URI: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 853 Registrant Contact: The IESG. 854 XML: N/A, the requested URI is an XML namespace. 856 This document registers the following YANG module in the YANG Module 857 Names registry [RFC6020] within the "YANG Parameters" registry: 859 name: ietf-sap-ntw 860 namespace: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 861 maintained by IANA? N 862 prefix: sap 863 reference: RFC XXXX 865 8. Security Considerations 867 The YANG module specified in this document defines schema for data 868 that is designed to be accessed via network management protocols such 869 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 870 is the secure transport layer, and the mandatory-to-implement secure 871 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 872 is HTTPS, and the mandatory-to-implement secure transport is TLS 873 [RFC8446]. 875 The Network Configuration Access Control Model (NACM) [RFC8341] 876 provides the means to restrict access for particular NETCONF or 877 RESTCONF users to a preconfigured subset of all available NETCONF or 878 RESTCONF protocol operations and content. 880 There are a number of data nodes defined in this YANG module that are 881 writable/creatable/deletable (i.e., config true, which is the 882 default). These data nodes may be considered sensitive or vulnerable 883 in some network environments. Write operations (e.g., edit-config) 884 to these data nodes without proper protection can have a negative 885 effect on network operations. These are the subtrees and data nodes 886 and their sensitivity/vulnerability: 888 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 890 This subtree specifies the configurations of the nodes in a SAP 891 network model. Unexpected changes to this subtree (e.g., 892 associating a SAP with another parent termination interface) could 893 lead to service disruption and/or network misbehavior. 895 Some of the readable data nodes in this YANG module may be considered 896 sensitive or vulnerable in some network environments. It is thus 897 important to control read access (e.g., via get, get-config, or 898 notification) to these data nodes. These are the subtrees and data 899 nodes and their sensitivity/vulnerability: 901 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 903 Unauthorized access to this subtree can disclose the operational 904 state information of the nodes in a SAP network model (e.g., 905 disclose the identity of a customer 'peer-sap-id'). 907 9. Acknowledgements 909 Thanks to Adrian Farrell and Daniel King for the suggestions on the 910 name used in a previous version. 912 Thanks to Dhruv Dhody, Benoit Claise, Bo Wu, Erez Segev, Raul Arco, 913 and Joe Clarke for the comments. 915 Thanks to Martin Bjoerklund for yang-doctors review. 917 10. References 919 10.1. Normative References 921 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 922 Requirement Levels", BCP 14, RFC 2119, 923 DOI 10.17487/RFC2119, March 1997, 924 . 926 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 927 DOI 10.17487/RFC3688, January 2004, 928 . 930 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 931 the Network Configuration Protocol (NETCONF)", RFC 6020, 932 DOI 10.17487/RFC6020, October 2010, 933 . 935 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 936 and A. Bierman, Ed., "Network Configuration Protocol 937 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 938 . 940 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 941 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 942 . 944 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 945 RFC 7950, DOI 10.17487/RFC7950, August 2016, 946 . 948 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 949 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 950 . 952 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 953 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 954 May 2017, . 956 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 957 Access Control Model", STD 91, RFC 8341, 958 DOI 10.17487/RFC8341, March 2018, 959 . 961 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 962 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 963 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 964 2018, . 966 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 967 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 968 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 969 March 2018, . 971 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 972 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 973 . 975 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 976 O. Gonzalez de Dios, "YANG Data Model for Traffic 977 Engineering (TE) Topologies", RFC 8795, 978 DOI 10.17487/RFC8795, August 2020, 979 . 981 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 982 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 983 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 984 2022, . 986 10.2. Informative References 988 [I-D.ietf-bess-bgp-sdwan-usage] 989 Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem, 990 B., and D. Carrel, "BGP Usage for SDWAN Overlay Networks", 991 Work in Progress, Internet-Draft, draft-ietf-bess-bgp- 992 sdwan-usage-04, 18 October 2021, 993 . 996 [I-D.ietf-opsawg-l2nm] 997 Barguil, S., Dios, O. G. D., Boucadair, M., and L. A. 998 Munoz, "A Layer 2 VPN Network YANG Model", Work in 999 Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22 1000 November 2021, . 1003 [I-D.ietf-teas-enhanced-vpn] 1004 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1005 Framework for Enhanced Virtual Private Network (VPN+) 1006 Services", Work in Progress, Internet-Draft, draft-ietf- 1007 teas-enhanced-vpn-10, 6 March 2022, 1008 . 1011 [I-D.ietf-teas-ietf-network-slices] 1012 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 1013 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 1014 Network Slices", Work in Progress, Internet-Draft, draft- 1015 ietf-teas-ietf-network-slices-08, 6 March 2022, 1016 . 1019 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1020 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1021 2006, . 1023 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1024 LAN Service (VPLS) Using BGP for Auto-Discovery and 1025 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1026 . 1028 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1029 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1030 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1031 . 1033 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1034 Networking: A Perspective from within a Service Provider 1035 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1036 . 1038 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1039 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1040 . 1042 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1043 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1044 Defined Networking (SDN): Layers and Architecture 1045 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1046 2015, . 1048 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1049 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1050 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1051 2015, . 1053 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 1054 Henderickx, "Provider Backbone Bridging Combined with 1055 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 1056 September 2015, . 1058 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1059 Rabadan, "Virtual Private Wire Service Support in Ethernet 1060 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1061 . 1063 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1064 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1065 DOI 10.17487/RFC8299, January 2018, 1066 . 1068 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1069 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1070 . 1072 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1073 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1074 . 1076 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1077 and R. Wilton, "Network Management Datastore Architecture 1078 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1079 . 1081 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1082 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1083 . 1085 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1086 Uttaro, J., and W. Henderickx, "A Network Virtualization 1087 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1088 DOI 10.17487/RFC8365, March 2018, 1089 . 1091 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1092 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1093 DOI 10.17487/RFC8453, August 2018, 1094 . 1096 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1097 Data Model for Layer 2 Virtual Private Network (L2VPN) 1098 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1099 2018, . 1101 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1102 L. Geng, "A Framework for Automating Service and Network 1103 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1104 January 2021, . 1106 [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1107 Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model 1108 for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, 1109 February 2022, . 1111 Appendix A. A Simplified SAP Network Example 1113 An example of a SAP topology that is reported by a network controller 1114 is depicted in Figure 8. This example echoes the topology shown in 1115 Figure 5. Only a minimum set of information is provided for each 1116 SAP. 1118 { 1119 "ietf-network:networks": { 1120 "network": [ 1121 { 1122 "network-types": { 1123 "service-type": [ 1124 "ietf-vpn-common:l3vpn", 1125 "ietf-vpn-common:vpls" 1126 ] 1127 }, 1128 "network-id": "foo:an-id", 1129 "node": [ 1130 { 1131 "node-id": "PE1", 1132 "ietf-sap-ntw:service": [ 1133 { 1134 "service-type": "ietf-vpn-common:l3vpn", 1135 "sap": [ 1136 { 1137 "sap-id": "sap#11", 1138 "peer-sap-id": "ce-1", 1139 "service-status": { 1140 "status": "ietf-vpn-common:op-up" 1141 } 1142 }, 1143 { 1144 "sap-id": "sap#12" 1145 }, 1146 { 1147 "sap-id": "sap#13" 1148 }, 1149 { 1150 "sap-id": "sap#14" 1151 } 1152 ] 1153 } 1154 ] 1155 }, 1156 { 1157 "node-id": "PE2", 1158 "ietf-sap-ntw:service": [ 1159 { 1160 "service-type": "ietf-vpn-common:l3vpn", 1161 "sap": [ 1162 { 1163 "sap-id": "sap#21" 1164 }, 1165 { 1166 "sap-id": "sap#22", 1167 "peer-sap-id": "ce-2", 1168 "service-status": { 1169 "status": "ietf-vpn-common:op-up" 1170 } 1171 } 1173 ] 1174 } 1175 ] 1176 }, 1177 { 1178 "node-id": "PE3", 1179 "ietf-sap-ntw:service": [ 1180 { 1181 "service-type": "ietf-vpn-common:l3vpn", 1182 "sap": [ 1183 { 1184 "sap-id": "sap#31" 1185 }, 1186 { 1187 "sap-id": "sap#32" 1188 }, 1189 { 1190 "sap-id": "sap#33", 1191 "peer-sap-id": "ce-3", 1192 "service-status": { 1193 "status": "ietf-vpn-common:op-up" 1194 } 1195 } 1196 ] 1197 } 1198 ] 1199 }, 1200 { 1201 "node-id": "PE4", 1202 "ietf-sap-ntw:service": [ 1203 { 1204 "service-type": "ietf-vpn-common:l3vpn", 1205 "sap": [ 1206 { 1207 "sap-id": "sap#41" 1208 }, 1209 { 1210 "sap-id": "sap#42", 1211 "peer-sap-id": "ce-4", 1212 "service-status": { 1213 "status": "ietf-vpn-common:op-up" 1214 } 1215 }, 1216 { 1217 "sap-id": "sap#43" 1218 }, 1219 { 1220 "sap-id": "sap#44", 1221 "peer-sap-id": "ce-5", 1222 "service-status": { 1223 "status": "ietf-vpn-common:op-up" 1224 } 1225 } 1226 ] 1227 } 1228 ] 1229 } 1230 ] 1231 } 1232 ] 1233 } 1234 } 1236 Figure 8: A Simplified SAP Network Example 1238 Appendix B. A Simple Example of SAP Network Model: Node Filter 1240 In the example shown in Figure 9, PE1 has two physical interfaces 1241 "GE0/6/1" and "GE0/6/4". Two sub-interfaces "GE0/6/4.1" and 1242 "GE0/6/4.2" are associated with the physical interface "GE0/6/4". 1243 Let us consider that four SAPs are exposed to the service 1244 orchestrator and mapped to these physical interfaces and sub- 1245 interfaces. 1247 .-------------------------. 1248 | GE0/6/4 | 1249 | PE1 .----+----. 1250 | |sap#2 |GE0/6/4.1 1251 | | .--+--. 1252 | | |sap#3| 1253 | | '--+--' 1254 | | |GE0/6/4.2 1255 | | .--+--. 1256 | | |sap#4| 1257 | | '--+--' 1258 | | | 1259 | +----+----+ 1260 | | 1261 | GE0/6/1| 1262 | .----+----. 1263 | |sap#1 | 1264 | '----+----' 1265 | | 1266 '-------------------------' 1268 Figure 9: An Example of a PE and its Physical/Logical Interfaces 1270 Let us assume that no service is enabled yet for the SAP associated 1271 with the physical interface "GE0/6/1". Also, let us assume that, for 1272 the SAPs that are associated with the physical interface "GE0/6/4", 1273 VPLS and L3VPN services are activated on the two sub-interfaces 1274 "GE0/6/4.1" and "GE0/6/4.2", respectively. 1276 A service orchestrator can query what services are provided on which 1277 SAPs of PE1 from the network controller by sending, e.g., a GET 1278 RESTCONF request. Figure 10 shows the body of the RESTCONF response 1279 that is received from the network controller. 1281 { 1282 "ietf-sap-ntw:service": [ 1283 { 1284 "service-type": "ietf-vpn-common:l3vpn", 1285 "sap": [ 1286 { 1287 "sap-id": "sap#1", 1288 "description": "Ready to host SAPs", 1289 "attachment-interface": "GE0/6/1", 1290 "interface-type": "ietf-sap-ntw:phy", 1291 "role": "ietf-sap-ntw:uni", 1292 "sap-status": { 1293 "status": "ietf-vpn-common:op-up" 1294 } 1295 }, 1296 { 1297 "sap-id": "sap#2", 1298 "description": "Ready to host SAPs", 1299 "attachment-interface": "GE0/6/4", 1300 "interface-type": "ietf-sap-ntw:phy", 1301 "role": "ietf-sap-ntw:uni", 1302 "sap-status": { 1303 "status": "ietf-vpn-common:op-up" 1304 } 1305 }, 1306 { 1307 "sap-id": "sap#3", 1308 "description": "A first SAP description", 1309 "parent-termination-point": "GE0/6/4", 1310 "attachment-interface": "GE0/6/4.1", 1311 "interface-type": "ietf-sap-ntw:logical", 1312 "encapsulation-type": "ietf-vpn-common:vlan-type", 1313 "sap-status": { 1314 "status": "ietf-vpn-common:op-up" 1315 }, 1316 "service-status": { 1317 "status": "ietf-vpn-common:op-up" 1318 } 1319 } 1320 ] 1321 }, 1322 { 1323 "service-type": "ietf-vpn-common:vpls", 1324 "sap": [ 1325 "sap-id": "sap#1", 1326 "description": "Ready to host SAPs", 1327 "attachment-interface": "GE0/6/1", 1328 "interface-type": "ietf-sap-ntw:phy", 1329 "role": "ietf-sap-ntw:uni", 1330 "sap-status": { 1331 "status": "ietf-vpn-common:op-up" 1332 } 1333 }, 1334 { 1335 "sap-id": "sap#2", 1336 "description": "Ready to host SAPs", 1337 "attachment-interface": "GE0/6/4", 1338 "interface-type": "ietf-sap-ntw:phy", 1339 "role": "ietf-sap-ntw:uni", 1340 "sap-status": { 1341 "status": "ietf-vpn-common:op-up" 1342 } 1343 }, 1344 { 1345 "sap-id": "sap#4", 1346 "description": "Another description", 1347 "parent-termination-point": "GE0/6/4", 1348 "attachment-interface": "GE0/6/4.2", 1349 "interface-type": "ietf-sap-ntw:logical", 1350 "encapsulation-type": "ietf-vpn-common:vlan-type", 1351 "sap-status": { 1352 "status": "ietf-vpn-common:op-up" 1353 }, 1354 "service-status": { 1355 "status": "ietf-vpn-common:op-up" 1356 } 1357 } 1358 ] 1359 } 1360 ] 1361 } 1362 Figure 10: An Example of a Response Body to a Request with a Node 1363 Filter 1365 Figure 11 shows the message body of a response that is received from 1366 the network controller if the request includes a filter on the 1367 service type for a particular node: 1369 { 1370 "ietf-sap-ntw:service": [ 1371 { 1372 "service-type": "ietf-vpn-common:l3vpn", 1373 "sap": [ 1374 { 1375 "sap-id": "sap#1", 1376 "description": "Ready to host SAPs", 1377 "attachment-interface": "GE0/6/1", 1378 "interface-type": "ietf-sap-ntw:phy", 1379 "role": "ietf-sap-ntw:uni", 1380 "sap-status": { 1381 "status": "ietf-vpn-common:op-up" 1382 } 1383 }, 1384 { 1385 "sap-id": "sap#2", 1386 "description": "Ready to host SAPs", 1387 "attachment-interface": "GE0/6/4", 1388 "interface-type": "ietf-sap-ntw:phy", 1389 "role": "ietf-sap-ntw:uni", 1390 "sap-status": { 1391 "status": "ietf-vpn-common:op-up" 1392 } 1393 }, 1394 { 1395 "sap-id": "sap#3", 1396 "description": "A first SAP description", 1397 "parent-termination-point": "GE0/6/4", 1398 "attachment-interface": "GE0/6/4.1", 1399 "interface-type": "ietf-sap-ntw:logical", 1400 "encapsulation-type": "ietf-vpn-common:vlan-type", 1401 "sap-status": { 1402 "status": "ietf-vpn-common:op-up" 1403 }, 1404 "service-status": { 1405 "status": "ietf-vpn-common:op-up" 1406 } 1407 } 1408 ] 1409 } 1410 ] 1411 } 1413 Figure 11: An Example of a Response Body to a Request with a 1414 Service Filter 1416 Appendix C. An Example of NNI SAP: Inter-AS VPN Option A 1418 Section 10 of [RFC4364] discuses several options to extend a VPN 1419 service beyond the scope of a single Autonomous System (AS). For 1420 illustration purposes, this section focuses on the so called "Option 1421 A" but similar examples can be considered for other options. 1423 In this option, an ASBR of an AS is directly connected to an ASBR of 1424 a neighboring AS. These two ASBRs are connected by multiple physical 1425 or logical interfaces. Also, at least one sub-interface is 1426 maintained by these ASBRs for each of the VPNs that require their 1427 routes to be passed from one AS to the other AS. Each ASBR behaves 1428 as a PE and treats the other as if it were a CE. 1430 Figure 12 shows a simplified (excerpt) topology of two ASes A and B 1431 with a focus on the interconnection links between these two ASes. 1433 .--------------------. .--------------------. 1434 | | | | 1435 | A .--+--. .--+--. A | 1436 | S | +================+ | S | 1437 | B | (VRF1)----(VPN1)----(VRF1) | B | 1438 | R | | | | R | 1439 | | (VRF2)----(VPN2)----(VRF2) | | 1440 | a | +================+ | b | 1441 | 1 '--+--' '--+--' 1 | 1442 | AS A | | AS B | 1443 | A .--+--. .--+--. A | 1444 | S | +================+ | S | 1445 | B | (VRF1)----(VPN1)----(VRF1) | B | 1446 | R | | | | R | 1447 | | (VRF2)----(VPN2)----(VRF2) | | 1448 | a | +================+ | b | 1449 | 2 '--+--' '--+--' 2 | 1450 | | | | 1451 '--------------------' '--------------------' 1453 Figure 12: An Example of Inter-AS VPN (Option A) 1455 Figure 13 shows an example of a message body that is received from 1456 the network controller of AS A (with a focus on the NNIs shown in 1457 Figure 12). 1459 { 1460 "ietf-network:networks": { 1461 "network": [ 1462 { 1463 "network-types": { 1464 "service-type": [ 1465 "ietf-vpn-common:l3vpn" 1466 ] 1467 }, 1468 "network-id": "foo:an-id", 1469 "node": [ 1470 { 1471 "node-id": "asbr-a1", 1472 "ietf-sap-ntw:service": [ 1473 { 1474 "service-type": "ietf-vpn-common:l3vpn", 1475 "sap": [ 1476 { 1477 "sap-id": "sap#11", 1478 "description": "parent inter-as link#1", 1479 "role": "ietf-sap-ntw:nni", 1480 "peer-sap-id": "asbr-b1", 1481 "service-status": { 1482 "status": "ietf-vpn-common:op-up" 1483 } 1484 }, 1485 { 1486 "sap-id": "sap#12", 1487 "description": "parent inter-as link#2", 1488 "role": "ietf-sap-ntw:nni", 1489 "peer-sap-id": "asbr-b1", 1490 "service-status": { 1491 "status": "ietf-vpn-common:op-up" 1492 } 1493 }, 1494 { 1495 "sap-id": "sap#13", 1496 "description": "vpn1", 1497 "role": "ietf-sap-ntw:nni", 1498 "peer-sap-id": "asbr-b1", 1499 "service-status": { 1500 "status": "ietf-vpn-common:op-up" 1501 } 1502 }, 1503 { 1504 "sap-id": "sap#14", 1505 "description": "vpn2", 1506 "role": "ietf-sap-ntw:nni", 1507 "peer-sap-id": "asbr-b1", 1508 "service-status": { 1509 "status": "ietf-vpn-common:op-up" 1510 } 1511 } 1512 ] 1513 } 1514 ] 1515 }, 1516 { 1517 "node-id": "asbr-a2", 1518 "ietf-sap-ntw:service": [ 1519 { 1520 "service-type": "ietf-vpn-common:l3vpn", 1521 "sap": [ 1522 { 1523 "sap-id": "sap#11", 1524 "description": "parent inter-as link#1", 1525 "role": "ietf-sap-ntw:nni", 1526 "peer-sap-id": "asbr-b2", 1527 "service-status": { 1528 "status": "ietf-vpn-common:op-up" 1529 } 1530 }, 1531 { 1532 "sap-id": "sap#12", 1533 "description": "parent inter-as link#2", 1534 "role": "ietf-sap-ntw:nni", 1535 "peer-sap-id": "asbr-b2", 1536 "service-status": { 1537 "status": "ietf-vpn-common:op-up" 1538 } 1539 }, 1540 { 1541 "sap-id": "sap#21", 1542 "description": "vpn1", 1543 "role": "ietf-sap-ntw:nni", 1544 "peer-sap-id": "asbr-b2", 1545 "service-status": { 1546 "status": "ietf-vpn-common:op-up" 1547 } 1548 }, 1549 { 1550 "sap-id": "sap#22", 1551 "description": "vpn2", 1552 "role": "ietf-sap-ntw:nni", 1553 "peer-sap-id": "asbr-b2", 1554 "service-status": { 1555 "status": "ietf-vpn-common:op-up" 1556 } 1557 } 1558 ] 1559 } 1560 ] 1561 } 1562 ] 1563 } 1564 ] 1565 } 1566 } 1568 Figure 13: An Example of SAP Usage for NNI 1570 Appendix D. An Example of Using the SAP Network Model in Service 1571 Creation 1573 This section describes an example to illustrate the use of the SAP 1574 model for service creation purposes. 1576 An example of a SAP topology is presented in Figure 8. This example 1577 includes four PEs with their SAPs, as well as the customer 1578 information. 1580 Let us assume that an operator wants to create an L3VPN service 1581 between two PEs (PE3 and PE4) that are servicing two CEs (CE6 and 1582 CE7). To that aim, the operator would query the SAP topology and 1583 would obtain a response similar to what is depicted in Figure 8. 1584 That response indicates that the SAPs having "sap#31" and "sap#43" as 1585 attachment identifiers do not have any installed services. Once the 1586 "free" SAPs are identified, the 'interface-type' and 'encapsulation- 1587 type' are checked to see if the requested L3VPN service is compatible 1588 with the SAP characteristics. If they are compatible, as proposed in 1589 Section 5, the 'attachment-id' value can be used as the VPN network 1590 access identifier in an L3NM create query. 1592 Let us now assume that, instead of the L3VPN service, the operator 1593 wants to set up an L2VPN service. If the 'interface-type' is a 1594 physical port, a new logical SAP can be created using the SAP model 1595 to cope with the service needs (e.g., the 'encapsulation-type' 1596 attribute can be set to 'ietf-vpn-common:vlan-type'). Once the 1597 logical SAP is created, the 'attachment-id' of the new SAP is used to 1598 create an L2NM instance (Section 7.6 of [I-D.ietf-opsawg-l2nm]). 1600 Authors' Addresses 1601 Mohamed Boucadair (editor) 1602 Orange 1603 France 1604 Email: mohamed.boucadair@orange.com 1606 Oscar Gonzalez de Dios 1607 Telefonica 1608 Madrid 1609 Spain 1610 Email: oscar.gonzalezdedios@telefonica.com 1612 Samier Barguil 1613 Telefonica 1614 Madrid 1615 Spain 1616 Email: samier.barguilgiraldo.ext@telefonica.com 1618 Qin Wu 1619 Huawei 1620 101 Software Avenue, Yuhua District 1621 Nanjing 1622 Jiangsu, 210012 1623 China 1624 Email: bill.wu@huawei.com 1626 Victor Lopez 1627 Nokia 1628 Spain 1629 Email: victor.lopez@nokia.com