idnits 2.17.1 draft-tnbidt-ccamp-transport-nbi-analysis-uc1-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group I. Busi (Ed.) 2 Internet Draft Huawei 3 Intended status: Informational D. King (Ed.) 4 Lancaster University 6 Expires: April 2018 October 30, 2017 8 Analysis of Transport North Bound Interface Use Case 1 9 draft-tnbidt-ccamp-transport-nbi-analysis-uc1-01 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on April 30, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document analyses how YANG models being defined by IETF (TEAS 52 and CCAMP WGs in particular) can be used to support Use Case 1 53 (single-domain with single-layer) scenarios, as referenced later in 54 this document. 56 Table of Contents 58 1. Introduction...................................................2 59 1.1. Assumptions...............................................3 60 1.2. Feedbacks provided to the IETF Working Groups.............3 61 2. Conventions used in this document..............................4 62 3. High-level Overview............................................5 63 3.1. Topology Abstraction......................................5 64 3.1.1. ODU White Topology Abstraction.......................5 65 3.2. Service Configuration.....................................8 66 3.2.1. ODU Transit Service..................................8 67 3.2.2. EPL over ODU Service................................10 68 3.2.3. OTN Client Private Line Service.....................11 69 3.2.4. EVPL over ODU Service...............................12 70 4. Topology Abstraction: detailed JSON examples..................12 71 4.1. ODU White Topology Abstraction...........................12 72 5. Service Configuration: detailed JSON examples.................13 73 5.1. ODU Transit Service......................................13 74 6. Security Considerations.......................................13 75 7. IANA Considerations...........................................13 76 8. Conclusions...................................................13 77 9. References....................................................13 78 9.1. Normative References.....................................13 79 9.2. Informative References...................................14 80 10. Acknowledgments..............................................14 81 Appendix A. Validating a JSON fragment against a YANG Model......15 82 A.1. DSDL-based approach......................................15 83 A.2. Why not using a XSD-based approach.......................15 84 A.3. JSON Code: use-case-1-topology-01.json...................16 85 A.4. JSON Code: use-case-1-topology-01.json...................16 87 1. Introduction 89 This document analyses how YANG models being developed by IETF (TEAS 90 and CCAMP WGs) can be used to support Use Case 1 (single-domain with 91 single-layer) scenarios, as described in [TNBI-UseCases]. 93 1.1. Assumptions 95 This document analyses how existing models developed by the IETF can 96 be used at the MPI between the Transport PNC and the MDSC to support 97 the use case 1 scenarios, as defined in section 3 of [TNBI-UseCases]. 99 This document assumes the applicability of the YANG models to the 100 ACTN interfaces as defined in [ACTN-YANG] and therefore considers the 101 TE Topology YANG model defined in [TE-TOPO], with the OTN Topology 102 augmentation defined in [OTN-TOPO] and the TE Tunnel YANG model 103 defined in [TE-TUNNEL], with the OTN Tunnel augmentation defined in 104 [OTN-TUNNEL]. 106 The analysis of how to use the attributes in the I2RS Topology YANG 107 model, defined in [I2RS-TOPO], is for further study. 109 Moreover, this document is making the following assumptions, still to 110 be validated with TEAS WG: 112 1. The MDSC can request, at the MPI, the Transport PNC to setup a 113 Transit Tunnel Segment using the TE Tunnel YANG model: in this 114 case, since the endpoints of the E2E Tunnel are outside the domain 115 controlled by the Transport PNC, the MDSC would not specify any 116 source or destination TTP (i.e., it would leave the source, 117 destination, src-tp-id and dst-tp-id attributes empty) and it 118 would use the explicit-route-object list to specify the ingress 119 and egress links of the Transit Tunnel Segment. 121 2. The Transport PNC provides to the MDSC, at the MPI, the list of 122 available timeslots on the access links using the TE Topology YANG 123 model and OTN Topology augmentation. The TE Topology YANG model in 124 [TE-TOPO] is being updated to report the label set information. 126 1.2. Feedbacks provided to the IETF Working Groups 128 The analysis done in this version of this document has triggered the 129 following feedbacks to CCAMP WG: 131 o A set of YANG models have been submitted in draft-zheng-ccamp- 132 client-topo-yang and draft-zheng-ccamp-otn-client-signal-yang, 133 providing an initial proposal, to be reviewed and discussed by the 134 DT and the CCAMP WG, to resolve the open issues for EPL, other OTN 135 client Private Line and EVPL services described in this version of 136 the document. 138 2. Conventions used in this document 140 This document provides some detailed JSON code examples to describe 141 how the YANG models being developed by IETF (TEAS and CCAMP WG in 142 particular) can be used. 144 The examples are provided using JSON because JSON code is easier for 145 humans to read and write. 147 Different objects need to have an identifier. The convention used to 148 create mnemonic identifiers is to use the object name (e.g., S3 for 149 node S3), followed by its type (e.g., NODE), separated by an "-", 150 followed by "-ID". For example the mnemonic identifier for node S3 151 would be S3-NODE-ID. 153 JSON language does not support the insertion of comments that have 154 been instead found to be useful when writing the examples. This 155 document inserts comments into the JSON code as JSON name/value pair 156 with the JSON name string starting with the "//" characters. For 157 example, when describing the example of a TE Topology instance 158 representing the ODU Abstract Topology exposed by the Transport PNC, 159 the following comment has been added to the JSON code: 161 "// comment": "ODU Abstract Topology @ MPI", 163 The JSON code examples provided in this document have been validated 164 against the YANG models following the validation process described in 165 Appendix A, which would not consider the comments. 167 In order to have successful validation of the examples, some 168 numbering scheme has been defined to assign identifiers to the 169 different entities which would pass the syntax checks. In that case, 170 to simplify the reading, another JSON name/value pair, formatted as a 171 comment and using the mnemonic identifiers is also provided. For 172 example, the identifier of node S3 (S3-NODE-ID) has been assumed to 173 be "10.0.0.3" and would be shown in the JSON code example using the 174 two JSON name/value pair: 176 "// te-node-id": "S3-NODE-ID", 178 "te-node-id": "10.0.0.3", 180 The first JSON name/value pair will be automatically removed in the 181 first step of the validation process while the second JSON name/value 182 pair will be validate against the YANG model definitions. 184 3. High-level Overview 186 Use Case 1 is described in [TNBI-UseCases] as a single-domain with 187 single layer network scenario supporting different types of services. 188 This section provides a high-level overview of how IETF YANG models 189 can be used to support these uses cases at the MPI between the 190 Transport PNC and the MDSC. 192 Section 3.1 describes the topology abstraction provided to the MDSC 193 by the Transport PNC at the MPI. 195 Section 3.2 describes how the difference services, defined in section 196 4.3 of [TNBI-UseCases], can be requested to the Transport PNC by the 197 MDSC at the MPI. 199 3.1. Topology Abstraction 201 3.1.1. ODU White Topology Abstraction 203 In case the Transport PNC exports to the MDSC a white topology, at 204 the MPI there will be one TE Topology instance for the ODU layer 205 (called "ODU Topology") containing one TE Node (called "ODU Node") 206 for each physical node, as shown in Figure 1 below. 208 .................................. 209 : : 210 : ODU Abstract Topology @ MPI : 211 : : 212 : +----+ +----+ : 213 : | | | | : 214 : | S1 |--------| S2 |- - - - -(C-R4) 215 : +----+ +----+ : 216 : / | : 217 : / | : 218 : +----+ +----+ | : 219 : | | | | | : 220 (C-R1)- - - - -| S3 |---| S4 | | : 221 :S3-1+----+ +----+ | : 222 : \ \ | : 223 : \ \ | : 224 : +----+ \ | : 225 : | | \ | : 226 : | S5 | \ | : 227 : +----+ \ | : 228 (C-R2)- - - - - / \ \ | : 229 :S6-1 \ / \ \ | : 230 : +----+ +----+ +----+ : 231 : | | | | | | : 232 : | S6 |---| S7 |---| S8 |- - - - -(C-R5) 233 : +----+ +----+ +----+ : 234 : / : 235 (C-R3)- - - - - : 236 :S6-2 : 237 :................................: 239 Figure 1 White Topology Abstraction (ODU Topology) 241 The ODU Nodes in Figure 1 are using with the same names as the 242 physical nodes to simplify the description of the mapping between the 243 ODU Nodes exposed by the Transport PNCs at the MPI and the physical 244 nodes in the data plane. This does not correspond to the reality of 245 the usage of the topology model, as described in section 4.3 of [TE- 246 TOPO], in which renaming by the client it is necessary. 248 As described in section 3.2 of [TNBI-UseCases], it is assumed that 249 the physical links between the physical nodes are pre-configured up 250 to the OTU4 trail using mechanisms which are outside the scope of 251 this document. The Transport PNC exports to the MDSC via the MPI, one 252 TE Link (called "ODU Link") for each of these physical links. 254 Access links in Figure 1 are shown as ODU Links: the modeling of the 255 access links for other access technologies is currently an open 256 issue. 258 The modeling of the access link in case of non-ODU access technology, 259 has also an impact on the need to model ODU TTPs and layer transition 260 capabilities on the edge nodes (e.g., nodes S2, S3, S6 and S8 in 261 Figure 1). 263 If, for example, the physical NE S6, is implemented in a "pizza box", 264 the data plane would have only set of ODU termination resources 265 (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and 266 160xODUflex can be terminated). The traffic coming from each of the 267 10GE access links can be mapped into any of these ODU terminations. 269 Instead if, for example, the physical NE S6 can be implemented as a 270 multi-board system where access links reside on different/dedicated 271 access cards with separated set of ODU termination resources(where up 272 to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for each 273 resource can be terminated). The traffic coming from one 10GE access 274 links can be mapped only into the ODU terminations which reside on 275 the same access card. 277 The more generic implementation option for a physical NE (e.g., S6) 278 would be case is of a multi-board system with multiple access cards 279 with separated sets of access links and ODU termination resources 280 (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex 281 for each resource can be terminated). The traffic coming from each of 282 the 10GE access links on one access card can be mapped only into any 283 of the ODU terminations which reside on the same access card. 285 In the last two cases, only the ODUs terminated on the same access 286 card where the access links resides can carry the traffic coming from 287 that 10GE access link. Terminated ODUs can instead be sent to any of 288 the OTU4 interfaces 290 In all these cases, terminated ODUs can be sent to any of the OTU4 291 interfaces assuming the implementation is based on a non-blocking ODU 292 cross-connect. 294 If the access links are reported via MPI in some, still to be 295 defined, client topology, it is possible to report each set of ODU 296 termination resources as an ODU TTP within the ODU Topology of Figure 297 1 and to use either the inter-layer lock-id or the transitional link, 298 as described in sections 3.4 and 3.10 of [TE-TOPO], to correlate the 299 access links, in the client topology, with the ODU TTPs, in the ODU 300 topology, to which access link are connected to. 302 The "external-domain" container allows the MDSC to glue together the 303 ODU Topology provided by the Transport PNC with the information 304 provided by the IP PNC to know which access link is connected with 305 each link/router in the IP domain (e.g., that C-R1 is connected with 306 the access link terminating on S3-1 LTP in the ODU Topology). 308 Further details about how the MDSC can glue together the access link 309 information will be added in a future version of this document. 311 3.2. Service Configuration 313 3.2.1. ODU Transit Service 315 In this case, the access links are configured as ODU Link, as 316 described in section 3.1.1 above. 318 As described in section 4.3.1 of [TNBI-UseCases], the MDSC needs to 319 setup an ODU2 trail, supporting an IP link, between C-R1 and C-R3. 321 From the topology information described in section 3.1.1 above, the 322 MDSC can know that C-R1 is attached to the access link terminating on 323 S3-1 LTP in the ODU Topology and that C-R3 is attached to the access 324 link terminating on S6-2 LTP in the ODU Topology. 326 Based on the assumption 1) in section 1.1, MDSC would then request 327 the Transport PNC to setup an ODU2 (Transit Segment) Tunnel between 328 S3-1 and S6-2 LTPs: 330 o Source and Destination TTPs are not specified (since it is a 331 Transit Tunnel) 333 o Ingress and egress points are indicated in the explicit-route- 334 objects of the primary path: 336 o The first element of the explicit-route-objects references the 337 access link terminating on S3-1 LTP 339 o Last element of the explicit-route-objects references the 340 access link terminating on S6-2 LTP 342 The configuration of the timeslots used by the ODU2 connection within 343 the transport network domain (i.e., on the internal links) is a 344 matter of the Transport PNC and its interactions with the physical 345 network elements and therefore is outside the scope of this document. 347 However, the configuration of the timeslots used by the ODU2 348 connection at the edge of the transport network domain (i.e., on the 349 access links) needs to take into account not only the timeslots 350 available on the physical nodes at the edge of the transport network 351 domain (e.g., S3 and S6) but also on the devices, outside of the 352 transport network domain, connected through these access links (e.g., 353 C-R1 and C-R3). 355 Based on the assumption 2) in section 1.1, the MDSC, when requesting 356 the Transport PNC to setup the (Transit Segment) ODU2 Tunnel, it 357 would also configure the timeslots to be used on the access links. 358 The MDSC can know the timeslots which are available on the edge OTN 359 Node (e.g., S3 and S6) from the OTN Topology information exposed by 360 the Transport PNC at the MPI as well as the timeslots which are 361 available on the devices outside of the transport network domain 362 (e.g., C-R1 and C-R3), by means which are outside the scope of this 363 document. 365 The Transport PNC performs path computation and sets up the ODU2 366 cross-connections within the physical nodes S3, S5 and S6, as shown 367 in section 4.3.1 of [TNBI-UseCases]. 369 The Transport PNC reports the status of the created ODU2 (Transit 370 Segment) Tunnel and its path within the ODU Topology as shown in 371 Figure 2 below: 373 .................................. 374 : : 375 : ODU Abstract Topology @ MPI : 376 : : 377 : +----+ +----+ : 378 : | | | | : 379 : | S1 |--------| S2 |- - - - -(C-R4) 380 : +----+ +----+ : 381 : / | : 382 : / | : 383 : +----+ +----+ | : 384 : | | | | | : 385 (C-R1)- - - - - S3 |---| S4 | | : 386 :S3-1 <<==+ +----+ | : 387 : = \ | : 388 : = \ \ | : 389 : == ---+ \ | : 390 : = | \ | : 391 : = S5 | \ | : 392 : == --+ \ | : 393 (C-R2)- - - - - = \ \ | : 394 :S6-1 \ / = \ \ | : 395 : +--- = +----+ +----+ : 396 : | = | | | | : 397 : | S6 = --| S7 |---| S8 |- - - - -(C-R5) 398 : +--- = +----+ +----+ : 399 : / = : 400 (C-R3)- - - - - <<== : 401 :S6-2 : 402 :................................: 404 Figure 2 ODU2 Transit Tunnel 406 3.2.2. EPL over ODU Service 408 As described in section 4.3.2 of [TNBI-UseCases], the MDSC needs to 409 setup an EPL service between C-R1 and C-R3 supported by an ODU2 end- 410 to-end connection between S3 and S6. 412 As described in section 3.1.1 above, it is not clear in this case how 413 the Ethernet access links between the transport network and the IP 414 router, are reported by the PNC to the MDSC. 416 If the 10GE physical links are not reported as ODU links within the 417 ODU topology information, described in section 3.1.1 above, than the 418 MDSC will not have sufficient information to know that C-R1 and C-R3 419 are attached to nodes S3 and S6. 421 Assuming that the MDSC knows how C-R1 and C-R3 are attached to the 422 transport network, the MDSC would request the Transport PNC to setup 423 an ODU2 end-to-end Tunnel between S3 and S6. 425 This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In case 426 nodes S3 and S6 support more than one TTP, the MDSC should decide 427 which TTP to use. 429 As discussed in section 3.1.1, depending on the different hardware 430 implementations of the physical nodes S3 and S6, not all the access 431 links can be connected to all the TTPs. The MDSC should therefore not 432 only select the optimal TTP but also a TTP that would allow the 433 Tunnel to be used by the service. 435 It is assumed that in case node S3 or node S6 supports only one TTP, 436 this TTP can be accessed by all the access links. 438 Once the ODU2 Tunnel setup has been requested, unless there is a one- 439 to-one relationship between the S3 and S6 TTPs and the Ethernet 440 access links toward C-R1 and C-R3 (as in the case, described in 441 section 3.1.1, where the Ethernet access links reside on 442 different/dedicated access card such that the ODU2 tunnel can only 443 carry the Ethernet traffic from the only Ethernet access link on the 444 same access card where the ODU2 tunnel is terminated), the MDSC also 445 needs to request the setup of an EPL service from the access links on 446 S3 and S6, attached to C-R1 and C-R3, and this ODU2 Tunnel. 448 3.2.3. OTN Client Private Line Service 450 As described in section 3.1.1 above, it is not clear in this case how 451 the access links (e.g., the STM-N access links) between the transport 452 network and the IP router, are reported by the PNC to the MDSC. 454 As described in section 4.3.3 of [TNBI-UseCases], the MDSC needs to 455 setup an STM-64 Private Link service between C-R1 and C-R3 supported 456 by an ODU2 end-to-end connection between S3 and S6. 458 The same issues, as described in section 3.2.2, apply here: 460 o the MDSC needs to understand that C-R1 and C-R3 are connected, 461 thought STM-64 access links, with S3 and S6 463 o the MDSC needs to understand which TTPs in S3 and S6 can be 464 accessed by these access links 466 o the MDSC needs to configure the private line service from these 467 access links through the ODU2 tunnel 469 3.2.4. EVPL over ODU Service 471 As described in section 3.1.1 above, it is not clear in this case how 472 the Ethernet access links between the transport network and the IP 473 router, are reported by the PNC to the MDSC. 475 As described in section 4.3.3 of [TNBI-UseCases], the MDSC needs to 476 setup EVPL services between C-R1 and C-R3, as well as between C-R1 477 and C-R4, supported by ODU0 end-to-end connections between S3 and S6 478 as well as between S3 and S2. 480 The same issues, as described in section 3.2.2, apply here: 482 o the MDSC needs to understand that C-R1, C-R3 and C-R4 are 483 connected, thought the Ethernet access links, with S3, S6 and S2 485 o the MDSC needs to understand which TTPs in S3, S6 and S2 can be 486 accessed by these access links 488 o the MDSC needs to configure the EVPL services from these access 489 links through the ODU0 tunnels 491 In addition, the MDSC needs to get the information that the access 492 links on S3, S6 and S2 are capable to support EVPL (rather than just 493 EPL) as well as to coordinate the VLAN configuration, for each EVPL 494 service, on these access links (this is a similar issue as the 495 timeslot configuration on access links discussed in section 3.2.1 496 below). 498 4. Topology Abstraction: detailed JSON examples 500 4.1. ODU White Topology Abstraction 502 Section 3.1.1 describes how the Transport PNC can provide a white 503 topology abstraction to the MDSC via the MPI. Figure 1 is an example 504 of such ODU Topology. 506 This section provides the detailed JSON code describing how this ODU 507 Topology is reported by the PNC, using the [TE-TOPO] and [OTN-TOPO] 508 YANG models at the MPI. 510 JSON code "use-case-1-topology-01.json" has been provided at in the 511 appendix of this document. 513 5. Service Configuration: detailed JSON examples 515 5.1. ODU Transit Service 517 Section 3.2.1 describes how the MDSC can request a Transport PNC, via 518 the MPI, to setup an ODU2 transit service over an ODU Topology 519 described in section 3.1.1. 521 This section provides the detailed JSON code describing how the setup 522 of this ODU2 transit service can be requested by the MDSC, using the 523 [TE-TUNNEL] and [OTN-TUNNEL] YANG models at the MPI. 525 JSON code "use-case-1-odu2-service-01.json" has been provided at in 526 the appendix of this document. 528 6. Security Considerations 530 This section is for further study 532 7. IANA Considerations 534 This document requires no IANA actions. 536 8. Conclusions 538 This section is for further study 540 9. References 542 9.1. Normative References 544 [TNBI-UseCases] Busi, I., King, D. et al, "Transport Northbound 545 Interface Applicability Statement and Use Cases", draft- 546 ietf-ccamp-transport-nbi-use-cases, work in progress. 548 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft- 549 ietf-teas-yang-te-topo, work in progress. 551 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport 552 Network Topology", draft-ietf-ccamp-otn-topo-yang, work in 553 progress. 555 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 556 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 557 te, work in progress. 559 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-ietf- 560 ccamp-otn-tunnel-model, work in progress. 562 9.2. Informative References 564 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 565 Abstraction and Control of Traffic Engineered Networks", 566 draft-zhang-teas-actn-yang, work in progress. 568 [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", 569 draft-ietf-i2rs-yang-network-topo, work in progress. 571 10. Acknowledgments 573 The authors would like to thank all members of the Transport NBI 574 Design Team involved in the definition of use cases, gap analysis and 575 guidelines for using the IETF YANG models at the Northbound Interface 576 (NBI) of a Transport SDN Controller. 578 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 579 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 580 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 581 the work on gap analysis for transport NBI and having provided 582 foundations work for the development of this document. 584 The authors would like to thank the authors of the TE Topology and 585 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor 586 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 587 support in addressing any gap identified during the analysis work. 589 This document was prepared using 2-Word-v2.0.template.dot. 591 Appendix A. Validating a JSON fragment against a YANG Model 593 The objective is to have a tool that allows validating whether a 594 piece of JSON code is compliant with a YANG model without using a 595 client/server. 597 A.1. DSDL-based approach 599 The idea is to generate a JSON driver file (JTOX) from YANG, then use 600 it to translate JSON to XML and validate it against the DSDL schemas, 601 as shown in Figure 3. 603 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 605 (2) 606 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 607 | | 608 | (1) | 609 | | 610 Config/state JTOX-file | (4) 611 \ | | 612 \ | | 613 \ V V 614 JSON-file------------> XML-file ----------------> Output 615 (3) 617 Figure 3 - DSDL-based approach for JSON code validation 619 In order to allow the use of comments following the convention 620 defined in section 2 without impacting the validation process, these 621 comments will be automatically removed from the JSON-file that will 622 be validate. 624 A.2. Why not using a XSD-based approach 626 This approach has been analyzed and discarded because no longer 627 supported by pyang. 629 The idea is to convert YANG to XSD, JSON to XML and validate it 630 against the XSD, as shown in Figure 4: 632 (1) 633 YANG-module ---> XSD-schema - \ (3) 634 +--> Validation 635 JSON-file------> XML-file ----/ 636 (2) 638 Figure 4 - XSD-based approach for JSON code validation 640 The pyang support for the XSD output format was deprecated in 1.5 and 641 removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG 642 1.1 so the process shown in Figure 4 will stop just at step (1). 644 A.3. JSON Code: use-case-1-topology-01.json 646 The JSON code for this use case is currently located on GitHub at: 648 https://github.com/danielkinguk/transport-nbi/blob/master/Internet- 649 Drafts/Use-Case-1-Analysis/use-case-1-topology-01.json 651 A.4. JSON Code: use-case-1-topology-01.json 653 The JSON code for this use case is currently located on GitHub at: 655 https://github.com/danielkinguk/transport-nbi/blob/master/Internet- 656 Drafts/Use-Case-1-Analysis/use-case-1-odu2-service-01.json 657 Authors' Addresses 659 Italo Busi (Editor) 660 Huawei 661 Email: italo.busi@huawei.com 663 Daniel King (Editor) 664 Lancaster University 665 Email: d.king@lancaster.ac.uk 667 Sergio Belotti 668 Nokia 669 Email: sergio.belotti@nokia.com 671 Gianmarco Bruno 672 Ericsson 673 Email: gianmarco.bruno@ericsson.com 675 Carlo Perocchio 676 Ericsson 677 Email: carlo.perocchio@ericsson.com