idnits 2.17.1 draft-tnbidt-ccamp-transport-nbi-analysis-uc3-00.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 225: '...link information MUST be complete and ...' RFC 2119 keyword, line 253: '...scovery mechanisms), it is RECOMMENDED...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TNBI-Usecases' is mentioned on line 270, but not defined == Unused Reference: 'I2RS-TOPO' is defined on line 448, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Haomian Zheng 2 Internet Draft Italo Busi 3 Intended status: Informational Huawei 4 Yunbin Xu 5 CAICT 6 Ricard Vilalta 7 CTTC 9 Expires: April 2018 October 30, 2017 11 Analysis of Transport North Bound Interface Use Case 3 12 draft-tnbidt-ccamp-transport-nbi-analysis-uc3-00 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on April 30, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Abstract 54 This document analyses how YANG models being defined by IETF (TEAS 55 and CCAMP WG in particular) can be used to support Use Case 3 (multi- 56 domain with single-layer) scenarios as referenced later in this 57 document. 59 Table of Contents 61 1. Introduction...................................................3 62 1.1. Assumptions...............................................3 63 1.2. Feedbacks provided to the IETF Working Groups.............3 64 2. Conventions used in this document..............................3 65 3. Scenario Overview..............................................3 66 3.1. Topology Abstractions.....................................4 67 3.1.1. Single Domain Topology...............................5 68 3.1.2. Multi-domain Topology Stitching......................6 69 3.2. Multi-domain Service Configuration........................7 70 3.2.1. Procedure Description................................7 71 3.2.2. ODU Transit Service..................................9 72 3.2.3. EPL over ODU Service.................................9 73 3.2.4. Other OTN Client Services............................9 74 3.3. Protection Scenarios......................................9 75 3.3.1. Linear Protection (end-to-end).......................9 76 3.3.2. Segmented Protection.................................9 77 4. Topology Abstraction: detailed JSON examples..................10 78 5. Service Configuration: detailed JSON examples.................10 79 5.1. ODU Transit Service......................................10 80 6. Security Considerations.......................................10 81 7. IANA Considerations...........................................10 82 8. Conclusions...................................................10 83 9. References....................................................10 84 9.1. Normative References.....................................10 85 9.2. Informative References...................................11 86 10. Acknowledgments..............................................11 88 1. Introduction 90 This document analyses how YANG models developed by IETF (TEAS and 91 CCAMP WG) can be used to support Use Case 3 (multi-domain with 92 single-layer) scenarios as described in [TNBI-UseCases]. 94 1.1. Assumptions 96 This document is using the ACTN [ACTN-Fwk] as an architecture that 97 deploys the IETF models. The motivation of this draft is to analyze 98 how existing IETF models can be used on the MPI between the PNC and 99 the MDSC to support the use case 3 scenarios as defined in section 6 100 of [TNBI-UseCases]. 102 This document assumes the applicability of the YANG models to the 103 ACTN interfaces as defined in [ACTN-YANG] and therefore considers the 104 TE Topology YANG model defined in [TE-TOPO], with the OTN Topology 105 augmentation defined in [OTN-TOPO] and the TE Tunnel YANG model 106 defined in [TE-TUNNEL], with the OTN Tunnel augmentation defined in 107 [OTN-TUNNEL]. 109 In this document, the assumptions made in section 1 of [TNBI-UseCase- 110 1] still apply. In summary, it is assumed that 1) MDSC uses the 111 explicit-route-object list on MPI to specify the ingress/egress links 112 for a tunnel segment request, and 2) label and TS availability 113 information are reported from PNC to MDSC. 115 1.2. Feedbacks provided to the IETF Working Groups 117 The analysis done in this version of this document has triggered the 118 following feedbacks to TEAS WG: 120 o Updates to the plug-id definition in [TE-TOPO] to support plug-id 121 also when auto-discovery (e.g., LMP based) mechanisms are used on 122 inter-domain links 124 2. Conventions used in this document 126 The conventions defined in section 2 of [TNBI-UseCase-1] still apply 127 in this document. 129 3. Scenario Overview 131 Use Case 3 is described in [TNBI-Use Cases] as a multi-domain with 132 single layer network scenario supporting different types of services. 133 This section provides a high-level overview of how IETF YANG models 134 can be used to support these uses cases at the MPI between the 135 Transport PNC and the MDSC. 137 Section 3.1 describes the different topology abstractions provided to 138 the MDSC by each PNC via its own MPI. The reference network and 139 controlling hierarchy is defined in section 6.1 of [TNBI-Use Cases]. 141 Section 3.2 describes how the difference services, defined in section 142 6.3 of [TNBI-UseCases], can be setup by the MDSC by coordinating 143 requests to each PNC via their own MPIs. 145 Section 3.3 describes how the protection scenarios can be deployed, 146 including end-to-end protection and segment protection, for both 147 intra-domain and inter-domain scenario. 149 3.1. Topology Abstractions 151 The reference network is shown in Figure 1, which is the same as 152 Figure 3 of [TNBI-UseCases]: 154 ........................ 155 .......... : : 156 : : : Network domain 1 : ............. 157 :Customer: : : : : 158 :domain 1: : S1 -------+ : : Network : 159 : : : / \ : : domain 3 : .......... 160 : C-R1 ------- S3 ----- S4 \ : : : : : 161 : : : \ \ S2 --------+ : :Customer: 162 : : : \ \ | : : \ : :domain 3: 163 : : : S5 \ | : : \ : : : 164 : C-R2 ------+ / \ \ | : : S31 --------- C-R7 : 165 : : : \ / \ \ | : : / \ : : : 166 : : : S6 ---- S7 ---- S8 ------ S32 S33 ------ C-R8 : 167 : : : / | | : : / \ / : :........: 168 : C-R3 ------+ | | : :/ S34 : 169 : : :..........|.......|...: / / : 170 :........: | | /:.../.......: 171 | | / / 172 ...........|.......|..../..../... 173 : | | / / : .......... 174 : Network | | / / : : : 175 : domain 2 | | / / : :Customer: 176 : S11 ---- S12 / : :domain 2: 177 : / | \ / : : : 178 : S13 S14 | S15 ------------- C-R4 : 179 : | \ / \ | \ : : : 180 : | S16 \ | \ : : : 181 : | / S17 -- S18 --------- C-R5 : 182 : | / \ / : : : 183 : S19 ---- S20 ---- S21 ------------ C-R6 : 184 : : : : 185 :...............................: :........: 187 Figure 1 Reference Topology 189 The network is portioned in three domains with inter-domain links 190 connecting the domains with each other. The controlling hierarchy is 191 shown in Figure 3 of [TNBI-UseCases]: the three PNCs are responsible 192 for the topology abstraction and device configuration for their 193 respective domains, and the MDSC is used to coordinate the 3 domains. 195 3.1.1. Single Domain Topology 197 Each PNC reports its respective topology to the MDSC with different 198 abstraction method, as described in section 6.2 of [TNBI-UseCases]. 200 The physical topology of domain 1 and the topology abstraction (i.e., 201 white topology abstraction) provided by PNC1 are the same as those 202 described in section 3.1.1 of [TNBI-UseCase-1] for the single domain 203 topology abstraction use case. 205 PNC2 provides a "type A grey topology abstraction": only one abstract 206 node (i.e., AN2), with only inter-domain and access links, is 207 reported at the MPI2. 209 PNC3 provides a "type B grey topology abstraction": two abstract 210 nodes (i.e., AN31 and AN32), with internal links, inter-domain links 211 and access links, are reported at the MPI3. 213 3.1.2. Multi-domain Topology Stitching 215 As assumed in the beginning of this section, MDSC does not have any 216 knowledge of the topologies of each domain until each PNC reports its 217 own abstraction topology, so the MDSC needs to merge together the 218 abstract topologies provided by different PNCs, at the MPIs, to build 219 its own topology view, as described in section 4.3 of [TE-TOPO]. 221 Given the topologies reported from multiple PNCs, the MDSC need to 222 stitch the multi-domain topology and obtain the full map of topology. 223 The topology of each domain main be in an abstracted shape (refer to 224 section 5.2 of [ACTN-Fwk]for different level of abstraction), while 225 the inter-domain link information MUST be complete and fully 226 configured by the MDSC. 228 The inter-domain link information is reported to the MDSC by the two 229 PNCs, controlling the two ends of the inter-domain link. 231 The MDSC needs to understand how to "stitch" together these inter- 232 domain links. 234 One possibility is to use the plug-id information, defined in [TE- 235 TOPO]: two inter-domain links reporting the same plug-id value can be 236 merged as a single intra-domain link within any MDSC native topology. 237 The value of the reported plug-id information can be either assigned 238 by a central network authority, and configured within the two PNC 239 domains, or it can be discovered using automatic discovery mechanisms 240 (e.g., LMP-based, as defined in [RFC6898]). 242 In case the plug-id values are assigned by a central authority, it is 243 under the central authority responsibility to assign unique values. 245 In case the plug-id values are automatically discovered, the 246 information discovered by the automatic discovery mechanisms needs to 247 be encoded as a bit string within the plug-id value. This encoding is 248 implementation specific but the encoding rules need to be consistent 249 across all the PNCs. 251 In case of co-existence within the same network of multiple sources 252 for the plug-id (e.g., central authority and automatic discovery or 253 even different automatic discovery mechanisms), it is RECOMMENDED 254 that the plug-id namespace is partitioned to avoid that different 255 sources assign the same plug-id value to different inter-domain link. 256 The encoding of the plug-id namespace within the plug-id value is 257 implementation specific but needs to be consistent across all the 258 PNCs. 260 Another possibility is to pre-configure, either in the adjacent PNCs 261 or in the MDSC, the association between the inter-domain link 262 identifiers (topology-id, node-id and tp-id) assigned by the two 263 adjacent PNCs to the same inter-domain link. 265 This option requires further investigation. 267 3.2. Multi-domain Service Configuration 269 Multi-domain service configuration can be found in section 6.3 of 270 [TNBI-Usecases]. 272 As an example, the objective in this section is to configure a 273 transport service between C-R1 and C-R5. The cross-domain routing is 274 assumed to be C-R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> 275 S18 <-> C-R5. 277 According to the different client signal type, there is different 278 adaptation required. In this document, we are trying our best to 279 reuse what has been defined in [TNBI-UseCase-1], which is the single 280 domain case. 282 3.2.1. Procedure Description 284 The service configuration procedure is assumed to be initiated (step 285 1 in Figure 2) at the CMI from CNC to MDSC, using XXX(LxSM, 286 transport-service, VN, TBD) service models. The MDSC will understand 287 this configure as as a request to setup a service from node A to node 288 Z. Analysis of the CMI models is for further study. 290 | 291 | {1} 292 V 293 ---------------- 294 | {2} | 295 | {3} MDSC | 296 | | 297 ---------------- 298 ^ ^ ^ 299 {3.1} | | | 300 +---------+ |{3.2} | 301 | | +----------+ 302 | V | 303 | ---------- |{3.3} 304 | | PNC2 | | 305 | ---------- | 306 | ^ | 307 V | {4.2} | 308 ---------- V | 309 | PNC1 | ----- V 310 ---------- (Network) ---------- 311 ^ ( Domain 2) | PNC3 | 312 | {4.1} ( _) ---------- 313 V ( ) ^ 314 ----- C==========D | {4.3} 315 (Network) / ( ) \ V 316 ( Domain 1) / ----- \ ----- 317 ( )/ \ (Network) 318 A===========B \ ( Domain 3) 319 / ( ) \( ) 320 AP-1 ( ) X===========Z 321 ----- ( ) \ 322 ( ) AP-2 323 ----- 325 Figure 2 Multi-domain Service Setup 327 After receiving such request, MDSC determines the domain sequence, 328 i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and 329 inter-domain links (step 1 in Figure 2). 331 As described in [PATH-COMPUTE], the domain sequence can be determined 332 by running the MDSC own path computation on the MDSC internal 333 topology, defined in section 3.1.2, if and only if the MDSC has 334 enough topology information. Otherwise the MDSC can send path 335 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in 336 Figure 2) and use this information to determine the optimal path on 337 its internal topology and therefore the domain sequence. 339 The MDSC will then decompose the tunnel request into a few tunnel 340 segments via tunnel model (including both TE tunnel model and OTN 341 tunnel model), and request different PNCs to setup each intra-domain 342 tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 2). 344 Assume that each intra-domain tunnel segment can be set up 345 successfully, and each PNC response to the MDSC respectively. Based 346 on each segment, MDSC will take care of the configuration of both the 347 intra-domain tunnel segment and inter-domain tunnel via corresponding 348 MPI (via TE tunnel model and OTN tunnel model). More specifically, 349 for the inter-domain configuration, the ts bitmap and tpn information 350 need to be configured via OTN tunnel model. . Then the end-to-end OTN 351 tunnel will be ready. 353 In any case, the access link configuration is done only on the PNCs 354 that control the access links (e.g., PNC-1 and PNC-3 in our example) 355 and not on the PNCs of transit domain (e.g., PNC-2 in our example). 356 Access link will be configured by MDSC after the OTN tunnel is set 357 up. Access configuration is different and dependent on the different 358 type of service. More details can be found in the following sections. 360 3.2.2. ODU Transit Service 362 To be added 364 3.2.3. EPL over ODU Service 366 To be added 368 3.2.4. Other OTN Client Services 370 To be added 372 3.3. Protection Scenarios 374 3.3.1. Linear Protection (end-to-end) 376 To be added 378 3.3.2. Segmented Protection 380 To be added 382 4. Topology Abstraction: detailed JSON examples 384 To be added 386 5. Service Configuration: detailed JSON examples 388 5.1. ODU Transit Service 390 To be added 392 6. Security Considerations 394 This section is for further study 396 7. IANA Considerations 398 This document requires no IANA actions. 400 8. Conclusions 402 This section is for further study 404 9. References 406 9.1. Normative References 408 [ACTN-Fwk] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 409 and Control of Transport Networks", draft-ietf-teas-actn- 410 framework, work in progress. 412 [TNBI-UseCases] Busi, I., King, D. et al, "Transport Northbound 413 Interface Use Cases", draft-ietf-ccamp-transport-nbi-use- 414 cases, work in progress. 416 [TNBI-UseCase-1] Busi, I., King, D. et al, "Analysis of Transport 417 North Bound Interface Use Case 1", draft-tnbidt-ccamp- 418 transport-nbi-analysis-uc1, work in progress. 420 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft- 421 ietf-teas-yang-te-topo, work in progress. 423 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport 424 Network Topology", draft-ietf-ccamp-otn-topo-yang, work in 425 progress. 427 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 428 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 429 te, work in progress. 431 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 432 requesting Path Computation", draft-busibel-teas-yang-path- 433 computation, work in progress. 435 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- 436 sharma-ccamp-otn-tunnel-model, work in progress. 438 9.2. Informative References 440 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 441 Negotiation and Configuration Modifications", RFC 6898, 442 March 2013. 444 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 445 Abstraction and Control of Traffic Engineered Networks", 446 draft-zhang-teas-actn-yang, work in progress. 448 [I2RS-TOPO] Clemm, A. et al., "A Data Model for Network Topologies", 449 draft-ietf-i2rs-yang-network-topo, work in progress. 451 10. Acknowledgments 453 The authors would like to thank all members of the Transport NBI 454 Design Team involved in the definition of use cases, gap analysis and 455 guidelines for using the IETF YANG models at the Northbound Interface 456 (NBI) of a Transport SDN Controller. 458 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 459 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 460 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 461 the work on gap analysis for transport NBI and having provided 462 foundations work for the development of this document. 464 The authors would like to thank the authors of the TE Topology and 465 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor 466 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 467 support in addressing any gap identified during the analysis work. 469 This document was prepared using 2-Word-v2.0.template.dot. 471 Authors' Addresses 472 Haomian Zheng (Editor) 473 Huawei 474 Email: zhenghaomian@huawei.com 476 Italo Busi 477 Huawei 478 Email: italo.busi@huawei.com 480 Yunbin Xu (Editor) 481 CAICT 482 Email: xuyunbin@ritt.cn mailto:d.king@lancaster.ac.uk 484 Ricard Vilalta 485 CTTC 486 Email: ricard.vilalta@cttc.es 488 Carlo Perocchio 489 Ericsson 490 Email: carlo.perocchio@ericsson.com 492 Gianmarco Bruno 493 Ericsson 494 Email: gianmarco.bruno@ericsson.com