idnits 2.17.1 draft-busi-teas-te-topology-profiles-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 318 has weird spacing: '...k-tp-id te-...' == Line 323 has weird spacing: '...k-tp-id te-...' -- The document date (12 July 2021) is 1017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-eth-client-te-topo-yang-00 == Outdated reference: A later version (-18) exists of draft-ietf-ccamp-otn-topo-yang-13 == Outdated reference: A later version (-27) exists of draft-ietf-teas-rfc3272bis-12 == Outdated reference: A later version (-18) exists of draft-ietf-teas-yang-sr-te-topo-10 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group I. Busi 3 Internet-Draft Huawei 4 Intended status: Informational X. Liu 5 Expires: 13 January 2022 Volta Networks 6 I. Bryskin 7 Individual 8 V. Beeram 9 T. Saad 10 Juniper Networks 11 O. Gonzalez de Dios 12 Telefonica 13 12 July 2021 15 Profiles for Traffic Engineering (TE) Topology Data Model 16 draft-busi-teas-te-topology-profiles-02 18 Abstract 20 This document describes how profiles of the Traffic Engineering (TE) 21 Topology Model, defined in RFC8795, can be used to address 22 applications beyond "Traffic Engineering". 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 January 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Examples of non-TE scenarios . . . . . . . . . . . . . . . . 3 59 2.1. UNI Topology Discovery . . . . . . . . . . . . . . . . . 3 60 2.2. Administrative and Operational status management . . . . 5 61 2.3. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.4. Overlay and Underlay non-TE Topologies . . . . . . . . . 7 63 2.5. Nodes with switching limitations . . . . . . . . . . . . 8 64 3. Technology-specific augmentations . . . . . . . . . . . . . . 9 65 3.1. Multi-inheritance . . . . . . . . . . . . . . . . . . . . 11 66 3.2. Example (Link augmentation) . . . . . . . . . . . . . . . 12 67 4. Implemented profiles . . . . . . . . . . . . . . . . . . . . 13 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 7.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 There are many network scenarios being discussed in various IETF 79 Working Groups (WGs) that are not classified as "Traffic Engineering" 80 but can be addressed by a sub-set (profile) of the Traffic 81 Engineering (TE) Topology YANG data model, defined in [RFC8795]. 83 Traffic Engineering (TE) is defined in [I-D.ietf-teas-rfc3272bis] as 84 aspects of Internet network engineering that deal with the issues of 85 performance evaluation and performance optimization of operational IP 86 networks. TE encompasses the application of technology and 87 scientific principles to the measurement, characterization, modeling, 88 and control of Internet traffic. 90 The TE Topology Model is augmenting the Network Topology Model 91 defined in [RFC8345] with generic and technology-agnostic features 92 that some are strictly applicable to TE networks, while others 93 applicable to both TE and non-TE networks. 95 Examples of such features that are applicable to both TE and non-TE 96 networks are: inter-domain link discovery (plug-id), geo- 97 localization, and admin/operational status. 99 It is also worth noting that the TE Topology Model is quite an 100 extensive and comprehensive model in which most features are 101 optional. Therefore, even though the full model appears to be 102 complex, at the first glance, a sub-set of the model (profile) can be 103 used to address specific scenarios, e.g. suitable also to non-TE use 104 cases. 106 The implementation of such TE Topology profiles can simplify and 107 expedite adoption of the full TE topology YANG data model, and allow 108 for its reuse even for non-TE use case. The key question being 109 whether all or some of the attributes defined in the TE Topology 110 Model are needed to address a given network scenario. 112 Section 2 provides examples where profiles of the TE Topology Model 113 can be used to address some generic use cases applicable to both TE 114 and non-TE technologies. 116 2. Examples of non-TE scenarios 118 2.1. UNI Topology Discovery 120 UNI Topology Discovery is independent from whether the network is TE 121 or non-TE. 123 The TE Topology Model supports inter-domain link discovery (including 124 but not being limited to UNI link discovery) using the plug-id 125 attribute. This solution is quite generic and does not require the 126 network to be a TE network. 128 The following profile of the TE Topology model can be used for the 129 UNI Topology Discovery: 131 module: ietf-te-topology 132 augment /nw:networks/nw:network/nw:network-types: 133 +--rw te-topology! 134 augment /nw:networks/nw:network/nw:node/nt:termination-point: 135 +--rw te-tp-id? te-types:te-tp-id 136 +--rw te! 137 +--rw admin-status? 138 | te-types:te-admin-status 139 +--rw inter-domain-plug-id? binary 140 +--ro oper-status? te-types:te-oper-status 142 Figure 1: UNI Topology 144 The profile data model shown in Figure 1 can be used to discover TE 145 and non TE UNIs as well as to discover UNIs for TE or non TE 146 networks. 148 Such a UNI TE Topology profile model can also be used with 149 technology-specific UNI augmentations, as described in section 3. 151 For example, in [I-D.ietf-ccamp-eth-client-te-topo-yang], the eth-svc 152 container is defined to represent the capabilities of the Termination 153 Point (TP) to be configured as an Ethernet client UNI, together with 154 the Ethernet classification and VLAN operations supported by that TP. 156 The [I-D.ietf-ccamp-otn-topo-yang] provides another example, where: 158 * the client-svc container is defined to represent the capabilities 159 of the TP to be configured as an transparent client UNI (e.g., 160 STM-N, Fiber Channel or transparent Ethernet); 162 * the OTN technology-specific Link Termination Point (LTP) 163 augmentations are defined to represent the capabilities of the TP 164 to be configured as an OTN UNI, together with the information 165 about OTN label and bandwidth availability at the OTN UNI. 167 For example, the UNI TE Topology profile can be used to model 168 features defined in [I-D.ogondio-opsawg-uni-topology]: 170 * The inter-domain-plug-id attribute would provide the same 171 information as the attachment-id attribute defined in 172 [I-D.ogondio-opsawg-uni-topology]; 174 * The admin-status and oper-status that exists in this TE topology 175 profile can provide the same information as the admin-status and 176 oper-status attributes defined in 177 [I-D.ogondio-opsawg-uni-topology]. 179 Following the same approach in 180 [I-D.ietf-ccamp-eth-client-te-topo-yang] and 181 [I-D.ietf-ccamp-otn-topo-yang], the type and encapsulation-type 182 attributes can be defined by technology- specific UNI 183 augmentations to represent the capability of a TP to be configured 184 as a L2VPN/L3VPN UNI Service Attachment Point (SAP). 186 The advantages of using a TE Topology profile would be having 187 common solutions for: 189 * discovering UNIs as well as inter-domain NNI links, which is 190 applicable to any technology (TE or non TE) used at the UNI or 191 within the network; 193 * modelling non TE UNIs such as Ethernet, and TE UNIs such as OTN, 194 as well as UNIs which can configured as TE or non-TE (e.g., being 195 configured as either Ethernet or OTN UNI). 197 2.2. Administrative and Operational status management 199 The TE Topology Model supports the management of administrative and 200 operational state, including also the possibility to associate some 201 administrative names, for nodes, termination points and links. This 202 solution is generic and also does not require the network to be a TE 203 network. 205 The following profile of the TE Topology Model can be used for 206 administrative and operational state management: 208 module: ietf-te-topology 209 augment /nw:networks/nw:network/nw:network-types: 210 +--rw te-topology! 211 augment /nw:networks/nw:network: 212 +--rw te-topology-identifier 213 | +--rw provider-id? te-global-id 214 | +--rw client-id? te-global-id 215 | +--rw topology-id? te-topology-id 216 +--rw te! 217 +--rw name? string 218 augment /nw:networks/nw:network/nw:node: 219 +--rw te-node-id? te-types:te-node-id 220 +--rw te! 221 +--rw te-node-attributes 222 | +--rw admin-status? te-types:te-admin-status 223 | +--rw name? string 224 +--ro oper-status? te-types:te-oper-status 225 augment /nw:networks/nw:network/nt:link: 226 +--rw te! 227 +--rw te-link-attributes 228 | +--rw name? string 229 | +--rw admin-status? te-types:te-admin-status 230 +--ro oper-status? te-types:te-oper-status 231 augment /nw:networks/nw:network/nw:node/nt:termination-point: 232 +--rw te-tp-id? te-types:te-tp-id 233 +--rw te! 234 +--rw admin-status? te-types:te-admin-status 235 +--rw name? string 236 +--ro oper-status? te-types:te-oper-status 238 Figure 2: Generic Topology with admin and operational state 240 The TE topology data model profile shown in Figure 2 is applicable to 241 any technology (TE or non-TE) that requires management of the 242 administrative and operational state and administrative names for 243 nodes, termination points and links. 245 2.3. Geolocation 247 The TE Topology model supports the management of geolocation 248 coordinates for nodes and termination points. This solution is 249 generic and does not necessarily require the network to be a TE 250 network. 252 The TE topology data model profile shown in Figure 3 can be used to 253 model geolocation data for networks. 255 module: ietf-te-topology 256 augment /nw:networks/nw:network/nw:network-types: 257 +--rw te-topology! 258 augment /nw:networks/nw:network/nw:node/nt:termination-point: 259 +--rw te-tp-id? te-types:te-tp-id 260 +--rw te! 261 +--ro geolocation 262 +--ro altitude? int64 263 +--ro latitude? geographic-coordinate-degree 264 +--ro longitude? geographic-coordinate-degree 265 augment /nw:networks/nw:network/nw:node: 266 +--rw te-node-id? te-types:te-node-id 267 +--rw te! 268 +--ro geolocation 269 +--ro altitude? int64 270 +--ro latitude? geographic-coordinate-degree 271 +--ro longitude? geographic-coordinate-degree 272 augment /nw:networks/nw:network/nw:node/nt:termination-point: 273 +--rw te-tp-id? te-types:te-tp-id 274 +--rw te! 275 +--ro geolocation 276 +--ro altitude? int64 277 +--ro latitude? geographic-coordinate-degree 278 +--ro longitude? geographic-coordinate-degree 280 Figure 3: Generic Topology with geolocation information 282 This profile is applicable to any network technology (TE or non-TE) 283 that requires management of the geolocation information for its nodes 284 and termination points. 286 2.4. Overlay and Underlay non-TE Topologies 288 The TE Topology model supports the management of overlay/underlay 289 relationship for nodes and links, as described in section 5.8 of 290 [RFC8795]. This solution is generic and does not require the network 291 to be a TE network. 293 The following TE topology data model profile can be used to manage 294 overlay/underlay network data: 296 module: ietf-te-topology 297 augment /nw:netorks/nw:network/nw:network-types: 298 +--rw te-topology! 299 augment /nw:networks/nw:network/nw:node: 300 +--rw te-node-id? te-types:te-node-id 301 +--rw te! 302 +--rw te-node-attributes 303 +--rw underlay-topology {te-topology-hierarchy}? 304 +--rw network-ref? -> /nw:networks/network/network-id 305 augment /nw:networks/nw:network/nt:link: 306 +--rw te! 307 +--rw te-link-attributes 308 +--rw underlay {te-topology-hierarchy}? 309 +--rw enabled? boolean 310 +--rw primary-path 311 +--rw network-ref? 312 | -> /nw:networks/network/network-id 313 +--rw path-element* [path-element-id] 314 +--rw path-element-id uint32 315 +--rw (type)? 316 +--:(numbered-link-hop) 317 | +--rw numbered-link-hop 318 | +--rw link-tp-id te-tp-id 319 | +--rw hop-type? te-hop-type 320 | +--rw direction? te-link-direction 321 +--:(unnumbered-link-hop) 322 +--rw unnumbered-link-hop 323 +--rw link-tp-id te-tp-id 324 +--rw node-id te-node-id 325 +--rw hop-type? te-hop-type 326 +--rw direction? te-link-direction 328 Figure 4: Generic Topology with overlay/underlay information 330 This profile is applicable to any technology (TE or non-TE) when it 331 is needed to manage the overlay/underlay information. It is also 332 allows a TE underlay network to support a non-TE overlay network and, 333 vice versa, a non-TE underlay network to support a TE overlay 334 network. 336 2.5. Nodes with switching limitations 338 A node can have some switching limitations where connectivity is not 339 possible between all its TP pairs, for example when: 341 * the node represents a physical device with switching limitations; 343 * the node represents an abstraction of a network topology. 345 This scenario is generic and applies to both TE and non-TE 346 technologies. 348 A connectivity TE Topology profile data model supports the management 349 of the node connectivity matrix to represent feasible connections 350 between termination points across the nodes. This solution is 351 generic and does not necessarily require a TE enabled network. 353 The following profile of the TE Topology model can be used for nodes 354 with connectivity constraints: 356 module: ietf-te-topology 357 augment /nw:networks/nw:network/nw:network-types: 358 +--rw te-topology! 359 augment /nw:networks/nw:network/nw:node: 360 +--rw te-node-id? te-types:te-node-id 361 +--rw te! 362 +--rw te-node-attributes 363 +--rw connectivity-matrices 364 +--rw number-of-entries? uint16 365 +--rw is-allowed? boolean 366 +--rw connectivity-matrix* [id] 367 +--rw id uint32 368 +--rw from 369 | +--rw tp-ref? leafref 370 +--rw to 371 | +--rw tp-ref? leafref 372 +--rw is-allowed? boolean 374 Figure 5: Generic Topology with connectivity constraints 376 The TE topology data model profile shown in Figure 5 is applicable to 377 any technology (TE or non-TE) networks that requires managing nodes 378 with certain connectivity constraints. When used with TE 379 technologies, additional TE attributes, as defined in [RFC8795], can 380 also be provided. 382 3. Technology-specific augmentations 384 There are two main options to define technology-specific Topology 385 Models which can use the attributes defined in the TE Topology Model 386 [RFC8795]. 388 Both options are applicable to any possible profile of the TE 389 Topology Model, such as those defined in Section 2. 391 The first option is to define a technology-specific TE Topology Model 392 which augments the TE Topology Model, as shown in Figure 6: 394 +-------------------+ 395 | Network Topology | 396 +-------------------+ 397 ^ 398 | 399 | Augments 400 | 401 +-----------+-----------+ 402 | TE Topology | 403 | (profile) | 404 +-----------------------+ 405 ^ 406 | 407 | Augments 408 | 409 +----------+----------+ 410 | Technology-Specific | 411 | TE Topology | 412 +---------------------+ 414 Figure 6: Augmenting the TE Topology Model 416 This approach is more suitable for cases when the technology-specific 417 TE topology model provides augmentations to the TE Topology 418 constructs, such as bandwidth information (e.g., link bandwidth), 419 tunnel termination points (TTPs) or connectivity matrices. It also 420 allows providing augmentations to the Network Topology constructs, 421 such as nodes, links, and termination points (TPs). 423 This is the approach currently used in 424 [I-D.ietf-ccamp-eth-client-te-topo-yang] and 425 [I-D.ietf-ccamp-otn-topo-yang]. 427 It is worth noting that a profile of the technology-specific TE 428 Topology model not using any TE topology attribute or constructs can 429 be used to address any use case that do not require these attributes. 430 In this case, only the te-topology presence container of the TE 431 Topology Model needs to be implemented. 433 The second option is to define a technology-specific Network Topology 434 Model which augments the Network Topology Model and to rely on the 435 multiple inheritance capability, which is implicit in the network- 436 types definition of [RFC8345], to allow using also the generic 437 attributes defined in the TE Topology model: 439 +-----------------------+ 440 | Network Topology | 441 +-----------------------+ 442 ^ ^ 443 | | 444 Augments +---+ +--+ Augments 445 | | 446 +---------+---+ +----------+----------+ 447 | TE Topology | | Technology-specific | 448 | (profile) | | Network Topology | 449 +-------------+ +---------------------+ 451 Figure 7: Augmenting the Network Topology Model with multi- 452 inheritance 454 This approach is more suitable in cases where the technology-specific 455 Network Topology Model provides augmentation only to the constructs 456 defined in the Network Topology Model, such as nodes, links, and 457 termination points (TPs). Therefore, with this approach, only the 458 generic attributes defined in the TE Topology Model could be used. 460 It is also worth noting that in this case, technology-specific 461 augmentations for the bandwidth information could not be defined. 463 In principle, it would be also possible to define both a technology 464 specific TE Topology Model which augments the TE Topology Model, and 465 a technology-specific Network Topology Model which augments the 466 Network Topology Model and to rely on the multiple inheritance 467 capability, as shown in Figure 8: 469 +-----------------------+ 470 | Network Topology | 471 +-----------------------+ 472 ^ ^ 473 | | 474 Augments +---+ +--+ Augments 475 | | 476 +---------+---+ +----------+----------+ 477 | TE Topology | | Technology-specific | 478 | (profile) | | Network Topology | 479 +-------------+ +---------------------+ 480 ^ ^ 481 | | 482 | Augments | References 483 | | 484 +----------+----------+ | 485 | Technology-Specific +--------------+ 486 | TE Topology | 487 +---------------------+ 489 Figure 8: Augmenting both the Network and TE Topology Models 491 This option does not provide any technical advantage with respect to 492 the first option, shown in Figure 6, but could be useful to add 493 augmentations to the TE Topology constructs and to re-use an already 494 existing technology-specific Network Topology Model. 496 It is worth noting that the technology-specific TE Topology model can 497 reference constructs defined by the technology-specific Network 498 Topology model but it could not augment constructs defined by the 499 technology-specific Network Topology model. 501 3.1. Multi-inheritance 503 As described in section 4.1 of [RFC8345], the network types should be 504 defined using presence containers to allow the representation of 505 network subtypes. 507 The hierachy of netwok subtypes can be single hierarchy, as shown in 508 Figure 6. In this case, each presence container contains at most one 509 child presence container, as shows in the JSON code below: 511 { 512 "ietf-network:ietf-network": { 513 "ietf-te-topology:te-topology": { 514 "example-te-topology": {} 515 } 516 } 517 } 519 The hierachy of netwok subtypes can also be multi-hierarchy, as shown 520 in Figure 7 and Figure 8. In this case, one presence container can 521 contain more than one child presence containers, as show in the JSON 522 codes below: 524 { 525 "ietf-network:ietf-network": { 526 "ietf-te-topology:te-topology": {} 527 "example-network-topology": {} 528 } 529 } 531 { 532 "ietf-network:ietf-network": { 533 "ietf-te-topology:te-topology": { 534 "example-te-topology": {} 535 } 536 "example-network-topology": {} 537 } 538 } 540 Other examples of multi-hierarchy topologies are described in 541 [I-D.ietf-teas-yang-sr-te-topo]. 543 3.2. Example (Link augmentation) 545 This section provides an example on how technology-specific 546 attributes can be added to the Link construct: 548 +--rw link* [link-id] 549 +--rw link-id link-id 550 +--rw source 551 | +--rw source-node? -> ../../../nw:node/node-id 552 | +--rw source-tp? leafref 553 +--rw destination 554 | +--rw dest-node? -> ../../../nw:node/node-id 555 | +--rw dest-tp? leafref 556 +--rw supporting-link* [network-ref link-ref] 557 | +--rw network-ref 558 | | -> ../../../nw:supporting-network/network-ref 559 | +--rw link-ref leafref 560 +--rw example-link-attributes 561 | <...> 562 +--rw te! 563 +--rw te-link-attributes 564 +--rw name? string 565 +--rw example-te-link-attributes 566 | <...> 567 +--rw max-link-bandwidth 568 +--rw te-bandwidth 569 +--rw (technology)? 570 +--:(generic) 571 | +--rw generic? te-bandwidth 572 +--:(example) 573 +--rw example? example-bandwidth 575 Figure 9: Augmenting the Link with technology-specific attributes 577 The technology-specific attributes within the example-link-attributes 578 container can be defined either in the technology-specific TE 579 Topology Model (Option 1) or in the technology-specific Network 580 Topology Model (Option 2 or Option 3). These attributes can only be 581 non-TE and do not require the implementation of the te container. 583 The technology-specific attributes within the example-te-link- 584 attributes container as well as the example max-link-bandwidth can 585 only be defined in the technology-specific TE Topology Model (Option 586 1 or Option 3). These attributes can be TE or non-TE and require the 587 implementation of the te container. 589 4. Implemented profiles 591 When a server implements a profile of the TE topology model, it is 592 not clear how the server can report to the client the subset of the 593 model being implemented. 595 It is also worth noting that the supported profile may also depend on 596 other attributes (for example the network type). 598 In case the TE topology profile is reported by the server to the 599 client, the server will report in the operational datastore only the 600 leaves which have been implemented, as described in section 5.3 of 601 [RFC8342]. 603 More investigation is required in case the TE topology profile is 604 configured by the client. 606 5. Security Considerations 608 This document provides only information about how the TE Topology 609 Model, as defined in [RFC8795], can be profiled to address some 610 scenarios which are not considered as TE. 612 As such, this document does not introduce any additional security 613 considerations besides those already defined in [RFC8795]. 615 6. IANA Considerations 617 This document requires no IANA actions. 619 7. References 621 7.1. Normative References 623 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 624 and R. Wilton, "Network Management Datastore Architecture 625 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 626 . 628 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 629 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 630 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 631 2018, . 633 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 634 O. Gonzalez de Dios, "YANG Data Model for Traffic 635 Engineering (TE) Topologies", RFC 8795, 636 DOI 10.17487/RFC8795, August 2020, 637 . 639 7.2. Informative References 641 [I-D.ietf-ccamp-eth-client-te-topo-yang] 642 Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. 643 Liu, "A YANG Data Model for Ethernet TE Topology", Work in 644 Progress, Internet-Draft, draft-ietf-ccamp-eth-client-te- 645 topo-yang-00, 9 March 2021, 646 . 649 [I-D.ietf-ccamp-otn-topo-yang] 650 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 651 Dios, "A YANG Data Model for Optical Transport Network 652 Topology", Work in Progress, Internet-Draft, draft-ietf- 653 ccamp-otn-topo-yang-13, 12 July 2021, 654 . 657 [I-D.ietf-teas-rfc3272bis] 658 Farrel, A., "Overview and Principles of Internet Traffic 659 Engineering", Work in Progress, Internet-Draft, draft- 660 ietf-teas-rfc3272bis-12, 15 May 2021, 661 . 664 [I-D.ietf-teas-yang-sr-te-topo] 665 Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H., 666 and S. Litkowski, "YANG Data Model for SR and SR TE 667 Topologies on MPLS Data Plane", Work in Progress, 668 Internet-Draft, draft-ietf-teas-yang-sr-te-topo-10, 6 July 669 2021, . 672 [I-D.ogondio-opsawg-uni-topology] 673 Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A 674 YANG Model for User-Network Interface (UNI) Topologies", 675 Work in Progress, Internet-Draft, draft-ogondio-opsawg- 676 uni-topology-01, 2 April 2020, 677 . 680 Contributors 682 Aihua Guo 683 Futurewei Inc. 685 Email: aihuaguo.ietf@gmail.com 686 Haomian Zheng 687 Huawei 689 Email: zhenghaomian@huawei.com 691 Sergio Belotti 692 Nokia 694 Email: sergio.belotti@nokia.com 696 Authors' Addresses 698 Italo Busi 699 Huawei 701 Email: italo.busi@huawei.com 703 Xufeng Liu 704 Volta Networks 706 Email: xufeng.liu.ietf@gmail.com 708 Igor Bryskin 709 Individual 711 Email: i_bryskin@yahoo.com 713 Vishnu Pavan Beeram 714 Juniper Networks 716 Email: vbeeram@juniper.net 718 Tarek Saad 719 Juniper Networks 721 Email: tsaad@juniper.net 723 Oscar Gonzalez de Dios 724 Telefonica 726 Email: oscar.gonzalezdedios@telefonica.com