idnits 2.17.1 draft-ietf-ccamp-transport-nbi-app-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2018) is 2234 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PKT' is mentioned on line 1077, but not defined == Missing Reference: 'ODU2' is mentioned on line 1076, but not defined == Missing Reference: 'TE-Topo' is mentioned on line 474, but not defined == Missing Reference: 'ODU0' is mentioned on line 724, but not defined == Missing Reference: 'MAC' is mentioned on line 787, but not defined == Missing Reference: 'ODUflex' is mentioned on line 790, but not defined == Unused Reference: 'CLIENT-TOPO' is defined on line 1671, but no explicit reference was found in the text == Unused Reference: 'CLIENT-SVC' is defined on line 1686, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group I. Busi 2 Internet Draft Huawei 3 Intended status: Informational D. King 4 Lancaster University 5 H. Zheng 6 Huawei 7 Y. Xu 8 CAICT 10 Expires: September 2018 March 5, 2018 12 Transport Northbound Interface Applicability Statement 13 draft-ietf-ccamp-transport-nbi-app-statement-01 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on September 5, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Transport network domains, including Optical Transport Network (OTN) 56 and Wavelength Division Multiplexing (WDM) networks, are typically 57 deployed based on a single vendor or technology platforms. They are 58 often managed using proprietary interfaces to dedicated Element 59 Management Systems (EMS), Network Management Systems (NMS) and 60 increasingly Software Defined Network (SDN) controllers. 62 A well-defined open interface to each domain management system or 63 controller is required for network operators to facilitate control 64 automation and orchestrate end-to-end services across multi-domain 65 networks. These functions may be enabled using standardized data 66 models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). 68 This document analyses the applicability of the YANG models being 69 defined by IETF (TEAS and CCAMP WGs in particular) to support OTN 70 single and multi-domain scenarios. 72 Table of Contents 74 1. Introduction..................................................3 75 1.1. Scope of this document...................................4 76 1.2. Assumptions..............................................5 77 2. Terminology...................................................5 78 3. Conventions used in this document.............................6 79 3.1. Topology and traffic flow processing.....................6 80 3.2. JSON code................................................7 81 4. Scenarios Description.........................................8 82 4.1. Reference Network........................................8 83 4.1.1. Single-Domain Scenario.............................10 84 4.1.2. Multi-Domain Scenario..............................10 85 4.2. Topology Abstractions...................................10 86 4.3. Service Configuration...................................12 87 4.3.1. ODU Transit........................................13 88 4.3.2. EPL over ODU.......................................13 89 4.3.3. Other OTN Clients Services.........................14 90 4.3.4. EVPL over ODU......................................15 91 4.3.5. EVPLAN and EVPTree Services........................16 92 4.3.6. Dynamic Service Configuration......................18 94 4.4. Multi-function Access Links.............................18 95 4.5. Protection and Restoration Configuration................19 96 4.5.1. Linear Protection (end-to-end).....................20 97 4.5.2. Segmented Protection...............................21 98 4.5.3. End-to-End Dynamic Restoration.....................21 99 4.5.4. Segmented Dynamic Restoration......................22 100 4.6. Service Modification and Deletion.......................23 101 4.7. Notification............................................23 102 4.8. Path Computation with Constraint........................23 103 5. YANG Model Analysis..........................................24 104 5.1. YANG Models for Topology Abstraction....................24 105 5.1.1. Domain 1 Topology Abstraction......................25 106 5.1.2. Domain 2 Grey (Type A) Topology Abstraction........26 107 5.1.3. Domain 3 Grey (Type B) Topology Abstraction........26 108 5.1.4. Multi-domain Topology Stitching....................26 109 5.1.5. Access Links.......................................27 110 5.2. YANG Models for Service Configuration...................28 111 5.2.1. ODU Transit Service................................30 112 5.2.2. EPL over ODU Service...............................32 113 5.2.3. Other OTN Client Services..........................33 114 5.2.4. EVPL over ODU Service..............................34 115 5.3. YANG Models for Protection Configuration................35 116 5.3.1. Linear Protection (end-to-end).....................35 117 5.3.2. Segmented Protection...............................35 118 6. Detailed JSON Examples.......................................35 119 6.1. JSON Examples for Topology Abstractions.................35 120 6.1.1. Domain 1 White Topology Abstraction................35 121 6.2. JSON Examples for Service Configuration.................35 122 6.2.1. ODU Transit Service................................35 123 6.3. JSON Example for Protection Configuration...............36 124 7. Security Considerations......................................36 125 8. IANA Considerations..........................................36 126 9. References...................................................36 127 9.1. Normative References....................................36 128 9.2. Informative References..................................37 129 10. Acknowledgments.............................................38 130 Appendix A. Detailed JSON Examples..............................39 131 A.1. JSON Code: mpi1-otn-topology.json.......................39 132 A.2. JSON Code: mpi1-odu2-service-config.json...............39 133 Appendix B. Validating a JSON fragment against a YANG Model.....40 134 B.1. DSDL-based approach.....................................40 135 B.2. Why not using a XSD-based approach......................40 137 1. Introduction 139 Transport of packet services are critical for a wide-range of 140 applications and services, including: data center and LAN 141 interconnects, Internet service backhauling, mobile backhaul and 142 enterprise Carrier Ethernet Services. These services are typically 143 setup using stovepipe NMS and EMS platforms, often requiring 144 propriety management platforms and legacy management interfaces. A 145 clear goal of operators will be to automate setup of transport 146 services across multiple transport technology domains. 148 A common open interface (API) to each domain controller and or 149 management system is pre-requisite for network operators to control 150 multi-vendor and multi-domain networks and enable also service 151 provisioning coordination/automation. This can be achieved by using 152 standardized YANG models, used together with an appropriate protocol 153 (e.g., RESTCONF). 155 This document analyses the applicability of the YANG models being 156 defined by IETF (TEAS and CCAMP WGs in particular) to support OTN 157 single and multi-domain scenarios. 159 1.1. Scope of this document 161 This document assumes a reference architecture, including 162 interfaces, based on the Abstraction and Control of Traffic- 163 Engineered Networks (ACTN), defined in [ACTN-Frame]. 165 The focus of this document is on the MPI (interface between the 166 Multi Domain Service Coordinator (MDSC) and a Physical Network 167 Controller (PNC), controlling a transport network domain). 169 It is worth noting that the same MPI analyzed in this document could 170 be used between hierarchical MDSC controllers, as shown in Figure 4 171 of [ACTN-Frame]. 173 Detailed analysis of the CMI (interface between the Customer Network 174 Controller (CNC) and the MDSC) as well as of the interface between 175 service and network orchestrators are outside the scope of this 176 document. However, some considerations and assumptions about the 177 information could be described when needed. 179 The relationship between the current IETF YANG models and the type 180 of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it 181 considers the TE Topology YANG model defined in [TE-TOPO], with the 182 OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel 183 YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation 184 defined in [OTN-TUNNEL]. 186 The analysis of how to use the attributes in the I2RS Topology YANG 187 model, defined in [I2RS-TOPO], is for further study. 189 The ONF Technical Recommendations for Functional Requirements for 190 the transport API in [ONF TR-527] and the ONF transport API multi- 191 domain examples in [ONF GitHub] have been considered as an input for 192 defining the reference scenarios analyzed in this document. 194 1.2. Assumptions 196 This document is making the following assumptions, still to be 197 validated with TEAS WG: 199 1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel 200 Segment using the TE Tunnel YANG model: in this case, since the 201 endpoints of the E2E Tunnel are outside the domain controlled by 202 that PNC, the MDSC would not specify any source or destination 203 TTP (i.e., it would leave the source, destination, src-tp-id and 204 dst-tp-id attributes empty) and it would use the explicit-route- 205 object list to specify the ingress and egress links of the 206 Transit Tunnel Segment. 208 2. Each PNC provides to the MDSC, at the MPI, the list of available 209 timeslots on the inter-domain links using the TE Topology YANG 210 model and OTN Topology augmentation. The TE Topology YANG model 211 in [TE-TOPO] is being updated to report the label set 212 information. 214 This document is also making the following assumptions, still to be 215 validated with CCAMP WG: 217 2. Terminology 219 Domain: defined as a collection of network elements within a common 220 realm of address space or path computation responsibility [RFC5151] 222 E-LINE: Ethernet Line 224 EPL: Ethernet Private Line 226 EVPL: Ethernet Virtual Private Line 228 OTN: Optical Transport Network 230 Service: A service in the context of this document can be considered 231 as some form of connectivity between customer sites across the 232 network operator's network [RFC8309] 234 Service Model: As described in [RFC8309] it describes a service and 235 the parameters of the service in a portable way that can be used 236 uniformly and independent of the equipment and operating 237 environment. 239 UNI: User Network Interface 241 MDSC: Multi-Domain Service Coordinator 243 CNC: Customer Network Controller 245 PNC: Provisioning Network Controller 247 MAC Bridging: Virtual LANs (VLANs) on IEEE 802.3 Ethernet network 249 3. Conventions used in this document 251 3.1. Topology and traffic flow processing 253 The traffic flow between different nodes is specified as an ordered 254 list of nodes, separated with commas, indicating within the brackets 255 the processing within each node: 257 (){, ()} 259 The order represents the order of traffic flow being forwarded 260 through the network. 262 The processing can be either an adaptation of a client layer into a 263 server layer "(client -> server)" or switching at a given layer 264 "([switching])". Multi-layer switching is indicated by two layer 265 switching with client/server adaptation: "([client] -> [server])". 267 For example, the following traffic flow: 269 C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 270 C-R3 (ODU2 -> [PKT]) 272 Node C-R1 is switching at the packet (PKT) layer and mapping packets 273 into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are 274 switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which 275 then sends it to S6 which finally sends to C-R3. Node C-R3 276 terminates the ODU2 from S6 before switching at the packet (PKT) 277 layer. 279 The paths of working and protection transport entities are specified 280 as an ordered list of nodes, separated with commas: 282 {, } 284 The order represents the order of traffic flow being forwarded 285 through the network in the forward direction. In case of 286 bidirectional paths, the forward and backward directions are 287 selected arbitrarily, but the convention is consistent between 288 working/protection path pairs as well as across multiple domains. 290 3.2. JSON code 292 This document provides some detailed JSON code examples to describe 293 how the YANG models being developed by IETF (TEAS and CCAMP WG in 294 particular) can be used. 296 The examples are provided using JSON because JSON code is easier for 297 humans to read and write. 299 Different objects need to have an identifier. The convention used to 300 create mnemonic identifiers is to use the object name (e.g., S3 for 301 node S3), followed by its type (e.g., NODE), separated by an "-", 302 followed by "-ID". For example, the mnemonic identifier for node S3 303 would be S3-NODE-ID. 305 JSON language does not support the insertion of comments that have 306 been instead found to be useful when writing the examples. This 307 document inserts comments into the JSON code as JSON name/value pair 308 with the JSON name string starting with the "//" characters. For 309 example, when describing the example of a TE Topology instance 310 representing the ODU Abstract Topology exposed by the Transport PNC, 311 the following comment has been added to the JSON code: 313 "// comment": "ODU Abstract Topology @ MPI", 315 The JSON code examples provided in this document have been validated 316 against the YANG models following the validation process described 317 in Appendix B, which would not consider the comments. 319 In order to have successful validation of the examples, some 320 numbering scheme has been defined to assign identifiers to the 321 different entities which would pass the syntax checks. In that case, 322 to simplify the reading, another JSON name/value pair, formatted as 323 a comment and using the mnemonic identifiers is also provided. For 324 example, the identifier of node S3 (S3-NODE-ID) has been assumed to 325 be "10.0.0.3" and would be shown in the JSON code example using the 326 two JSON name/value pair: 328 "// te-node-id": "S3-NODE-ID", 330 "te-node-id": "10.0.0.3", 332 The first JSON name/value pair will be automatically removed in the 333 first step of the validation process while the second JSON 334 name/value pair will be validate against the YANG model definitions. 336 4. Scenarios Description 338 4.1. Reference Network 340 The physical topology of the reference network is shown in Figure 1. 341 It represents an OTN network composed of three transport network 342 domains providing transport services to an IP customer network 343 through eight access links: 345 ........................ 346 .......... : : 347 : : Network domain 1 : ............. 348 Customer: : : : : 349 domain : : S1 -------+ : : Network : 350 : : / \ : : domain 3 : .......... 351 C-R1 ------- S3 ----- S4 \ : : : : 352 : : \ \ S2 --------+ : :Customer 353 : : \ \ | : : \ : : domain 354 : : S5 \ | : : \ : : 355 C-R2 ------+ / \ \ | : : S31 --------- C-R7 356 : : \ / \ \ | : : / \ : : 357 : : S6 ---- S7 ---- S8 ------ S32 S33 ------ C-R8 358 : : / | | : : / \ / : :....... 359 C-R3 ------+ | | : :/ S34 : : 360 : :..........|.......|...: / / : : 361 ........: | | /:.../.......: : 362 | | / / : 363 ...........|.......|..../..../... : 364 : | | / / : .............. 365 : Network | | / / : : 366 : domain 2 | | / / : :Customer 367 : S11 ---- S12 / : : domain 368 : / | \ / : : 369 : S13 S14 | S15 ------------- C-R4 370 : | \ / \ | \ : : 371 : | S16 \ | \ : : 372 : | / S17 -- S18 --------- C-R5 373 : | / \ / : : 374 : S19 ---- S20 ---- S21 ------------ C-R6 375 : : : 376 :...............................: :............. 378 Figure 1 Reference network 380 The transport domain control architecture, shown in Figure 2, 381 follows the ACTN architecture and framework document [ACTN-Frame], 382 and functional components: 384 -------------- 385 | | 386 | CNC | 387 | | 388 -------------- 389 | 390 ....................|....................... CMI 391 | 392 ---------------- 393 | | 394 | MDSC | 395 | | 396 ---------------- 397 / | \ 398 / | \ 399 ............../.....|......\................ MPIs 400 / | \ 401 / ---------- \ 402 / | PNC2 | \ 403 / ---------- \ 404 ---------- | \ 405 | PNC1 | ----- \ 406 ---------- ( ) ---------- 407 | ( ) | PNC3 | 408 ----- ( Network ) ---------- 409 ( ) ( Domain 2 ) | 410 ( ) ( ) ----- 411 ( Network ) ( ) ( ) 412 ( Domain 1 ) ----- ( ) 413 ( ) ( Network ) 414 ( ) ( Domain 3 ) 415 ----- ( ) 416 ( ) 417 ----- 419 Figure 2 Controlling Hierarchy 421 The ACTN framework facilitates the detachment of the network and 422 service control from the underlying technology and help the customer 423 express the network as desired by business needs. Therefore, care 424 must be taken to keep minimal dependency on the CMI (or no 425 dependency at all) with respect to the network domain technologies. 427 The MPI instead requires some specialization according to the domain 428 technology. 430 In this document we address the use case where the CNC controls: the 431 customer IP network and requests, at the CMI, transport connectivity 432 among IP routers to an MDSC which coordinates, via three MPIs, the 433 control of a multi-domain transport network via three PNCs. 435 The interfaces within scope of this document are the three MPIs, 436 while the interface between the CNC and the IP routers is out of 437 scope of this document. It is also assumed that the CMI allows the 438 CNC to provide all the information that is required by the MDSC to 439 properly configure the transport connectivity requested by the 440 customer. 442 4.1.1. Single-Domain Scenario 444 In case the CNC requests transport connectivity between IP routers 445 attached to the same transport domain (e.g., between C-R1 and C-R3), 446 the MDSC can pass the service request to the PNC (e.g., PNC1) and 447 let the PNC takes decisions about how to implement the service. 449 4.1.2. Multi-Domain Scenario 451 In case the CNC requests transport connectivity between IP routers 452 attached to different transport domain (e.g., between C-R1 and C- 453 R5), the MDSC can split the service request into tunnel segment 454 configuration and then pass to multiple PNCs (PNC1 and PNC2 in this 455 example) and let the PNC takes decisions about how to deploy the 456 service. 458 4.2. Topology Abstractions 460 Abstraction provides a selective method for representing 461 connectivity information within a domain. There are multiple methods 462 to abstract a network topology. This document assumes the 463 abstraction method defined in [RFC7926]: 465 "Abstraction is the process of applying policy to the available TE 466 information within a domain, to produce selective information that 467 represents the potential ability to connect across the domain. 468 Thus, abstraction does not necessarily offer all possible 469 connectivity options, but presents a general view of potential 470 connectivity according to the policies that determine how the 471 domain's administrator wants to allow the domain resources to be 472 used." 474 [TE-Topo] Describes a YANG base model for TE topology without any 475 technology specific parameters. Moreover, it defines how to abstract 476 for TE-network topologies. 478 [ACTN-Frame] Provides the context of topology abstraction in the 479 ACTN architecture and discusses a few alternatives for the 480 abstraction methods for both packet and optical networks. This is an 481 important consideration since the choice of the abstraction method 482 impacts protocol design and the information it carries. According 483 to [ACTN-Frame], there are three types of topology: 485 o White topology: This is a case where the PNC provides the actual 486 network topology to the MDSC without any hiding or filtering. In 487 this case, the MDSC has the full knowledge of the underlying 488 network topology; 490 o Black topology: The entire domain network is abstracted as a 491 single virtual node with the access/egress links without 492 disclosing any node internal connectivity information; 494 o Grey topology: This abstraction level is between black topology 495 and white topology from a granularity point of view. This is 496 abstraction of TE tunnels for all pairs of border nodes. We may 497 further differentiate from a perspective of how to abstract 498 internal TE resources between the pairs of border nodes: 500 - Grey topology type A: border nodes with a TE links between 501 them in a full mesh fashion; 503 - Grey topology type B: border nodes with some internal 504 abstracted nodes and abstracted links. 506 Each PNC should provide the MDSC a topology abstraction of the 507 domain's network topology. 509 Each PNC provides topology abstraction of its own domain topology 510 independently from each other and therefore it is possible that 511 different PNCs provide different types of topology abstractions. 513 The MPI operates on the abstract topology regardless on the type of 514 abstraction provided by the PNC. 516 To analyze how the MPI operates on abstract topologies independently 517 from the topology abstraction provided by each PNC and, therefore, 518 that that different PNCs can provide different topology 519 abstractions, it is assumed that: 521 o PNC1 provides a topology abstraction which exposes at the MPI an 522 abstract node and an abstract link for each physical node and 523 link within network domain 1 525 o PNC2 provides a topology abstraction which exposes at the MPI a 526 single abstract node (representing the whole network domain) with 527 abstract links representing only the inter-domain physical links 529 o PNC3 provides a topology abstraction which exposes at the MPI two 530 abstract nodes (AN31 and AN32). They abstract respectively nodes 531 S31+S33 and nodes S32+S34. At the MPI, only the abstract nodes 532 should be reported: the mapping between the abstract nodes (AN31 533 and AN32) and the physical nodes (S31, S32, S33 and S34) should 534 be done internally by the PNC. 536 The MDSC should be capable to stitch together each abstracted 537 topology to build its own view of the multi-domain network topology. 538 The process may require suitable oversight, including administrative 539 configuration and trust models, but this is out of scope for this 540 document. 542 A method and process for topology abstraction for the CMI is 543 required, and will be discussed in a future revision of this 544 document. 546 4.3. Service Configuration 548 In the following scenarios, it is assumed that the CNC is capable to 549 request service connectivity from the MDSC to support IP routers 550 connectivity. 552 The type of services could depend of the type of physical links 553 (e.g. OTN link, ETH link or SDH link) between the routers and 554 transport network. 556 The control of different adaptations inside IP routers, C-Ri (PKT 557 -> foo) and C-Rj (foo -> PKT), are assumed to be performed by means 558 that are not under the control of, and not visible to, the MDSC nor 559 to the PNCs. Therefore, these mechanisms are outside the scope of 560 this document. 562 It is just assumed that the CNC is capable to request the proper 563 configuration of the different adaptation functions inside the 564 customer's IP routers, by means which are outside the scope of this 565 document. 567 4.3.1. ODU Transit 569 The physical links interconnecting the IP routers and the transport 570 network can be OTN links. In this case, the physical/optical 571 interconnections below the ODU layer are supposed to be pre- 572 configured and not exposed at the MPI to the MDSC. 574 To setup a 10Gb IP link between C-R1 and C-R5, an ODU2 end-to-end 575 data plane connection needs be created between C-R1 and C-R5, 576 crossing transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 577 which belong to different PNC domains. 579 The traffic flow between C-R1 and C-R5 can be summarized as: 581 C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 582 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 583 S15 ([ODU2]), S18 ([ODU2]), C-R5 (ODU2 -> [PKT]) 585 It is assumed that the CNC requests, via the CMI, the setup of an 586 ODU2 transit service, providing all the information that the MDSC 587 needs to understand that it shall setup a multi-domain ODU2 segment 588 connection between nodes S3 and S18. 590 In case the CNC needs the setup of a 10Gb IP link between C-R1 and 591 C-R3 (single-domain service request), the traffic flow between C-R1 592 and C-R3 can be summarized as: 594 C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 595 C-R3 (ODU2 -> [PKT]) 597 Since the CNC is unaware of the transport network domains, it 598 requests the setup of an ODU2 transit service in the same way as 599 before, regardless the fact the fact that this is a single-domain 600 service. 602 It is assumed that the information provided at the CMI is sufficient 603 for the MDSC to understand that this is a single-domain service 604 request. 606 The MDSC can then just request PNC1 to setup a single-domain ODU2 607 data plane segment connection between nodes S3 and S6. 609 4.3.2. EPL over ODU 611 The physical links interconnecting the IP routers and the transport 612 network can be Ethernet links. 614 To setup a 10Gb IP link between C-R1 and C-R5, an EPL service needs 615 to be created between C-R1 and C-R5, supported by an ODU2 end-to-end 616 data plane connection between transport nodes S3 and S18, crossing 617 transport nodes S1, S2, S31, S33, S34 and S15 which belong to 618 different PNC domains. 620 The traffic flow between C-R1 and C-R5 can be summarized as: 622 C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 623 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 624 S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT]) 626 It is assumed that the CNC requests, via the CMI, the setup of an 627 EPL service, providing all the information that the MDSC needs to 628 understand that it shall coordinate the three PNCs to setup a multi- 629 domain ODU2 end-to-end connection between nodes S3 and S18 as well 630 as the configuration of the adaptation functions inside nodes S3 and 631 S18: S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> [ODU2]) 632 and S3 ([ODU2] -> ETH). 634 In case the CNC needs the setup of a 10Gb IP link between C-R1 and 635 C-R3 (single-domain service request), the traffic flow between C-R1 636 and C-R3 can be summarized as: 638 C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), 639 S6 ([ODU2] -> ETH), C-R3 (ETH-> [PKT]) 641 As described in section 4.3.1, the CNC requests the setup of an EPL 642 service in the same way as before and the information provided at 643 the CMI is sufficient for the MDSC to understand that this is a 644 single-domain service request. 646 The MDSC can then just request PNC1 to setup a single-domain EPL 647 service between nodes S3 and S6. PNC1 can take care of setting up 648 the single-domain ODU2 end-to-end connection between nodes S3 and S6 649 as well as of configuring the adaptation functions on these edge 650 nodes. 652 4.3.3. Other OTN Clients Services 654 [ITU-T G.709] defines mappings of different client layers into 655 ODU. Most of them are used to provide Private Line services over 656 an OTN transport network supporting a variety of types of physical 657 access links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, 658 etc.). 660 The physical links interconnecting the IP routers and the transport 661 network can be any of these types. 663 In order to setup a 10Gb IP link between C-R1 and C-R5 using, for 664 example SDH physical links between the IP routers and the transport 665 network, an STM-64 Private Line service needs to be created between 666 C-R1 and C-R5, supported by ODU2 end-to-end data plane connection 667 between transport nodes S3 and S18, crossing transport nodes S1, S2, 668 S31, S33, S34 and S15 which belong to different PNC domains. 670 The traffic flow between C-R1 and C-R5 can be summarized as: 672 C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 673 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 674 S15 ([ODU2]), S18 ([ODU2] -> STM-64), C-R5 (STM-64 -> [PKT]) 676 As described in section 4.3.2, it is assumed that the CNC is 677 capable, via the CMI, to request the setup of an STM-64 Private Line 678 service, providing all the information that the MDSC needs to 679 coordinate the setup of a multi-domain ODU2 connection as well as 680 the adaptation functions on the edge nodes. 682 In the single-domain case (10Gb IP link between C-R1 and C-R3), the 683 traffic flow between C-R1 and C-R3 can be summarized as: 685 C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), 686 S6 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT]) 688 As described in section 4.3.1, the CNC requests the setup of an STM- 689 64 Private Line service in the same way as before and the 690 information provided at the CMI is sufficient for the MDSC to 691 understand that this is a single-domain service request. 693 As described in section 4.3.2, the MDSC could just request PNC1 to 694 setup a single-domain STM-64 Private Line service between nodes S3 695 and S6. 697 4.3.4. EVPL over ODU 699 When the physical links interconnecting the IP routers and the 700 transport network are Ethernet links, it is also possible that 701 different Ethernet services (e.g., EVPL) can share the same physical 702 link using different VLANs. 704 To setup two 1Gb IP links between C-R1 to C-R3 and between C-R1 and 705 C-R5, two EVPL services need to be created, supported by two ODU0 706 end-to-end connections respectively between S3 and S6, crossing 707 transport node S5, and between S3 and S18, crossing transport nodes 708 S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. 710 Since the two EVPL services are sharing the same Ethernet physical 711 link between C-R1 and S3, different VLAN IDs are associated with 712 different EVPL services: for example, VLAN IDs 10 and 20 713 respectively. 715 The traffic flow between C-R1 and C-R5 can be summarized as: 717 C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), 718 S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]), 719 S15 ([ODU0]), S18 ([ODU0] -> VLAN), C-R5 (VLAN -> [PKT]) 721 The traffic flow between C-R1 and C-R3 can be summarized as: 723 C-R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]), 724 S6 ([ODU0] -> VLAN), C-R3 (VLAN -> [PKT]) 726 As described in section 4.3.2, it is assumed that the CNC is 727 capable, via the CMI, to request the setup of these EVPL services, 728 providing all the information that the MDSC needs to understand that 729 it need to request PNC1 to setup an EVPL service between nodes S3 730 and S6 (single-domain service request) and it also needs to 731 coordinate the setup of a multi-domain ODU0 connection between nodes 732 S3 and S16 as well as the adaptation functions on these edge nodes. 734 4.3.5. EVPLAN and EVPTree Services 736 When the physical links interconnecting the IP routers and the 737 transport network are Ethernet links, multipoint Ethernet services 738 (e.g, EPLAN and EPTree) can also be supported. It is also possible 739 that multiple Ethernet services (e.g, EVPL, EVPLAN and EVPTree) 740 share the same physical link using different VLANs. 742 Note - it is assumed that EPLAN and EPTree services can be supported 743 by configuring EVPLAN and EVPTree with port mapping. 745 Since this EVPLAN/EVPTree service can share the same Ethernet 746 physical links between IP routers and transport nodes (e.g., with 747 the EVPL services described in section 4.3.4), a different VLAN ID 748 (e.g., 30) can be associated with this EVPLAN/EVPTree service. 750 In order to setup an IP subnet between C-R1, C-R2, C-R3 and C-R5, an 751 EVPLAN/EVPTree service needs to be created, supported by two ODUflex 752 end-to-end connections respectively between S3 and S6, crossing 753 transport node S5, and between S3 and S18, crossing transport nodes 754 S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. 756 Some MAC Bridging capabilities are also required on some nodes at 757 the edge of the transport network: for example Ethernet Bridging 758 capabilities can be configured in nodes S3 and S6: 760 o MAC Bridging in node S3 is needed to select, based on the MAC 761 Destination Address, whether received Ethernet frames should be 762 forwarded to C-R1 or to the ODUflex terminating on node S6 or to 763 the other ODUflex terminating on node S18; 765 o MAC bridging function in node S6 is needed to select, based on 766 the MAC Destination Address, whether received Ethernet frames 767 should be sent to C-R2 or to C-R3 or to the ODUflex terminating 768 on node S3. 770 In order to support an EVPTree service instead of an EVPLAN, 771 additional configuration of the Ethernet Bridging capabilities on 772 the nodes at the edge of the transport network is required. 774 The traffic flows between C-R1 and C-R3, between C-R3 and C-R5 and 775 between C-R1 and C-R5 can be summarized as: 777 C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 778 S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN), 779 C-R3 (VLAN -> [PKT]) 781 C-R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]), 782 S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]), 783 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 784 S33 ([ODUflex]), S34 ([ODUflex]), 785 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), C-R5 (VLAN -> [PKT]) 787 C-R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 788 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 789 S33 ([ODUflex]), S34 ([ODUflex]), 790 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), C-R5 (VLAN -> [PKT]) 792 As described in section 4.3.2, it is assumed that the CNC is 793 capable, via the CMI, to request the setup of this EVPLAN/EVPTree 794 service, providing all the information that the MDSC needs to 795 understand that it need to request PNC1 to setup an ODUflex 796 connection between nodes S3 and S6 (single-domain service request) 797 and it also needs to coordinate the setup of a multi-domain ODUflex 798 connection between nodes S3 and S16 as well as the MAC bridging and 799 the adaptation functions on these edge nodes. 801 In case the CNC needs the setup of an EVPLAN/EVPTree service only 802 between C-R1, C-R2 and C-R3 (single-domain service request), it 803 would request the setup of this service in the same way as before 804 and the information provided at the CMI is sufficient for the MDSC 805 to understand that this is a single-domain service request. 807 The MDSC can then just request PNC1 to setup a single-domain 808 EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care 809 of setting up the single-domain ODUflex end-to-end connection 810 between nodes S3 and S6 as well as of configuring the MAC bridging 811 and the adaptation functions on these edge nodes. 813 4.3.6. Dynamic Service Configuration 815 Given the service established in the previous sections, there is a 816 demand for an update of some service characteristics. A 817 straightforward approach would be terminate the current service and 818 replace with a new one. Another more advanced approach would be 819 dynamic configuration, in which case there will be no interruption 820 for the connection. 822 An example application would be updating the SLA information for a 823 certain connection. For example, an ODU transit connection is set up 824 according to section 4.3.1, with the corresponding SLA level of 'no 825 protection'. After the establishment of this connection, the user 826 would like to enhance this service by providing a restoration after 827 potential failure, and a request is generated on the CMI. In this 828 case, after receiving the request, the MDSC would need to send an 829 update message to the PNC, changing the SLA parameters in TE Tunnel 830 model. Then the connection characteristic would be changed by PNC, 831 and a notification would be sent to MDSC for acknowledgement. 833 4.4. Multi-function Access Links 835 Some physical links interconnecting the IP routers and the transport 836 network can be configured in different modes, e.g., as OTU2 or STM- 837 64 or 10GE. 839 This configuration can be done a-priori by means outside the scope 840 of this document. In this case, these links will appear at the MPI 841 either as an ODU Link or as a STM-64 Link or as a 10GE Link 842 (depending on the a-priori configuration) and will be controlled at 843 the MPI as discussed in section 4.3. 845 It is also possible not to configure these links a-priori and give 846 the control to the MPI to decide, based on the service 847 configuration, how to configure it. 849 For example, if the physical link between C-R1 and S3 is a multi- 850 functional access link while the physical links between C-R7 and S31 851 and between C-R5 and S18 are STM-64 and 10GE physical links 852 respectively, it is possible to configure either an STM-64 Private 853 Line service between C-R1 and C-R7 or an EPL service between C-R1 854 and C-R5. 856 The traffic flow between C-R1 and C-R7 can be summarized as: 858 C-R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 859 S2 ([ODU2]), S31 ([ODU2] -> STM-64), C-R3 (STM-64 -> [PKT]) 861 The traffic flow between C-R1 and C-R5 can be summarized as: 863 C-R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 864 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 865 S15 ([ODU2]), S18 ([ODU2] -> ETH), C-R5 (ETH -> [PKT]) 867 As described in section 4.3.2, it is assumed that the CNC is 868 capable, via the CMI, to request the setup either an STM-64 Private 869 Line service between C-R1 and C-R7 or an EPL service between C-R1 870 and C-R5, providing all the information that the MDSC needs to 871 understand that it need to coordinate the setup of a multi-domain 872 ODU2 connection, either between nodes S3 and S31, or between nodes 873 S3 and S18, as well as the adaptation functions on these edge nodes, 874 and in particular whether the multi-function access link on between 875 C-R1 and S3 should operate as an STM-64 or as a 10GE link. 877 4.5. Protection and Restoration Configuration 879 Protection switching provides a pre-allocated survivability 880 mechanism, typically provided via linear protection methods and 881 would be configured to operate as 1+1 unidirectional (the most 882 common OTN protection method), 1+1 bidirectional or 1:n 883 bidirectional. This ensures fast and simple service survivability. 885 Restoration methods would provide capability to reroute and restore 886 connectivity traffic around network faults, without the network 887 penalty imposed with dedicated 1+1 protection schemes. 889 This section describes only services which are protected with linear 890 protection and with dynamic restoration. 892 The MDSC needs to be capable to coordinate different PNCs to 893 configure protection switching when requesting the setup of the 894 protected connectivity services described in section 4.3. 896 Since in these service examples, switching within the transport 897 network domain is performed only in the OTN ODU layer, also 898 protection switching within the transport network domain can only be 899 provided at the OTN ODU layer. 901 4.5.1. Linear Protection (end-to-end) 903 In order to protect any service defined in section 4.3 from failures 904 within the OTN multi-domain transport network, the MDSC should be 905 capable to coordinate different PNCs to configure and control OTN 906 linear protection in the data plane between nodes S3 and node S18. 908 It is assumed that the OTN linear protection is configured to with 909 1+1 unidirectional protection switching type, as defined in [ITU-T 910 G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. 912 In these scenarios, a working transport entity and a protection 913 transport entity, as defined in [ITU-T G.808.1], (or a working LSP 914 and a protection LSP, as defined in [RFC4427]) should be configured 915 in the data plane. 917 Two cases can be considered: 919 o In one case, the working and protection transport entities pass 920 through the same PNC domains: 922 Working transport entity: S3, S1, S2, 923 S31, S33, S34, 924 S15, S18 926 Protection transport entity: S3, S4, S8, 927 S32, 928 S12, S17, S18 930 o In another case, the working and protection transport entities 931 can pass through different PNC domains: 933 Working transport entity: S3, S5, S7, 934 S11, S12, S17, S18 936 Protection transport entity: S3, S1, S2, 937 S31, S33, S34, 938 S15, S18 940 The PNCs should be capable to report to the MDSC which is the active 941 transport entity, as defined in [ITU-T G.808.1], in the data plane. 943 Given the fast dynamic of protection switching operations in the 944 data plane (50ms recovery time), this reporting is not expected to 945 be in real-time. 947 It is also worth noting that with unidirectional protection 948 switching, e.g., 1+1 unidirectional protection switching, the active 949 transport entity may be different in the two directions. 951 4.5.2. Segmented Protection 953 To protect any service defined in section 4.3 from failures within 954 the OTN multi-domain transport network, the MDSC should be capable 955 to request each PNC to configure OTN intra-domain protection when 956 requesting the setup of the ODU2 data plane connection segment. 958 If PNC1 provides linear protection, the working and protection 959 transport entities could be: 961 Working transport entity: S3, S1, S2 963 Protection transport entity: S3, S4, S8, S2 965 If PNC2 provides linear protection, the working and protection 966 transport entities could be: 968 Working transport entity: S15, S18 970 Protection transport entity: S15, S12, S17, S18 972 If PNC3 provides linear protection, the working and protection 973 transport entities could be: 975 Working transport entity: S31, S33, S34 977 Protection transport entity: S31, S32, S34 979 4.5.3. End-to-End Dynamic restoration 981 To restore any service defined in section 4.3 from failures within 982 the OTN multi-domain transport network, the MDSC should be capable 983 to coordinate different PNCs to configure and control OTN end-to-end 984 dynamic Restoration in the data plane between nodes S3 and node S18. 985 For example, the MDSC can request the PNC1, PNC2 and PNC3 to create 986 a service with no-protection, MDSC set the end-to-end service with 987 the dynamic restoration. 989 Working transport entity: S3, S1, S2, 990 S31, S33, S34, 991 S15, S18 993 When a link failure between S1 and s2 occurred in network domain 1, 994 PNC1 does not restore the tunnel and send the alarm notification to 995 the MDSC, MDSC will perform the end-to-end restoration. 997 Restored transport entity: S3, S4, S8, 998 S12, S15, S18 1000 4.5.4. Segmented Dynamic Restoration 1002 To restore any service defined in section 4.3 from failures within 1003 the OTN multi-domain transport network, the MDSC should be capable 1004 to coordinate different PNCs to configure and control OTN segmented 1005 dynamic Restoration in the data plane between nodes S3 and node S18. 1007 Working transport entity: S3, S1, S2, 1008 S31, S33, S34, 1009 S15, S18 1011 When a link failure between S1 and s2 occurred in network domain 1, 1012 PNC1 will restore the tunnel and send the alarm or tunnel update 1013 notification to the MDSC, MDSC will update the restored tunnel. 1015 Restored transport entity: S3, S4, S8, S2 1016 S31, S33, S34, 1017 S15, S18 1019 When a link failure between network domain 1 and network domain 2 1020 occurred, PNC1 and PNC2 will send the alarm notification to the 1021 MDSC, MDSC will update the restored tunnel. 1023 Restored transport entity: S3, S4, S8, 1024 S12, S15, S18 1026 In order to improve the efficiency of recovery, the controller can 1027 establish a recovery path in a concurrent way. When the recovery 1028 fails in one domain or one network element, the rollback operation 1029 should be supported. 1031 The creation of the recovery path by the controller can use the 1032 method of "make-before-break", in order to reduce the impact of the 1033 recovery operation on the services. 1035 4.6. Service Modification and Deletion 1037 To be discussed in future versions of this document. 1039 4.7. Notification 1041 To realize the topology update, service update and restoration 1042 function, following notification type should be supported. 1044 1. Object create 1046 2. Object delete 1048 3. Object state change 1050 4. Alarm 1052 Because there are three types of topology abstraction type defined 1053 in section Section 4.2., the notification should also be abstracted. 1054 The PNC and MDSC should coordinate together to determine the 1055 notification policy, such as when an intra-domain alarm occurred, 1056 the PNC may not report the alarm but the service state change 1057 notification to the MDSC. 1059 4.8. Path Computation with Constraint 1061 It is possible to have constraint during path computation procedure, 1062 typical cases include IRO/XRO and so on. This information is carried 1063 in the TE Tunnel model and used when there is a request with 1064 constraint. Consider the example in section 4.3.1, the request can 1065 be a Tunnel from C-R1 to C-R5 with an IRO from S2 to S31, then a 1066 qualified feedback would become: 1068 C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1069 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 1070 S15 ([ODU2]), S18 ([ODU2]), C-R5 (ODU2 -> [PKT]) 1072 If the request covers the IRO from S8 to S12, then the above path 1073 would not be qualified, while a possible computation result may be: 1075 C-R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1076 S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), C-R5 (ODU2 -> 1077 [PKT]) 1079 Similarly, the XRO can be represented by TE tunnel model as well. 1081 When there is a technology specific network (e.g, OTN), the 1082 corresponding technology (OTN) model should also be used to specify 1083 the tunnel information on MPI, with the constraint included in TE 1084 Tunnel model. 1086 5. YANG Model Analysis 1088 This section provides a high-level overview of how IETF YANG models 1089 can be used at the MPIs, between the MDSC and the PNCs, to support 1090 the scenarios described in section 4. 1092 Section 5.1 describes the different topology abstractions provided 1093 to the MDSC by each PNC via its own MPI. 1095 Section 0 describes how the MDSC can coordinate different requests 1096 to different PNCs, via their own MPIs, to setup different services, 1097 as defined in section 4.3. 1099 Section 5.3 describes how the protection scenarios can be deployed, 1100 including end-to-end protection and segment protection, for both 1101 intra-domain and inter-domain scenario. 1103 5.1. YANG Models for Topology Abstraction 1105 Each PNC reports its respective abstract topology to the MDSC, as 1106 described in section 4.1.2. 1108 5.1.1. Domain 1 Topology Abstraction 1110 PNC1 provides the required topology abstraction to expose at its MPI 1111 toward the MDSC (called "MPI1") one TE Topology instance for the ODU 1112 layer (called "MPI1 ODU Topology"), containing one TE Node (called 1113 "ODU Node") for each physical node, as shown in Figure 3. below. 1115 .................................. 1116 : : 1117 : ODU Abstract Topology @ MPI : 1118 : Gotham City Area : 1119 : Metro Transport Network : 1120 : : 1121 : +----+ +----+ : 1122 : | |S1-1 | |S2-1: 1123 : | S1 |--------| S2 |- - - - -(C-R4) 1124 : +----+ S2-2+----+ : 1125 : S1-2/ |S2-3 : 1126 : S3-2/ Robinson Park | : 1127 : +----+ +----+ | : 1128 : | |3 1| | | : 1129 (C-R1)- - - - -| S3 |---| S4 | | : 1130 :S3-1+----+ +----+ | : 1131 : S3-4 \ \S4-2 | : 1132 : \S5-1 \ | : 1133 : +----+ \ | : 1134 : | | \S8-3| : 1135 : | S5 | \ | : 1136 : +----+ Metro \ |S8-2 : 1137 (C-R2)- - - - - 2/ E \3 Main \ | : 1138 :S6-1 \ /3 a E \1 Ring \| : 1139 : +----+s-n+----+ +----+ : 1140 : | |t d| | | |S8-1: 1141 : | S6 |---| S7 |---| S8 |- - - - -(C-R5) 1142 : +----+4 2+----+3 4+----+ : 1143 : / : 1144 (C-R3)- - - - - : 1145 :S6-2 : 1146 :................................: 1148 Figure 3 Abstract Topology exposed at MPI1 (MPI1 ODU Topology) 1150 The ODU Nodes in Figure 3 are using the same names as the physical 1151 nodes to simplify the description of the mapping between the ODU 1152 Nodes exposed by the Transport PNCs at the MPI and the physical 1153 nodes in the data plane. This does not 1154 correspond to the reality of the usage of the topology model, as 1155 described in section 4.3 of [TE-TOPO], in which renaming by the 1156 client it is necessary. 1158 As described in section 4.1.2, it is assumed that the physical links 1159 between the physical nodes are pre-configured up to the OTU4 trail 1160 using mechanisms which are outside the scope of this document. PNC1 1161 exports at MPI1 one TE Link (called "ODU Link") for each of these 1162 OTU4 trails. 1164 5.1.2. Domain 2 Grey (Type A) Topology Abstraction 1166 PNC2 provides the required topology abstraction to expose at its MPI 1167 towards the MDSC (called "MPI2") only one abstract node (i.e., AN2), 1168 with only inter-domain and access links, is reported at the MPI2. 1170 5.1.3. Domain 3 Grey (Type B) Topology Abstraction 1172 PNC3 provides the required topology abstraction to expose at its MPI 1173 towards the MDSC (called "MPI3") only two abstract nodes (i.e., AN31 1174 and AN32), with internal links, inter-domain links and access links. 1176 5.1.4. Multi-domain Topology Stitching 1178 As assumed in the beginning of this section, MDSC does not have any 1179 knowledge of the topologies of each domain until each PNC reports 1180 its own abstraction topology, so the MDSC needs to merge together 1181 the abstract topologies provided by different PNCs, at the MPIs, to 1182 build its own topology view, as described in section 4.3 of [TE- 1183 TOPO]. 1185 Given the topologies reported from multiple PNCs, the MDSC need to 1186 stitch the multi-domain topology and obtain the full map of 1187 topology. The topology of each domain main be in an abstracted shape 1188 (refer to section 5.2 of [ACTN-Frame] for different level of 1189 abstraction), while the inter-domain link information must be 1190 complete and fully configured by the MDSC. 1192 The inter-domain link information is reported to the MDSC by the two 1193 PNCs, controlling the two ends of the inter-domain link. 1195 The MDSC needs to understand how to "stitch" together these inter- 1196 domain links. 1198 One possibility is to use the plug-id information, defined in [TE- 1199 TOPO]: two inter-domain links reporting the same plug-id value can 1200 be merged as a single intra-domain link within any MDSC native 1201 topology. The value of the reported plug-id information can be 1202 either assigned by a central network authority, and configured 1203 within the two PNC domains, or it can be discovered using automatic 1204 discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). 1206 In case the plug-id values are assigned by a central authority, it 1207 is under the central authority responsibility to assign unique 1208 values. 1210 In case the plug-id values are automatically discovered, the 1211 information discovered by the automatic discovery mechanisms needs 1212 to be encoded as a bit string within the plug-id value. This 1213 encoding is implementation specific but the encoding rules need to 1214 be consistent across all the PNCs. 1216 In case of co-existence within the same network of multiple sources 1217 for the plug-id (e.g., central authority and automatic discovery or 1218 even different automatic discovery mechanisms), it is recommended 1219 that the plug-id namespace is partitioned to avoid that different 1220 sources assign the same plug-id value to different inter-domain 1221 link. The encoding of the plug-id namespace within the plug-id value 1222 is implementation specific but needs to be consistent across all the 1223 PNCs. 1225 Another possibility is to pre-configure, either in the adjacent PNCs 1226 or in the MDSC, the association between the inter-domain link 1227 identifiers (topology-id, node-id and tp-id) assigned by the two 1228 adjacent PNCs to the same inter-domain link. 1230 This last scenario requires further investigation and will be 1231 discussed in a future version of this document. 1233 5.1.5. Access Links 1235 Access links in Figure 3. are shown as ODU Links: the modeling of 1236 the access links for other access technologies is currently an open 1237 issue. 1239 The modeling of the access link in case of non-ODU access technology 1240 has also an impact on the need to model ODU TTPs and layer 1241 transition capabilities on the edge nodes (e.g., nodes S2, S3, S6 1242 and S8 in Figure 3.). 1244 If, for example, the physical NE S6 is implemented in a "pizza box", 1245 the data plane would have only set of ODU termination resources 1246 (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and 1247 160xODUflex can be terminated). The traffic coming from each of the 1248 10GE access links can be mapped into any of these ODU terminations. 1250 Instead if, for example, the physical NE S6 can be implemented as a 1251 multi-board system where access links reside on different/dedicated 1252 access cards with separated set of ODU termination resources (where 1253 up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for 1254 each resource can be terminated). The traffic coming from one 10GE 1255 access links can be mapped only into the ODU terminations which 1256 reside on the same access card. 1258 The more generic implementation option for a physical NE (e.g., S6) 1259 would be case is of a multi-board system with multiple access cards 1260 with separated sets of access links and ODU termination resources 1261 (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 1262 80xODUflex for each resource can be terminated). The traffic coming 1263 from each of the 10GE access links on one access card can be mapped 1264 only into any of the ODU terminations which reside on the same 1265 access card. 1267 In the last two cases, only the ODUs terminated on the same access 1268 card where the access links resides can carry the traffic coming 1269 from that 10GE access link. Terminated ODUs can instead be sent to 1270 any of the OTU4 interfaces 1272 In all these cases, terminated ODUs can be sent to any of the OTU4 1273 interfaces assuming the implementation is based on a non-blocking 1274 ODU cross-connect. 1276 If the access links are reported via MPI in some, still to be 1277 defined, client topology, it is possible to report each set of ODU 1278 termination resources as an ODU TTP within the ODU Topology of 1279 Figure 1. and to use either the inter-layer lock-id or the 1280 transitional link, as described in sections 3.4 and 3.10 of 1281 [TE-TOPO], to correlate the access links, in the client 1282 topology, with the ODU TTPs, in the ODU topology, to which access 1283 link are connected to. 1285 5.2. YANG Models for Service Configuration 1287 The service configuration procedure is assumed to be initiated (step 1288 1 in Figure 4) at the CMI from CNC to MDSC. Analysis of the CMI 1289 models is (e.g., L1SM, L2SM, Transport-Service, VN, et al.) is 1290 outside the scope of this document. 1292 As described in section 4.3, it is assumed that the CMI YANG models 1293 provides all the information that allows the MDSC to understand that 1294 it needs to coordinate the setup of a multi-domain ODU connection 1295 (or connection segment) and, when needed, also the configuration of 1296 the adaptation functions in the edge nodes belonging to different 1297 domains. 1299 | 1300 | {1} 1301 V 1302 ---------------- 1303 | {2} | 1304 | {3} MDSC | 1305 | | 1306 ---------------- 1307 ^ ^ ^ 1308 {3.1} | | | 1309 +---------+ |{3.2} | 1310 | | +----------+ 1311 | V | 1312 | ---------- |{3.3} 1313 | | PNC2 | | 1314 | ---------- | 1315 | ^ | 1316 V | {4.2} | 1317 ---------- V | 1318 | PNC1 | ----- V 1319 ---------- (Network) ---------- 1320 ^ ( Domain 2) | PNC3 | 1321 | {4.1} ( _) ---------- 1322 V ( ) ^ 1323 ----- C==========D | {4.3} 1324 (Network) / ( ) \ V 1325 ( Domain 1) / ----- \ ----- 1326 ( )/ \ (Network) 1327 A===========B \ ( Domain 3) 1328 / ( ) \( ) 1329 AP-1 ( ) X===========Z 1330 ----- ( ) \ 1331 ( ) AP-2 1332 ----- 1334 Figure 4 Multi-domain Service Setup 1336 As an example, the objective in this section is to configure a 1337 transport service between C-R1 and C-R5. The cross-domain routing is 1338 assumed to be C-R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> 1339 S18 <-> C-R5. 1341 According to the different client signal type, there is different 1342 adaptation required. 1344 After receiving such request, MDSC determines the domain sequence, 1345 i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs 1346 and inter-domain links (step 2 in Figure 4). 1348 As described in [PATH-COMPUTE], the domain sequence can be 1349 determined by running the MDSC own path computation on the MDSC 1350 internal topology, defined in section 5.1.4, if and only if the MDSC 1351 has enough topology information. Otherwise the MDSC can send path 1352 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 1353 in Figure 4) and use this information to determine the optimal path 1354 on its internal topology and therefore the domain sequence. 1356 The MDSC will then decompose the tunnel request into a few tunnel 1357 segments via tunnel model (including both TE tunnel model and OTN 1358 tunnel model), and request different PNCs to setup each intra-domain 1359 tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 4). 1361 Assume that each intra-domain tunnel segment can be set up 1362 successfully, and each PNC response to the MDSC respectively. Based 1363 on each segment, MDSC will take care of the configuration of both 1364 the intra-domain tunnel segment and inter-domain tunnel via 1365 corresponding MPI (via TE tunnel model and OTN tunnel model). More 1366 specifically, for the inter-domain configuration, the ts-bitmap and 1367 tpn attributes need to be configured using the OTN Tunnel model 1368 [xxx]. Then the end-to-end OTN tunnel will be ready. 1370 In any case, the access link configuration is done only on the PNCs 1371 that control the access links (e.g., PNC-1 and PNC-3 in our example) 1372 and not on the PNCs of transit domain (e.g., PNC-2 in our example). 1373 Access link will be configured by MDSC after the OTN tunnel is set 1374 up. Access configuration is different and dependent on the different 1375 type of service. More details can be found in the following 1376 sections. 1378 5.2.1. ODU Transit Service 1380 In this scenario, the access links are configured as ODU Links. 1382 As described in section 4.3.1, the CNC needs to setup an ODU2 end- 1383 to-end connection, supporting an IP link, between C-R1 and C-R5 and 1384 requests via the CMI to the MDSC the setup of an ODU transit 1385 service. 1387 From the topology information described in section 5.1 above, the 1388 MDSC understands that C-R1 is attached to the access link 1389 terminating on S3-1 LTP in the ODU Topology exposed by PNC1 and that 1390 C-R5 is attached to the access link terminating on AN2-1 LTP in the 1391 ODU Topology exposed by PNC2. 1393 Based on the assumption 0) in section 1.2, MDSC would then request 1394 the PNC1 to setup an ODU2 (Transit Segment) Tunnel between S3-1 and 1395 S6-2 LTPs: 1397 o Source and Destination TTPs are not specified (since it is a 1398 Transit Tunnel) 1400 o Ingress and egress points are indicated in the explicit-route- 1401 objects of the primary path: 1403 o The first element of the explicit-route-objects references 1404 the access link terminating on S3-1 LTP 1406 o Last element of the explicit-route-objects references the 1407 access link terminating on S6-2 LTP 1409 The configuration of the timeslots used by the ODU2 connection 1410 within the transport network domain (i.e., on the internal links) is 1411 a matter of the Transport PNC and its interactions with the physical 1412 network elements and therefore is outside the scope of this 1413 document. 1415 However, the configuration of the timeslots used by the ODU2 1416 connection at the edge of the transport network domain (i.e., on the 1417 access links) needs to take into account not only the timeslots 1418 available on the physical nodes at the edge of the transport network 1419 domain (e.g., S3 and S6) but also on the devices, outside of the 1420 transport network domain, connected through these access links 1421 (e.g., C-R1 and C-R3). 1423 Based on the assumption 2) in section 1.2, the MDSC, when requesting 1424 the Transport PNC to setup the (Transit Segment) ODU2 Tunnel, it 1425 would also configure the timeslots to be used on the access links. 1426 The MDSC can know the timeslots which are available on the edge OTN 1427 Node (e.g., S3 and S6) from the OTN Topology information exposed by 1428 the Transport PNC at the MPI as well as the timeslots which are 1429 available on the devices outside of the transport network domain 1430 (e.g., C-R1 and C-R3), by means which are outside the scope of this 1431 document. 1433 The Transport PNC performs path computation and sets up the ODU2 1434 cross-connections within the physical nodes S3, S5 and S6, as shown 1435 in section 4.3.1. 1437 The Transport PNC reports the status of the created ODU2 (Transit 1438 Segment) Tunnel and its path within the ODU Topology as shown in 1439 Figure 5 below: 1441 .................................. 1442 : : 1443 : ODU Abstract Topology @ MPI : 1444 : : 1445 : +----+ +----+ : 1446 : | | | | : 1447 : | S1 |--------| S2 |- - - - -(C-R4) 1448 : +----+ +----+ : 1449 : / | : 1450 : / | : 1451 : +----+ +----+ | : 1452 : | | | | | : 1453 (C-R1)- - - - - S3 |---| S4 | | : 1454 :S3-1 <<== + +----+ | : 1455 : = \ | : 1456 : = \ \ | : 1457 : == ---+ \ | : 1458 : = | \ | : 1459 : = S5 | \ | : 1460 : == --+ \ | : 1461 (C-R2)- - - - - = \ \ | : 1462 :S6-1 \ / = \ \ | : 1463 : +--- = +----+ +----+ : 1464 : | = | | | | : 1465 : | S6 = --| S7 |---| S8 |- - - - -(C-R5) 1466 : +--- = +----+ +----+ : 1467 : / = : 1468 (C-R3)- - - - - <<== : 1469 :S6-2 : 1470 :................................: 1472 Figure 5 ODU2 Transit Tunnel 1474 5.2.2. EPL over ODU Service 1476 In this scenario, the access links are configured as Ethernet Links. 1478 As described in section 4.3.2, the CNC needs to setup an EPL 1479 service, supporting an IP link, between C-R1 and C-R3 and requests 1480 this service at the CMI to the MDSC. 1482 MDSC needs to setup an EPL service between C-R1 and C-R3 supported 1483 by an ODU2 end-to-end connection between S3 and S6. 1485 As described in section 5.1.5 above, it is not clear in this case 1486 how the Ethernet access links between the transport network and the 1487 IP router, are reported by the PNC to the MDSC. 1489 If the 10GE physical links are not reported as ODU links within the 1490 ODU topology information, described in section 5.1.1 above, than the 1491 MDSC will not have sufficient information to know that C-R1 and C-R3 1492 are attached to nodes S3 and S6. 1494 Assuming that the MDSC knows how C-R1 and C-R3 are attached to the 1495 transport network, the MDSC would request the Transport PNC to setup 1496 an ODU2 end-to-end Tunnel between S3 and S6. 1498 This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In 1499 case nodes S3 and S6 support more than one TTP, the MDSC should 1500 decide which TTP to use. 1502 As discussed in 5.1.5, depending on the different hardware 1503 implementations of the physical nodes S3 and S6, not all the access 1504 links can be connected to all the TTPs. The MDSC should therefore 1505 not only select the optimal TTP but also a TTP that would allow the 1506 Tunnel to be used by the service. 1508 It is assumed that in case node S3 or node S6 supports only one TTP, 1509 this TTP can be accessed by all the access links. 1511 Once the ODU2 Tunnel setup has been requested, unless there is a 1512 one-to-one relationship between the S3 and S6 TTPs and the Ethernet 1513 access links toward C-R1 and C-R3 (as in the case, described in 1514 section 5.1.5, where the Ethernet access links reside on 1515 different/dedicated access card such that the ODU2 tunnel can only 1516 carry the Ethernet traffic from the only Ethernet access link on the 1517 same access card where the ODU2 tunnel is terminated), the MDSC also 1518 needs to request the setup of an EPL service from the access links 1519 on S3 and S6, attached to C-R1 and C-R3, and this ODU2 Tunnel. 1521 5.2.3. Other OTN Client Services 1523 In this scenario, the access links are configured as one of the OTN 1524 clients (e.g., STM-64) links. 1526 As described in section 4.3.3, the CNC needs to setup an STM-64 1527 Private Link service, supporting an IP link, between C-R1 and C-R3 1528 and requests this service at the CMI to the MDSC. 1530 MDSC needs to setup an STM-64 Private Link service between C-R1 and 1531 C-R3 supported by an ODU2 end-to-end connection between S3 and S6. 1533 As described in section 5.1.5 above, it is not clear in this case 1534 how the access links (e.g., the STM-N access links) between the 1535 transport network and the IP router, are reported by the PNC to the 1536 MDSC. 1538 The same issues, as described in section 5.2.2, apply here: 1540 o the MDSC needs to understand that C-R1 and C-R3 are connected, 1541 thought STM-64 access links, with S3 and S6 1543 o the MDSC needs to understand which TTPs in S3 and S6 can be 1544 accessed by these access links 1546 o the MDSC needs to configure the private line service from these 1547 access links through the ODU2 tunnel 1549 5.2.4. EVPL over ODU Service 1551 In this scenario, the access links are configured as Ethernet links, 1552 as described in section 5.2.2 above. 1554 As described in section 4.3.4, the CNC needs to setup EVPL services, 1555 supporting IP links, between C-R1 and C-R3, as well as between C-R1 1556 and C-R4 and requests these services at the CMI to the MDSC. 1558 MDSC needs to setup two EVPL services, between C-R1 and C-R3, as 1559 well as between C-R1 and C-R4, supported by ODU0 end-to-end 1560 connections between S3 and S6 and between S3 and S2 respectively. 1562 As described in section 5.1.5 above, it is not clear in this case 1563 how the Ethernet access links between the transport network and the 1564 IP router, are reported by the PNC to the MDSC. 1566 The same issues, as described in section 5.1.5 above, apply here: 1568 o the MDSC needs to understand that C-R1, C-R3 and C-R4 are 1569 connected, thought the Ethernet access links, with S3, S6 and S2 1571 o the MDSC needs to understand which TTPs in S3, S6 and S2 can be 1572 accessed by these access links 1574 o the MDSC needs to configure the EVPL services from these access 1575 links through the ODU0 tunnels 1577 In addition, the MDSC needs to get the information that the access 1578 links on S3, S6 and S2 are capable to support EVPL (rather than just 1579 EPL) as well as to coordinate the VLAN configuration, for each EVPL 1580 service, on these access links (this is a similar issue as the 1581 timeslot configuration on access links discussed in section 4.3.1 1582 above). 1584 5.3. YANG Models for Protection Configuration 1586 5.3.1. Linear Protection (end-to-end) 1588 To be discussed in future versions of this document. 1590 5.3.2. Segmented Protection 1592 To be discussed in future versions of this document. 1594 6. Detailed JSON Examples 1596 6.1. JSON Examples for Topology Abstractions 1598 6.1.1. Domain 1 White Topology Abstraction 1600 Section 5.1.1 describes how PNC1 can provide a white topology 1601 abstraction to the MDSC via the MPI. Figure 3. is an example of 1602 such ODU Topology. 1604 This section provides the detailed JSON code describing how this ODU 1605 Topology is reported by the PNC, using the [TE-TOPO] and [OTN-TOPO] 1606 YANG models at the MPI. 1608 JSON code "mpi1-otn-topology.json" has been provided at in the 1609 appendix of this document. 1611 6.2. JSON Examples for Service Configuration 1613 6.2.1. ODU Transit Service 1615 Section 5.2.1 describes how the MDSC can request PNC1, via the MPI, 1616 to setup an ODU2 transit service over an ODU Topology described in 1617 section 5.1.1. 1619 This section provides the detailed JSON code describing how the 1620 setup of this ODU2 transit service can be requested by the MDSC, 1621 using the [TE-TUNNEL] and [OTN-TUNNEL] YANG models at the MPI. 1623 JSON code "mpi1-odu2-service-config.json" has been provided at in 1624 the appendix of this document. 1626 6.3. JSON Example for Protection Configuration 1628 To be added 1630 7. Security Considerations 1632 This section is for further study 1634 8. IANA Considerations 1636 This document requires no IANA actions. 1638 9. References 1640 9.1. Normative References 1642 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1643 Information Exchange between Interconnected Traffic- 1644 Engineered Networks", BCP 206, RFC 7926, July 2016. 1646 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 1647 Restoration) Terminology for Generalized Multi-Protocol 1648 Label Switching (GMPLS)", RFC 4427, March 2006. 1650 [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for 1651 Abstraction and Control of Transport Networks", draft- 1652 ietf-teas-actn-framework, work in progress. 1654 [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for 1655 the optical transport network", June 2016. 1657 [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic 1658 protection switching - Linear trail and subnetwork 1659 protection", May 2014. 1661 [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical 1662 transport network (OTN): Linear protection", May 2014. 1664 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 1665 draft-ietf-teas-yang-te-topo, work in progress. 1667 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 1668 Transport Network Topology", draft-ietf-ccamp-otn-topo- 1669 yang, work in progress. 1671 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 1672 Topology", draft-zheng-ccamp-client-topo-yang, work in 1673 progress. 1675 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 1676 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1677 te, work in progress. 1679 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 1680 requesting Path Computation", draft-busibel-teas-yang- 1681 path-computation, work in progress. 1683 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- 1684 ietf-ccamp-otn-tunnel-model, work in progress. 1686 [CLIENT-SVC] Zheng, H. et al., "A YANG Data Model for Optical 1687 Transport Network Client Signals", draft-zheng-ccamp-otn- 1688 client-signal-yang, work in progress. 1690 9.2. Informative References 1692 [RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic 1693 Engineering --Resource Reservation Protocol-Traffic 1694 Engineering (RSVP-TE) Extensions", RFC 5151, February 1695 2008. 1697 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 1698 Negotiation and Configuration Modifications", RFC 6898, 1699 March 2013. 1701 [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, 1702 January 2018. 1704 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 1705 Abstraction and Control of Traffic Engineered Networks", 1706 draft-zhang-teas-actn-yang, work in progress. 1708 [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", 1709 draft-ietf-i2rs-yang-network-topo, work in progress. 1711 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 1712 Requirements for Transport API", June 2016. 1714 [ONF GitHub] ONF Open Transport (SNOWMASS) 1715 https://github.com/OpenNetworkingFoundation/Snowmass- 1716 ONFOpenTransport 1718 10. Acknowledgments 1720 The authors would like to thank all members of the Transport NBI 1721 Design Team involved in the definition of use cases, gap analysis 1722 and guidelines for using the IETF YANG models at the Northbound 1723 Interface (NBI) of a Transport SDN Controller. 1725 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 1726 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 1727 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 1728 the work on gap analysis for transport NBI and having provided 1729 foundations work for the development of this document. 1731 The authors would like to thank the authors of the TE Topology and 1732 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor 1733 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 1734 support in addressing any gap identified during the analysis work. 1736 This document was prepared using 2-Word-v2.0.template.dot. 1738 Appendix A. Detailed JSON Examples 1740 A.1. JSON Code: mpi1-otn-topology.json 1742 The JSON code for this use case is currently located on GitHub at: 1744 https://github.com/danielkinguk/transport-nbi/blob/master/Internet- 1745 Drafts/Applicability-Statement/01/mpi1-otn-topology.json 1747 A.2. JSON Code: mpi1-odu2-service-config.json 1749 The JSON code for this use case is currently located on GitHub at: 1751 https://github.com/danielkinguk/transport-nbi/blob/master/Internet- 1752 Drafts/Applicability-Statement/01/mpi1-odu2-service-config.json 1754 Appendix B. Validating a JSON fragment against a YANG Model 1756 The objective is to have a tool that allows validating whether a 1757 piece of JSON code is compliant with a YANG model without using a 1758 client/server. 1760 B.1. DSDL-based approach 1762 The idea is to generate a JSON driver file (JTOX) from YANG, then 1763 use it to translate JSON to XML and validate it against the DSDL 1764 schemas, as shown in Figure 6. 1766 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 1768 (2) 1769 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 1770 | | 1771 | (1) | 1772 | | 1773 Config/state JTOX-file | (4) 1774 \ | | 1775 \ | | 1776 \ V V 1777 JSON-file------------> XML-file ----------------> Output 1778 (3) 1780 Figure 6 - DSDL-based approach for JSON code validation 1782 In order to allow the use of comments following the convention 1783 defined in section Section 2. without impacting the validation 1784 process, these comments will be automatically removed from the 1785 JSON-file that will be validate. 1787 B.2. Why not using a XSD-based approach 1789 This approach has been analyzed and discarded because no longer 1790 supported by pyang. 1792 The idea is to convert YANG to XSD, JSON to XML and validate it 1793 against the XSD, as shown in Figure 7: 1795 (1) 1796 YANG-module ---> XSD-schema - \ (3) 1797 +--> Validation 1798 JSON-file------> XML-file ----/ 1799 (2) 1801 Figure 7 - XSD-based approach for JSON code validation 1803 The pyang support for the XSD output format was deprecated in 1.5 1804 and removed in 1.7.1. However pyang 1.7.1 is necessary to work with 1805 YANG 1.1 so the process shown in Figure 7 will stop just at step 1806 (1). 1808 Authors' Addresses 1810 Italo Busi (Editor) 1811 Huawei 1813 Email: italo.busi@huawei.com 1815 Daniel King (Editor) 1816 Lancaster University 1818 Email: d.king@lancaster.ac.uk 1820 Haomian Zheng (Editor) 1821 Huawei 1823 Email: zhenghaomian@huawei.com 1825 Yunbin Xu (Editor) 1826 CAICT 1828 Email: xuyunbin@ritt.cn 1830 Yang Zhao 1831 China Mobile 1833 Email: zhaoyangyjy@chinamobile.com 1835 Sergio Belotti 1836 Nokia 1838 Email: sergio.belotti@nokia.com 1840 Gianmarco Bruno 1841 Ericsson 1843 Email: gianmarco.bruno@ericsson.com 1844 Young Lee 1845 Huawei 1847 Email: leeyoung@huawei.com 1849 Victor Lopez 1850 Telefonica 1852 Email: victor.lopezalvarez@telefonica.com 1854 Carlo Perocchio 1855 Ericsson 1857 Email: carlo.perocchio@ericsson.com 1859 Ricard Vilalta 1860 CTTC 1862 Email: ricard.vilalta@cttc.es