idnits 2.17.1 draft-ietf-ccamp-transport-nbi-app-statement-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1215: '... inter-domain link information MUST be...' RFC 2119 keyword, line 1244: '...scovery mechanisms), it is RECOMMENDED...' RFC 2119 keyword, line 1789: '... <=72-chars? MUST MAY...' RFC 2119 keyword, line 1791: '... valid JSON? MAY MUST ...' RFC 2119 keyword, line 1793: '... JSON-encoding MAY MAY ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 577 has weird spacing: '...tations insi...' -- The document date (July 2, 2018) is 2126 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RESTCONF' is mentioned on line 155, but not defined == Missing Reference: 'Client-Topo' is mentioned on line 221, but not defined == Missing Reference: 'PKT' is mentioned on line 1101, but not defined == Missing Reference: 'ODU2' is mentioned on line 1100, but not defined == Missing Reference: 'ODU0' is mentioned on line 749, but not defined == Missing Reference: 'MAC' is mentioned on line 812, but not defined == Missing Reference: 'ODUflex' is mentioned on line 815, but not defined == Missing Reference: 'ACTN-Fwk' is mentioned on line 1214, but not defined == Unused Reference: 'CLIENT-TOPO' is defined on line 1684, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 11 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: January 2019 July 2, 2018 12 Transport Northbound Interface Applicability Statement 13 draft-ietf-ccamp-transport-nbi-app-statement-02 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 January 2, 2019. 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...................................................4 75 1.1. Scope of this document....................................4 76 1.2. Assumptions...............................................5 77 2. Terminology....................................................6 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..............................11 84 4.1.2. Multi-Domain Scenario...............................11 85 4.2. Topology Abstractions....................................11 86 4.3. Service Configuration....................................13 87 4.3.1. ODU Transit.........................................14 88 4.3.2. EPL over ODU........................................15 89 4.3.3. Other OTN Clients Services..........................16 90 4.3.4. EVPL over ODU.......................................17 91 4.3.5. EVPLAN and EVPTree Services.........................18 92 4.3.6. Dynamic Service Configuration.......................19 93 4.4. Multi-function Access Links..............................20 94 4.5. Protection and Restoration Configuration.................21 95 4.5.1. Linear Protection (end-to-end)......................21 96 4.5.2. Segmented Protection................................23 97 4.5.3. End-to-End Dynamic restoration......................23 98 4.5.4. Segmented Dynamic Restoration.......................24 99 4.6. Service Modification and Deletion........................24 100 4.7. Notification.............................................25 101 4.8. Path Computation with Constraint.........................25 102 5. YANG Model Analysis...........................................26 103 5.1. YANG Models for Topology Abstraction.....................26 104 5.1.1. Domain 1 Topology Abstraction.......................27 105 5.1.2. Domain 2 Grey (Type A) Topology Abstraction.........28 106 5.1.3. Domain 3 Grey (Type B) Topology Abstraction.........28 107 5.1.4. Multi-domain Topology Stitching.....................28 108 5.1.5. Access Links........................................29 109 5.2. YANG Models for Service Configuration....................31 110 5.2.1. ODU Transit Service.................................33 111 5.2.1.1. Single Domain Example..........................35 112 5.2.2. EPL over ODU Service................................36 113 5.2.3. Other OTN Client Services...........................38 114 5.2.4. EVPL over ODU Service...............................38 115 5.3. YANG Models for Protection Configuration.................39 116 5.3.1. Linear Protection (end-to-end)......................39 117 5.3.2. Segmented Protection................................39 118 6. Security Considerations.......................................39 119 7. IANA Considerations...........................................39 120 8. References....................................................39 121 8.1. Normative References.....................................39 122 8.2. Informative References...................................41 123 9. Acknowledgments...............................................41 124 Appendix A Validating a JSON fragment against a YANG Model....43 125 A.1. Manipulation of JSON fragments...........................43 126 A.2. Comments in JSON fragments...............................44 127 A.3. Validation of JSON fragments: DSDL-based approach........44 128 A.4. Validation of JSON fragments: why not using a XSD-based 129 approach......................................................45 130 Appendix B Detailed JSON Examples.............................46 131 B.1. JSON Examples for Topology Abstractions..................46 132 B.1.1. JSON Code: mpi1-otn-topology.json...................46 134 B.2. JSON Examples for Service Configuration..................73 135 B.2.1. JSON Code: mpi1-odu2-service-config.json...........73 136 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json.............77 137 B.2.3. JSON Code: mpi1-epl-service-config.json.............80 139 1. Introduction 141 Transport of packet services are critical for a wide-range of 142 applications and services, including: data center and LAN 143 interconnects, Internet service backhauling, mobile backhaul and 144 enterprise Carrier Ethernet Services. These services are typically 145 setup using stovepipe NMS and EMS platforms, often requiring 146 propriety management platforms and legacy management interfaces. A 147 clear goal of operators will be to automate setup of transport 148 services across multiple transport technology domains. 150 A common open interface (API) to each domain controller and or 151 management system is pre-requisite for network operators to control 152 multi-vendor and multi-domain networks and enable also service 153 provisioning coordination/automation. This can be achieved by using 154 standardized YANG models, used together with an appropriate protocol 155 (e.g., [RESTCONF]). 157 This document analyses the applicability of the YANG models being 158 defined by IETF (TEAS and CCAMP WGs in particular) to support OTN 159 single and multi-domain scenarios. 161 1.1. Scope of this document 163 This document assumes a reference architecture, including 164 interfaces, based on the Abstraction and Control of Traffic- 165 Engineered Networks (ACTN), defined in [ACTN-Frame]. 167 The focus of this document is on the MPI (interface between the 168 Multi Domain Service Coordinator (MDSC) and a Physical Network 169 Controller (PNC), controlling a transport network domain). 171 It is worth noting that the same MPI analyzed in this document could 172 be used between hierarchical MDSC controllers, as shown in Figure 4 173 of [ACTN-Frame]. 175 Detailed analysis of the CMI (interface between the Customer Network 176 Controller (CNC) and the MDSC) as well as of the interface between 177 service and network orchestrators are outside the scope of this 178 document. However, some considerations and assumptions about the 179 information could be described when needed. 181 The relationship between the current IETF YANG models and the type 182 of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it 183 considers the TE Topology YANG model defined in [TE-TOPO], with the 184 OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel 185 YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation 186 defined in [OTN-TUNNEL]. 188 The analysis of how to use the attributes in the I2RS Topology YANG 189 model, defined in [I2RS-TOPO], is for further study. 191 The ONF Technical Recommendations for Functional Requirements for 192 the transport API in [ONF TR-527] and the ONF transport API multi- 193 domain examples in [ONF GitHub] have been considered as an input for 194 defining the reference scenarios analyzed in this document. 196 1.2. Assumptions 198 This document is making the following assumptions, still to be 199 validated with TEAS WG: 201 1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel 202 Segment using the TE Tunnel YANG model: in this case, since the 203 endpoints of the E2E Tunnel are outside the domain controlled by 204 that PNC, the MDSC would not specify any source or destination 205 TTP (i.e., it would leave the source, destination, src-tp-id and 206 dst-tp-id attributes empty) for the tunnel and it would use the 207 explicit-route-object/route-object-include-exclude list to 208 specify the ingress and egress links for each path of the Transit 209 Tunnel Segment. 211 2. Each PNC provides to the MDSC, at the MPI, the list of available 212 timeslots on the inter-domain links using the TE Topology YANG 213 model and OTN Topology augmentation. The TE Topology YANG model 214 in [TE-TOPO] is being updated to report the label set 215 information. 217 This document is also making the following assumptions, still to be 218 validated with CCAMP WG: 220 1. The topology information for the Ethernet access links are 221 modelled using the YANG model defined in [Client-Topo]. 223 2. The service information for Ethernet and other OTN client layer 224 services are modelled using the YANG model defined in [Client- 225 Signal]. 227 2. Terminology 229 Domain: defined as a collection of network elements within a common 230 realm of address space or path computation responsibility [RFC5151] 232 E-LINE: Ethernet Line 234 EPL: Ethernet Private Line 236 EVPL: Ethernet Virtual Private Line 238 OTN: Optical Transport Network 240 Service: A service in the context of this document can be considered 241 as some form of connectivity between customer sites across the 242 network operator's network [RFC8309] 244 Service Model: As described in [RFC8309] it describes a service and 245 the parameters of the service in a portable way that can be used 246 uniformly and independent of the equipment and operating 247 environment. 249 UNI: User Network Interface 251 MDSC: Multi-Domain Service Coordinator 253 CNC: Customer Network Controller 255 PNC: Provisioning Network Controller 257 MAC Bridging: Virtual LANs (VLANs) on IEEE 802.3 Ethernet network 259 3. Conventions used in this document 261 3.1. Topology and traffic flow processing 263 The traffic flow between different nodes is specified as an ordered 264 list of nodes, separated with commas, indicating within the brackets 265 the processing within each node: 267 (){, ()} 269 The order represents the order of traffic flow being forwarded 270 through the network. 272 The processing can be either an adaptation of a client layer into a 273 server layer "(client -> server)" or switching at a given layer 274 "([switching])". Multi-layer switching is indicated by two layer 275 switching with client/server adaptation: "([client] -> [server])". 277 For example, the following traffic flow: 279 R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 280 R3 (ODU2 -> [PKT]) 282 Node R1 is switching at the packet (PKT) layer and mapping packets 283 into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are 284 switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which 285 then sends it to S6 which finally sends to R3. Node R3 terminates 286 the ODU2 from S6 before switching at the packet (PKT) layer. 288 The paths of working and protection transport entities are specified 289 as an ordered list of nodes, separated with commas: 291 {, } 293 The order represents the order of traffic flow being forwarded 294 through the network in the forward direction. In case of 295 bidirectional paths, the forward and backward directions are 296 selected arbitrarily, but the convention is consistent between 297 working/protection path pairs as well as across multiple domains. 299 3.2. JSON code 301 This document provides some detailed JSON code examples to describe 302 how the YANG models being developed by IETF (TEAS and CCAMP WG in 303 particular) can be used. 305 The examples are provided using JSON because JSON code is easier for 306 humans to read and write. 308 Different objects need to have an identifier. The convention used to 309 create mnemonic identifiers is to use the object name (e.g., S3 for 310 node S3), followed by its type (e.g., NODE), separated by an "-", 311 followed by "-ID". For example, the mnemonic identifier for node S3 312 would be S3-NODE-ID. 314 JSON language does not support the insertion of comments that have 315 been instead found to be useful when writing the examples. This 316 document inserts comments into the JSON code as JSON name/value pair 317 with the JSON name string starting with the "//" characters. For 318 example, when describing the example of a TE Topology instance 319 representing the ODU Abstract Topology exposed by the Transport PNC, 320 the following comment has been added to the JSON code: 322 "// comment": "ODU Abstract Topology @ MPI", 324 The JSON code examples provided in this document have been validated 325 against the YANG models following the validation process described 326 in Appendix A, which would not consider the comments. 328 In order to have successful validation of the examples, some 329 numbering scheme has been defined to assign identifiers to the 330 different entities which would pass the syntax checks. In that case, 331 to simplify the reading, another JSON name/value pair, formatted as 332 a comment and using the mnemonic identifiers is also provided. For 333 example, the identifier of node S3 (S3-NODE-ID) has been assumed to 334 be "10.0.0.3" and would be shown in the JSON code example using the 335 two JSON name/value pair: 337 "// te-node-id": "S3-NODE-ID", 339 "te-node-id": "10.0.0.3", 341 The first JSON name/value pair will be automatically removed in the 342 first step of the validation process while the second JSON 343 name/value pair will be validate against the YANG model definitions. 345 4. Scenarios Description 347 4.1. Reference Network 349 The physical topology of the reference network is shown in Figure 1. 350 It represents an OTN network composed of three transport network 351 domains providing transport services to an IP customer network 352 through eight access links: 354 ........................ 355 .......... : : 356 : : Network domain 1 : ............. 357 Customer: : : : : 358 domain : : S1 -------+ : : Network : 359 : : / \ : : domain 3 : .......... 360 R1 ------- S3 ----- S4 \ : : : : 361 : : \ \ S2 --------+ : :Customer 362 : : \ \ | : : \ : : domain 363 : : S5 \ | : : \ : : 364 R2 ------+ / \ \ | : : S31 --------- R7 365 : : \ / \ \ | : : / \ : : 366 : : S6 ---- S7 ---- S8 ------ S32 S33 ------ R8 367 : : / | | : : / \ / : :....... 368 R3 ------+ | | : :/ S34 : : 369 : :..........|.......|...: / / : : 370 ........: | | /:.../.......: : 371 | | / / : 372 ...........|.......|..../..../... : 373 : | | / / : .............. 374 : Network | | / / : : 375 : domain 2 | | / / : :Customer 376 : S11 ---- S12 / : : domain 377 : / | \ / : : 378 : S13 S14 | S15 ------------- R4 379 : | \ / \ | \ : : 380 : | S16 \ | \ : : 381 : | / S17 -- S18 --------- R5 382 : | / \ / : : 383 : S19 ---- S20 ---- S21 ------------ R6 384 : : : 385 :...............................: :............. 387 Figure 1 Reference network 389 This document assumes that all the transport network switching nodes 390 Si are OTN switching nodes capable to switch only in the electrical 391 domain (ODU switching only) and that all the Si-Sj OTN links within 392 the transport network (intra-domain or inter-domain) are 100G links 393 while the access Ri-Sj links are 10G links. Different technologies 394 can be used at the access links (e.g., Ethernet, STM-n, OTN). 396 It is also assumed that, within the transport network, the 397 physical/optical interconnections supporting the Si-Sj OTN links (up 398 to the OTU4 trail), are pre-configured using mechanisms which are 399 outside the scope of this document and are not exposed at the MPIs 400 to the MDSC. 402 The transport domain control architecture, shown in Figure 2, 403 follows the ACTN architecture and framework document [ACTN-Frame], 404 and functional components: 406 -------------- 407 | | 408 | CNC | 409 | | 410 -------------- 411 | 412 ....................|....................... CMI 413 | 414 ---------------- 415 | | 416 | MDSC | 417 | | 418 ---------------- 419 / | \ 420 / | \ 421 ............../.....|......\................ MPIs 422 / | \ 423 / ---------- \ 424 / | PNC2 | \ 425 / ---------- \ 426 ---------- | \ 427 | PNC1 | ----- \ 428 ---------- ( ) ---------- 429 | ( ) | PNC3 | 430 ----- ( Network ) ---------- 431 ( ) ( Domain 2 ) | 432 ( ) ( ) ----- 433 ( Network ) ( ) ( ) 434 ( Domain 1 ) ----- ( ) 435 ( ) ( Network ) 436 ( ) ( Domain 3 ) 437 ----- ( ) 438 ( ) 439 ----- 441 Figure 2 Controlling Hierarchy 443 The ACTN framework facilitates the detachment of the network and 444 service control from the underlying technology and help the customer 445 express the network as desired by business needs. Therefore, care 446 must be taken to keep minimal dependency on the CMI (or no 447 dependency at all) with respect to the network domain technologies. 448 The MPI instead requires some specialization according to the domain 449 technology. 451 This document assumes that the CNC controls the customer IP network 452 and requests, at the CMI, transport connectivity between IP routers. 453 The MDSC coordinates, via three MPIs, the control of a multi-domain 454 transport network through three PNCs. 456 The control interfaces within scope of this document are the three 457 MPIs, while the control interface(s) between the CNC and the IP 458 routers is outside the scope of this document. It is also assumed 459 that the CMI allows the CNC to provide all the information that is 460 required by the MDSC to properly configure the transport 461 connectivity requested by the customer. 463 4.1.1. Single-Domain Scenario 465 In case the CNC requests transport connectivity between IP routers 466 attached to the same transport domain (e.g., between R1 and R3 in 467 Figure 1), the MDSC can just pass the service request to the PNC 468 controlling that domain (e.g., PNC1 in Figure 2) and let the PNC 469 take decisions about how to implement the service (e.g., setting up 470 the intra-domain end-to-end OTN connection). 472 4.1.2. Multi-Domain Scenario 474 In case the CNC requests transport connectivity between IP routers 475 attached to different transport domains (e.g., between R1 and R5), 476 the MDSC needs to coordinate the setup of a multi-domain end-to-end 477 OTN connection across multiple PNCs (e.g., PNC1, PNC2 and PNC3 in in 478 Figure 2) as well as to coordinate the configuration of the service 479 with the PNCs controlling the edge domains (e.g., PNC1 and PNC2 in 480 Figure 2). 482 4.2. Topology Abstractions 484 Abstraction provides a selective method for representing 485 connectivity information within a domain. There are multiple methods 486 to abstract a network topology. This document assumes the 487 abstraction method defined in [RFC7926]: 489 "Abstraction is the process of applying policy to the available TE 490 information within a domain, to produce selective information that 491 represents the potential ability to connect across the domain. 492 Thus, abstraction does not necessarily offer all possible 493 connectivity options, but presents a general view of potential 494 connectivity according to the policies that determine how the 495 domain's administrator wants to allow the domain resources to be 496 used." 498 [ACTN-Frame] Provides the context of topology abstraction in the 499 ACTN architecture and discusses a few alternatives for the 500 abstraction methods for both packet and optical networks. This is an 501 important consideration since the choice of the abstraction method 502 impacts protocol design and the information it carries. According 503 to [ACTN-Frame], there are three types of topology: 505 o White topology: This is a case where the PNC provides the actual 506 network topology to the MDSC without any hiding or filtering. In 507 this case, the MDSC has the full knowledge of the underlying 508 network topology; 510 o Black topology: The entire domain network is abstracted as a 511 single virtual node with the access/egress links without 512 disclosing any node internal connectivity information; 514 o Grey topology: This abstraction level is between black topology 515 and white topology from a granularity point of view. This is 516 abstraction of TE tunnels for all pairs of border nodes. We may 517 further differentiate from a perspective of how to abstract 518 internal TE resources between the pairs of border nodes: 520 - Grey topology type A: border nodes with a TE links between 521 them in a full mesh fashion; 523 - Grey topology type B: border nodes with some internal 524 abstracted nodes and abstracted links. 526 Each PNC should provide the MDSC a topology abstraction of the 527 domain's network topology. 529 Each PNC provides topology abstraction of its own domain topology 530 independently from each other and therefore it is possible that 531 different PNCs provide different types of topology abstractions. 533 The MPI operates on the abstract topology regardless on the type of 534 abstraction provided by the PNC. 536 To analyze how the MPI operates on abstract topologies independently 537 from the topology abstraction provided by each PNC and, therefore, 538 that that different PNCs can provide different topology 539 abstractions, it is assumed that: 541 o PNC1 provides a topology abstraction which exposes at MPI1 an 542 abstract node and an abstract link for each physical node and 543 link within network domain 1 545 o PNC2 provides a topology abstraction which exposes at MPI2 a 546 single abstract node (representing the whole network domain) with 547 abstract links representing only the inter-domain physical links 549 o PNC3 provides a topology abstraction which exposes at MPI3 two 550 abstract nodes (called AN31 and AN32). They abstract respectively 551 nodes S31+S33 and nodes S32+S34. At MPI3, only the abstract nodes 552 should be reported: the mapping between the abstract nodes (AN31 553 and AN32) and the physical nodes (S31, S32, S33 and S34) should 554 be done internally by PNC3. 556 The MDSC should be capable to stitch together each abstracted 557 topology to build its own view of the multi-domain network topology. 558 The process may require suitable oversight, including administrative 559 configuration and trust models, but this is out of scope for this 560 document. 562 The MDSC can also provide topology abstraction of its own view of 563 the multi-domain network topology at its CMIs depending on the 564 customers' needs: it can provide different types of topology 565 abstractions at different CMIs. 567 4.3. Service Configuration 569 In the following scenarios, it is assumed that the CNC is capable to 570 request service connectivity from the MDSC to support IP routers 571 connectivity. 573 The type of services could depend of the type of physical links 574 (e.g. OTN link, ETH link or SDH link) between the routers and 575 transport network. 577 The control of different adaptations inside IP routers, Ri (PKT -> 578 foo) and Rj (foo -> PKT), are assumed to be performed by means that 579 are not under the control of, and not visible to, the MDSC nor to 580 the PNCs. Therefore, these mechanisms are outside the scope of this 581 document. 583 It is just assumed that the CNC is capable to request the proper 584 configuration of the different adaptation functions inside the 585 customer's IP routers, by means which are outside the scope of this 586 document. 588 4.3.1. ODU Transit 590 The physical links interconnecting the IP routers and the transport 591 network can be OTN links. In this case, it is assumed that the 592 physical/optical interconnections below the ODU layer (up to the 593 OTU2 trail) are pre-configured using mechanisms which are outside 594 the scope of this document and not exposed at the MPIs to the MDSC. 596 To setup a 10Gb IP link between R1 and R5, an ODU2 end-to-end data 597 plane connection needs be created between R1 and R5, crossing 598 transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong 599 to different PNC domains. 601 The traffic flow between R1 and R5 can be summarized as: 603 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 604 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 605 S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) 607 It is assumed that the CNC requests, via the CMI, the setup of an 608 ODU2 transit service, providing all the information that the MDSC 609 needs to understand that it shall setup a multi-domain ODU2 segment 610 connection between nodes S3 and S18. 612 In case the CNC needs the setup of a 10Gb IP link between R1 and R3 613 (single-domain service request), the traffic flow between R1 and R3 614 can be summarized as: 616 R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 617 R3 (ODU2 -> [PKT]) 619 Since the CNC is unaware of the transport network domains, it 620 requests the setup of an ODU2 transit service in the same way as 621 before, regardless the fact the fact that this is a single-domain 622 service. 624 It is assumed that the information provided at the CMI is sufficient 625 for the MDSC to understand that this is a single-domain service 626 request. 628 The MDSC can then just request PNC1 to setup a single-domain ODU2 629 data plane segment connection between nodes S3 and S6. 631 4.3.2. EPL over ODU 633 The physical links interconnecting the IP routers and the transport 634 network can be Ethernet links. In this case, it is assumed that the 635 Ethernet physical interconnections below the MAC layer (up to the 636 OTU2 trail) are pre-configured using mechanisms which are outside 637 the scope of this document and not exposed at the MPIs to the MDSC. 639 To setup a 10Gb IP link between R1 and R5, an EPL service needs to 640 be created between R1 and R5, supported by an ODU2 end-to-end data 641 plane connection between transport nodes S3 and S18, crossing 642 transport nodes S1, S2, S31, S33, S34 and S15 which belong to 643 different PNC domains. 645 The traffic flow between R1 and R5 can be summarized as: 647 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 648 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 649 S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) 651 It is assumed that the CNC requests, via the CMI, the setup of an 652 EPL service, providing all the information that the MDSC needs to 653 understand that it shall coordinate the three PNCs to setup a multi- 654 domain ODU2 end-to-end connection between nodes S3 and S18 as well 655 as the configuration of the adaptation functions inside nodes S3 and 656 S18: S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> [ODU2]) 657 and S3 ([ODU2] -> ETH). 659 In case the CNC needs the setup of a 10Gb IP link between R1 and R3 660 (single-domain service request), the traffic flow between R1 and R3 661 can be summarized as: 663 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), 664 S6 ([ODU2] -> ETH), R3 (ETH-> [PKT]) 666 As described in section 4.3.1, the CNC requests the setup of an EPL 667 service in the same way as before and the information provided at 668 the CMI is sufficient for the MDSC to understand that this is a 669 single-domain service request. 671 The MDSC can then just request PNC1 to setup a single-domain EPL 672 service between nodes S3 and S6. PNC1 can take care of setting up 673 the single-domain ODU2 end-to-end connection between nodes S3 and S6 674 as well as of configuring the adaptation functions on these edge 675 nodes. 677 4.3.3. Other OTN Clients Services 679 [ITU-T G.709] defines mappings of different client layers into 680 ODU. Most of them are used to provide Private Line services over 681 an OTN transport network supporting a variety of types of physical 682 access links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, 683 etc.). 685 The physical links interconnecting the IP routers and the transport 686 network can be any of these types. 688 In order to setup a 10Gb IP link between R1 and R5 using, for 689 example SDH physical links between the IP routers and the transport 690 network, an STM-64 Private Line service needs to be created between 691 R1 and R5, supported by ODU2 end-to-end data plane connection 692 between transport nodes S3 and S18, crossing transport nodes S1, S2, 693 S31, S33, S34 and S15 which belong to different PNC domains. 695 The traffic flow between R1 and R5 can be summarized as: 697 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 698 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 699 S15 ([ODU2]), S18 ([ODU2] -> STM-64), R5 (STM-64 -> [PKT]) 701 As described in section 4.3.2, it is assumed that the CNC is 702 capable, via the CMI, to request the setup of an STM-64 Private Line 703 service, providing all the information that the MDSC needs to 704 coordinate the setup of a multi-domain ODU2 connection as well as 705 the adaptation functions on the edge nodes. 707 In the single-domain case (10Gb IP link between R1 and R3), the 708 traffic flow between R1 and R3 can be summarized as: 710 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), 711 S6 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) 713 As described in section 4.3.1, the CNC requests the setup of an STM- 714 64 Private Line service in the same way as before and the 715 information provided at the CMI is sufficient for the MDSC to 716 understand that this is a single-domain service request. 718 As described in section 4.3.2, the MDSC could just request PNC1 to 719 setup a single-domain STM-64 Private Line service between nodes S3 720 and S6. 722 4.3.4. EVPL over ODU 724 When the physical links interconnecting the IP routers and the 725 transport network are Ethernet links, it is also possible that 726 different Ethernet services (e.g., EVPL) can share the same physical 727 link using different VLANs. 729 To setup two 1Gb IP links between R1 to R3 and between R1 and R5, 730 two EVPL services need to be created, supported by two ODU0 end-to- 731 end connections respectively between S3 and S6, crossing transport 732 node S5, and between S3 and S18, crossing transport nodes S1, S2, 733 S31, S33, S34 and S15 which belong to different PNC domains. 735 Since the two EVPL services are sharing the same Ethernet physical 736 link between R1 and S3, different VLAN IDs are associated with 737 different EVPL services: for example, VLAN IDs 10 and 20 738 respectively. 740 The traffic flow between R1 and R5 can be summarized as: 742 R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), 743 S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]), 744 S15 ([ODU0]), S18 ([ODU0] -> VLAN), R5 (VLAN -> [PKT]) 746 The traffic flow between R1 and R3 can be summarized as: 748 R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]), 749 S6 ([ODU0] -> VLAN), R3 (VLAN -> [PKT]) 751 As described in section 4.3.2, it is assumed that the CNC is 752 capable, via the CMI, to request the setup of these EVPL services, 753 providing all the information that the MDSC needs to understand that 754 it need to request PNC1 to setup an EVPL service between nodes S3 755 and S6 (single-domain service request) and it also needs to 756 coordinate the setup of a multi-domain ODU0 connection between nodes 757 S3 and S16 as well as the adaptation functions on these edge nodes. 759 4.3.5. EVPLAN and EVPTree Services 761 When the physical links interconnecting the IP routers and the 762 transport network are Ethernet links, multipoint Ethernet services 763 (e.g, EPLAN and EPTree) can also be supported. It is also possible 764 that multiple Ethernet services (e.g, EVPL, EVPLAN and EVPTree) 765 share the same physical link using different VLANs. 767 Note - it is assumed that EPLAN and EPTree services can be supported 768 by configuring EVPLAN and EVPTree with port mapping. 770 Since this EVPLAN/EVPTree service can share the same Ethernet 771 physical links between IP routers and transport nodes (e.g., with 772 the EVPL services described in section 4.3.4), a different VLAN ID 773 (e.g., 30) can be associated with this EVPLAN/EVPTree service. 775 In order to setup an IP subnet between R1, R2, R3 and R5, an 776 EVPLAN/EVPTree service needs to be created, supported by two ODUflex 777 end-to-end connections respectively between S3 and S6, crossing 778 transport node S5, and between S3 and S18, crossing transport nodes 779 S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. 781 Some MAC Bridging capabilities are also required on some nodes at 782 the edge of the transport network: for example Ethernet Bridging 783 capabilities can be configured in nodes S3 and S6: 785 o MAC Bridging in node S3 is needed to select, based on the MAC 786 Destination Address, whether received Ethernet frames should be 787 forwarded to R1 or to the ODUflex terminating on node S6 or to 788 the other ODUflex terminating on node S18; 790 o MAC bridging function in node S6 is needed to select, based on 791 the MAC Destination Address, whether received Ethernet frames 792 should be sent to R2 or to R3 or to the ODUflex terminating on 793 node S3. 795 In order to support an EVPTree service instead of an EVPLAN, 796 additional configuration of the Ethernet Bridging capabilities on 797 the nodes at the edge of the transport network is required. 799 The traffic flows between R1 and R3, between R3 and R5 and between 800 R1 and R5 can be summarized as: 802 R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 803 S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN), 804 R3 (VLAN -> [PKT]) 806 R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]), 807 S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]), 808 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 809 S33 ([ODUflex]), S34 ([ODUflex]), 810 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) 812 R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 813 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 814 S33 ([ODUflex]), S34 ([ODUflex]), 815 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) 817 As described in section 4.3.2, it is assumed that the CNC is 818 capable, via the CMI, to request the setup of this EVPLAN/EVPTree 819 service, providing all the information that the MDSC needs to 820 understand that it need to request PNC1 to setup an ODUflex 821 connection between nodes S3 and S6 (single-domain service request) 822 and it also needs to coordinate the setup of a multi-domain ODUflex 823 connection between nodes S3 and S16 as well as the MAC bridging and 824 the adaptation functions on these edge nodes. 826 In case the CNC needs the setup of an EVPLAN/EVPTree service only 827 between R1, R2 and R3 (single-domain service request), it would 828 request the setup of this service in the same way as before and the 829 information provided at the CMI is sufficient for the MDSC to 830 understand that this is a single-domain service request. 832 The MDSC can then just request PNC1 to setup a single-domain 833 EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care 834 of setting up the single-domain ODUflex end-to-end connection 835 between nodes S3 and S6 as well as of configuring the MAC bridging 836 and the adaptation functions on these edge nodes. 838 4.3.6. Dynamic Service Configuration 840 Given the service established in the previous sections, there is a 841 demand for an update of some service characteristics. A 842 straightforward approach would be terminate the current service and 843 replace with a new one. Another more advanced approach would be 844 dynamic configuration, in which case there will be no interruption 845 for the connection. 847 An example application would be updating the SLA information for a 848 certain connection. For example, an ODU transit connection is set up 849 according to section 4.3.1, with the corresponding SLA level of 'no 850 protection'. After the establishment of this connection, the user 851 would like to enhance this service by providing a restoration after 852 potential failure, and a request is generated on the CMI. In this 853 case, after receiving the request, the MDSC would need to send an 854 update message to the PNC, changing the SLA parameters in TE Tunnel 855 model. Then the connection characteristic would be changed by PNC, 856 and a notification would be sent to MDSC for acknowledgement. 858 4.4. Multi-function Access Links 860 Some physical links interconnecting the IP routers and the transport 861 network can be configured in different modes, e.g., as OTU2 or STM- 862 64 or 10GE. 864 This configuration can be done a-priori by means outside the scope 865 of this document. In this case, these links will appear at the MPI 866 either as an ODU Link or as a STM-64 Link or as a 10GE Link 867 (depending on the a-priori configuration) and will be controlled at 868 the MPI as discussed in section 4.3. 870 It is also possible not to configure these links a-priori and give 871 the control to the MPI to decide, based on the service 872 configuration, how to configure it. 874 For example, if the physical link between R1 and S3 is a multi- 875 functional access link while the physical links between R7 and S31 876 and between R5 and S18 are STM-64 and 10GE physical links 877 respectively, it is possible to configure either an STM-64 Private 878 Line service between R1 and R7 or an EPL service between R1 and R5. 880 The traffic flow between R1 and R7 can be summarized as: 882 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 883 S2 ([ODU2]), S31 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) 885 The traffic flow between R1 and R5 can be summarized as: 887 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 888 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 889 S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) 891 As described in section 4.3.2, it is assumed that the CNC is 892 capable, via the CMI, to request the setup either an STM-64 Private 893 Line service between R1 and R7 or an EPL service between R1 and R5, 894 providing all the information that the MDSC needs to understand that 895 it need to coordinate the setup of a multi-domain ODU2 connection, 896 either between nodes S3 and S31, or between nodes S3 and S18, as 897 well as the adaptation functions on these edge nodes, and in 898 particular whether the multi-function access link on between R1 and 899 S3 should operate as an STM-64 or as a 10GE link. 901 4.5. Protection and Restoration Configuration 903 Protection switching provides a pre-allocated survivability 904 mechanism, typically provided via linear protection methods and 905 would be configured to operate as 1+1 unidirectional (the most 906 common OTN protection method), 1+1 bidirectional or 1:n 907 bidirectional. This ensures fast and simple service survivability. 909 Restoration methods would provide capability to reroute and restore 910 connectivity traffic around network faults, without the network 911 penalty imposed with dedicated 1+1 protection schemes. 913 This section describes only services which are protected with linear 914 protection and with dynamic restoration. 916 The MDSC needs to be capable to coordinate different PNCs to 917 configure protection switching when requesting the setup of the 918 protected connectivity services described in section 4.3. 920 Since in these service examples, switching within the transport 921 network domain is performed only in the OTN ODU layer, also 922 protection switching within the transport network domain can only be 923 provided at the OTN ODU layer. 925 4.5.1. Linear Protection (end-to-end) 927 In order to protect any service defined in section 4.3 from failures 928 within the OTN multi-domain transport network, the MDSC should be 929 capable to coordinate different PNCs to configure and control OTN 930 linear protection in the data plane between nodes S3 and node S18. 932 It is assumed that the OTN linear protection is configured to with 933 1+1 unidirectional protection switching type, as defined in [ITU-T 934 G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. 936 In these scenarios, a working transport entity and a protection 937 transport entity, as defined in [ITU-T G.808.1], (or a working LSP 938 and a protection LSP, as defined in [RFC4427]) should be configured 939 in the data plane. 941 Two cases can be considered: 943 o In one case, the working and protection transport entities pass 944 through the same PNC domains: 946 Working transport entity: S3, S1, S2, 947 S31, S33, S34, 948 S15, S18 950 Protection transport entity: S3, S4, S8, 951 S32, 952 S12, S17, S18 954 o In another case, the working and protection transport entities 955 can pass through different PNC domains: 957 Working transport entity: S3, S5, S7, 958 S11, S12, S17, S18 960 Protection transport entity: S3, S1, S2, 961 S31, S33, S34, 962 S15, S18 964 The PNCs should be capable to report to the MDSC which is the active 965 transport entity, as defined in [ITU-T G.808.1], in the data plane. 967 Given the fast dynamic of protection switching operations in the 968 data plane (50ms recovery time), this reporting is not expected to 969 be in real-time. 971 It is also worth noting that with unidirectional protection 972 switching, e.g., 1+1 unidirectional protection switching, the active 973 transport entity may be different in the two directions. 975 4.5.2. Segmented Protection 977 To protect any service defined in section 4.3 from failures within 978 the OTN multi-domain transport network, the MDSC should be capable 979 to request each PNC to configure OTN intra-domain protection when 980 requesting the setup of the ODU2 data plane connection segment. 982 If PNC1 provides linear protection, the working and protection 983 transport entities could be: 985 Working transport entity: S3, S1, S2 987 Protection transport entity: S3, S4, S8, S2 989 If PNC2 provides linear protection, the working and protection 990 transport entities could be: 992 Working transport entity: S15, S18 994 Protection transport entity: S15, S12, S17, S18 996 If PNC3 provides linear protection, the working and protection 997 transport entities could be: 999 Working transport entity: S31, S33, S34 1001 Protection transport entity: S31, S32, S34 1003 4.5.3. End-to-End Dynamic restoration 1005 To restore any service defined in section 4.3 from failures within 1006 the OTN multi-domain transport network, the MDSC should be capable 1007 to coordinate different PNCs to configure and control OTN end-to-end 1008 dynamic Restoration in the data plane between nodes S3 and node S18. 1009 For example, the MDSC can request the PNC1, PNC2 and PNC3 to create 1010 a service with no-protection, MDSC set the end-to-end service with 1011 the dynamic restoration. 1013 Working transport entity: S3, S1, S2, 1014 S31, S33, S34, 1015 S15, S18 1017 When a link failure between S1 and s2 occurred in network domain 1, 1018 PNC1 does not restore the tunnel and send the alarm notification to 1019 the MDSC, MDSC will perform the end-to-end restoration. 1021 Restored transport entity: S3, S4, S8, 1022 S12, S15, S18 1024 4.5.4. Segmented Dynamic Restoration 1026 To restore any service defined in section 4.3 from failures within 1027 the OTN multi-domain transport network, the MDSC should be capable 1028 to coordinate different PNCs to configure and control OTN segmented 1029 dynamic Restoration in the data plane between nodes S3 and node S18. 1031 Working transport entity: S3, S1, S2, 1032 S31, S33, S34, 1033 S15, S18 1035 When a link failure between S1 and s2 occurred in network domain 1, 1036 PNC1 will restore the tunnel and send the alarm or tunnel update 1037 notification to the MDSC, MDSC will update the restored tunnel. 1039 Restored transport entity: S3, S4, S8, S2 1040 S31, S33, S34, 1041 S15, S18 1043 When a link failure between network domain 1 and network domain 2 1044 occurred, PNC1 and PNC2 will send the alarm notification to the 1045 MDSC, MDSC will update the restored tunnel. 1047 Restored transport entity: S3, S4, S8, 1048 S12, S15, S18 1050 In order to improve the efficiency of recovery, the controller can 1051 establish a recovery path in a concurrent way. When the recovery 1052 fails in one domain or one network element, the rollback operation 1053 should be supported. 1055 The creation of the recovery path by the controller can use the 1056 method of "make-before-break", in order to reduce the impact of the 1057 recovery operation on the services. 1059 4.6. Service Modification and Deletion 1061 To be discussed in future versions of this document. 1063 4.7. Notification 1065 To realize the topology update, service update and restoration 1066 function, following notification type should be supported. 1068 1. Object create 1070 2. Object delete 1072 3. Object state change 1074 4. Alarm 1076 Because there are three types of topology abstraction type defined 1077 in section 4.2, the notification should also be abstracted. The PNC 1078 and MDSC should coordinate together to determine the notification 1079 policy, such as when an intra-domain alarm occurred, the PNC may not 1080 report the alarm but the service state change notification to the 1081 MDSC. 1083 4.8. Path Computation with Constraint 1085 It is possible to have constraint during path computation procedure, 1086 typical cases include IRO/XRO and so on. This information is carried 1087 in the TE Tunnel model and used when there is a request with 1088 constraint. Consider the example in section 4.3.1. , the request can 1089 be a Tunnel from R1 to R5 with an IRO from S2 to S31, then a 1090 qualified feedback would become: 1092 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1093 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 1094 S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) 1096 If the request covers the IRO from S8 to S12, then the above path 1097 would not be qualified, while a possible computation result may be: 1099 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1100 S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> 1101 [PKT]) 1103 Similarly, the XRO can be represented by TE tunnel model as well. 1105 When there is a technology specific network (e.g, OTN), the 1106 corresponding technology (OTN) model should also be used to specify 1107 the tunnel information on MPI, with the constraint included in TE 1108 Tunnel model. 1110 5. YANG Model Analysis 1112 This section provides a high-level overview of how IETF YANG models 1113 can be used at the MPIs, between the MDSC and the PNCs, to support 1114 the scenarios described in section 4. 1116 Section 5.1 describes the different topology abstractions provided 1117 to the MDSC by each PNC via its own MPI. 1119 Section 5.2 describes how the MDSC can coordinate different requests 1120 to different PNCs, via their own MPIs, to setup the different 1121 services described in section 4.3. 1123 Section 5.3 describes how the protection scenarios can be deployed, 1124 including end-to-end protection and segment protection, for both 1125 intra-domain and inter-domain scenario. 1127 5.1. YANG Models for Topology Abstraction 1129 Each PNC reports its respective abstract topology to the MDSC, as 1130 described in section 4.2. 1132 5.1.1. Domain 1 Topology Abstraction 1134 PNC1 provides the required topology abstraction to expose at its MPI 1135 toward the MDSC (called "MPI1") one TE Topology instance for the ODU 1136 layer (called "MPI1 ODU Topology"), containing one TE Node (called 1137 "ODU Node") for each physical node, as shown in Figure 3 below. 1139 .................................. 1140 : : 1141 : ODU Abstract Topology @ MPI : 1142 : Gotham City Area : 1143 : Metro Transport Network : 1144 : : 1145 : +----+ +----+ : 1146 : | |S1-1 | |S2-1: 1147 : | S1 |--------| S2 |- - - - -(R4) 1148 : +----+ S2-2+----+ : 1149 : S1-2/ |S2-3 : 1150 : S3-2/ Robinson Park | : 1151 : +----+ +----+ | : 1152 : | |3 1| | | : 1153 (R1)- - - - -| S3 |---| S4 | | : 1154 :S3-1+----+ +----+ | : 1155 : S3-4 \ \S4-2 | : 1156 : \S5-1 \ | : 1157 : +----+ \ | : 1158 : | | \S8-3| : 1159 : | S5 | \ | : 1160 : +----+ Metro \ |S8-2 : 1161 (R2)- - - - - 2/ E \3 Main \ | : 1162 :S6-1 \ /3 a E \1 Ring \| : 1163 : +----+s-n+----+ +----+ : 1164 : | |t d| | | |S8-1: 1165 : | S6 |---| S7 |---| S8 |- - - - -(R5) 1166 : +----+4 2+----+3 4+----+ : 1167 : / : 1168 (R3)- - - - - : 1169 :S6-2 : 1170 :................................: 1172 Figure 3 Abstract Topology exposed at MPI1 (MPI1 ODU Topology) 1174 The ODU Nodes in Figure 3 are using the same names as the physical 1175 nodes to simplify the description of the mapping between the ODU 1176 Nodes exposed by the Transport PNCs at the MPI and the physical 1177 nodes in the data plane. This does not correspond to the reality of 1178 the usage of the topology model, as described in section 4.3 of [TE- 1179 TOPO], in which renaming by the client it is necessary. 1181 As described in section 4.1, it is assumed that the physical links 1182 between the physical nodes are pre-configured and therefore PNC1 1183 exports at MPI1 one TE Link (called "ODU Link") for each of these 1184 OTU4 trails. 1186 Appendix B.1.1 provides the detailed JSON code ("mpi1-otn- 1187 topology.json") describing how this ODU Topology is reported by the 1188 PNC, using the [TE-TOPO] and [OTN-TOPO] YANG models at MPI1. 1190 5.1.2. Domain 2 Grey (Type A) Topology Abstraction 1192 PNC2 provides the required topology abstraction to expose at its MPI 1193 towards the MDSC (called "MPI2") only one abstract node (i.e., AN2), 1194 with only inter-domain and access links, is reported at the MPI2. 1196 5.1.3. Domain 3 Grey (Type B) Topology Abstraction 1198 PNC3 provides the required topology abstraction to expose at its MPI 1199 towards the MDSC (called "MPI3") only two abstract nodes (i.e., AN31 1200 and AN32), with internal links, inter-domain links and access links. 1202 5.1.4. Multi-domain Topology Stitching 1204 As assumed in the beginning of this section, MDSC does not have any 1205 knowledge of the topologies of each domain until each PNC reports 1206 its own abstraction topology, so the MDSC needs to merge together 1207 the abstract topologies provided by different PNCs, at the MPIs, to 1208 build its own topology view, as described in section 4.3 of [TE- 1209 TOPO]. 1211 Given the topologies reported from multiple PNCs, the MDSC need to 1212 stitch the multi-domain topology and obtain the full map of 1213 topology. The topology of each domain main be in an abstracted shape 1214 (refer to section 5.2 of [ACTN-Fwk] for different level of 1215 abstraction), while the inter-domain link information MUST be 1216 complete and fully configured by the MDSC. 1218 The inter-domain link information is reported to the MDSC by the two 1219 PNCs, controlling the two ends of the inter-domain link. 1221 The MDSC needs to understand how to "stitch" together these inter- 1222 domain links. 1224 One possibility is to use the plug-id information, defined in [TE- 1225 TOPO]: two inter-domain links reporting the same plug-id value can 1226 be merged as a single intra-domain link within any MDSC native 1227 topology. The value of the reported plug-id information can be 1228 either assigned by a central network authority, and configured 1229 within the two PNC domains, or it can be discovered using automatic 1230 discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). 1232 In case the plug-id values are assigned by a central authority, it 1233 is under the central authority responsibility to assign unique 1234 values. 1236 In case the plug-id values are automatically discovered, the 1237 information discovered by the automatic discovery mechanisms needs 1238 to be encoded as a bit string within the plug-id value. This 1239 encoding is implementation specific but the encoding rules need to 1240 be consistent across all the PNCs. 1242 In case of co-existence within the same network of multiple sources 1243 for the plug-id (e.g., central authority and automatic discovery or 1244 even different automatic discovery mechanisms), it is RECOMMENDED 1245 that the plug-id namespace is partitioned to avoid that different 1246 sources assign the same plug-id value to different inter-domain 1247 link. The encoding of the plug-id namespace within the plug-id value 1248 is implementation specific but needs to be consistent across all the 1249 PNCs. 1251 Another possibility is to pre-configure, either in the adjacent PNCs 1252 or in the MDSC, the association between the inter-domain link 1253 identifiers (topology-id, node-id and tp-id) assigned by the two 1254 adjacent PNCs to the same inter-domain link. 1256 This last scenario requires further investigation and will be 1257 discussed in a future version of this document. 1259 5.1.5. Access Links 1261 Access links in Figure 3 are shown as ODU Links: the modeling of the 1262 access links for other access technologies is currently an open 1263 issue. 1265 The modeling of the access link in case of non-ODU access technology 1266 has also an impact on the need to model ODU TTPs and layer 1267 transition capabilities on the edge nodes (e.g., nodes S2, S3, S6 1268 and S8 in Figure 3). 1270 If, for example, the physical NE S6 is implemented in a "pizza box", 1271 the data plane would have only set of ODU termination resources 1272 (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and 1273 160xODUflex can be terminated). The traffic coming from each of the 1274 10GE access links can be mapped into any of these ODU terminations. 1276 Instead if, for example, the physical NE S6 can be implemented as a 1277 multi-board system where access links reside on different/dedicated 1278 access cards with separated set of ODU termination resources (where 1279 up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for 1280 each resource can be terminated). The traffic coming from one 10GE 1281 access links can be mapped only into the ODU terminations which 1282 reside on the same access card. 1284 The more generic implementation option for a physical NE (e.g., S6) 1285 would be case is of a multi-board system with multiple access cards 1286 with separated sets of access links and ODU termination resources 1287 (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 1288 80xODUflex for each resource can be terminated). The traffic coming 1289 from each of the 10GE access links on one access card can be mapped 1290 only into any of the ODU terminations which reside on the same 1291 access card. 1293 In the last two cases, only the ODUs terminated on the same access 1294 card where the access links resides can carry the traffic coming 1295 from that 10GE access link. Terminated ODUs can instead be sent to 1296 any of the OTU4 interfaces 1298 In all these cases, terminated ODUs can be sent to any of the OTU4 1299 interfaces assuming the implementation is based on a non-blocking 1300 ODU cross-connect. 1302 If the access links are reported via MPI in some, still to be 1303 defined, client topology, it is possible to report each set of ODU 1304 termination resources as an ODU TTP within the ODU Topology of 1305 Figure 3 and to use either the inter-layer lock-id or the 1306 transitional link, as described in sections 3.4 and 3.10 of [TE- 1307 TOPO], to correlate the access links, in the client topology, with 1308 the ODU TTPs, in the ODU topology, to which access link are 1309 connected to. 1311 5.2. YANG Models for Service Configuration 1313 The service configuration procedure is assumed to be initiated (step 1314 1 in Figure 4) at the CMI from CNC to MDSC. Analysis of the CMI 1315 models is (e.g., L1SM, L2SM, Transport-Service, VN, et al.) is 1316 outside the scope of this document. 1318 As described in section 4.3, it is assumed that the CMI YANG models 1319 provides all the information that allows the MDSC to understand that 1320 it needs to coordinate the setup of a multi-domain ODU connection 1321 (or connection segment) and, when needed, also the configuration of 1322 the adaptation functions in the edge nodes belonging to different 1323 domains. 1325 | 1326 | {1} 1327 V 1328 ---------------- 1329 | {2} | 1330 | {3} MDSC | 1331 | | 1332 ---------------- 1333 ^ ^ ^ 1334 {3.1} | | | 1335 +---------+ |{3.2} | 1336 | | +----------+ 1337 | V | 1338 | ---------- |{3.3} 1339 | | PNC2 | | 1340 | ---------- | 1341 | ^ | 1342 V | {4.2} | 1343 ---------- V | 1344 | PNC1 | ----- V 1345 ---------- (Network) ---------- 1346 ^ ( Domain 2) | PNC3 | 1347 | {4.1} ( _) ---------- 1348 V ( ) ^ 1349 ----- C==========D | {4.3} 1350 (Network) / ( ) \ V 1351 ( Domain 1) / ----- \ ----- 1352 ( )/ \ (Network) 1353 A===========B \ ( Domain 3) 1354 / ( ) \( ) 1355 AP-1 ( ) X===========Z 1356 ----- ( ) \ 1357 ( ) AP-2 1358 ----- 1360 Figure 4 Multi-domain Service Setup 1362 As an example, the objective in this section is to configure a 1363 transport service between R1 and R5. The cross-domain routing is 1364 assumed to be R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> 1365 S18 <-> R5. 1367 According to the different client signal type, there is different 1368 adaptation required. 1370 After receiving such request, MDSC determines the domain sequence, 1371 i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs 1372 and inter-domain links (step 2 in Figure 4). 1374 As described in [PATH-COMPUTE], the domain sequence can be 1375 determined by running the MDSC own path computation on the MDSC 1376 internal topology, defined in section 5.1.4, if and only if the MDSC 1377 has enough topology information. Otherwise the MDSC can send path 1378 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 1379 in Figure 4) and use this information to determine the optimal path 1380 on its internal topology and therefore the domain sequence. 1382 The MDSC will then decompose the tunnel request into a few tunnel 1383 segments via tunnel model (including both TE tunnel model and OTN 1384 tunnel model), and request different PNCs to setup each intra-domain 1385 tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 4). 1387 Assume that each intra-domain tunnel segment can be set up 1388 successfully, and each PNC response to the MDSC respectively. Based 1389 on each segment, MDSC will take care of the configuration of both 1390 the intra-domain tunnel segment and inter-domain tunnel via 1391 corresponding MPI (via TE tunnel model and OTN tunnel model). More 1392 specifically, for the inter-domain configuration, the ts-bitmap and 1393 tpn attributes need to be configured using the OTN Tunnel model 1394 [xxx]. Then the end-to-end OTN tunnel will be ready. 1396 In any case, the access link configuration is done only on the PNCs 1397 that control the access links (e.g., PNC-1 and PNC-3 in our example) 1398 and not on the PNCs of transit domain (e.g., PNC-2 in our example). 1399 Access link will be configured by MDSC after the OTN tunnel is set 1400 up. Access configuration is different and dependent on the different 1401 type of service. More details can be found in the following 1402 sections. 1404 5.2.1. ODU Transit Service 1406 In this scenario, described in section 4.3.1, the access links are 1407 configured as ODU Links. 1409 Since it is assumed that the physical access links are pre- 1410 configured, each PNC exposes, at its MPI, one TE Link (called "ODU 1411 Link") for each of these physical access link. These links are 1412 reported, together with any other ODU internal or inter-domain link, 1413 within the OTN abstract topology exposed by each PNC, at its own 1414 MPI. 1416 To setup this IP link, between R1 and R5, the CNC requests, at the 1417 CMI, the MDSC to setup an ODU transit service. 1419 From the topology information described in section 5.1 above, the 1420 MDSC understands that R1 is attached to the access link terminating 1421 on S3-1 LTP in the ODU Topology exposed by PNC1 and that R5 is 1422 attached to the access link terminating on AN2-1 LTP in the ODU 1423 Topology exposed by PNC2. 1425 MDSC would then request, at MPI1, the PNC1 to setup an ODU2 (Transit 1426 Segment) Tunnel with one primary path between S3-1 and S2-1 LTPs: 1428 o Source and Destination TTPs are not specified (since it is a 1429 Transit Tunnel) 1431 o Ingress and egress points are indicated in the route-object- 1432 include-exclude list of the explicit-route-objects of the primary 1433 path: 1435 o The first element references the access link terminating on 1436 S3-1 LTP 1438 o The last two element references respectively the inter-domain 1439 link terminating on S2-1 LTP and the data plane resources 1440 (i.e., the timeslots and the TPN, called "OTN Label") used by 1441 the ODU2 connection over that link. 1443 The configuration of the timeslots used by the ODU2 connection on 1444 the internal links within a PNC domain (i.e., on the internal links 1445 domain) is outside the scope of this document since it is a matter 1446 of the PNC domain internal implementation. 1448 However, the configuration of the timeslots used by the ODU2 1449 connection at the transport network domain boundaries (e.g., on the 1450 inter-domain links) needs to take into account the timeslots 1451 available on physical nodes belonging to different PNC domains 1452 (e.g., on node S2 within PNC1 domain and on node S31 within PNC3 1453 domain). 1455 The MDSC, when coordinating the setup of a multi-domain ODU 1456 connection, also configures the data plane resources (i.e., the 1457 timeslots and the TPN) to be used on the inter-domain links. The 1458 MDSC can know the timeslots which are available on the physical OTN 1459 nodes terminating the inter-domain links (e.g., S2 and S31) from the 1460 OTN Topology information exposed, at the MPIs, by the PNCs 1461 controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling 1462 respectively the physical nodes S2 and S31). 1464 Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- 1465 config.json") describing how the setup of this ODU2 (Transit 1466 Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL] 1467 and [OTN-TUNNEL] YANG models at MPI1. 1469 The Transport PNC performs path computation and sets up the ODU2 1470 cross-connections within the physical nodes S3, S5 and S6, as shown 1471 in section 4.3.1. 1473 5.2.1.1. Single Domain Example 1475 To setup an ODU2 end-to-end connection, supporting an IP link, 1476 between R1 and R3, the CNC requests, at the CMI, the MDSC to setup 1477 an ODU transit service. 1479 The Transport PNC reports the status of the created ODU2 (Transit 1480 Segment) Tunnel and its path within the ODU Topology as shown in 1481 Figure 5 below: 1483 .................................. 1484 : : 1485 : ODU Abstract Topology @ MPI : 1486 : : 1487 : +----+ +----+ : 1488 : | | | | : 1489 : | S1 |--------| S2 |- - - - -(R4) 1490 : +----+ +----+ : 1491 : / | : 1492 : / | : 1493 : +----+ +----+ | : 1494 : | | | | | : 1495 (R1)- - - - - S3 |---| S4 | | : 1496 :S3-1 <<= + +----+ | : 1497 : = \ | : 1498 : = \ \ | : 1499 : == ---+ \ | : 1500 : = | \ | : 1501 : = S5 | \ | : 1502 : == --+ \ | : 1503 (R2)- - - - - = \ \ | : 1504 :S6-1 \ / = \ \ | : 1505 : +--- = +----+ +----+ : 1506 : | = | | | | : 1507 : | S6 = --| S7 |---| S8 |- - - - -(R5) 1508 : +--- = +----+ +----+ : 1509 : / = : 1510 (R3)- - - - - <<== : 1511 :S6-2 : 1512 :................................: 1514 Figure 5 ODU2 Transit Tunnel 1516 5.2.2. EPL over ODU Service 1518 In this scenario, described in section 4.3.2, the access links are 1519 configured as Ethernet Links. 1521 To setup this IP link, between R1 and R5, the CNC requests, at the 1522 CMI, the MDSC to setup an EPL service. 1524 As described in section 5.1.5 above, it is not clear in this case 1525 how the Ethernet access links between the transport network and the 1526 IP router, are reported by the PNC to the MDSC. 1528 If the 10GE physical links are not reported as ODU links within the 1529 ODU topology information, described in section 5.1.1 above, than the 1530 MDSC will not have sufficient information to know that R1 and R5 are 1531 attached to the access links terminating on S3 and S6. 1533 Assuming that the MDSC knows how R1 and R3 are attached to the 1534 transport network, the MDSC would request the Transport PNC to setup 1535 an ODU2 end-to-end Tunnel between S3 and S6. 1537 This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In 1538 case nodes S3 and S6 support more than one TTP, the MDSC should 1539 decide which TTP to use. 1541 As discussed in 5.1.5, depending on the different hardware 1542 implementations of the physical nodes S3 and S6, not all the access 1543 links can be connected to all the TTPs. The MDSC should therefore 1544 not only select the optimal TTP but also a TTP that would allow the 1545 Tunnel to be used by the service. 1547 It is assumed that in case node S3 or node S6 supports only one TTP, 1548 this TTP can be accessed by all the access links. 1550 Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- 1551 config.json") describing how the setup of this ODU2 (Head Segment) 1552 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- 1553 TUNNEL] YANG models at MPI1. 1555 Once the ODU2 Tunnel setup has been requested, unless there is a 1556 one-to-one relationship between the S3 and S6 TTPs and the Ethernet 1557 access links toward R1 and R3 (as in the case, described in section 1558 5.1.5, where the Ethernet access links reside on different/dedicated 1559 access card such that the ODU2 tunnel can only carry the Ethernet 1560 traffic from the only Ethernet access link on the same access card 1561 where the ODU2 tunnel is terminated), the MDSC also needs to request 1562 the setup of an EPL service from the access links on S3 and S6, 1563 attached to R1 and R3, and this ODU2 Tunnel. 1565 Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service- 1566 config.json") describing how the setup of this EPL service using the 1567 ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SVC] 1568 YANG model at MPI1. 1570 5.2.3. Other OTN Client Services 1572 In this scenario, the access links are configured as one of the OTN 1573 clients (e.g., STM-64) links. 1575 As described in section 4.3.3, the CNC needs to setup an STM-64 1576 Private Link service, supporting an IP link, between R1 and R3 and 1577 requests this service at the CMI to the MDSC. 1579 MDSC needs to setup an STM-64 Private Link service between R1 and R3 1580 supported by an ODU2 end-to-end connection between S3 and S6. 1582 As described in section 5.1.5 above, it is not clear in this case 1583 how the access links (e.g., the STM-N access links) between the 1584 transport network and the IP router, are reported by the PNC to the 1585 MDSC. 1587 The same issues, as described in section 5.2.2, apply here: 1589 o the MDSC needs to understand that R1 and R3 are connected, 1590 thought STM-64 access links, with S3 and S6 1592 o the MDSC needs to understand which TTPs in S3 and S6 can be 1593 accessed by these access links 1595 o the MDSC needs to configure the private line service from these 1596 access links through the ODU2 tunnel 1598 5.2.4. EVPL over ODU Service 1600 In this scenario, the access links are configured as Ethernet links, 1601 as described in section 5.2.2 above. 1603 As described in section 4.3.4, the CNC needs to setup EVPL services, 1604 supporting IP links, between R1 and R3, as well as between R1 and R4 1605 and requests these services at the CMI to the MDSC. 1607 MDSC needs to setup two EVPL services, between R1 and R3, as well as 1608 between R1 and R4, supported by ODU0 end-to-end connections between 1609 S3 and S6 and between S3 and S2 respectively. 1611 As described in section 5.1.5 above, it is not clear in this case 1612 how the Ethernet access links between the transport network and the 1613 IP router, are reported by the PNC to the MDSC. 1615 The same issues, as described in section 5.1.5 above, apply here: 1617 o the MDSC needs to understand that R1, R3 and R4 are connected, 1618 thought the Ethernet access links, with S3, S6 and S2 1620 o the MDSC needs to understand which TTPs in S3, S6 and S2 can be 1621 accessed by these access links 1623 o the MDSC needs to configure the EVPL services from these access 1624 links through the ODU0 tunnels 1626 In addition, the MDSC needs to get the information that the access 1627 links on S3, S6 and S2 are capable to support EVPL (rather than just 1628 EPL) as well as to coordinate the VLAN configuration, for each EVPL 1629 service, on these access links (this is a similar issue as the 1630 timeslot configuration on access links discussed in section 4.3.1 1631 above). 1633 5.3. YANG Models for Protection Configuration 1635 5.3.1. Linear Protection (end-to-end) 1637 To be discussed in future versions of this document. 1639 5.3.2. Segmented Protection 1641 To be discussed in future versions of this document. 1643 6. Security Considerations 1645 This section is for further study 1647 7. IANA Considerations 1649 This document requires no IANA actions. 1651 8. References 1653 8.1. Normative References 1655 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1656 Information Exchange between Interconnected Traffic- 1657 Engineered Networks", BCP 206, RFC 7926, July 2016. 1659 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 1660 Restoration) Terminology for Generalized Multi-Protocol 1661 Label Switching (GMPLS)", RFC 4427, March 2006. 1663 [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for 1664 Abstraction and Control of Transport Networks", draft- 1665 ietf-teas-actn-framework, work in progress. 1667 [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for 1668 the optical transport network", June 2016. 1670 [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic 1671 protection switching - Linear trail and subnetwork 1672 protection", May 2014. 1674 [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical 1675 transport network (OTN): Linear protection", May 2014. 1677 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 1678 draft-ietf-teas-yang-te-topo, work in progress. 1680 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 1681 Transport Network Topology", draft-ietf-ccamp-otn-topo- 1682 yang, work in progress. 1684 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 1685 Topology", draft-zheng-ccamp-client-topo-yang, work in 1686 progress. 1688 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 1689 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1690 te, work in progress. 1692 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 1693 requesting Path Computation", draft-busibel-teas-yang- 1694 path-computation, work in progress. 1696 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- 1697 ietf-ccamp-otn-tunnel-model, work in progress. 1699 [CLIENT-SVC] Zheng, H. et al., "A YANG Data Model for Optical 1700 Transport Network Client Signals", draft-zheng-ccamp-otn- 1701 client-signal-yang, work in progress. 1703 8.2. Informative References 1705 [RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic 1706 Engineering --Resource Reservation Protocol-Traffic 1707 Engineering (RSVP-TE) Extensions", RFC 5151, February 1708 2008. 1710 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 1711 Negotiation and Configuration Modifications", RFC 6898, 1712 March 2013. 1714 [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, 1715 January 2018. 1717 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 1718 Abstraction and Control of Traffic Engineered Networks", 1719 draft-zhang-teas-actn-yang, work in progress. 1721 [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", 1722 draft-ietf-i2rs-yang-network-topo, work in progress. 1724 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 1725 Requirements for Transport API", June 2016. 1727 [ONF GitHub] ONF Open Transport (SNOWMASS) 1728 https://github.com/OpenNetworkingFoundation/Snowmass- 1729 ONFOpenTransport 1731 9. Acknowledgments 1733 The authors would like to thank all members of the Transport NBI 1734 Design Team involved in the definition of use cases, gap analysis 1735 and guidelines for using the IETF YANG models at the Northbound 1736 Interface (NBI) of a Transport SDN Controller. 1738 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 1739 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 1740 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 1741 the work on gap analysis for transport NBI and having provided 1742 foundations work for the development of this document. 1744 The authors would like to thank the authors of the TE Topology and 1745 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor 1746 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 1747 support in addressing any gap identified during the analysis work. 1749 This document was prepared using 2-Word-v2.0.template.dot. 1751 Appendix A Validating a JSON fragment against a YANG Model 1753 The objective is to have a tool that allows validating whether a 1754 piece of JSON code embedded in an Internet-Draft is compliant with a 1755 YANG model without using a client/server. 1757 A.1. Manipulation of JSON fragments 1759 This section describes the various ways JSON fragments are used in 1760 the I-D processing and how to manage them. 1762 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 1763 72 chars width and it is acceptable for it to be invalid JSON. 1765 We then define "unfolded-JSON" a valid JSON fragment having the same 1766 contents of the "folded-JSON " without folding, i.e. limits on the 1767 text width. The folding/unfolding operation may be done according to 1768 draft-kwatsen-netmod-artwork-folding. The "unfolded-JSON" can be 1769 edited by the authors using JSON editors with the advantages of 1770 syntax validation and pretty-printing. 1772 Both the "folded" and the "unfolded" JSON fragments can include 1773 comments having descriptive fields and directives we'll describe 1774 later to facilitate the reader and enable some automatic processing. 1776 The presence of comments in the "unfolded-JSON" fragment makes it an 1777 invalid JSON encoding of YANG data. Therefore we call "naked JSON" 1778 the JSON where the comments have been stripped out: not only it is 1779 valid JSON but it is a valid JSON encoding of YANG data. 1781 The following schema resumes these definitions: 1783 unfold_it --> stripper --> 1785 Folded-JSON Unfolded-JSON Naked JSON 1787 <-- fold_it <-- author edits 1789 <=72-chars? MUST MAY MAY 1791 valid JSON? MAY MUST MUST 1793 JSON-encoding MAY MAY MUST 1795 of YANG data 1796 Our validation toolchain has been designed to take a JSON in any of 1797 the three formats and validate it automatically against a set of 1798 relevant YANG modules using available open-source tools. It can be 1799 found at: https://github.com/GianmarcoBruno/json-yang/ 1801 A.2. Comments in JSON fragments 1803 We found useful to introduce two kinds of comments, both defined as 1804 key-value pairs where the key starts with "//": 1806 - free-form descriptive comments, e.g."// COMMENT" : "refine this" 1807 to describe properties of JSON fragments. 1809 - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : { 1810 "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to 1811 automatically download from the network the relevant I-Ds or RFCs 1812 and extract from them the YANG models of interest. This is 1813 particularly useful to keep consistency when the drafting work is 1814 rapidly evolving. 1816 A.3. Validation of JSON fragments: DSDL-based approach 1818 The idea is to generate a JSON driver file (JTOX) from YANG, then 1819 use it to translate JSON to XML and validate it against the DSDL 1820 schemas, as shown in Figure 6. 1822 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 1824 (2) 1825 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 1826 | | 1827 | (1) | 1828 | | 1829 Config/state JTOX-file | (4) 1830 \ | | 1831 \ | | 1832 \ V V 1833 JSON-file------------> XML-file ----------------> Output 1834 (3) 1836 Figure 6 - DSDL-based approach for JSON code validation 1838 In order to allow the use of comments following the convention 1839 defined in section 3without impacting the validation process, these 1840 comments will be automatically removed from the JSON-file that will 1841 be validate. 1843 A.4. Validation of JSON fragments: why not using a XSD-based approach 1845 This approach has been analyzed and discarded because no longer 1846 supported by pyang. 1848 The idea is to convert YANG to XSD, JSON to XML and validate it 1849 against the XSD, as shown in Figure 7: 1851 (1) 1852 YANG-module ---> XSD-schema - \ (3) 1853 +--> Validation 1854 JSON-file------> XML-file ----/ 1855 (2) 1857 Figure 7 - XSD-based approach for JSON code validation 1859 The pyang support for the XSD output format was deprecated in 1.5 1860 and removed in 1.7.1. However pyang 1.7.1 is necessary to work with 1861 YANG 1.1 so the process shown in Figure 7 will stop just at step 1862 (1). 1864 Appendix B Detailed JSON Examples 1866 B.1. JSON Examples for Topology Abstractions 1868 B.1.1. JSON Code: mpi1-otn-topology.json 1870 { 1871 "// __TITLE__": "ODU Abstract Topology @ MPI1", 1872 "// __LAST_UPDATE__": "July 2, 2018", 1873 "// __RESTCONF_OPERATION__": { 1874 "operation": "GET", 1875 "url": 1876 "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks" 1877 }, 1878 "// __REFERENCE_DRAFTS__": { 1879 "ietf-network@2017-12-18": 1880 "draft-ietf-i2rs-yang-network-topo-20", 1881 "ietf-network-topology@2017-12-18": 1882 "draft-ietf-i2rs-yang-network-topo-20", 1883 "ietf-te-topology@2018-02-21": 1884 "draft-ietf-teas-yang-te-topo-15", 1885 "ietf-te-types@2018-02-19": "draft-ietf-teas-yang-te-12", 1886 "ietf-routing-types@2017-12-04": "rfc8294", 1887 "ietf-otn-topology@2017-10-30": 1888 "draft-ietf-ccamp-otn-topo-yang-02", 1889 "ietf-otn-types@2017-10-30": 1890 "draft-ietf-ccamp-otn-tunnel-model-01" 1891 }, 1892 "// __MISSING_ATTRIBUTES__": true, 1893 "ietf-network:networks": { 1894 "network": [ 1895 { 1896 "network-id": "tnbi", 1897 "network-types": { 1898 "ietf-te-topology:te-topology": { 1899 "ietf-otn-topology:otn-topology": {} 1900 } 1901 }, 1902 "// __DISCUSS__ ietf-te-topology:provider-id": null, 1903 "ietf-te-topology:provider-id": 0, 1904 "// __DISCUSS__ ietf-te-topology:client-id": 0, 1905 "ietf-te-topology:client-id": 0, 1906 "// __DISCUSS__ ietf-te-topology:te-topology-id": null, 1907 "ietf-te-topology:te-topology-id": "tnbi", 1908 "// comment": [ 1909 "te container presence requires: ", 1910 " provider-id, client-id and te-topology-id" 1911 ], 1912 "ietf-te-topology:te": { 1913 "name": "gotham-city:metro-transport-network" 1914 }, 1915 "ietf-network:node": [ 1916 { 1917 "// __NODE__:__DESCRIPTION__": [ 1918 "S3", 1919 "10.0.0.3", 1920 "ADM" 1921 ], 1922 "node-id": "10.0.0.3", 1923 "ietf-te-topology:te-node-id": "10.0.0.3", 1924 "ietf-te-topology:te": { 1925 "oper-status": "up", 1926 "te-node-attributes": { 1927 "// comment-on-name": [ 1928 "Often transport domains contain subdomain ", 1929 "topological partitioning that may be reported ", 1930 "in node te name " 1931 ], 1932 "name": "S3-metro_main_ring-gateway", 1933 "admin-status": "up", 1934 "// __DISCUSS__ domain-id": 65001 1935 }, 1936 "// __DISCUSS__ tunnel-termination-point": [] 1937 }, 1938 "ietf-network-topology:termination-point": [ 1939 { 1940 "// __DESCRIPTION__:__LTP__": [ 1941 "S3-1 LTP", 1942 "connected to (C-R1)", 1943 "unnumberd/ifIndex: 1", 1944 "OTU-2", 1945 "tributary port" 1946 ], 1947 "tp-id": "1", 1948 "ietf-te-topology:te-tp-id": 1, 1949 "ietf-te-topology:te": { 1950 "// _OBSOLETE_ ietf-otn-topology:client-facing": [ 1951 null 1952 ], 1953 "admin-status": "up", 1954 "oper-status": "up", 1955 "// ietf-otn-topology:supported-payload-types": 1956 "__DISCUSS__", 1957 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 1958 "ietf-transport-types:prot-OTU2", 1959 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 1960 "ODU" 1961 } 1962 }, 1963 { 1964 "// __DESCRIPTION__:__LTP__": [ 1965 "S3-2 LTP", 1966 "connected to S1-2", 1967 "unnumberd/ifIndex: 2", 1968 "OTU-4", 1969 "line port" 1970 ], 1971 "tp-id": "2", 1972 "ietf-te-topology:te-tp-id": 2, 1973 "ietf-te-topology:te": { 1974 "admin-status": "up", 1975 "oper-status": "up", 1976 "// ietf-otn-topology:supported-payload-types": 1977 "__DISCUSS__", 1978 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 1979 "ietf-transport-types:prot-OTU4", 1980 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 1981 "ODU" 1982 } 1983 }, 1984 { 1985 "// __DESCRIPTION__:__LTP__": [ 1986 "S3-3 LTP", 1987 "connected to S4-1", 1988 "unnumberd/ifIndex: 3", 1989 "OTU-4", 1990 "line port" 1991 ], 1992 "tp-id": "3", 1993 "ietf-te-topology:te-tp-id": 3, 1994 "ietf-te-topology:te": { 1995 "admin-status": "up", 1996 "oper-status": "up", 1997 "// ietf-otn-topology:supported-payload-types": 1998 "__DISCUSS__", 2000 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2001 "ietf-transport-types:prot-OTU4", 2002 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2003 "ODU" 2004 } 2005 }, 2006 { 2007 "// __DESCRIPTION__:__LTP__": [ 2008 "S3-4 LTP", 2009 "connected to S5-1", 2010 "unnumberd/ifIndex: 4", 2011 "OTU-4", 2012 "line port" 2013 ], 2014 "tp-id": "4", 2015 "ietf-te-topology:te-tp-id": 4, 2016 "ietf-te-topology:te": { 2017 "admin-status": "up", 2018 "oper-status": "up", 2019 "// ietf-otn-topology:supported-payload-types": 2020 "__DISCUSS__", 2021 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2022 "ietf-transport-types:prot-OTU4", 2023 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2024 "ODU" 2025 } 2026 } 2027 ] 2028 }, 2029 { 2030 "// __NODE__:__DESCRIPTION__": [ 2031 "S4", 2032 "10.0.0.4", 2033 "pizza-box" 2034 ], 2035 "node-id": "10.0.0.4", 2036 "ietf-te-topology:te-node-id": "10.0.0.4", 2037 "ietf-te-topology:te": { 2038 "// comment": "TO BE COMPLETED", 2039 "oper-status": "up", 2040 "te-node-attributes": { 2041 "name": "S4-line-metro_main_ring", 2042 "admin-status": "up", 2043 "// __DISCUSS__ domain-id": 65001 2044 }, 2045 "// __DISCUSS__ tunnel-termination-point": [] 2046 }, 2047 "ietf-network-topology:termination-point": [ 2048 { 2049 "// __DESCRIPTION__:__LTP__": [ 2050 "S4-1 LTP", 2051 "connected to S3-3", 2052 "unnumberd/ifIndex: 1", 2053 "OTU-4", 2054 "line port" 2055 ], 2056 "// comment": "S4-1 LTP", 2057 "tp-id": "1", 2058 "ietf-te-topology:te-tp-id": 1, 2059 "ietf-te-topology:te": { 2060 "admin-status": "up", 2061 "oper-status": "up", 2062 "// ietf-otn-topology:supported-payload-types": 2063 "__DISCUSS__", 2064 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2065 "ietf-transport-types:prot-OTU4", 2066 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2067 "ODU" 2068 } 2069 }, 2070 { 2071 "// __DESCRIPTION__:__LTP__": [ 2072 "S4-2 LTP", 2073 "connected to S8-3", 2074 "unnumberd/ifIndex: 2", 2075 "OTU-4", 2076 "line port" 2077 ], 2078 "// comment": "S4-2 LTP", 2079 "tp-id": "2", 2080 "ietf-te-topology:te-tp-id": 2, 2081 "ietf-te-topology:te": { 2082 "admin-status": "up", 2083 "oper-status": "up", 2084 "// ietf-otn-topology:supported-payload-types": 2085 "__DISCUSS__", 2086 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2087 "ietf-transport-types:prot-OTU4", 2088 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2089 "ODU" 2091 } 2092 } 2093 ] 2094 }, 2095 { 2096 "// __NODE__:__DESCRIPTION__": [ 2097 "S1", 2098 "10.0.0.1", 2099 "pizza-box" 2100 ], 2101 "node-id": "10.0.0.1", 2102 "ietf-te-topology:te-node-id": "10.0.0.1", 2103 "ietf-te-topology:te": { 2104 "// comment": "TO BE COMPLETED", 2105 "oper-status": "up", 2106 "te-node-attributes": { 2107 "name": "S1-robinson_park_ring-line", 2108 "admin-status": "up", 2109 "// __DISCUSS__ domain-id": 65001 2110 }, 2111 "// __DISCUSS__ tunnel-termination-point": [] 2112 }, 2113 "ietf-network-topology:termination-point": [ 2114 { 2115 "// __DESCRIPTION__:__LTP__": [ 2116 "S1-1 LTP", 2117 "connected to S2-2", 2118 "unnumberd/ifIndex: 1", 2119 "OTU-4", 2120 "line port" 2121 ], 2122 "// comment": "S1-1 LTP", 2123 "tp-id": "1", 2124 "ietf-te-topology:te-tp-id": 1, 2125 "ietf-te-topology:te": { 2126 "admin-status": "up", 2127 "oper-status": "up", 2128 "// ietf-otn-topology:supported-payload-types": 2129 "__DISCUSS__", 2130 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2131 "ietf-transport-types:prot-OTU4", 2132 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2133 "ODU" 2134 } 2135 }, 2136 { 2137 "// __DESCRIPTION__:__LTP__": [ 2138 "S1-2 LTP", 2139 "connected to S3-2", 2140 "unnumberd/ifIndex: 2", 2141 "OTU-4", 2142 "line port" 2143 ], 2144 "// comment": "S1-2 LTP", 2145 "tp-id": "2", 2146 "ietf-te-topology:te-tp-id": 2, 2147 "ietf-te-topology:te": { 2148 "admin-status": "up", 2149 "oper-status": "up", 2150 "// ietf-otn-topology:supported-payload-types": 2151 "__DISCUSS__", 2152 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2153 "ietf-transport-types:prot-OTU4", 2154 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2155 "ODU" 2156 } 2157 } 2158 ] 2159 }, 2160 { 2161 "// __NODE__:__DESCRIPTION__": [ 2162 "S2", 2163 "10.0.0.2", 2164 "ADM" 2165 ], 2166 "node-id": "10.0.0.2", 2167 "ietf-te-topology:te-node-id": "10.0.0.2", 2168 "ietf-te-topology:te": { 2169 "// comment": "TO BE COMPLETED", 2170 "oper-status": "up", 2171 "te-node-attributes": { 2172 "name": "S2-robinson_park_ring-access", 2173 "admin-status": "up", 2174 "// __DISCUSS__ domain-id": 65001 2175 }, 2176 "// __DISCUSS__ tunnel-termination-point": [] 2177 }, 2178 "ietf-network-topology:termination-point": [ 2179 { 2180 "// __DESCRIPTION__:__LTP__": [ 2181 "S2-1 LTP", 2182 "connected to (C-R4)", 2183 "unnumberd/ifIndex: 1", 2184 "OTU-2", 2185 "tributary port" 2186 ], 2187 "// comment": "S2-1 LTP", 2188 "tp-id": "1", 2189 "ietf-te-topology:te-tp-id": 1, 2190 "ietf-te-topology:te": { 2191 "// _OBSOLETE_ ietf-otn-topology:client-facing": [ 2192 null 2193 ], 2194 "admin-status": "up", 2195 "oper-status": "up", 2196 "// ietf-otn-topology:supported-payload-types": 2197 "__DISCUSS__", 2198 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2199 "ietf-transport-types:prot-OTU2", 2200 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2201 "ODU" 2202 } 2203 }, 2204 { 2205 "// __DESCRIPTION__:__LTP__": [ 2206 "S2-2 LTP", 2207 "connected to S1-1", 2208 "unnumberd/ifIndex: 2", 2209 "OTU-4", 2210 "line port" 2211 ], 2212 "// comment": "S2-2 LTP", 2213 "tp-id": "2", 2214 "ietf-te-topology:te-tp-id": 2, 2215 "ietf-te-topology:te": { 2216 "admin-status": "up", 2217 "oper-status": "up", 2218 "// ietf-otn-topology:supported-payload-types": 2219 "__DISCUSS__", 2220 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2221 "ietf-transport-types:prot-OTU4", 2222 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2223 "ODU" 2224 } 2225 }, 2226 { 2227 "// __DESCRIPTION__:__LTP__": [ 2228 "S2-3 LTP", 2229 "connected to S8-2", 2230 "unnumberd/ifIndex: 3", 2231 "OTU-4", 2232 "line port" 2233 ], 2234 "// comment": "S2-3 LTP", 2235 "tp-id": "3", 2236 "ietf-te-topology:te-tp-id": 3, 2237 "ietf-te-topology:te": { 2238 "admin-status": "up", 2239 "oper-status": "up", 2240 "// ietf-otn-topology:supported-payload-types": 2241 "__DISCUSS__", 2242 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2243 "ietf-transport-types:prot-OTU4", 2244 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2245 "ODU" 2246 } 2247 } 2248 ] 2249 }, 2250 { 2251 "// __NODE__:__DESCRIPTION__": [ 2252 "S7", 2253 "10.0.0.7", 2254 "ADM" 2255 ], 2256 "node-id": "10.0.0.7", 2257 "ietf-te-topology:te-node-id": "10.0.0.7", 2258 "ietf-te-topology:te": { 2259 "// comment": "TO BE COMPLETED", 2260 "oper-status": "up", 2261 "te-node-attributes": { 2262 "name": "S7-east_end_ring-gateway", 2263 "admin-status": "up", 2264 "// __DISCUSS__ domain-id": 65001 2265 }, 2266 "// __DISCUSS__ tunnel-termination-point": [] 2267 }, 2268 "ietf-network-topology:termination-point": [ 2269 { 2270 "// __DESCRIPTION__:__LTP__": [ 2271 "S7-1 LTP", 2272 "connected to S5-3", 2273 "unnumberd/ifIndex: 1", 2274 "OTU-4", 2275 "line port" 2276 ], 2277 "// comment": "S7-1 LTP", 2278 "tp-id": "1", 2279 "ietf-te-topology:te-tp-id": 1, 2280 "ietf-te-topology:te": { 2281 "admin-status": "up", 2282 "oper-status": "up", 2283 "// ietf-otn-topology:supported-payload-types": 2284 "__DISCUSS__", 2285 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2286 "ietf-transport-types:prot-OTU4", 2287 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2288 "ODU" 2289 } 2290 }, 2291 { 2292 "// __DESCRIPTION__:__LTP__": [ 2293 "S7-2 LTP", 2294 "connected to S6-4", 2295 "unnumberd/ifIndex: 2", 2296 "OTU-4", 2297 "line port" 2298 ], 2299 "// comment": "S7-2 LTP", 2300 "tp-id": "2", 2301 "ietf-te-topology:te-tp-id": 2, 2302 "ietf-te-topology:te": { 2303 "admin-status": "up", 2304 "oper-status": "up", 2305 "// ietf-otn-topology:supported-payload-types": 2306 "__DISCUSS__", 2307 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2308 "ietf-transport-types:prot-OTU4", 2309 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2310 "ODU" 2311 } 2312 }, 2313 { 2314 "// __DESCRIPTION__:__LTP__": [ 2315 "S7-3 LTP", 2316 "connected to S8-4", 2317 "unnumberd/ifIndex: 3", 2318 "OTU-4", 2319 "line port" 2320 ], 2321 "// comment": "S7-3 LTP", 2322 "tp-id": "3", 2323 "ietf-te-topology:te-tp-id": 3, 2324 "ietf-te-topology:te": { 2325 "admin-status": "up", 2326 "oper-status": "up", 2327 "// ietf-otn-topology:supported-payload-types": 2328 "__DISCUSS__", 2329 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2330 "ietf-transport-types:prot-OTU4", 2331 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2332 "ODU" 2333 } 2334 } 2335 ] 2336 }, 2337 { 2338 "// __NODE__:__DESCRIPTION__": [ 2339 "S8", 2340 "10.0.0.8", 2341 "ADM" 2342 ], 2343 "node-id": "10.0.0.8", 2344 "ietf-te-topology:te-node-id": "10.0.0.8", 2345 "ietf-te-topology:te": { 2346 "// comment": "TO BE COMPLETED", 2347 "oper-status": "up", 2348 "te-node-attributes": { 2349 "name": "S8-metro_main_ring-access", 2350 "admin-status": "up", 2351 "// __DISCUSS__ domain-id": 65001 2352 }, 2353 "// __DISCUSS__ tunnel-termination-point": [] 2354 }, 2355 "ietf-network-topology:termination-point": [ 2356 { 2357 "// __DESCRIPTION__:__LTP__": [ 2358 "S8-1 LTP", 2359 "connected to (C-R5)", 2360 "unnumberd/ifIndex: 1", 2361 "OTU-2", 2362 "tributary port" 2363 ], 2364 "// comment": "S8-1 LTP", 2365 "tp-id": "1", 2366 "ietf-te-topology:te-tp-id": 1, 2367 "ietf-te-topology:te": { 2368 "// _OBSOLETE_ ietf-otn-topology:client-facing": [ 2369 null 2370 ], 2371 "admin-status": "up", 2372 "oper-status": "up", 2373 "// ietf-otn-topology:supported-payload-types": 2374 "__DISCUSS__", 2375 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2376 "ietf-transport-types:prot-OTU2", 2377 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2378 "ODU" 2379 } 2380 }, 2381 { 2382 "// __DESCRIPTION__:__LTP__": [ 2383 "S8-2 LTP", 2384 "connected to S2-3", 2385 "unnumberd/ifIndex: 2", 2386 "OTU-4", 2387 "line port" 2388 ], 2389 "// comment": "S8-2 LTP", 2390 "tp-id": "2", 2391 "ietf-te-topology:te-tp-id": 2, 2392 "ietf-te-topology:te": { 2393 "admin-status": "up", 2394 "oper-status": "up", 2395 "// ietf-otn-topology:supported-payload-types": 2396 "__DISCUSS__", 2397 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2398 "ietf-transport-types:prot-OTU4", 2399 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2400 "ODU" 2401 } 2402 }, 2403 { 2404 "// __DESCRIPTION__:__LTP__": [ 2405 "S8-3 LTP", 2406 "connected to S4-2", 2407 "unnumberd/ifIndex: 3", 2408 "OTU-4", 2409 "line port" 2410 ], 2411 "// comment": "S8-3 LTP", 2412 "tp-id": "3", 2413 "ietf-te-topology:te-tp-id": 3, 2414 "ietf-te-topology:te": { 2415 "admin-status": "up", 2416 "oper-status": "up", 2417 "// ietf-otn-topology:supported-payload-types": 2418 "__DISCUSS__", 2419 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2420 "ietf-transport-types:prot-OTU4", 2421 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2422 "ODU" 2423 } 2424 }, 2425 { 2426 "// __DESCRIPTION__:__LTP__": [ 2427 "S8-4 LTP", 2428 "connected to S7-3", 2429 "unnumberd/ifIndex: 4", 2430 "OTU-4", 2431 "line port" 2432 ], 2433 "// comment": "S8-4 LTP", 2434 "tp-id": "4", 2435 "ietf-te-topology:te-tp-id": 4, 2436 "ietf-te-topology:te": { 2437 "admin-status": "up", 2438 "oper-status": "up", 2439 "// ietf-otn-topology:supported-payload-types": 2440 "__DISCUSS__", 2441 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2442 "ietf-transport-types:prot-OTU4", 2443 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2444 "ODU" 2445 } 2446 } 2447 ] 2448 }, 2449 { 2450 "// __NODE__:__DESCRIPTION__": [ 2451 "S5", 2452 "10.0.0.5", 2453 "ADM" 2454 ], 2455 "node-id": "10.0.0.5", 2456 "ietf-te-topology:te-node-id": "10.0.0.5", 2457 "ietf-te-topology:te": { 2458 "// comment": "TO BE COMPLETED", 2459 "oper-status": "up", 2460 "te-node-attributes": { 2461 "name": "S5-east_end_ring-gateway", 2462 "admin-status": "up", 2463 "// __DISCUSS__ domain-id": 65001 2464 }, 2465 "// __DISCUSS__ tunnel-termination-point": [] 2466 }, 2467 "ietf-network-topology:termination-point": [ 2468 { 2469 "// __DESCRIPTION__:__LTP__": [ 2470 "S5-1 LTP", 2471 "connected to S3-4", 2472 "unnumberd/ifIndex: 1", 2473 "OTU-4", 2474 "line port" 2475 ], 2476 "// comment": "S5-1 LTP", 2477 "tp-id": "1", 2478 "ietf-te-topology:te-tp-id": 1, 2479 "ietf-te-topology:te": { 2480 "admin-status": "up", 2481 "oper-status": "up", 2482 "// ietf-otn-topology:supported-payload-types": 2483 "__DISCUSS__", 2484 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2485 "ietf-transport-types:prot-OTU4", 2486 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2487 "ODU" 2488 } 2489 }, 2490 { 2491 "// __DESCRIPTION__:__LTP__": [ 2492 "S5-2 LTP", 2493 "connected to S6-3", 2494 "unnumberd/ifIndex: 2", 2495 "OTU-4", 2496 "line port" 2497 ], 2498 "// comment": "S5-2 LTP", 2499 "tp-id": "2", 2500 "ietf-te-topology:te-tp-id": 2, 2501 "ietf-te-topology:te": { 2502 "admin-status": "up", 2503 "oper-status": "up", 2504 "// ietf-otn-topology:supported-payload-types": 2505 "__DISCUSS__", 2506 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2507 "ietf-transport-types:prot-OTU4", 2508 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2509 "ODU" 2510 } 2511 }, 2512 { 2513 "// __DESCRIPTION__:__LTP__": [ 2514 "S5-3 LTP", 2515 "connected to S7-1", 2516 "unnumberd/ifIndex: 3", 2517 "OTU-4", 2518 "line port" 2519 ], 2520 "// comment": "S5-3 LTP", 2521 "tp-id": "3", 2522 "ietf-te-topology:te-tp-id": 3, 2523 "ietf-te-topology:te": { 2524 "admin-status": "up", 2525 "oper-status": "up", 2526 "// ietf-otn-topology:supported-payload-types": 2527 "__DISCUSS__", 2528 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2529 "ietf-transport-types:prot-OTU4", 2530 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2531 "ODU" 2532 } 2533 } 2534 ] 2535 }, 2536 { 2537 "// __NODE__:__DESCRIPTION__": [ 2538 "S6", 2539 "10.0.0.6", 2540 "ADM" 2542 ], 2543 "node-id": "10.0.0.6", 2544 "ietf-te-topology:te-node-id": "10.0.0.6", 2545 "ietf-te-topology:te": { 2546 "// comment": "TO BE COMPLETED", 2547 "oper-status": "up", 2548 "te-node-attributes": { 2549 "name": "S6-east_end_ring-access", 2550 "admin-status": "up", 2551 "// __DISCUSS__ domain-id": 65001 2552 }, 2553 "// __DISCUSS__ tunnel-termination-point": [] 2554 }, 2555 "ietf-network-topology:termination-point": [ 2556 { 2557 "// __DESCRIPTION__:__LTP__": [ 2558 "S6-1 LTP", 2559 "connected to (C-R2)", 2560 "unnumberd/ifIndex: 1", 2561 "OTU-2", 2562 "tributary port" 2563 ], 2564 "// comment": "S6-1 LTP", 2565 "tp-id": "1", 2566 "ietf-te-topology:te-tp-id": 1, 2567 "ietf-te-topology:te": { 2568 "admin-status": "up", 2569 "oper-status": "up", 2570 "// _OBSOLETE_ ietf-otn-topology:client-facing": [ 2571 null 2572 ], 2573 "// ietf-otn-topology:supported-payload-types": 2574 "__DISCUSS__", 2575 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2576 "ietf-transport-types:prot-OTU2", 2577 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2578 "ODU" 2579 } 2580 }, 2581 { 2582 "// __DESCRIPTION__:__LTP__": [ 2583 "S6-2 LTP", 2584 "connected to (C-R3)", 2585 "unnumberd/ifIndex: 2", 2586 "OTU-2", 2587 "tributary port" 2588 ], 2589 "// comment": "S6-2 LTP", 2590 "tp-id": "2", 2591 "ietf-te-topology:te-tp-id": 2, 2592 "ietf-te-topology:te": { 2593 "admin-status": "up", 2594 "oper-status": "up", 2595 "// _OBSOLETE_ ietf-otn-topology:client-facing": [ 2596 null 2597 ], 2598 "// ietf-otn-topology:supported-payload-types": 2599 "__DISCUSS__", 2600 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2601 "ietf-transport-types:prot-OTU2", 2602 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2603 "ODU" 2604 } 2605 }, 2606 { 2607 "// __DESCRIPTION__:__LTP__": [ 2608 "S6-3 LTP", 2609 "connected to S5-2", 2610 "unnumberd/ifIndex: 3", 2611 "OTU-4", 2612 "line port" 2613 ], 2614 "// comment": "S6-3 LTP", 2615 "tp-id": "3", 2616 "ietf-te-topology:te-tp-id": 3, 2617 "ietf-te-topology:te": { 2618 "admin-status": "up", 2619 "oper-status": "up", 2620 "// ietf-otn-topology:supported-payload-types": 2621 "__DISCUSS__", 2622 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2623 "ietf-transport-types:prot-OTU4", 2624 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2625 "ODU" 2626 } 2627 }, 2628 { 2629 "// __DESCRIPTION__:__LTP__": [ 2630 "S6-4 LTP", 2631 "connected to S7-2", 2632 "unnumberd/ifIndex: 4", 2633 "OTU-4", 2634 "line port" 2635 ], 2636 "// comment": "S6-4 LTP", 2637 "tp-id": "4", 2638 "ietf-te-topology:te-tp-id": 4, 2639 "ietf-te-topology:te": { 2640 "admin-status": "up", 2641 "oper-status": "up", 2642 "// ietf-otn-topology:supported-payload-types": 2643 "__DISCUSS__", 2644 "// _OBSOLETE_ ietf-otn-topology:protocol-type": 2645 "ietf-transport-types:prot-OTU4", 2646 "// _OBSOLETE_ ietf-otn-topology:adaptation-type": 2647 "ODU" 2648 } 2649 } 2650 ] 2651 } 2652 ], 2653 "// ietf-network-topology:link": 2654 "Access links to be added in a future update.", 2655 "ietf-network-topology:link": [ 2656 { 2657 "// __DESCRIPTION__:__LINK__": [ 2658 "Link from S1-2 to S3-2", 2659 "internal link" 2660 ], 2661 "// link-id": "S1, S1-2, S3, S3-2", 2662 "link-id": "10.0.0.1,2,10.0.0.3,2", 2663 "ietf-te-topology:te": { 2664 "oper-status": "up", 2665 "te-link-attributes": { 2666 "access-type": "point-to-point", 2667 "// comment": [ 2668 "external-domain container", 2669 "not present for internal links" 2670 ], 2671 "name": "Link between S1 and S3", 2672 "admin-status": "up", 2673 "interface-switching-capability": [ 2674 { 2675 "switching-capability": 2676 "ietf-te-types:switching-otn", 2678 "encoding": "ietf-te-types:lsp-encoding-oduk", 2679 "max-lsp-bandwidth": [ 2680 { 2681 "priority": 0, 2682 "te-bandwidth": { 2683 "// _OBSOLETE_ otn": [ 2684 "_WARNING_ : technology specific bandwidth definition", 2685 { 2686 "rate-type": "ietf-te-types:odu2", 2687 "counter": 1 2688 } 2689 ] 2690 } 2691 }, 2692 { 2693 "priority": 1, 2694 "te-bandwidth": { 2695 "// _OBSOLETE_ otn": [ 2696 "_WARNING_ : technology specific bandwidth definition", 2697 { 2698 "rate-type": "ietf-te-types:odu2", 2699 "counter": 1 2700 } 2701 ] 2702 } 2703 }, 2704 { 2705 "priority": 2, 2706 "te-bandwidth": { 2707 "// _OBSOLETE_ otn": [ 2708 "_WARNING_ : technology specific bandwidth definition", 2709 { 2710 "rate-type": "ietf-te-types:odu2", 2711 "counter": 1 2712 } 2713 ] 2714 } 2715 }, 2716 { 2717 "priority": 3, 2718 "te-bandwidth": { 2719 "// _OBSOLETE_ otn": [ 2720 "_WARNING_ : technology specific bandwidth definition", 2721 { 2722 "rate-type": "ietf-te-types:odu2", 2723 "counter": 1 2724 } 2725 ] 2726 } 2727 }, 2728 { 2729 "priority": 4, 2730 "te-bandwidth": { 2731 "// _OBSOLETE_ otn": [ 2732 "_WARNING_ : technology specific bandwidth definition", 2733 { 2734 "rate-type": "ietf-te-types:odu2", 2735 "counter": 1 2736 } 2737 ] 2738 } 2739 }, 2740 { 2741 "priority": 5, 2742 "te-bandwidth": { 2743 "// _OBSOLETE_ otn": [ 2744 "_WARNING_ : technology specific bandwidth definition", 2745 { 2746 "rate-type": "ietf-te-types:odu2", 2747 "counter": 1 2748 } 2749 ] 2750 } 2751 }, 2752 { 2753 "priority": 6, 2754 "te-bandwidth": { 2755 "// _OBSOLETE_ otn": [ 2756 "_WARNING_ : technology specific bandwidth definition", 2757 { 2758 "rate-type": "ietf-te-types:odu2", 2759 "counter": 1 2760 } 2761 ] 2762 } 2763 }, 2764 { 2765 "priority": 7, 2766 "te-bandwidth": { 2767 "// _OBSOLETE_ otn": [ 2769 "_WARNING_ : technology specific bandwidth definition", 2770 { 2771 "rate-type": "ietf-te-types:odu2", 2772 "counter": 1 2773 } 2774 ] 2775 } 2776 } 2777 ] 2778 } 2779 ] 2780 } 2781 } 2782 }, 2783 { 2784 "// __DESCRIPTION__:__LINK__": [ 2785 "Link from S5-2 to S6-3", 2786 "internal link" 2787 ], 2788 "// link-id": "S5, S5-2, S6, S6-3", 2789 "link-id": "10.0.0.5,2,10.0.0.6,3", 2790 "ietf-te-topology:te": { 2791 "oper-status": "up", 2792 "te-link-attributes": { 2793 "access-type": "point-to-point", 2794 "name": "Link between S5 and S6", 2795 "admin-status": "up" 2796 } 2797 } 2798 }, 2799 { 2800 "// __DESCRIPTION__:__LINK__": [ 2801 "Link from S3-3 to S4-1", 2802 "internal link" 2803 ], 2804 "// link-id": "S3, S3-3, S4, S4-1", 2805 "link-id": "10.0.0.3,3,10.0.0.4,1", 2806 "ietf-te-topology:te": { 2807 "oper-status": "up", 2808 "te-link-attributes": { 2809 "access-type": "point-to-point", 2810 "name": "Link between S3 and S4", 2811 "admin-status": "up" 2812 } 2813 } 2815 }, 2816 { 2817 "// __DESCRIPTION__:__LINK__": [ 2818 "Link from S5-3 to S7-1", 2819 "internal link" 2820 ], 2821 "// link-id": "S5, S5-3, S7, S7-1", 2822 "link-id": "10.0.0.5,3,10.0.0.7,1", 2823 "ietf-te-topology:te": { 2824 "oper-status": "up", 2825 "te-link-attributes": { 2826 "access-type": "point-to-point", 2827 "name": "Link between S5 and S7", 2828 "admin-status": "up" 2829 } 2830 } 2831 }, 2832 { 2833 "// __DESCRIPTION__:__LINK__": [ 2834 "Link from S3-4 to S5-1", 2835 "internal link" 2836 ], 2837 "// link-id": "S3, S3-4, S5, S5-1", 2838 "link-id": "10.0.0.3,4,10.0.0.5,1", 2839 "ietf-te-topology:te": { 2840 "oper-status": "up", 2841 "te-link-attributes": { 2842 "access-type": "point-to-point", 2843 "name": "Link between S3 and S5", 2844 "admin-status": "up" 2845 } 2846 } 2847 }, 2848 { 2849 "// __DESCRIPTION__:__LINK__": [ 2850 "Link from S4-2 to S8-3", 2851 "internal link" 2852 ], 2853 "// link-id": "S4, S4-2, S8, S8-3", 2854 "link-id": "10.0.0.4,2,10.0.0.8,3", 2855 "ietf-te-topology:te": { 2856 "oper-status": "up", 2857 "te-link-attributes": { 2858 "access-type": "point-to-point", 2859 "name": "Link between S4 and S8", 2860 "admin-status": "up" 2861 } 2862 } 2863 }, 2864 { 2865 "// __DESCRIPTION__:__LINK__": [ 2866 "Link from S2-3 to S8-2", 2867 "internal link" 2868 ], 2869 "// link-id": "S2, S2-3, S8, S8-2", 2870 "link-id": "10.0.0.2,3,10.0.0.8,2", 2871 "ietf-te-topology:te": { 2872 "oper-status": "up", 2873 "te-link-attributes": { 2874 "access-type": "point-to-point", 2875 "name": "Link between S2 and S8", 2876 "admin-status": "up" 2877 } 2878 } 2879 }, 2880 { 2881 "// __DESCRIPTION__:__LINK__": [ 2882 "Link from S8-2 to S2-3", 2883 "internal link" 2884 ], 2885 "// link-id": "S8, S8-2, S2, S2-3", 2886 "link-id": "10.0.0.8,2,10.0.0.2,3", 2887 "ietf-te-topology:te": { 2888 "oper-status": "up", 2889 "te-link-attributes": { 2890 "access-type": "point-to-point", 2891 "name": "Link between S8 and S2", 2892 "admin-status": "up" 2893 } 2894 } 2895 }, 2896 { 2897 "// __DESCRIPTION__:__LINK__": [ 2898 "Link from S3-2 to S1-2", 2899 "internal link" 2900 ], 2901 "// link-id": "S3, S3-2, S1, S1-2", 2902 "link-id": "10.0.0.3,2,10.0.0.1,2", 2903 "ietf-te-topology:te": { 2904 "oper-status": "up", 2905 "te-link-attributes": { 2906 "access-type": "point-to-point", 2907 "name": "Link between S3 and S1", 2908 "admin-status": "up" 2909 } 2910 } 2911 }, 2912 { 2913 "// __DESCRIPTION__:__LINK__": [ 2914 "Link from S7-1 to S5-3", 2915 "internal link" 2916 ], 2917 "// link-id": "S7, S7-1, S5, S5-3", 2918 "link-id": "10.0.0.7,1,10.0.0.5,3", 2919 "ietf-te-topology:te": { 2920 "oper-status": "up", 2921 "te-link-attributes": { 2922 "access-type": "point-to-point", 2923 "name": "Link between S7 and S5", 2924 "admin-status": "up" 2925 } 2926 } 2927 }, 2928 { 2929 "// __DESCRIPTION__:__LINK__": [ 2930 "Link from S8-3 to S4-2", 2931 "internal link" 2932 ], 2933 "// link-id": "S8, S8-3, S4, S4-2", 2934 "link-id": "10.0.0.8,3,10.0.0.4,2", 2935 "ietf-te-topology:te": { 2936 "oper-status": "up", 2937 "te-link-attributes": { 2938 "access-type": "point-to-point", 2939 "name": "Link between S8 and S4", 2940 "admin-status": "up" 2941 } 2942 } 2943 }, 2944 { 2945 "// __DESCRIPTION__:__LINK__": [ 2946 "Link from S5-1 to S3-4", 2947 "internal link" 2948 ], 2949 "// link-id": "S5, S5-1, S3, S3-4", 2950 "link-id": "10.0.0.5,1,10.0.0.3,4", 2951 "ietf-te-topology:te": { 2952 "oper-status": "up", 2953 "te-link-attributes": { 2954 "access-type": "point-to-point", 2955 "name": "Link between S5 and S3", 2956 "admin-status": "up" 2957 } 2958 } 2959 }, 2960 { 2961 "// __DESCRIPTION__:__LINK__": [ 2962 "Link from S2-2 to S1-1", 2963 "internal link" 2964 ], 2965 "// link-id": "S2, S2-2, S1, S1-1", 2966 "link-id": "10.0.0.2,2,10.0.0.1,1", 2967 "ietf-te-topology:te": { 2968 "oper-status": "up", 2969 "te-link-attributes": { 2970 "access-type": "point-to-point", 2971 "name": "Link between S2 and S1", 2972 "admin-status": "up" 2973 } 2974 } 2975 }, 2976 { 2977 "// __DESCRIPTION__:__LINK__": [ 2978 "Link from S7-2 to S6-4", 2979 "internal link" 2980 ], 2981 "// link-id": "S7, S7-2, S6, S6-4", 2982 "link-id": "10.0.0.7,2,10.0.0.6,4", 2983 "ietf-te-topology:te": { 2984 "oper-status": "up", 2985 "te-link-attributes": { 2986 "access-type": "point-to-point", 2987 "name": "Link between S7 and S6", 2988 "admin-status": "up" 2989 } 2990 } 2991 }, 2992 { 2993 "// __DESCRIPTION__:__LINK__": [ 2994 "Link from S8-4 to S7-3", 2995 "internal link" 2996 ], 2997 "// link-id": "S8, S8-4, S7, S7-3", 2998 "link-id": "10.0.0.8,4,10.0.0.7,3", 2999 "ietf-te-topology:te": { 3000 "oper-status": "up", 3001 "te-link-attributes": { 3002 "access-type": "point-to-point", 3003 "name": "Link between S8 and S7", 3004 "admin-status": "up" 3005 } 3006 } 3007 }, 3008 { 3009 "// __DESCRIPTION__:__LINK__": [ 3010 "Link from S6-3 to S5-2", 3011 "internal link" 3012 ], 3013 "// link-id": "S6, S6-3, S5, S5-2", 3014 "link-id": "10.0.0.6,3,10.0.0.5,2", 3015 "ietf-te-topology:te": { 3016 "oper-status": "up", 3017 "te-link-attributes": { 3018 "access-type": "point-to-point", 3019 "name": "Link between S6 and S5", 3020 "admin-status": "up" 3021 } 3022 } 3023 }, 3024 { 3025 "// __DESCRIPTION__:__LINK__": [ 3026 "Link from S4-1 to S3-3", 3027 "internal link" 3028 ], 3029 "// link-id": "S4, S4-1, S3, S3-3", 3030 "link-id": "10.0.0.4,1,10.0.0.3,3", 3031 "ietf-te-topology:te": { 3032 "oper-status": "up", 3033 "te-link-attributes": { 3034 "access-type": "point-to-point", 3035 "name": "Link between S4 and S3", 3036 "admin-status": "up" 3037 } 3038 } 3039 }, 3040 { 3041 "// __DESCRIPTION__:__LINK__": [ 3042 "Link from S6-4 to S7-2", 3043 "internal link" 3044 ], 3045 "// link-id": "S6, S6-4, S7, S7-2", 3046 "link-id": "10.0.0.6,4,10.0.0.7,2", 3047 "ietf-te-topology:te": { 3048 "oper-status": "up", 3049 "te-link-attributes": { 3050 "access-type": "point-to-point", 3051 "name": "Link between S6 and S7", 3052 "admin-status": "up" 3053 } 3054 } 3055 }, 3056 { 3057 "// __DESCRIPTION__:__LINK__": [ 3058 "Link from S1-1 to S2-2", 3059 "internal link" 3060 ], 3061 "// link-id": "S1, S1-1, S2, S2-2", 3062 "link-id": "10.0.0.1,1,10.0.0.2,2", 3063 "ietf-te-topology:te": { 3064 "oper-status": "up", 3065 "te-link-attributes": { 3066 "access-type": "point-to-point", 3067 "name": "Link between S1 and S2", 3068 "admin-status": "up" 3069 } 3070 } 3071 }, 3072 { 3073 "// __DESCRIPTION__:__LINK__": [ 3074 "Link from S7-3 to S8-4", 3075 "internal link" 3076 ], 3077 "// link-id": "S7, S7-3, S8, S8-4", 3078 "link-id": "10.0.0.7,3,10.0.0.8,4", 3079 "ietf-te-topology:te": { 3080 "oper-status": "up", 3081 "te-link-attributes": { 3082 "access-type": "point-to-point", 3083 "name": "Link between S7 and S8", 3084 "admin-status": "up" 3086 } 3087 } 3088 } 3089 ] 3090 } 3091 ] 3092 } 3093 } 3095 B.2. JSON Examples for Service Configuration 3097 B.2.1. JSON Code: mpi1-odu2-service-config.json 3099 { 3100 "// __TITLE__": "ODU2 Service Configuration @ MPI1", 3101 "// __LAST_UPDATE__": "July 2, 2018", 3102 "// __RESTCONF_OPERATION__": { 3103 "operation": "PUT", 3104 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" 3105 }, 3106 "// __REFERENCE_DRAFTS__": { 3107 "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", 3108 "ietf-routing-types@2017-12-04": "rfc8294", 3109 "ietf-te@2018-06-12": "draft-ietf-teas-yang-te-15", 3110 "ietf-otn-types@2018-06-07": 3111 "draft-ietf-ccamp-otn-tunnel-model-02", 3112 "ietf-otn-tunnel@2018-06-07": 3113 "draft-ietf-ccamp-otn-tunnel-model-02" 3114 }, 3115 "// __MISSING_ATTRIBUTES__": true, 3116 "ietf-te:te": { 3117 "tunnels": { 3118 "tunnel": [ 3119 { 3120 "name": "mpi1-odu2-service", 3121 "// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", 3122 "identifier": 1, 3123 "description": 3124 "ODU2 Service implemented by ODU2 OTN Tunnel Segment @ MPI1", 3125 "// encoding and switching-type": "ODU", 3126 "encoding": "ietf-te-types:lsp-encoding-oduk ", 3127 "switching-type": "ietf-te-types:switching-otn", 3128 "// source": "None: transit tunnel segment", 3129 "// destination": "None: transit tunnel segment", 3130 "// src-tp-id": "None: transit tunnel segment", 3131 "// dst-tp-id": "None: transit tunnel segment", 3132 "// __ ACTION __ ietf-otn-tunnel:payload-treatment": [ 3133 "This attribute should be removed in the next otn-tunnel", 3134 " model update" 3135 ], 3136 "ietf-otn-tunnel:src-client-signal": 3137 "ietf-otn-types:client-signal-ODU2", 3138 "// __ ACTION __ src-tpn": [ 3139 "This attribute should be removed in the next otn-tunnel", 3140 " model update" 3141 ], 3142 "// __ ACTION __ src-tsg": [ 3143 "This attribute should be removed in the next otn-tunnel", 3144 " model update" 3145 ], 3146 "// __ ACTION __ src-tributary-slot-count": [ 3147 "This attribute should be removed in the next otn-tunnel", 3148 " model update" 3149 ], 3150 "// __ ACTION __ src-tributary-slots": [ 3151 "This attribute should be removed in the next otn-tunnel", 3152 " model update" 3153 ], 3154 "ietf-otn-tunnel:dst-client-signal": 3155 "ietf-otn-types:client-signal-ODU2", 3156 "// __ ACTION __ dst-tpn": [ 3157 "This attribute should be removed in the next otn-tunnel", 3158 " model update" 3159 ], 3160 "// __ ACTION __ dst-tsg": [ 3161 "This attribute should be removed in the next otn-tunnel", 3162 " model update" 3163 ], 3164 "// __ ACTION __ dst-tributary-slot-count": [ 3165 "This attribute should be removed in the next otn-tunnel", 3166 " model update" 3167 ], 3168 "// __ ACTION __ dst-tributary-slots": [ 3169 "This attribute should be removed in the next otn-tunnel", 3170 " model update" 3171 ], 3172 "bidirectional": true, 3173 "// __ DEFAULT __ protection": { 3174 "// __ DEFAULT __ enable": false 3175 }, 3176 "// __ DEFAULT __ restoration": { 3177 "// __ DEFAULT __ enable": false 3178 }, 3179 "// __ DISCUSS __ te-topology-identifier": [ 3180 "Need to add the te-topology-identifier", 3181 "information. Waiting for updates to topology identifiers" 3182 ], 3183 "te-bandwidth": { 3184 "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2" 3185 }, 3186 "// hierarchical-link": 3187 "Not to be specified: transit tunnel segment", 3188 "p2p-primary-paths": { 3189 "p2p-primary-path": [ 3190 { 3191 "name": "mpi1-odu2-tunnel-primary-path", 3192 "// __ DISCUSS __ path-scope": [ 3193 "Need to align the model based on the on-going", 3194 " disucssion of the related open issue" 3195 ], 3196 "path-scope": "ietf-te-types:path-scope-segment", 3197 "// te-bandwidth": [ 3198 "None: only the tunnel bandwidth needs to be specified", 3199 " in transport applications" 3200 ], 3201 "explicit-route-objects": { 3202 "route-object-include-exclude": [ 3203 { 3204 "// comment": 3205 "Tunnel hand-off OTU2 ingress interface (S3-1)", 3206 "index": 1, 3207 "explicit-route-usage": 3208 "ietf-te-types:route-include-ero", 3209 "num-unnum-hop": { 3210 "// node-id": "S3-NODE-ID", 3211 "node-id": "10.0.0.3", 3212 "// link-tp-id": "S3-1-LTP-ID", 3213 "link-tp-id": 1, 3214 "hop-type": "STRICT", 3215 "direction": "INCOMING" 3216 } 3217 }, 3218 { 3219 "// comment": [ 3220 "Tunnel hand-off ODU2 ingress label (ODU2 over", 3221 " OTU2) at S3-1" 3222 ], 3223 "index": 2, 3224 "explicit-route-usage": 3225 "ietf-te-types:route-include-ero", 3226 "label-hop": { 3227 "te-label": { 3228 "// __ DISCUSS __ odu-label": [ 3229 "How are HO-ODU (ODUk voer OTUk) label", 3230 " represented?" 3231 ], 3232 "// __ ACTION __ direction": 3233 "Check with TE Tunnel authors", 3234 "direction": "FORWARD " 3235 } 3236 } 3237 }, 3238 { 3239 "// comment": 3240 "Tunnel hand-off OTU4 egress interface (S2-1)", 3241 "index": 3, 3242 "explicit-route-usage": 3243 "ietf-te-types:route-include-ero", 3244 "num-unnum-hop": { 3245 "// node-id": "S2-NODE-ID", 3246 "node-id": "10.0.0.2", 3247 "// link-tp-id": "S2-1-LTP-ID", 3248 "link-tp-id": 1, 3249 "hop-type": "STRICT", 3250 "direction": "OUTGOING" 3251 } 3252 }, 3253 { 3254 "// comment": [ 3255 "Tunnel hand-off ODU2 egress label (ODU2 over", 3256 " OTU4) at S2-1" 3257 ], 3258 "index": 4, 3259 "explicit-route-usage": 3260 "ietf-te-types:route-include-ero", 3261 "label-hop": { 3262 "te-label": { 3263 "ietf-otn-tunnel:tpn": 1, 3264 "ietf-otn-tunnel:tsg": 3265 "ietf-otn-types:tsg-1.25G", 3267 "ietf-otn-tunnel:ts-list": "1-8", 3268 "// __ ACTION __ direction": 3269 "Check with TE Tunnel authors", 3270 "direction": "FORWARD " 3271 } 3272 } 3273 } 3274 ] 3275 } 3276 } 3277 ] 3278 } 3279 } 3280 ] 3281 } 3282 } 3283 } 3285 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json 3287 { 3288 "// __TITLE__": "ODU2 Tunnel Configuration @ MPI1", 3289 "// __LAST_UPDATE__": "July 2, 2018", 3290 "// __RESTCONF_OPERATION__": { 3291 "operation": "PUT", 3292 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" 3293 }, 3294 "// __REFERENCE_DRAFTS__": { 3295 "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", 3296 "ietf-routing-types@2017-12-04": "rfc8294", 3297 "ietf-te@2018-06-12": "draft-ietf-teas-yang-te-15", 3298 "ietf-otn-types@2018-06-07": 3299 "draft-ietf-ccamp-otn-tunnel-model-02", 3300 "ietf-otn-tunnel@2018-06-07": 3301 "draft-ietf-ccamp-otn-tunnel-model-02" 3302 }, 3303 "// __MISSING_ATTRIBUTES__": true, 3304 "ietf-te:te": { 3305 "tunnels": { 3306 "tunnel": [ 3307 { 3308 "name": "mpi1-odu2-tunnel", 3309 "// identifier": "ODU2-TUNNEL-ID @ MPI1", 3310 "identifier": 2, 3311 "description": 3313 "TNBI Example for an ODU2 Head Tunnel Segment @ MPI1", 3314 "// encoding and switching-type": "ODU", 3315 "encoding": "ietf-te-types:lsp-encoding-oduk ", 3316 "switching-type": "ietf-te-types:switching-otn", 3317 "source": "10.0.0.3", 3318 "// destination": "None: head tunnel segment", 3319 "src-tp-id": "AAAB", 3320 "// dst-tp-id": "None: head tunnel segment", 3321 "ietf-otn-tunnel:src-client-signal": 3322 "ietf-otn-types:client-signal-ODU2", 3323 "ietf-otn-tunnel:dst-client-signal": 3324 "ietf-otn-types:client-signal-ODU2", 3325 "bidirectional": true, 3326 "// __ DEFAULT __ protection": { 3327 "// __ DEFAULT __ enable": false 3328 }, 3329 "// __ DEFAULT __ restoration": { 3330 "// __ DEFAULT __ enable": false 3331 }, 3332 "// __ DISCUSS __ te-topology-identifier": 3333 "Need to add the te-topology-identifier information", 3334 "te-bandwidth": { 3335 "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2" 3336 }, 3337 "// __ DISCUSS __ hierarchical-link": 3338 "Optional: tunnel supports service, not link in the client layer", 3339 "p2p-primary-paths": { 3340 "p2p-primary-path": [ 3341 { 3342 "name": "mpi1-odu2-tunnel-primary-path", 3343 "// __ DISCUSS __ path-scope": 3344 "Need to align the model", 3345 "path-scope": "ietf-te-types:path-scope-segment", 3346 "// te-bandwidth": 3347 "None: only the tunnel bandwidth needed in transport", 3348 "explicit-route-objects": { 3349 "route-object-include-exclude": [ 3350 { 3351 "// comment": "Tunnel TTP in node S3", 3352 "index": 1, 3353 "explicit-route-usage": 3354 "ietf-te-types:route-include-ero", 3355 "num-unnum-hop": { 3356 "// node-id": "S3-NODE-ID", 3357 "node-id": "10.0.0.3", 3358 "hop-type": "STRICT", 3359 "// __ ACTION __ direction": 3360 "Check with TE Tunnel authors", 3361 "direction": "OUTGOING" 3362 } 3363 }, 3364 { 3365 "// comment": 3366 "Tunnel hand-off OTU4 egress interface (S2-1)", 3367 "index": 2, 3368 "explicit-route-usage": 3369 "ietf-te-types:route-include-ero", 3370 "num-unnum-hop": { 3371 "// node-id": "S2-NODE-ID", 3372 "node-id": "10.0.0.2", 3373 "// link-tp-id": "S2-1-LTP-ID", 3374 "link-tp-id": 1, 3375 "hop-type": "STRICT", 3376 "direction": "OUTGOING" 3377 } 3378 }, 3379 { 3380 "// comment": 3381 "Tunnel hand-off ODU2 egress label (ODU2 over OTU4) at S2-1", 3382 "index": 3, 3383 "explicit-route-usage": 3384 "ietf-te-types:route-include-ero", 3385 "label-hop": { 3386 "te-label": { 3387 "ietf-otn-tunnel:tpn": 2, 3388 "ietf-otn-tunnel:tsg": 3389 "ietf-otn-types:tsg-1.25G", 3390 "ietf-otn-tunnel:ts-list": "9-16", 3391 "// __ ACTION __ direction": 3392 "Check with TE Tunnel authors", 3393 "direction": "FORWARD " 3394 } 3395 } 3396 } 3397 ] 3398 } 3399 } 3400 ] 3401 } 3402 } 3404 ] 3405 } 3406 } 3407 } 3409 B.2.3. JSON Code: mpi1-epl-service-config.json 3411 { 3412 "// __TITLE__": "EPL Configuration @ MPI1", 3413 "// __LAST_UPDATE__": "July 2, 2018", 3414 "// __RESTCONF_OPERATION__": { 3415 "operation": "PUT", 3416 "url": 3417 "http://{{PNC1}}/restconf/data/ietf-trans-client-service:etht-svc" 3418 }, 3419 "// __REFERENCE_DRAFTS__": { 3420 "ietf-te-types@2018-03-05": "draft-ietf-teas-yang-te-14", 3421 "ietf-eth-tran-types@2018-03-01": 3422 "draft-zheng-ccamp-otn-client-signal-yang-02", 3423 "ietf-routing-types@2017-12-04": "rfc8294", 3424 "ietf-eth-tran-service@2018-03-01": 3425 "draft-zheng-ccamp-otn-client-signal-yang-02" 3426 }, 3427 "// __MISSING_ATTRIBUTES__": true, 3428 "ietf-eth-tran-service:etht-svc": { 3429 "etht-svc-instances": [ 3430 { 3431 "etht-svc-name": "mpi1-epl-service", 3432 "etht-svc-descr": 3433 "TNBI Example for an EPL over ODU2 Service @ MPI1", 3434 "// __ DEFAULT __ etht-svc-type": "p2p-svc", 3435 "// __ DISCUSS __ te-topology-identifier": [ 3436 "Would it be possible to use this grouping instead of", 3437 " re-defining the three attributes below?" 3438 ], 3439 "// __ ACTION __ access-provider-id": 3440 "Need to add the te-topology-identifier information", 3441 "// __ ACTION __ access-client-id": 3442 "Need to add the te-topology-identifier information", 3443 "// __ ACTION __ topology-id": 3444 "Need to add the te-topology-identifier information", 3445 "etht-svc-access-ports": [ 3446 { 3447 "// comment": "10GE access interface (S3-1)", 3448 "access-port-id": 1, 3449 "// access-node-id": "S3-NODE-ID", 3450 "access-node-id": "10.0.0.3", 3451 "// access-ltp-id": "S3-1-LTP-ID", 3452 "access-ltp-id": 1, 3453 "service-classification-type": 3454 "ietf-eth-tran-types:port-classification", 3455 "// __ DISCUSS __ ingress-egress-bandwidth-profile-name": 3456 "10G-EPL-BWP", 3457 "// vlan-operations": 3458 "None: transparent VLAN operations" 3459 } 3460 ], 3461 "etht-svc-tunnels": [ 3462 { 3463 "tunnel-name": "mpi1-odu2-tunnel" 3464 } 3465 ], 3466 "admin-status": "ietf-te-types:tunnel-state-up" 3467 } 3468 ] 3469 } 3470 } 3471 Authors' Addresses 3473 Italo Busi (Editor) 3474 Huawei 3476 Email: italo.busi@huawei.com 3478 Daniel King (Editor) 3479 Lancaster University 3481 Email: d.king@lancaster.ac.uk 3483 Haomian Zheng (Editor) 3484 Huawei 3486 Email: zhenghaomian@huawei.com 3488 Yunbin Xu (Editor) 3489 CAICT 3491 Email: xuyunbin@ritt.cn 3493 Yang Zhao 3494 China Mobile 3496 Email: zhaoyangyjy@chinamobile.com 3498 Sergio Belotti 3499 Nokia 3501 Email: sergio.belotti@nokia.com 3503 Gianmarco Bruno 3504 Ericsson 3506 Email: gianmarco.bruno@ericsson.com 3507 Young Lee 3508 Huawei 3510 Email: leeyoung@huawei.com 3512 Victor Lopez 3513 Telefonica 3515 Email: victor.lopezalvarez@telefonica.com 3517 Carlo Perocchio 3518 Ericsson 3520 Email: carlo.perocchio@ericsson.com 3522 Ricard Vilalta 3523 CTTC 3525 Email: ricard.vilalta@cttc.es