idnits 2.17.1 draft-ietf-opsawg-sap-07.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 May 2022) is 707 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 (-22) exists of draft-ietf-bess-bgp-sdwan-usage-05 == Outdated reference: A later version (-19) exists of draft-ietf-opsawg-l2nm-16 == Outdated reference: A later version (-17) exists of draft-ietf-teas-enhanced-vpn-10 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-10 Summary: 0 errors (**), 0 flaws (~~), 6 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: 21 November 2022 S. Barguil 6 Telefonica 7 Q. Wu 8 Huawei 9 V. Lopez 10 Nokia 11 20 May 2022 13 A Network YANG Model for Service Attachment Points (SAPs) 14 draft-ietf-opsawg-sap-07 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 SAPs are the 27 network reference points to which network services, such as Layer 3 28 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network 29 (L2VPN), can be attached. Both User-Network Interface (UNI) and 30 Network-to-Network Interface (NNI) are supported in the SAP data 31 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 21 November 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 . . . . . . . . . . 25 79 Appendix B. A Simple Example of SAP Network Model: Node 80 Filter . . . . . . . . . . . . . . . . . . . . . . . . . 28 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 Service providers offer a variety of network services to their 89 customers. Such services include, but are not limited to, Virtual 90 Private Networks (VPNs), Software-Defined Wide Area Network (SDWAN) 91 [I-D.ietf-bess-bgp-sdwan-usage], and network slices 92 [I-D.ietf-teas-ietf-network-slices]. In order to rationalize the 93 overall service operations and allow for more automated service 94 provisioning procedures, service providers need to maintain a view on 95 where services can be delivered to customers. Such view can be used, 96 e.g., to feed an intelligence that is responsible for service order 97 handling, service feasibility checks, tracking per-service coverage, 98 etc. To that aim, this document introduces the concept of Service 99 Attachment Points (SAPs). 101 The SAPs represent the network reference points where network 102 services can be delivered to customers. For example, this concept is 103 used to decide where to attach and, thus, deliver the service in the 104 Layer 3 VPN Service Model (L3SM) [RFC8299] and the Layer 2 VPN 105 Service Model (L2SM) [RFC8466]. It can also be used to retrieve 106 where services, such as the Layer 3 VPN Network Model (L3NM) 107 [RFC9182] and the Layer 2 VPN Network Model (L2NM) 108 [I-D.ietf-opsawg-l2nm], are delivered to customers. 110 This document defines a YANG network model (Section 6) for 111 representing, managing, and controlling the SAPs. The data model 112 augments the 'ietf-network' module [RFC8345] by adding the concept of 113 SAPs. This document explains the scope and purpose of a SAP network 114 model and its relation with other models (Section 4). 116 Multiple service types can be associated with a given network. 117 Whether a SAP topology is dedicated to a specific service or shared 118 among many services is deployment specific. This document supports 119 both deployment schemes. 121 This document does not make any assumption about the service(s) 122 provided by a network to its users. VPN services (e.g., Layer 3 123 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network 124 (L2VPN)) [RFC4026] are used for illustration purposes (Appendices A 125 and B). 127 Given that User-Network Interface (UNI) and Network-to-Network 128 Interface (NNI) are reference points that are widely used by 129 operators to indicate the demarcation points when delivering 130 services, both UNI and NNI SAPs are supported in the document. The 131 reader may refer, e.g., to [MEF6], [MEF17], [RFC6004], or [RFC6215] 132 for a discussion on the use of UNI and NNI reference points. An 133 example of NNI usage in a VPN context is provided in Appendix C. 135 The YANG data model in Section 6 conforms to the Network Management 136 Datastore Architecture (NMDA) [RFC8342]. 138 2. Terminology 140 This document assumes that the reader is familiar with the contents 141 of [RFC6241], [RFC7950], [RFC8345], and [RFC8309]. The document uses 142 terms from those documents. 144 The meanings of the symbols in tree diagrams are defined in 145 [RFC8340]. 147 This document uses the term "network model" defined in Section 2.1 of 148 [RFC8969]. 150 This document uses the following terms: 152 Service povider: The organization responsible for operating the 153 network that offers a service (e.g., a VPN) to customers. 155 Attachment Circuit (AC): A channel that connects a Customer Edge 156 (CE) to a Provider Edge (PE). The AC may be a physical or logical 157 link (Section 6.1 of [RFC4026]). 159 Customer Edge (CE): An equipment that is dedicated to a particular 160 customer and is directly connected to one or more PEs via ACs. A 161 CE is usually located at the customer premises. A CE may be 162 dedicated to a single service (e.g., L3VPN), although it may 163 support multiple VPNs if each one has separate attachment 164 circuits. A CE can be a router, a bridge, a switch, etc. 166 Provider Edge (PE): An equipment owned and managed by the service 167 provider that can support multiple services (e.g., VPNs) for 168 different customers. A PE is directly connected to one or more 169 CEs via ACs. 171 Service Attachment Points (SAPs): An abstraction of the network 172 reference points (e.g., PE side of an AC) where network services 173 can be delivered and/or being delivered to customers. 175 3. SAP Network Model Usage 177 Management operations of a service provider network can be automated 178 using a variety of means such as interfaces based on YANG modules 179 [RFC8969]. From that standpoint, and considering the architecture 180 depicted in Figure 1, a goal of this document is to provide a 181 mechanism to show via a YANG-based interface an abstracted network 182 view from the network controller to the service orchestration layer 183 with a focus on where a service can be delivered to customers. The 184 model is also used to retrieve the network reference points where a 185 service is being delivered to customers. For services that require 186 resources from peer networks, the module can also be used to expose 187 NNIs. 189 +-----------------+ 190 | Customer | 191 +--------+--------+ 192 Customer Service Models | 193 (e.g., L3SM, L2SM) | 194 +--------+--------+ 195 | Service | 196 | Orchestration | 197 +------+---+------+ 198 Network Models | | SAP Network Model 199 (e.g., L3NM, L2NM) | | 200 +------+---+------+ 201 | Network | 202 | Controller | 203 +--------+--------+ 204 | 205 +---------------------+---------------------+ 206 | Network | 207 +-------------------------------------------+ 209 Figure 1: SAP Network Model Usage 211 Let us consider the example of a typical service provider network 212 (Figure 2), with PE and P nodes. 214 .---------. .---------. 215 | PE1 | | PE2 | 216 '---------' '---------' 217 \ / 218 .------. 219 | P(s) | 220 '------' 221 / \ 222 .---------. .---------. 223 | PE3 | | PE4 | 224 '---------' '---------' 226 Figure 2: Sample Network Topology 228 The service orchestration layer does not need to know about the 229 internals of the underlying network (e.g., P nodes). Figure 3 shows 230 the abstract network view as seen by a service orchestrator. 231 However, this view is not enough to provide to the service 232 orchestration layer the information to create services in the 233 network. The service topology need is to be able to expose the set 234 of nodes and the attachment points associated with the nodes from 235 which network services can be grafted (delivered). 237 .---------. .---------. 238 | PE1 | | PE2 | 239 '---------' '---------' 241 .---------. .---------. 242 | PE3 | | PE4 | 243 '---------' '---------' 245 Figure 3: Abstract Network Topology 247 Typically, and focusing on the UNIs, the service orchestration layer 248 would see a set of PEs and a set of client-facing interfaces 249 (physical or logical) to which CEs can be connected (or are actually 250 connected). The service orchestration layer can use these interfaces 251 to setup the requested services or to commit the delivery of a 252 service. Figure 4 depicts a sample SAP network topology that is 253 maintained by the network controller and exposed to the service 254 orchestration. 256 .-+-. .-+-. .-+-. .-+-. .-+-. 257 .-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. 258 | '---' '---' '---' | | '---' '---' | 259 .---. | | | 260 |sap| PE1 | | PE2 | 261 '---' | | | 262 | | | | 263 '-------------------' '-------------------' 265 .-------------------. .-------------------. 266 | | | | 267 | | | .---. 268 | PE3 | | PE4 |sap| 269 | | | '---' 270 | .---. .---. .---. | | .---. .---. .---. | 271 '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' 272 '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' 274 Figure 4: SAP Network Topology 276 A single SAP network topology can be used for one or multiple service 277 types (e.g., L3VPN, Ethernet VPN (EVPN)). The network controller 278 can, then, expose the service type(s) and associated interfaces via 279 the SAPs. 281 As shown in Figure 5, the service orchestration layer will have also 282 access to a set of customer service model (e.g., the L3SM or the 283 L2SM) in the customer-facing interface and a set of network models 284 (e.g., the L3NM and network topology data models) in the resource- 285 facing interface. In this use case, it is assumed that the network 286 controller is unaware of what happens beyond the PEs towards the CEs; 287 it is only responsible for the management and control of the SAPs and 288 the network between PEs. In order to correlate between delivery 289 points expressed in service requests and SAPs, the SAP model may 290 include a peer customer point identifier. That identifier can be a 291 CE identifier, a site identifier, etc. 293 .---. 294 |CE2| 295 '-+-' 296 | 297 .-+-. .-+-. .-+-. .-+-. .-+-. 298 .-|sap|-|sap|-|sap|-. .-|sap|-------|sap|-. 299 | '---' '---' '---' | | '---' '---' | 300 .---. .---. | | | 301 |CE1+--+sap| PE1 | | PE2 | 302 '---' '---' | | | 303 | | | | 304 '-------------------' '-------------------' 306 .-------------------. .-------------------. 307 | | | | 308 | | | .---. .---. 309 | PE3 | | PE4 |sap+--+CE5| 310 | | | '---' '---' 311 | .---. .---. .---. | | .---. .---. .---. | 312 '-|sap|-|sap|-|sap|-' '-|sap|-|sap|-|sap|-' 313 '-+-' '-+-' '-+-' '-+-' '-+-' '-+-' 314 | | | 315 .-+-. | .-+-. 316 |CE3+----------------' |CE4| 317 '-+-' '-+-' 319 Figure 5: Network Topology with CEs and ACs 321 Refer to Appendix A for an example echoing the topology depicted in 322 Figure 5. 324 4. Relationship to Other YANG Data Models 326 The SAP network model can be seen as inventory data associated with 327 SAPs. The model maintains an inventory of nodes contained in a 328 network relying upon [RFC8345]. 330 +-------------------------+ 331 | | 332 | Abstract Network Model | 333 | | 334 +------------+------------+ 335 | 336 +---------+---------+ 337 | | 338 +------V------+ +------V------+ 339 | Abstract | | Inventory | 340 | Network | | Model(s) | 341 | Topology | | e.g., SAP | 342 | Model | | Network | 343 | | | Model | 344 +-----+-------+ +-------------+ 345 | 346 +-----------+-----------+ 347 | | | 348 +----V----+ +----V----+ +----V----+ 349 |TE Topo | |L3 Topo | |L2 Topo | 350 | Model | | Model | | Model | ... 351 +---------+ +---------+ +---------+ 353 Figure 6: Relation of SAP Network Model to Other Models 355 Figure 6 depicts the relationship of the SAP network model to other 356 models. The SAP network model augments the Network model [RFC8345] 357 and imports the Network Topology model, while other technology- 358 specific topology models (e.g., Traffic Engineering (TE) Topologies 359 model [RFC8795] or Layer 3 Topologies model [RFC8346]) augment the 360 Network Topology model. 362 Also, the SAP is not a tunnel termination point (TTP) (Section 3.6 of 363 [RFC8795]) nor a link. 365 In the context of Software-Defined Networking (SDN) 366 [RFC7149][RFC7426], the SAP YANG data model can be used to exchange 367 information between control elements, so as to support VPN service 368 provision and resource management discussed in 369 [RFC9182][I-D.ietf-opsawg-l2nm]. Through this data model, the 370 service orchestration layer can learn the available endpoints (i.e., 371 SAPs) of interconnection resources of the underlying network. The 372 service orchestration layer can determine which interconnection 373 endpoints to add to an L2VPN or L3VPN service. With the help of 374 other data models (e.g., L3SM [RFC8299] or L2SM [RFC8466]), 375 hierarchical control elements can also assess the feasibility of an 376 end-to-end IP connectivity or L2VPN connectivity and, therefore, 377 derive the sequence of domains and the points of interconnection to 378 use. 380 Advanced low-level interface-specific data nodes are not exposed in 381 the SAP model. Filters based on the interface identifiers listed in 382 the SAP model can be used together with dedicated device models to 383 set or get such data. 385 5. SAP Module Tree Structure 387 The SAP network model 'ietf-sap-ntw' builds on the 'ietf-network' 388 module [RFC8345] by augmenting the nodes with SAPs. 390 The structure of the 'ietf-sap-ntw' module is shown in Figure 7. 392 module: ietf-sap-ntw 393 augment /nw:networks/nw:network/nw:network-types: 394 +--rw sap-network! 395 +--rw service-type* identityref 396 augment /nw:networks/nw:network/nw:node: 397 +--rw service* [service-type] 398 +--rw service-type identityref 399 +--rw sap* [sap-id] 400 +--rw sap-id string 401 +--rw description? string 402 +--rw parent-termination-point? nt:tp-id 403 +--rw attachment-interface? string 404 +--rw interface-type? identityref 405 +--rw encapsulation-type? identityref 406 +--rw role? identityref 407 +--rw peer-sap-id? string 408 +--ro sap-status 409 | +--ro status? identityref 410 | +--ro last-change? yang:date-and-time 411 +--ro service-status 412 +--ro status? identityref 413 +--ro last-change? yang:date-and-time 415 Figure 7: SAP YANG Module Tree Structure 417 A SAP network topology can be used for one or multiple service types 418 ('service-type'). Examples of supported service types are as 419 follows: 421 * L3VPN [RFC4364], 423 * Virtual Private LAN Service (VPLS) [RFC4761][RFC4762], 425 * Virtual Private Wire Service (VPWS) [RFC8214], 427 * BGP MPLS-Based Ethernet VPN [RFC7432], 429 * VPWS in Ethernet VPN [RFC8214], 431 * Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) 432 [RFC7623], 434 * VXLAN-based EVPN [RFC8365], 436 * Virtual Networks [RFC8453], 438 * Enhanced VPN (VPN+) [I-D.ietf-teas-enhanced-vpn], 440 * Network slice [I-D.ietf-teas-ietf-network-slices], 442 * SDWAN [I-D.ietf-bess-bgp-sdwan-usage], and 444 * Basic IP connectivity. 446 These service types build on the types that are already defined in 447 [RFC9181] and additional types that are defined in this document. 448 Other service types can be defined in future YANG modules, if needed. 450 Filters based on the service type can be used to access per-service 451 SAP topology. A example is depicted in Figure 11. 453 A node in the topology can support one or multiple service types 454 ('service-type') among those listed under the 'sap-network' 455 container. A list of SAPs are then bound to each service type that 456 is supported by a given node. Each SAP is characterized as follows: 458 'sap-id': Includes an identifier that uniquely identifies a SAP 459 within a node. 461 The same SAP may appear under distinct service types. In such a 462 case, the same identifier is used for these service types in 463 association. 465 SAPs that are associated with the interfaces that are directly 466 hosting services, interfaces that are ready to host per-service 467 sub-interfaces (but not yet activated), or service that are 468 already instantiated on sub-interfaces are listed as SAPs. 470 For example, 'sap-id' may be the VPN network access identifier in 471 Section 7.6 of [RFC9182]. An example to illustrate the use of 472 this attribute during service creation is provided in Appendix D. 474 'description': Includes a textual description of the SAP. 476 'parent-termination-point': Includes a reference to the parent 477 interface to which the SAP is bound (e.g., a physical port). 479 This attribute is used, e.g., to associate an interface with its 480 sub-interfaces as all these interfaces may be listed under the 481 SAPs of a node. It is also used to link a SAP with the physical 482 topology. 484 For example, this data node can be used to map the IETF Network 485 Slice endpoints ([I-D.ietf-teas-ietf-network-slices]) to the 486 service/tunnel/path endpoints in the underlay network. 488 'attachment-interface': Indicates a reference to the interface to 489 which the SAP is bound. The same interface may host multiple 490 services. 492 Whether the attachment identifier echoes the content of the 493 attachment interface is deployment specific. 495 For example, this reference may be any of the identifiers ('l2- 496 termination-point', 'local-bridge-reference', 'bearer-reference', 497 or 'lag-interface-id') defined in Section 7.6.1 of [RFC9182] or 498 'l3-termination-point' defined in Section 7.6.2 of [RFC9182]. It 499 is responsibility of the controller to ensure that consistent 500 references are used in the SAP and underlying device modes or any 501 other device inventory mechanism. 503 'interface-type': Indicates whether a SAP is bound to a physical 504 port, a loopback interface, a Link Aggregation Group (LAG) 505 interface [IEEE802.1AX], an Integrated Routing Bridge (IRB) (e.g., 506 [RFC9135]), a local bridge reference, etc. 508 The mapping to the detailed interface types as per [RFC7224] is 509 maintained by the controller. That mapping is used, for example, 510 when the controller translates this SAP network module into device 511 modules. 513 'encapsulation-type': Indicates the encapsulation type for the 514 interface indicated in the 'attachment-interface' attribute. The 515 types are taken from [RFC9181]. 517 This data node can be used, for example, to decide whether an 518 existing SAP can be (re)used to host a service or if a new sub- 519 interface has to be instantiated. 521 'role': Specifies the role of a SAP (e.g., a UNI or NNI). 523 A SAP inherits the role of its parent interface ('parent- 524 termination-point'). 526 'peer-sap-id': Includes a reference to the remote endpoint of an 527 attachment circuit. 529 Examples of such a reference are: a site identifier (Section 6.3 530 of [RFC8299]), a Service Demarcation Point (SDP) identifier 531 (Section 2.1 of [I-D.ietf-teas-ietf-network-slices]), the IP 532 address of a peer Autonomous System Border Router (ASBR). 534 'sap-status': Indicates the operational status of a SAP. Values are 535 taken from the values defined in [RFC9181]. 537 When both a sub-interface and its parent interface are present, 538 the status of the parent interface takes precedence over the 539 status indicated for the sub-interface. 541 'service-status': Reports the operational status of service for a 542 given SAP. This information is particularly useful when many 543 services are enabled for the same SAP, but only a subset of them 544 are activated. 546 6. SAP YANG Module 548 This module imports types from [RFC8343], [RFC8345], and [RFC9181]. 550 The 'sap-information' is defined as a grouping for the reuse of these 551 nodes in service-specific YANG modules. 553 file "ietf-sap-ntw@2022-04-11.yang" 554 module ietf-sap-ntw { 555 yang-version 1.1; 556 namespace "urn:ietf:params:xml:ns:yang:ietf-sap-ntw"; 557 prefix sap; 559 import ietf-network-topology { 560 prefix nt; 561 reference 562 "RFC 8345: A YANG Data Model for Network 563 Topologies, Section 6.2"; 564 } 565 import ietf-network { 566 prefix nw; 567 reference 568 "RFC 8345: A YANG Data Model for Network 569 Topologies, Section 6.1"; 570 } 571 import ietf-vpn-common { 572 prefix vpn-common; 573 reference 574 "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 575 VPNs"; 576 } 578 organization 579 "IETF OPSA (Operations and Management Area) Working Group "; 580 contact 581 "WG Web: 582 WG List: 584 Editor: Mohamed Boucadair 585 587 Author: Oscar Gonzalez de Dios 588 590 Author: Samier Barguil 591 593 Author: Qin Wu 594 596 Author: Victor Lopez 597 "; 598 description 599 "This YANG module defines a model for representing, managing, 600 and controlling the Service Attachment Points (SAPs) in the 601 network topology. 603 Copyright (c) 2022 IETF Trust and the persons identified as 604 authors of the code. All rights reserved. 606 Redistribution and use in source and binary forms, with or 607 without modification, is permitted pursuant to, and subject to 608 the license terms contained in, the Revised BSD License set 609 forth in Section 4.c of the IETF Trust's Legal Provisions 610 Relating to IETF Documents 611 (https://trustee.ietf.org/license-info). 613 This version of this YANG module is part of RFC XXXX 614 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 615 for full legal notices."; 617 revision 2022-04-11 { 618 description 619 "Initial version"; 620 reference 621 "RFC XXXX: A Network YANG Model for Service Attachment 622 Points (SAPs)"; 623 } 625 identity virtual-network { 626 base vpn-common:service-type; 627 description 628 "Virtual network. Refers to a logical network instance 629 that is built over a physical network."; 630 reference 631 "RFC 8453: Framework for Abstraction and Control of TE 632 Networks (ACTN)"; 633 } 635 identity enhanced-vpn { 636 base vpn-common:service-type; 637 description 638 "Enhanced VPN (VPN+). VPN+ is an approach that is 639 based on existing VPN and Traffic Engineering (TE) 640 technologies but adds characteristics that specific 641 services require over and above traditional VPNs."; 642 reference 643 "draft-ietf-teas-enhanced-vpn: 644 A Framework for Enhanced Virtual Private Network 645 (VPN+) Services"; 646 } 648 identity network-slice { 649 base vpn-common:service-type; 650 description 651 "IETF network slice. An IETF network slice 652 is a logical network topology connecting a number of 653 endpoints using a set of shared or dedicated network 654 resources that are used to satisfy specific service 655 objectives."; 657 reference 658 "draft-ietf-teas-ietf-network-slices: 659 Framework for IETF Network Slices"; 660 } 662 identity sdwan { 663 base vpn-common:service-type; 664 description 665 "PE-based Software-Defined Wide Area Network (SDWAN)."; 666 reference 667 "draft-ietf-bess-bgp-sdwan-usage: BGP Usage for SDWAN 668 Overlay Network"; 669 } 671 identity basic-connectivity { 672 base vpn-common:service-type; 673 description 674 "Basic IP connectivity. This is, for example, a plain 675 connectivity offered to Enterprises over a dedicated 676 or shared MPLS infrastructure."; 677 } 679 identity interface-role { 680 description 681 "Base identity for the network role of an interface."; 682 } 684 identity uni { 685 base interface-role; 686 description 687 "User-Network Interface (UNI)."; 688 } 690 identity nni { 691 base interface-role; 692 description 693 "Network-to-Network Interface (NNI)."; 694 } 696 identity interface-type { 697 description 698 "Base identity for the interface type."; 699 } 701 identity phy { 702 base interface-type; 703 description 704 "Physical port."; 706 } 708 identity loopback { 709 base interface-type; 710 description 711 "Loopback interface."; 712 } 714 identity lag { 715 base interface-type; 716 description 717 "Link Aggregation Group (LAG) interface."; 718 } 720 identity irb { 721 base interface-type; 722 description 723 "Integrated Routing Bridge (IRB). An IRB typically 724 connects an IP-VRF to a bridge domain."; 725 } 727 identity local-bridge { 728 base interface-type; 729 description 730 "A local bridge reference to accommodate, e.g., 731 implementations that require internal bridging. 732 When such a type is used, a reference to a local 733 bridge domain is used to identify the interface."; 734 } 736 identity logical { 737 base interface-type; 738 description 739 "Refers to a logical sub-interface that is typically 740 used to bind a service. This type is used only 741 if none of the other logical types can be used."; 742 } 744 grouping sap-information { 745 description 746 "Service Attachment Point (SAP) information."; 747 list sap { 748 key "sap-id"; 749 description 750 "The Service Attachment Points are abstraction of 751 the points where network services such as L3VPNs, 752 L2VPNs, or network slices can be attached to."; 753 leaf sap-id { 754 type string; 755 description 756 "Indicates an identifier that uniquely identifies 757 SAP within a node."; 758 } 759 leaf description { 760 type string; 761 description 762 "A textual description of the SAP."; 763 } 764 leaf parent-termination-point { 765 type nt:tp-id; 766 description 767 "Indicates the parent termination point to 768 which the SAP is attached to. A termination 769 point can be a physical port, an interface, etc."; 770 } 771 leaf attachment-interface { 772 type string; 773 description 774 "Indicates the interface to which the SAP is bound."; 775 } 776 leaf interface-type { 777 type identityref { 778 base interface-type; 779 } 780 description 781 "The type of the interface to which the SAP is bound."; 782 } 783 leaf encapsulation-type { 784 type identityref { 785 base vpn-common:encapsulation-type; 786 } 787 description 788 "Encapsulation type of the interface to which the 789 SAP is bound."; 790 } 791 leaf role { 792 type identityref { 793 base interface-role; 794 } 795 description 796 "Indicates the role of a SAP."; 797 } 798 leaf peer-sap-id { 799 type string; 800 description 801 "Indicates an identifier of the peer's termination 802 identifier (e.g., Customer Edge (CE)). This 803 information can be used for correlation purposes, 804 such as identifying the SAP that is attached to 805 an endpoint that is provided in a service request."; 806 } 807 container sap-status { 808 config "false"; 809 description 810 "Indicates the SAP status."; 811 uses vpn-common:oper-status-timestamp; 812 } 813 container service-status { 814 config "false"; 815 description 816 "Indicates the service status."; 817 uses vpn-common:oper-status-timestamp; 818 } 819 } 820 } 822 augment "/nw:networks/nw:network/nw:network-types" { 823 description 824 "Introduces a new network type for SAP network."; 825 container sap-network { 826 presence "Indicates SAP network type."; 827 description 828 "The presence of the container node indicates the 829 SAP network type."; 830 leaf-list service-type { 831 type identityref { 832 base vpn-common:service-type; 833 } 834 description 835 "Indicates the set of supported service types."; 836 } 837 } 838 } 840 augment "/nw:networks/nw:network/nw:node" { 841 when "../nw:network-types/sap:sap-network" { 842 description 843 "Augmentation parameters apply only for SAP 844 networks."; 845 } 846 description 847 "SAP parameters for the node level."; 848 list service { 849 key "service-type"; 850 description 851 "A list of supported service types for the node."; 852 leaf service-type { 853 type identityref { 854 base vpn-common:service-type; 855 } 856 description 857 "Indicates a service type."; 858 } 859 uses sap-information; 860 } 861 } 862 } 863 865 7. IANA Considerations 867 This document registers the following namespace URI in the "ns" 868 subregistry within the "IETF XML Registry" [RFC3688]: 870 URI: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 871 Registrant Contact: The IESG. 872 XML: N/A, the requested URI is an XML namespace. 874 This document registers the following YANG module in the YANG Module 875 Names registry [RFC6020] within the "YANG Parameters" registry: 877 name: ietf-sap-ntw 878 namespace: urn:ietf:params:xml:ns:yang:ietf-sap-ntw 879 maintained by IANA? N 880 prefix: sap 881 reference: RFC XXXX 883 8. Security Considerations 885 The YANG module specified in this document defines schema for data 886 that is designed to be accessed via network management protocols such 887 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 888 is the secure transport layer, and the mandatory-to-implement secure 889 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 890 is HTTPS, and the mandatory-to-implement secure transport is TLS 891 [RFC8446]. 893 The Network Configuration Access Control Model (NACM) [RFC8341] 894 provides the means to restrict access for particular NETCONF or 895 RESTCONF users to a preconfigured subset of all available NETCONF or 896 RESTCONF protocol operations and content. 898 There are a number of data nodes defined in this YANG module that are 899 writable/creatable/deletable (i.e., config true, which is the 900 default). These data nodes may be considered sensitive or vulnerable 901 in some network environments. Write operations (e.g., edit-config) 902 to these data nodes without proper protection can have a negative 903 effect on network operations. These are the subtrees and data nodes 904 and their sensitivity/vulnerability: 906 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 908 This subtree specifies the configurations of the nodes in a SAP 909 network model. Unexpected changes to this subtree (e.g., 910 associating a SAP with another parent termination interface) could 911 lead to service disruption and/or network misbehavior. 913 Some of the readable data nodes in this YANG module may be considered 914 sensitive or vulnerable in some network environments. It is thus 915 important to control read access (e.g., via get, get-config, or 916 notification) to these data nodes. These are the subtrees and data 917 nodes and their sensitivity/vulnerability: 919 * /nw:networks/nw:network/nw:node/sap:service-type/sap:sap 921 Unauthorized access to this subtree can disclose the operational 922 state information of the nodes in a SAP network model (e.g., 923 disclose the identity of a customer 'peer-sap-id'). 925 9. Acknowledgements 927 Thanks to Adrian Farrell, Daniel King, Dhruv Dhody, Benoit Claise, Bo 928 Wu, Erez Segev, Raul Arco, Joe Clarke, Riyas Valiyapalathingal, Tom 929 Petch, and Olga Havel for the comments. 931 Thanks to Martin Bjoerklund for yang-doctors review, Menachem Dodge 932 for the opsdir review, and Mach Chen for the rtgdir review. 934 10. References 936 10.1. Normative References 938 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 939 DOI 10.17487/RFC3688, January 2004, 940 . 942 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 943 the Network Configuration Protocol (NETCONF)", RFC 6020, 944 DOI 10.17487/RFC6020, October 2010, 945 . 947 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 948 and A. Bierman, Ed., "Network Configuration Protocol 949 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 950 . 952 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 953 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 954 . 956 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 957 RFC 7950, DOI 10.17487/RFC7950, August 2016, 958 . 960 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 961 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 962 . 964 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 965 Access Control Model", STD 91, RFC 8341, 966 DOI 10.17487/RFC8341, March 2018, 967 . 969 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 970 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 971 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 972 2018, . 974 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 975 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 976 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 977 March 2018, . 979 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 980 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 981 . 983 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 984 O. Gonzalez de Dios, "YANG Data Model for Traffic 985 Engineering (TE) Topologies", RFC 8795, 986 DOI 10.17487/RFC8795, August 2020, 987 . 989 [RFC9181] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 990 Ed., and Q. Wu, "A Common YANG Data Model for Layer 2 and 991 Layer 3 VPNs", RFC 9181, DOI 10.17487/RFC9181, February 992 2022, . 994 10.2. Informative References 996 [I-D.ietf-bess-bgp-sdwan-usage] 997 Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem, 998 B., and D. Carrel, "BGP Usage for SDWAN Overlay Networks", 999 Work in Progress, Internet-Draft, draft-ietf-bess-bgp- 1000 sdwan-usage-05, 18 April 2022, 1001 . 1004 [I-D.ietf-opsawg-l2nm] 1005 Boucadair, M., Dios, O. G. D., Barguil, S., and L. A. 1006 Munoz, "A YANG Network Data Model for Layer 2 VPNs", Work 1007 in Progress, Internet-Draft, draft-ietf-opsawg-l2nm-16, 13 1008 May 2022, . 1011 [I-D.ietf-teas-enhanced-vpn] 1012 Dong, J., Bryant, S., Li, Z., Miyasaka, T., and Y. Lee, "A 1013 Framework for Enhanced Virtual Private Network (VPN+) 1014 Services", Work in Progress, Internet-Draft, draft-ietf- 1015 teas-enhanced-vpn-10, 6 March 2022, 1016 . 1019 [I-D.ietf-teas-ietf-network-slices] 1020 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 1021 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 1022 Network Slices", Work in Progress, Internet-Draft, draft- 1023 ietf-teas-ietf-network-slices-10, 27 March 2022, 1024 . 1027 [IEEE802.1AX] 1028 "Link Aggregation", IEEE Std 802.1AX-2020, 2020. 1030 [MEF17] Forum, T. M. E., "Technical Specification MEF 17, Service 1031 OAM Requirements & Framework – Phase 1", April 2007, 1032 . 1035 [MEF6] Forum, T. M. E., "Technical Specification MEF 6, Ethernet 1036 Services Definitions - Phase I", June 2004, 1037 . 1040 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 1041 Private Network (VPN) Terminology", RFC 4026, 1042 DOI 10.17487/RFC4026, March 2005, 1043 . 1045 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1046 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1047 2006, . 1049 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 1050 LAN Service (VPLS) Using BGP for Auto-Discovery and 1051 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 1052 . 1054 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 1055 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 1056 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 1057 . 1059 [RFC6004] Berger, L. and D. Fedyk, "Generalized MPLS (GMPLS) Support 1060 for Metro Ethernet Forum and G.8011 Ethernet Service 1061 Switching", RFC 6004, DOI 10.17487/RFC6004, October 2010, 1062 . 1064 [RFC6215] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport 1065 Profile User-to-Network and Network-to-Network 1066 Interfaces", RFC 6215, DOI 10.17487/RFC6215, April 2011, 1067 . 1069 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 1070 Networking: A Perspective from within a Service Provider 1071 Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, 1072 . 1074 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", 1075 RFC 7224, DOI 10.17487/RFC7224, May 2014, 1076 . 1078 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 1079 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 1080 Defined Networking (SDN): Layers and Architecture 1081 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 1082 2015, . 1084 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1085 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1086 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1087 2015, . 1089 [RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. 1090 Henderickx, "Provider Backbone Bridging Combined with 1091 Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, 1092 September 2015, . 1094 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 1095 Rabadan, "Virtual Private Wire Service Support in Ethernet 1096 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 1097 . 1099 [RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, 1100 "YANG Data Model for L3VPN Service Delivery", RFC 8299, 1101 DOI 10.17487/RFC8299, January 2018, 1102 . 1104 [RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models 1105 Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018, 1106 . 1108 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1109 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1110 . 1112 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1113 and R. Wilton, "Network Management Datastore Architecture 1114 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1115 . 1117 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 1118 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 1119 . 1121 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 1122 Uttaro, J., and W. Henderickx, "A Network Virtualization 1123 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 1124 DOI 10.17487/RFC8365, March 2018, 1125 . 1127 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1128 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1129 DOI 10.17487/RFC8453, August 2018, 1130 . 1132 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1133 Data Model for Layer 2 Virtual Private Network (L2VPN) 1134 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1135 2018, . 1137 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and 1138 L. Geng, "A Framework for Automating Service and Network 1139 Management with YANG", RFC 8969, DOI 10.17487/RFC8969, 1140 January 2021, . 1142 [RFC9135] Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. 1143 Rabadan, "Integrated Routing and Bridging in Ethernet VPN 1144 (EVPN)", RFC 9135, DOI 10.17487/RFC9135, October 2021, 1145 . 1147 [RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M., 1148 Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model 1149 for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182, 1150 February 2022, . 1152 Appendix A. A Simplified SAP Network Example 1154 An example of a SAP topology that is reported by a network controller 1155 is depicted in Figure 8. This example echoes the topology shown in 1156 Figure 5. Only a minimum set of information is provided for each 1157 SAP. 1159 { 1160 "ietf-network:networks": { 1161 "network": [ 1162 { 1163 "network-types": { 1164 "ietf-sap-ntw:sap-network": { 1165 "service-type": [ 1166 "ietf-vpn-common:l3vpn", 1167 "ietf-vpn-common:vpls" 1168 ] 1169 } 1170 }, 1171 "network-id": "foo:an-id", 1172 "node": [ 1173 { 1174 "node-id": "foo:pe1", 1175 "ietf-sap-ntw:service": [ 1176 { 1177 "service-type": "ietf-vpn-common:l3vpn", 1178 "sap": [ 1179 { 1180 "sap-id": "sap#11", 1181 "peer-sap-id": "ce-1", 1182 "service-status": { 1183 "status": "ietf-vpn-common:op-up" 1184 } 1185 }, 1186 { 1187 "sap-id": "sap#12" 1188 }, 1189 { 1190 "sap-id": "sap#13" 1191 }, 1192 { 1193 "sap-id": "sap#14" 1194 } 1195 ] 1196 } 1197 ] 1198 }, 1199 { 1200 "node-id": "foo:pe2", 1201 "ietf-sap-ntw:service": [ 1202 { 1203 "service-type": "ietf-vpn-common:l3vpn", 1204 "sap": [ 1205 { 1206 "sap-id": "sap#21" 1207 }, 1208 { 1209 "sap-id": "sap#22", 1210 "peer-sap-id": "ce-2", 1211 "service-status": { 1212 "status": "ietf-vpn-common:op-up" 1213 } 1214 } 1215 ] 1216 } 1217 ] 1218 }, 1219 { 1220 "node-id": "foo:pe3", 1221 "ietf-sap-ntw:service": [ 1222 { 1223 "service-type": "ietf-vpn-common:l3vpn", 1224 "sap": [ 1225 { 1226 "sap-id": "sap#31" 1227 }, 1228 { 1229 "sap-id": "sap#32" 1230 }, 1231 { 1232 "sap-id": "sap#33", 1233 "peer-sap-id": "ce-3", 1234 "service-status": { 1235 "status": "ietf-vpn-common:op-up" 1236 } 1237 } 1238 ] 1239 } 1240 ] 1241 }, 1242 { 1243 "node-id": "foo:pe4", 1244 "ietf-sap-ntw:service": [ 1245 { 1246 "service-type": "ietf-vpn-common:l3vpn", 1247 "sap": [ 1248 { 1249 "sap-id": "sap#41", 1250 "peer-sap-id": "ce-3", 1251 "service-status": { 1252 "status": "ietf-vpn-common:op-up" 1253 } 1254 }, 1255 { 1256 "sap-id": "sap#42", 1257 "peer-sap-id": "ce-4", 1258 "service-status": { 1259 "status": "ietf-vpn-common:op-up" 1260 } 1261 }, 1262 { 1263 "sap-id": "sap#43" 1264 }, 1265 { 1266 "sap-id": "sap#44", 1267 "peer-sap-id": "ce-5", 1268 "service-status": { 1269 "status": "ietf-vpn-common:op-up" 1270 } 1271 } 1272 ] 1273 } 1274 ] 1275 } 1277 ] 1278 } 1279 ] 1280 } 1281 } 1283 Figure 8: A Simplified SAP Network Example 1285 Appendix B. A Simple Example of SAP Network Model: Node Filter 1287 In the example shown in Figure 9, PE1 (with a "node-id" set to 1288 "foo:pe1") has two physical interfaces "GE0/6/1" and "GE0/6/4". Two 1289 sub-interfaces "GE0/6/4.1" and "GE0/6/4.2" are associated with the 1290 physical interface "GE0/6/4". Let us consider that four SAPs are 1291 exposed to the service orchestrator and mapped to these physical 1292 interfaces and sub-interfaces. 1294 .-------------------------. 1295 | GE0/6/4 | 1296 | PE1 .----+----. 1297 | |sap#2 |GE0/6/4.1 1298 | | .--+--. 1299 | | |sap#3| 1300 | | '--+--' 1301 | | |GE0/6/4.2 1302 | | .--+--. 1303 | | |sap#4| 1304 | | '--+--' 1305 | | | 1306 | +----+----+ 1307 | | 1308 | GE0/6/1| 1309 | .----+----. 1310 | |sap#1 | 1311 | '----+----' 1312 | | 1313 '-------------------------' 1315 Figure 9: An Example of a PE and its Physical/Logical Interfaces 1317 Let us assume that no service is enabled yet for the SAP associated 1318 with the physical interface "GE0/6/1". Also, let us assume that, for 1319 the SAPs that are associated with the physical interface "GE0/6/4", 1320 VPLS and L3VPN services are activated on the two sub-interfaces 1321 "GE0/6/4.1" and "GE0/6/4.2", respectively. 1323 A service orchestrator can query what services are provided on which 1324 SAPs of PE1 from the network controller by sending, e.g., a GET 1325 RESTCONF request. Figure 10 shows the body of the RESTCONF response 1326 that is received from the network controller. 1328 { 1329 "ietf-sap-ntw:service": [ 1330 { 1331 "service-type": "ietf-vpn-common:l3vpn", 1332 "sap": [ 1333 { 1334 "sap-id": "sap#1", 1335 "description": "Ready to host SAPs", 1336 "attachment-interface": "GE0/6/1", 1337 "interface-type": "ietf-sap-ntw:phy", 1338 "role": "ietf-sap-ntw:uni", 1339 "sap-status": { 1340 "status": "ietf-vpn-common:op-up" 1341 } 1342 }, 1343 { 1344 "sap-id": "sap#2", 1345 "description": "Ready to host SAPs", 1346 "attachment-interface": "GE0/6/4", 1347 "interface-type": "ietf-sap-ntw:phy", 1348 "role": "ietf-sap-ntw:uni", 1349 "sap-status": { 1350 "status": "ietf-vpn-common:op-up" 1351 } 1352 }, 1353 { 1354 "sap-id": "sap#3", 1355 "description": "A first SAP description", 1356 "parent-termination-point": "GE0/6/4", 1357 "attachment-interface": "GE0/6/4.1", 1358 "interface-type": "ietf-sap-ntw:logical", 1359 "encapsulation-type": "ietf-vpn-common:vlan-type", 1360 "sap-status": { 1361 "status": "ietf-vpn-common:op-up" 1362 }, 1363 "service-status": { 1364 "status": "ietf-vpn-common:op-up" 1365 } 1366 } 1367 ] 1368 }, 1369 { 1370 "service-type": "ietf-vpn-common:vpls", 1371 "sap": [ 1372 "sap-id": "sap#1", 1373 "description": "Ready to host SAPs", 1374 "attachment-interface": "GE0/6/1", 1375 "interface-type": "ietf-sap-ntw:phy", 1376 "role": "ietf-sap-ntw:uni", 1377 "sap-status": { 1378 "status": "ietf-vpn-common:op-up" 1379 } 1380 }, 1381 { 1382 "sap-id": "sap#2", 1383 "description": "Ready to host SAPs", 1384 "attachment-interface": "GE0/6/4", 1385 "interface-type": "ietf-sap-ntw:phy", 1386 "role": "ietf-sap-ntw:uni", 1387 "sap-status": { 1388 "status": "ietf-vpn-common:op-up" 1389 } 1390 }, 1391 { 1392 "sap-id": "sap#4", 1393 "description": "Another description", 1394 "parent-termination-point": "GE0/6/4", 1395 "attachment-interface": "GE0/6/4.2", 1396 "interface-type": "ietf-sap-ntw:logical", 1397 "encapsulation-type": "ietf-vpn-common:vlan-type", 1398 "sap-status": { 1399 "status": "ietf-vpn-common:op-up" 1400 }, 1401 "service-status": { 1402 "status": "ietf-vpn-common:op-up" 1403 } 1404 } 1405 ] 1406 } 1407 ] 1408 } 1410 Figure 10: An Example of a Response Body to a Request with a Node 1411 Filter 1413 Figure 11 shows the message body of a response that is received from 1414 the network controller if the request includes a filter on the 1415 service type for a particular node: 1417 { 1418 "ietf-sap-ntw:service": [ 1419 { 1420 "service-type": "ietf-vpn-common:l3vpn", 1421 "sap": [ 1422 { 1423 "sap-id": "sap#1", 1424 "description": "Ready to host SAPs", 1425 "attachment-interface": "GE0/6/1", 1426 "interface-type": "ietf-sap-ntw:phy", 1427 "role": "ietf-sap-ntw:uni", 1428 "sap-status": { 1429 "status": "ietf-vpn-common:op-up" 1430 } 1431 }, 1432 { 1433 "sap-id": "sap#2", 1434 "description": "Ready to host SAPs", 1435 "attachment-interface": "GE0/6/4", 1436 "interface-type": "ietf-sap-ntw:phy", 1437 "role": "ietf-sap-ntw:uni", 1438 "sap-status": { 1439 "status": "ietf-vpn-common:op-up" 1440 } 1441 }, 1442 { 1443 "sap-id": "sap#3", 1444 "description": "A first SAP description", 1445 "parent-termination-point": "GE0/6/4", 1446 "attachment-interface": "GE0/6/4.1", 1447 "interface-type": "ietf-sap-ntw:logical", 1448 "encapsulation-type": "ietf-vpn-common:vlan-type", 1449 "sap-status": { 1450 "status": "ietf-vpn-common:op-up" 1451 }, 1452 "service-status": { 1453 "status": "ietf-vpn-common:op-up" 1454 } 1455 } 1456 ] 1457 } 1458 ] 1459 } 1461 Figure 11: An Example of a Response Body to a Request with a 1462 Service Filter 1464 Appendix C. An Example of NNI SAP: Inter-AS VPN Option A 1466 Section 10 of [RFC4364] discuses several options to extend a VPN 1467 service beyond the scope of a single Autonomous System (AS). For 1468 illustration purposes, this section focuses on the so called "Option 1469 A" but similar examples can be considered for other options. 1471 In this option, an ASBR of an AS is directly connected to an ASBR of 1472 a neighboring AS. These two ASBRs are connected by multiple physical 1473 or logical interfaces. Also, at least one sub-interface is 1474 maintained by these ASBRs for each of the VPNs that require their 1475 routes to be passed from one AS to the other AS. Each ASBR behaves 1476 as a PE and treats the other as if it were a CE. 1478 Figure 12 shows a simplified (excerpt) topology of two ASes A and B 1479 with a focus on the interconnection links between these two ASes. 1481 .--------------------. .--------------------. 1482 | | | | 1483 | A .--+--. .--+--. A | 1484 | S | +================+ | S | 1485 | B | (VRF1)----(VPN1)----(VRF1) | B | 1486 | R | | | | R | 1487 | | (VRF2)----(VPN2)----(VRF2) | | 1488 | a | +================+ | b | 1489 | 1 '--+--' '--+--' 1 | 1490 | AS A | | AS B | 1491 | A .--+--. .--+--. A | 1492 | S | +================+ | S | 1493 | B | (VRF1)----(VPN1)----(VRF1) | B | 1494 | R | | | | R | 1495 | | (VRF2)----(VPN2)----(VRF2) | | 1496 | a | +================+ | b | 1497 | 2 '--+--' '--+--' 2 | 1498 | | | | 1499 '--------------------' '--------------------' 1501 Figure 12: An Example of Inter-AS VPN (Option A) 1503 Figure 13 shows an example of a message body that is received from 1504 the network controller of AS A (with a focus on the NNIs shown in 1505 Figure 12). 1507 { 1508 "ietf-network:networks": { 1509 "network": [ 1510 { 1511 "network-types": { 1512 "ietf-sap-ntw:sap-network": { 1513 "service-type": [ 1514 "ietf-vpn-common:l3vpn" 1515 ] 1516 } 1517 }, 1518 "network-id": "foo:an-id", 1519 "node": [ 1520 { 1521 "node-id": "foo:asbr-a1", 1522 "ietf-sap-ntw:service": [ 1523 { 1524 "service-type": "ietf-vpn-common:l3vpn", 1525 "sap": [ 1526 { 1527 "sap-id": "sap#11", 1528 "description": "parent inter-as link#1", 1529 "role": "ietf-sap-ntw:nni", 1530 "peer-sap-id": "asbr-b1", 1531 "service-status": { 1532 "status": "ietf-vpn-common:op-up" 1533 } 1534 }, 1535 { 1536 "sap-id": "sap#12", 1537 "description": "parent inter-as link#2", 1538 "role": "ietf-sap-ntw:nni", 1539 "peer-sap-id": "asbr-b1", 1540 "service-status": { 1541 "status": "ietf-vpn-common:op-up" 1542 } 1543 }, 1544 { 1545 "sap-id": "sap#13", 1546 "description": "vpn1", 1547 "role": "ietf-sap-ntw:nni", 1548 "peer-sap-id": "asbr-b1", 1549 "service-status": { 1550 "status": "ietf-vpn-common:op-up" 1551 } 1552 }, 1553 { 1554 "sap-id": "sap#14", 1555 "description": "vpn2", 1556 "role": "ietf-sap-ntw:nni", 1557 "peer-sap-id": "asbr-b1", 1558 "service-status": { 1559 "status": "ietf-vpn-common:op-up" 1560 } 1561 } 1562 ] 1563 } 1564 ] 1565 }, 1566 { 1567 "node-id": "foo:asbr-a2", 1568 "ietf-sap-ntw:service": [ 1569 { 1570 "service-type": "ietf-vpn-common:l3vpn", 1571 "sap": [ 1572 { 1573 "sap-id": "sap#11", 1574 "description": "parent inter-as link#1", 1575 "role": "ietf-sap-ntw:nni", 1576 "peer-sap-id": "asbr-b2", 1577 "service-status": { 1578 "status": "ietf-vpn-common:op-up" 1579 } 1580 }, 1581 { 1582 "sap-id": "sap#12", 1583 "description": "parent inter-as link#2", 1584 "role": "ietf-sap-ntw:nni", 1585 "peer-sap-id": "asbr-b2", 1586 "service-status": { 1587 "status": "ietf-vpn-common:op-up" 1588 } 1589 }, 1590 { 1591 "sap-id": "sap#21", 1592 "description": "vpn1", 1593 "role": "ietf-sap-ntw:nni", 1594 "peer-sap-id": "asbr-b2", 1595 "service-status": { 1596 "status": "ietf-vpn-common:op-up" 1597 } 1598 }, 1599 { 1600 "sap-id": "sap#22", 1601 "description": "vpn2", 1602 "role": "ietf-sap-ntw:nni", 1603 "peer-sap-id": "asbr-b2", 1604 "service-status": { 1605 "status": "ietf-vpn-common:op-up" 1606 } 1607 } 1608 ] 1609 } 1610 ] 1611 } 1612 ] 1613 } 1614 ] 1615 } 1616 } 1618 Figure 13: An Example of SAP Usage for NNI 1620 Appendix D. An Example of Using the SAP Network Model in Service 1621 Creation 1623 This section describes an example to illustrate the use of the SAP 1624 model for service creation purposes. 1626 An example of a SAP topology is presented in Figure 8. This example 1627 includes four PEs with their SAPs, as well as the customer 1628 information. 1630 Let us assume that an operator wants to create an L3VPN service 1631 between two PEs (PE3 and PE4) that are servicing two CEs (CE6 and 1632 CE7). To that aim, the operator would query the SAP topology and 1633 would obtain a response similar to what is depicted in Figure 8. 1634 That response indicates that the SAPs having "sap#31" and "sap#43" as 1635 attachment identifiers do not have any installed services. Once the 1636 "free" SAPs are identified, the 'interface-type' and 'encapsulation- 1637 type' are checked to see if the requested L3VPN service is compatible 1638 with the SAP characteristics. If they are compatible, as proposed in 1639 Section 5, the 'attachment-id' value can be used as the VPN network 1640 access identifier in an L3NM create query. 1642 Let us now assume that, instead of the L3VPN service, the operator 1643 wants to set up an L2VPN service. If the 'interface-type' is a 1644 physical port, a new logical SAP can be created using the SAP model 1645 to cope with the service needs (e.g., the 'encapsulation-type' 1646 attribute can be set to 'ietf-vpn-common:vlan-type'). Once the 1647 logical SAP is created, the 'attachment-id' of the new SAP is used to 1648 create an L2NM instance (Section 7.6 of [I-D.ietf-opsawg-l2nm]). 1650 Authors' Addresses 1652 Mohamed Boucadair (editor) 1653 Orange 1654 France 1655 Email: mohamed.boucadair@orange.com 1657 Oscar Gonzalez de Dios 1658 Telefonica 1659 Madrid 1660 Spain 1661 Email: oscar.gonzalezdedios@telefonica.com 1663 Samier Barguil 1664 Telefonica 1665 Madrid 1666 Spain 1667 Email: samier.barguilgiraldo.ext@telefonica.com 1669 Qin Wu 1670 Huawei 1671 101 Software Avenue, Yuhua District 1672 Nanjing 1673 Jiangsu, 210012 1674 China 1675 Email: bill.wu@huawei.com 1677 Victor Lopez 1678 Nokia 1679 Spain 1680 Email: victor.lopez@nokia.com