idnits 2.17.00 (12 Aug 2021) /tmp/idnits13958/draft-busi-teas-te-topology-profiles-03.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: ---------------------------------------------------------------------------- == Line 319 has weird spacing: '...k-tp-id te-...' == Line 324 has weird spacing: '...k-tp-id te-...' -- The document date (4 February 2022) is 99 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ietf-ccamp-eth-client-te-topo-yang-01 == Outdated reference: A later version (-14) exists of draft-ietf-ccamp-otn-topo-yang-13 == Outdated reference: A later version (-16) exists of draft-ietf-teas-rfc3272bis-13 == Outdated reference: A later version (-13) exists of draft-ietf-teas-yang-sr-te-topo-11 Summary: 0 errors (**), 0 flaws (~~), 6 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: 8 August 2022 Volta Networks 6 I. Bryskin 7 Individual 8 T. Saad 9 Juniper Networks 10 O. Gonzalez de Dios 11 Telefonica 12 4 February 2022 14 Profiles for Traffic Engineering (TE) Topology Data Model and 15 Applicability to non-TE Use Cases 16 draft-busi-teas-te-topology-profiles-03 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 8 August 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised 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 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Normative References . . . . . . . . . . . . . . . . . . . . . 14 73 Informative References . . . . . . . . . . . . . . . . . . . . 15 74 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 There are many network scenarios being discussed in various IETF 80 Working Groups (WGs) that are not classified as "Traffic Engineering" 81 but can be addressed by a sub-set (profile) of the Traffic 82 Engineering (TE) Topology YANG data model, defined in [RFC8795]. 84 Traffic Engineering (TE) is defined in [I-D.ietf-teas-rfc3272bis] as 85 aspects of Internet network engineering that deal with the issues of 86 performance evaluation and performance optimization of operational IP 87 networks. TE encompasses the application of technology and 88 scientific principles to the measurement, characterization, modeling, 89 and control of Internet traffic. 91 The TE Topology Model is augmenting the Network Topology Model 92 defined in [RFC8345] with generic and technology-agnostic features 93 that some are strictly applicable to TE networks, while others 94 applicable to both TE and non-TE networks. 96 Examples of such features that are applicable to both TE and non-TE 97 networks are: inter-domain link discovery (plug-id), geo- 98 localization, and admin/operational status. 100 It is also worth noting that the TE Topology Model is quite an 101 extensive and comprehensive model in which most features are 102 optional. Therefore, even though the full model appears to be 103 complex, at the first glance, a sub-set of the model (profile) can be 104 used to address specific scenarios, e.g. suitable also to non-TE use 105 cases. 107 The implementation of such TE Topology profiles can simplify and 108 expedite adoption of the full TE topology YANG data model, and allow 109 for its reuse even for non-TE use case. The key question being 110 whether all or some of the attributes defined in the TE Topology 111 Model are needed to address a given network scenario. 113 Section 2 provides examples where profiles of the TE Topology Model 114 can be used to address some generic use cases applicable to both TE 115 and non-TE technologies. 117 2. Examples of non-TE scenarios 119 2.1. UNI Topology Discovery 121 UNI Topology Discovery is independent from whether the network is TE 122 or non-TE. 124 The TE Topology Model supports inter-domain link discovery (including 125 but not being limited to UNI link discovery) using the plug-id 126 attribute. This solution is quite generic and does not require the 127 network to be a TE network. 129 The following profile of the TE Topology model can be used for the 130 UNI Topology Discovery: 132 module: ietf-te-topology 133 augment /nw:networks/nw:network/nw:network-types: 134 +--rw te-topology! 135 augment /nw:networks/nw:network/nw:node/nt:termination-point: 136 +--rw te-tp-id? te-types:te-tp-id 137 +--rw te! 138 +--rw admin-status? 139 | te-types:te-admin-status 140 +--rw inter-domain-plug-id? binary 141 +--ro oper-status? te-types:te-oper-status 143 Figure 1: UNI Topology 145 The profile data model shown in Figure 1 can be used to discover TE 146 and non TE UNIs as well as to discover UNIs for TE or non TE 147 networks. 149 Such a UNI TE Topology profile model can also be used with 150 technology-specific UNI augmentations, as described in section 3. 152 For example, in [I-D.ietf-ccamp-eth-client-te-topo-yang], the eth-svc 153 container is defined to represent the capabilities of the Termination 154 Point (TP) to be configured as an Ethernet client UNI, together with 155 the Ethernet classification and VLAN operations supported by that TP. 157 The [I-D.ietf-ccamp-otn-topo-yang] provides another example, where: 159 * the client-svc container is defined to represent the capabilities 160 of the TP to be configured as an transparent client UNI (e.g., 161 STM-N, Fiber Channel or transparent Ethernet); 163 * the OTN technology-specific Link Termination Point (LTP) 164 augmentations are defined to represent the capabilities of the TP 165 to be configured as an OTN UNI, together with the information 166 about OTN label and bandwidth availability at the OTN UNI. 168 For example, the UNI TE Topology profile can be used to model 169 features defined in [I-D.ogondio-opsawg-uni-topology]: 171 * The inter-domain-plug-id attribute would provide the same 172 information as the attachment-id attribute defined in 173 [I-D.ogondio-opsawg-uni-topology]; 175 * The admin-status and oper-status that exists in this TE topology 176 profile can provide the same information as the admin-status and 177 oper-status attributes defined in 178 [I-D.ogondio-opsawg-uni-topology]. 180 Following the same approach in 181 [I-D.ietf-ccamp-eth-client-te-topo-yang] and 182 [I-D.ietf-ccamp-otn-topo-yang], the type and encapsulation-type 183 attributes can be defined by technology- specific UNI 184 augmentations to represent the capability of a TP to be configured 185 as a L2VPN/L3VPN UNI Service Attachment Point (SAP). 187 The advantages of using a TE Topology profile would be having 188 common solutions for: 190 * discovering UNIs as well as inter-domain NNI links, which is 191 applicable to any technology (TE or non TE) used at the UNI or 192 within the network; 194 * modelling non TE UNIs such as Ethernet, and TE UNIs such as OTN, 195 as well as UNIs which can configured as TE or non-TE (e.g., being 196 configured as either Ethernet or OTN UNI). 198 2.2. Administrative and Operational status management 200 The TE Topology Model supports the management of administrative and 201 operational state, including also the possibility to associate some 202 administrative names, for nodes, termination points and links. This 203 solution is generic and also does not require the network to be a TE 204 network. 206 The following profile of the TE Topology Model can be used for 207 administrative and operational state management: 209 module: ietf-te-topology 210 augment /nw:networks/nw:network/nw:network-types: 211 +--rw te-topology! 212 augment /nw:networks/nw:network: 213 +--rw te-topology-identifier 214 | +--rw provider-id? te-global-id 215 | +--rw client-id? te-global-id 216 | +--rw topology-id? te-topology-id 217 +--rw te! 218 +--rw name? string 219 augment /nw:networks/nw:network/nw:node: 220 +--rw te-node-id? te-types:te-node-id 221 +--rw te! 222 +--rw te-node-attributes 223 | +--rw admin-status? te-types:te-admin-status 224 | +--rw name? string 225 +--ro oper-status? te-types:te-oper-status 226 augment /nw:networks/nw:network/nt:link: 227 +--rw te! 228 +--rw te-link-attributes 229 | +--rw name? string 230 | +--rw admin-status? te-types:te-admin-status 231 +--ro oper-status? te-types:te-oper-status 232 augment /nw:networks/nw:network/nw:node/nt:termination-point: 233 +--rw te-tp-id? te-types:te-tp-id 234 +--rw te! 235 +--rw admin-status? te-types:te-admin-status 236 +--rw name? string 237 +--ro oper-status? te-types:te-oper-status 239 Figure 2: Generic Topology with admin and operational state 241 The TE topology data model profile shown in Figure 2 is applicable to 242 any technology (TE or non-TE) that requires management of the 243 administrative and operational state and administrative names for 244 nodes, termination points and links. 246 2.3. Geolocation 248 The TE Topology model supports the management of geolocation 249 coordinates for nodes and termination points. This solution is 250 generic and does not necessarily require the network to be a TE 251 network. 253 The TE topology data model profile shown in Figure 3 can be used to 254 model geolocation data for networks. 256 module: ietf-te-topology 257 augment /nw:networks/nw:network/nw:network-types: 258 +--rw te-topology! 259 augment /nw:networks/nw:network/nw:node/nt:termination-point: 260 +--rw te-tp-id? te-types:te-tp-id 261 +--rw te! 262 +--ro geolocation 263 +--ro altitude? int64 264 +--ro latitude? geographic-coordinate-degree 265 +--ro longitude? geographic-coordinate-degree 266 augment /nw:networks/nw:network/nw:node: 267 +--rw te-node-id? te-types:te-node-id 268 +--rw te! 269 +--ro geolocation 270 +--ro altitude? int64 271 +--ro latitude? geographic-coordinate-degree 272 +--ro longitude? geographic-coordinate-degree 273 augment /nw:networks/nw:network/nw:node/nt:termination-point: 274 +--rw te-tp-id? te-types:te-tp-id 275 +--rw te! 276 +--ro geolocation 277 +--ro altitude? int64 278 +--ro latitude? geographic-coordinate-degree 279 +--ro longitude? geographic-coordinate-degree 281 Figure 3: Generic Topology with geolocation information 283 This profile is applicable to any network technology (TE or non-TE) 284 that requires management of the geolocation information for its nodes 285 and termination points. 287 2.4. Overlay and Underlay non-TE Topologies 289 The TE Topology model supports the management of overlay/underlay 290 relationship for nodes and links, as described in section 5.8 of 291 [RFC8795]. This solution is generic and does not require the network 292 to be a TE network. 294 The following TE topology data model profile can be used to manage 295 overlay/underlay network data: 297 module: ietf-te-topology 298 augment /nw:netorks/nw:network/nw:network-types: 299 +--rw te-topology! 300 augment /nw:networks/nw:network/nw:node: 301 +--rw te-node-id? te-types:te-node-id 302 +--rw te! 303 +--rw te-node-attributes 304 +--rw underlay-topology {te-topology-hierarchy}? 305 +--rw network-ref? -> /nw:networks/network/network-id 306 augment /nw:networks/nw:network/nt:link: 307 +--rw te! 308 +--rw te-link-attributes 309 +--rw underlay {te-topology-hierarchy}? 310 +--rw enabled? boolean 311 +--rw primary-path 312 +--rw network-ref? 313 | -> /nw:networks/network/network-id 314 +--rw path-element* [path-element-id] 315 +--rw path-element-id uint32 316 +--rw (type)? 317 +--:(numbered-link-hop) 318 | +--rw numbered-link-hop 319 | +--rw link-tp-id te-tp-id 320 | +--rw hop-type? te-hop-type 321 | +--rw direction? te-link-direction 322 +--:(unnumbered-link-hop) 323 +--rw unnumbered-link-hop 324 +--rw link-tp-id te-tp-id 325 +--rw node-id te-node-id 326 +--rw hop-type? te-hop-type 327 +--rw direction? te-link-direction 329 Figure 4: Generic Topology with overlay/underlay information 331 This profile is applicable to any technology (TE or non-TE) when it 332 is needed to manage the overlay/underlay information. It is also 333 allows a TE underlay network to support a non-TE overlay network and, 334 vice versa, a non-TE underlay network to support a TE overlay 335 network. 337 2.5. Nodes with switching limitations 339 A node can have some switching limitations where connectivity is not 340 possible between all its TP pairs, for example when: 342 * the node represents a physical device with switching limitations; 344 * the node represents an abstraction of a network topology. 346 This scenario is generic and applies to both TE and non-TE 347 technologies. 349 A connectivity TE Topology profile data model supports the management 350 of the node connectivity matrix to represent feasible connections 351 between termination points across the nodes. This solution is 352 generic and does not necessarily require a TE enabled network. 354 The following profile of the TE Topology model can be used for nodes 355 with connectivity constraints: 357 module: ietf-te-topology 358 augment /nw:networks/nw:network/nw:network-types: 359 +--rw te-topology! 360 augment /nw:networks/nw:network/nw:node: 361 +--rw te-node-id? te-types:te-node-id 362 +--rw te! 363 +--rw te-node-attributes 364 +--rw connectivity-matrices 365 +--rw number-of-entries? uint16 366 +--rw is-allowed? boolean 367 +--rw connectivity-matrix* [id] 368 +--rw id uint32 369 +--rw from 370 | +--rw tp-ref? leafref 371 +--rw to 372 | +--rw tp-ref? leafref 373 +--rw is-allowed? boolean 375 Figure 5: Generic Topology with connectivity constraints 377 The TE topology data model profile shown in Figure 5 is applicable to 378 any technology (TE or non-TE) networks that requires managing nodes 379 with certain connectivity constraints. When used with TE 380 technologies, additional TE attributes, as defined in [RFC8795], can 381 also be provided. 383 3. Technology-specific augmentations 385 There are two main options to define technology-specific Topology 386 Models which can use the attributes defined in the TE Topology Model 387 [RFC8795]. 389 Both options are applicable to any possible profile of the TE 390 Topology Model, such as those defined in Section 2. 392 The first option is to define a technology-specific TE Topology Model 393 which augments the TE Topology Model, as shown in Figure 6: 395 +-------------------+ 396 | Network Topology | 397 +-------------------+ 398 ^ 399 | 400 | Augments 401 | 402 +-----------+-----------+ 403 | TE Topology | 404 | (profile) | 405 +-----------------------+ 406 ^ 407 | 408 | Augments 409 | 410 +----------+----------+ 411 | Technology-Specific | 412 | TE Topology | 413 +---------------------+ 415 Figure 6: Augmenting the TE Topology Model 417 This approach is more suitable for cases when the technology-specific 418 TE topology model provides augmentations to the TE Topology 419 constructs, such as bandwidth information (e.g., link bandwidth), 420 tunnel termination points (TTPs) or connectivity matrices. It also 421 allows providing augmentations to the Network Topology constructs, 422 such as nodes, links, and termination points (TPs). 424 This is the approach currently used in 425 [I-D.ietf-ccamp-eth-client-te-topo-yang] and 426 [I-D.ietf-ccamp-otn-topo-yang]. 428 It is worth noting that a profile of the technology-specific TE 429 Topology model not using any TE topology attribute or constructs can 430 be used to address any use case that do not require these attributes. 431 In this case, only the te-topology presence container of the TE 432 Topology Model needs to be implemented. 434 The second option is to define a technology-specific Network Topology 435 Model which augments the Network Topology Model and to rely on the 436 multiple inheritance capability, which is implicit in the network- 437 types definition of [RFC8345], to allow using also the generic 438 attributes defined in the TE Topology model: 440 +-----------------------+ 441 | Network Topology | 442 +-----------------------+ 443 ^ ^ 444 | | 445 Augments +---+ +--+ Augments 446 | | 447 +---------+---+ +----------+----------+ 448 | TE Topology | | Technology-specific | 449 | (profile) | | Network Topology | 450 +-------------+ +---------------------+ 452 Figure 7: Augmenting the Network Topology Model with multi- 453 inheritance 455 This approach is more suitable in cases where the technology-specific 456 Network Topology Model provides augmentation only to the constructs 457 defined in the Network Topology Model, such as nodes, links, and 458 termination points (TPs). Therefore, with this approach, only the 459 generic attributes defined in the TE Topology Model could be used. 461 It is also worth noting that in this case, technology-specific 462 augmentations for the bandwidth information could not be defined. 464 In principle, it would be also possible to define both a technology 465 specific TE Topology Model which augments the TE Topology Model, and 466 a technology-specific Network Topology Model which augments the 467 Network Topology Model and to rely on the multiple inheritance 468 capability, as shown in Figure 8: 470 +-----------------------+ 471 | Network Topology | 472 +-----------------------+ 473 ^ ^ 474 | | 475 Augments +---+ +--+ Augments 476 | | 477 +---------+---+ +----------+----------+ 478 | TE Topology | | Technology-specific | 479 | (profile) | | Network Topology | 480 +-------------+ +---------------------+ 481 ^ ^ 482 | | 483 | Augments | References 484 | | 485 +----------+----------+ | 486 | Technology-Specific +--------------+ 487 | TE Topology | 488 +---------------------+ 490 Figure 8: Augmenting both the Network and TE Topology Models 492 This option does not provide any technical advantage with respect to 493 the first option, shown in Figure 6, but could be useful to add 494 augmentations to the TE Topology constructs and to re-use an already 495 existing technology-specific Network Topology Model. 497 It is worth noting that the technology-specific TE Topology model can 498 reference constructs defined by the technology-specific Network 499 Topology model but it could not augment constructs defined by the 500 technology-specific Network Topology model. 502 3.1. Multi-inheritance 504 As described in section 4.1 of [RFC8345], the network types should be 505 defined using presence containers to allow the representation of 506 network subtypes. 508 The hierachy of netwok subtypes can be single hierarchy, as shown in 509 Figure 6. In this case, each presence container contains at most one 510 child presence container, as shows in the JSON code below: 512 { 513 "ietf-network:ietf-network": { 514 "ietf-te-topology:te-topology": { 515 "example-te-topology": {} 516 } 517 } 518 } 520 The hierachy of netwok subtypes can also be multi-hierarchy, as shown 521 in Figure 7 and Figure 8. In this case, one presence container can 522 contain more than one child presence containers, as show in the JSON 523 codes below: 525 { 526 "ietf-network:ietf-network": { 527 "ietf-te-topology:te-topology": {} 528 "example-network-topology": {} 529 } 530 } 532 { 533 "ietf-network:ietf-network": { 534 "ietf-te-topology:te-topology": { 535 "example-te-topology": {} 536 } 537 "example-network-topology": {} 538 } 539 } 541 Other examples of multi-hierarchy topologies are described in 542 [I-D.ietf-teas-yang-sr-te-topo]. 544 3.2. Example (Link augmentation) 546 This section provides an example on how technology-specific 547 attributes can be added to the Link construct: 549 +--rw link* [link-id] 550 +--rw link-id link-id 551 +--rw source 552 | +--rw source-node? -> ../../../nw:node/node-id 553 | +--rw source-tp? leafref 554 +--rw destination 555 | +--rw dest-node? -> ../../../nw:node/node-id 556 | +--rw dest-tp? leafref 557 +--rw supporting-link* [network-ref link-ref] 558 | +--rw network-ref 559 | | -> ../../../nw:supporting-network/network-ref 560 | +--rw link-ref leafref 561 +--rw example-link-attributes 562 | <...> 563 +--rw te! 564 +--rw te-link-attributes 565 +--rw name? string 566 +--rw example-te-link-attributes 567 | <...> 568 +--rw max-link-bandwidth 569 +--rw te-bandwidth 570 +--rw (technology)? 571 +--:(generic) 572 | +--rw generic? te-bandwidth 573 +--:(example) 574 +--rw example? example-bandwidth 576 Figure 9: Augmenting the Link with technology-specific attributes 578 The technology-specific attributes within the example-link-attributes 579 container can be defined either in the technology-specific TE 580 Topology Model (Option 1) or in the technology-specific Network 581 Topology Model (Option 2 or Option 3). These attributes can only be 582 non-TE and do not require the implementation of the te container. 584 The technology-specific attributes within the example-te-link- 585 attributes container as well as the example max-link-bandwidth can 586 only be defined in the technology-specific TE Topology Model (Option 587 1 or Option 3). These attributes can be TE or non-TE and require the 588 implementation of the te container. 590 4. Implemented profiles 592 When a server implements a profile of the TE topology model, it is 593 not clear how the server can report to the client the subset of the 594 model being implemented. 596 It is also worth noting that the supported profile may also depend on 597 other attributes (for example the network type). 599 In case the TE topology profile is reported by the server to the 600 client, the server will report in the operational datastore only the 601 leaves which have been implemented, as described in section 5.3 of 602 [RFC8342]. 604 More investigation is required in case the TE topology profile is 605 configured by the client. 607 5. Security Considerations 609 This document provides only information about how the TE Topology 610 Model, as defined in [RFC8795], can be profiled to address some 611 scenarios which are not considered as TE. 613 As such, this document does not introduce any additional security 614 considerations besides those already defined in [RFC8795]. 616 6. IANA Considerations 618 This document requires no IANA actions. 620 Acknowledgments 622 The authors would like to thank Daniele Ceccarelli, Jonas Ahlberg and 623 Scott Mansfield for providing useful suggestions for this draft. 625 This document was prepared using kramdown. 627 Previous versions of this document was prepared using 2-Word- 628 v2.0.template.dot. 630 References 632 Normative References 634 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 635 and R. Wilton, "Network Management Datastore Architecture 636 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 637 . 639 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 640 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 641 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 642 2018, . 644 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 645 O. Gonzalez de Dios, "YANG Data Model for Traffic 646 Engineering (TE) Topologies", RFC 8795, 647 DOI 10.17487/RFC8795, August 2020, 648 . 650 Informative References 652 [I-D.ietf-ccamp-eth-client-te-topo-yang] 653 Zheng, H., Guo, A., Busi, I., Xu, Y., Zhao, Y., and X. 654 Liu, "A YANG Data Model for Ethernet TE Topology", Work in 655 Progress, Internet-Draft, draft-ietf-ccamp-eth-client-te- 656 topo-yang-01, 7 September 2021, 657 . 660 [I-D.ietf-ccamp-otn-topo-yang] 661 Zheng, H., Busi, I., Liu, X., Belotti, S., and O. G. D. 662 Dios, "A YANG Data Model for Optical Transport Network 663 Topology", Work in Progress, Internet-Draft, draft-ietf- 664 ccamp-otn-topo-yang-13, 12 July 2021, 665 . 668 [I-D.ietf-teas-rfc3272bis] 669 Farrel, A., "Overview and Principles of Internet Traffic 670 Engineering", Work in Progress, Internet-Draft, draft- 671 ietf-teas-rfc3272bis-13, 8 November 2021, 672 . 675 [I-D.ietf-teas-yang-sr-te-topo] 676 Liu, X., Bryskin, I., Beeram, V. P., Saad, T., Shah, H., 677 and S. Litkowski, "YANG Data Model for SR and SR TE 678 Topologies on MPLS Data Plane", Work in Progress, 679 Internet-Draft, draft-ietf-teas-yang-sr-te-topo-11, 24 680 October 2021, . 683 [I-D.ogondio-opsawg-uni-topology] 684 Dios, O. G. D., Barguil, S., Wu, Q., and M. Boucadair, "A 685 YANG Model for User-Network Interface (UNI) Topologies", 686 Work in Progress, Internet-Draft, draft-ogondio-opsawg- 687 uni-topology-01, 2 April 2020, 688 . 691 Contributors 693 Aihua Guo 694 Futurewei Inc. 696 Email: aihuaguo.ietf@gmail.com 698 Haomian Zheng 699 Huawei 701 Email: zhenghaomian@huawei.com 703 Vishnu Pavan Beeram 704 Juniper Networks 706 Email: vbeeram@juniper.net 708 Sergio Belotti 709 Nokia 711 Email: sergio.belotti@nokia.com 713 Authors' Addresses 715 Italo Busi 716 Huawei 718 Email: italo.busi@huawei.com 720 Xufeng Liu 721 Volta Networks 723 Email: xufeng.liu.ietf@gmail.com 725 Igor Bryskin 726 Individual 728 Email: i_bryskin@yahoo.com 729 Tarek Saad 730 Juniper Networks 732 Email: tsaad@juniper.net 734 Oscar Gonzalez de Dios 735 Telefonica 737 Email: oscar.gonzalezdedios@telefonica.com