idnits 2.17.1 draft-ye-ccamp-mw-topo-yang-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 05, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-13) exists of draft-ietf-ccamp-mw-yang-04 == Outdated reference: A later version (-15) exists of draft-ietf-teas-actn-framework-11 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group M. Ye, Ed. 3 Internet-Draft A. Guo 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 6, 2018 J. Ahlberg 6 Ericsson AB 7 X. Li 8 NEC Laboratories Europe GmbH 9 D. Spreafico 10 Nokia - IT 11 March 05, 2018 13 A YANG Data Model for Microwave Topology 14 draft-ye-ccamp-mw-topo-yang-00 16 Abstract 18 This document defines a YANG data model to describe the topologies of 19 microwave/millimeter. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 6, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology and Definitions . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. YANG Data Model (Tree Structure) . . . . . . . . . . . . . . 3 64 3.1. The YANG Tree . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Relationship with microwave interface YANG model . . . . 3 66 4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Appendix A. Appendix A Examples of microwave topology . . . . . 9 73 A.1. Appendix A.1 A topology with single microwave radio link 9 74 A.2. Appendix A.2 A topology with microwave radio links 75 bundling . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 14 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 79 1. Terminology and Definitions 81 The following acronyms are used in this document: 83 PNC Provisioning Network Controller 85 MDSC Multi Domain Service Coordinator 87 2. Introduction 89 This document defines a YANG data model to describe the topologies of 90 microwave/millimeter(hereafter microwave is used to simplify the 91 text). The microwave topology model augments the TE topology model 92 defines in [I-D.ietf-teas-yang-te-topo]. 94 The microwave topology model is expected to be used between a 95 Provisioning Network Controller(PNC) and a Multi Domain Service 96 Coordinator(MDSC)([I-D.ietf-teas-actn-framework]). Possible use 97 cases of microwave topology models include: 99 1. The microwave link frequency could be used to understand the 100 current frequency usage, enabling a whole view of the network 101 topology information, and as an input for network frequency 102 planning. 104 2. The microwave radio link could change its bandwidth according to 105 the environments under the adatpive modulation mode, e.g., the 106 bandwidth will degrade when there's a heavy rain. To get to know 107 of current microwave link bandwidth is important for path 108 computation and service provisioning across different 109 technologies/networks. 111 3. Due to bandiwdth changing feature, availability is normally used 112 to describe the microwave radio link characteristic. [RFC8330] 113 defines a mechanism to report bandwidth-availability information 114 through OSPF-TE. It's also necessary to include the information 115 in the YANG data model to optimize the path/route computation. 117 3. YANG Data Model (Tree Structure) 119 3.1. The YANG Tree 121 module: ietf-microwave-topology 122 augment /nw:networks/nw:network/nw:network-types/tet:te-topology: 123 +--rw mw-topology! 124 augment /nw:networks/nw:network/nt:link/tet:te/tet:te-link-attributes: 125 +--rw mw-link-frequency? uint32 126 +--rw mw-link-channel-separation? uint32 127 +--ro mw-link-nominal-bandwidth? rt-types:bandwidth-ieee-float32 128 +--ro mw-link-current-bandwidth? rt-types:bandwidth-ieee-float32 129 +--ro mw-link-availability* 130 +--ro mw-link-availability rt-types:percentage 131 +--ro mw-link-bandwidth rt-types:bandwidth-ieee-float32 133 3.2. Relationship with microwave interface YANG model 135 [I-D.ietf-ccamp-mw-yang] defines an interface YANG model for 136 microwave radio link which is used between the PNC and the physical 137 device for device configuration. The PNC is able to convert the 138 information received from the topology model into the interface 139 model. For example, the link frequency in the topology model is 140 mapped to the tx-frequency of the carrier termination in the 141 interface model. 143 4. YANG Module 145 file "ietf-microwave-topology.yang" 147 module ietf-microwave-topology { 148 yang-version 1.1; 149 namespace "urn:ietf:params:xml:ns:yang:ietf-microwave-topology"; 151 prefix "mwtopo"; 153 import ietf-network { 154 prefix "nw"; 155 } 157 import ietf-network-topology { 158 prefix "nt"; 159 } 161 import ietf-te-topology { 162 prefix "tet"; 163 } 165 import ietf-routing-types { 166 prefix "rt-types"; 167 } 169 organization 170 "Internet Engineering Task Force (IETF) CCAMP WG"; 171 contact 172 " 173 WG List: 175 ID-draft authors: 176 Min Ye (amy.yemin@huawei.com); 177 Aihua Guo (aihuaguo@huawei.com); 178 Jonas Ahlberg (jonas.ahlberg@ericsson.com); 179 Xi Li (Xi.Li@neclab.eu); 180 Daniela Spreafico (daniela.spreafico@nokia.com) 181 "; 183 description 184 "This is a module for microwave topology."; 186 revision 2018-03-05 { 187 description 188 "Initial version."; 189 reference ""; 191 } 193 /* 194 * Groupings 195 */ 196 grouping mw-link-attributes { 197 description "Microwave link attributes"; 199 leaf mw-link-frequency { 200 type uint32; 201 units "kHz"; 202 description "Frequency of the link"; 203 } 205 leaf mw-link-channel-separation { 206 type uint32; 207 units "kHz"; 208 description "The distance 209 between adjacent channels in a radio frequency channel 210 arrangement used in this link"; 211 reference "ETSI EN 302 217-1"; 212 } 214 leaf mw-link-nominal-bandwidth { 215 type rt-types:bandwidth-ieee-float32; 216 units "Mbps"; 217 description "The nominal bandwidth of the link"; 218 } 220 leaf mw-link-current-bandwidth { 221 type rt-types:bandwidth-ieee-float32; 222 units "Mbps"; 223 description "The current bandwidth of the link"; 224 } 226 list mw-link-availability{ 227 key "availability"; 228 description "List of availability and its corresponding 229 link bandwidth"; 231 leaf availability { 232 type rt-types:percentage; 233 description "availability level of the link"; 234 } 236 leaf mw-link-bandwidth { 237 type rt-types:bandwidth-ieee-float32; 238 units "Mbps"; 239 description "the bandwidth corresponding to the 240 availability level"; 241 } 242 } 243 } 245 /* 246 * Data nodes 247 */ 248 augment "/nw:networks/nw:network/nw:network-types/" 249 + "tet:te-topology" { 250 container mw-topology { 251 presence "indicates a topology type of microwave."; 252 description "microwave topology type"; 253 } 254 description "augment network types to include microwave network"; 255 } 257 augment "/nw:networks/nw:network/nt:link/tet:te/" 258 + "tet:te-link-attributes" { 259 when "../../../nw:network-types/tet:te-topology/" 260 + "mwtopo:mw-topology" { 261 description "This augment is only valid for microwave."; 262 } 263 description "Microwave link augmentation"; 265 uses mw-link-attributes; 266 } 268 } 269 271 5. Security Considerations 273 The YANG module specified in this document defines a schema for data 274 that is designed to be accessed via network management protocols such 275 as NETCONF [RFC6241] or RESTCONF [RFC8040][RFC8040]. The lowest 276 NETCONF layer is the secure transport layer, and the mandatory-to- 277 implement secure transport is Secure Shell (SSH) [RFC6242]. The 278 lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure 279 transport is TLS [RFC5246]. 281 The NETCONF access control model [RFC6536] provides the means to 282 restrict access for particular NETCONF or RESTCONF users to a 283 preconfigured subset of all available NETCONF or RESTCONF protocol 284 operations and content. 286 There are a number of data nodes defined in this YANG module that are 287 writable/creatable/deletable (i.e., config true, which is the 288 default). These data nodes may be considered sensitive or vulnerable 289 in some network environments. Write operations (e.g., edit-config) 290 to these data nodes without proper protection can have a negative 291 effect on network operations. These are the subtrees and data nodes 292 and their sensitivity/vulnerability: 294 TBD.(list subtrees and data nodes and state why they are sensitive) 296 Some of the readable data nodes in this YANG module may be considered 297 sensitive or vulnerable in some network environments. It is thus 298 important to control read access (e.g., via get, get-config, or 299 notification) to these data nodes. These are the subtrees and data 300 nodes and their sensitivity/vulnerability: 302 TBD.(list subtrees and data nodes and state why they are sensitive) 304 6. IANA Considerations 306 IANA has assigned a new URI from the "IETF XML Registry" [RFC3688]. 308 URI: urn:ietf:params:xml:ns:yang:ietf-microwave-topology 309 Registrant Contact: The IESG 310 XML: N/A; the requested URI is an XML namespace. 312 IANA has recorded a YANG module name in the "YANG Module Names" 313 registry [RFC6020] as follows: 315 Name: ietf-microwave-topology 316 Namespace: urn:ietf:params:xml:ns:yang:ietf-microwave-topology 317 Prefix: mwtopo 318 Reference: RFC xxxx 320 7. References 322 7.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, 326 DOI 10.17487/RFC2119, March 1997, 327 . 329 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 330 DOI 10.17487/RFC3688, January 2004, 331 . 333 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 334 (TLS) Protocol Version 1.2", RFC 5246, 335 DOI 10.17487/RFC5246, August 2008, 336 . 338 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 339 the Network Configuration Protocol (NETCONF)", RFC 6020, 340 DOI 10.17487/RFC6020, October 2010, 341 . 343 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 344 and A. Bierman, Ed., "Network Configuration Protocol 345 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 346 . 348 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 349 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 350 . 352 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 353 Protocol (NETCONF) Access Control Model", RFC 6536, 354 DOI 10.17487/RFC6536, March 2012, 355 . 357 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 358 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 359 . 361 7.2. Informative References 363 [I-D.ietf-ccamp-mw-yang] 364 Ahlberg, J., Ye, M., Li, X., Spreafico, D., and M. 365 Vaupotic, "A YANG Data Model for Microwave Radio Link", 366 draft-ietf-ccamp-mw-yang-04 (work in progress), March 367 2018. 369 [I-D.ietf-teas-actn-framework] 370 Ceccarelli, D. and Y. Lee, "Framework for Abstraction and 371 Control of Traffic Engineered Networks", draft-ietf-teas- 372 actn-framework-11 (work in progress), October 2017. 374 [I-D.ietf-teas-yang-te-topo] 375 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 376 O. Dios, "YANG Data Model for Traffic Engineering (TE) 377 Topologies", draft-ietf-teas-yang-te-topo-15 (work in 378 progress), February 2018. 380 [RFC8330] Long, H., Ye, M., Mirsky, G., D'Alessandro, A., and H. 381 Shah, "OSPF Traffic Engineering (OSPF-TE) Link 382 Availability Extension for Links with Variable Discrete 383 Bandwidth", RFC 8330, DOI 10.17487/RFC8330, February 2018, 384 . 386 Appendix A. Appendix A Examples of microwave topology 388 A.1. Appendix A.1 A topology with single microwave radio link 390 Microwave is a transport technology which can be used to transport 391 client services, such as ETH. When an ETH service is transported by 392 a single microwave radio link, the topology could be shown as the 393 Figure 3. Note that the figure just shows an example, there might 394 be other possiblities to demonstrate the topology. 396 Node 1 Node 2 397 +---------------+ +---------------+ 398 | | | | 399 | +-----------+ | | +-----------+ | 400 | | LTP11 | | | | LTP21 | | --ETH topo 401 | +-------o---+ | ETH-TE-Link-1 | +---o-------+ | 402 | |---------------------------------| | 403 | | | | 404 | +-----------+ | | +-----------+ | 405 | | TTP-1 __ | | microwave tunnel-11 | | __ TTP-1 | | 406 | | \/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\/ | | 407 | | * | | | | * | | --Microwave topo 408 | | * | | microwave link 12 | | * | | 409 | | LTP-1 *o ------------------------o* LTP-1 | | 410 | | | | | | | | 411 | +-----------+ | | +-----------+ | 412 | | | | 413 +---------------+ +---------------+ 415 Figure 3: ETH transported on a single microwave radio link 417 In the above ETH topology, the ETH-TE-link is encoded in JSON as 418 below: 420 ... 421 "ietf-network-topology:link": [ 422 { 423 "link-id": "N1,LTP11,N2,LTP21", 424 "source": { 425 "source-node": "N1", 426 "source-tp": "LTP11" 427 } 428 "destination": { 429 "dest-node": "N2", 430 "dest-tp": "LTP21" 431 } 432 } 433 ] 434 "ietf-te-topology:link/te/te-link-attributes/": [ 435 { 436 "enabled": ture, 437 "primary-path":{ 438 "path-element": { 439 "path-element-id": "MW-11" 440 //no backup-path 441 //no protection-type 442 } 443 } 444 "tunnel-termination-points": { 445 "source": "N1/TTP-1", 446 "destination": "N2/TTP-1" 447 } 448 "tunnels" : { 449 "sharing": "false", 450 "tunnel":{ 451 "tunnel-name": "MW-11", 452 "sharing": "false" 453 } 454 } 455 } 456 ] 458 Note that the example above just shows the particular ETH link, not 459 the full ETH topology. 461 In the microwave topology, the microwave link is encoded in JSON as 462 below: 464 ... 465 "ietf-network-topology:link": [ 466 { 467 "link-id": "N1,LTP1,N2,LTP1", 468 "source": { 469 "source-node": "N1", 470 "source-tp": "LTP1" 471 } 472 "destination": { 473 "dest-node": "N2", 474 "dest-tp": "LTP1" 475 } 476 } 477 ] 478 "ietf-te-topology:link/te/te-link-attributes/underlay": [ 479 { 480 "mw-link-frequency": 10728000, 481 "mw-link-channel-separation": "28000", 482 "mw-link-actual-tx-cm":"qam-512", 483 "mw-link-nominal-bandwidth": "1000", 484 "mw-link-current-bandwidth": "1000", 485 "mw-link-availability":{ 486 "mw-link-availability":"0.9999", 487 "mw-link-bandwidth": "1000" 488 } 489 } 490 ] 492 A.2. Appendix A.2 A topology with microwave radio links bundling 494 When a ETH service is transported over two microwave radio links, the 495 topologies could be shown as in Figure 4. Note that the figure just 496 shows one example, there might be other possiblities to demonstrate 497 the topology. 499 Node 1 Node 2 500 +---------------+ +---------------+ 501 | | | | 502 | +-----------+ | | +-----------+ | 503 | | LTP11 | | | | LTP21 | | --ETH topo 504 | +-------o---+ | ETH-TE-Link-1 | +---o-------+ | 505 | |---------------------------------| | 506 | | | | 507 | +-----------+ | | +-----------+ | 508 | | TTP-1 __ | | microwave tunnel-11 | | __ TTP-1 | | 509 | | \/@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\/ | | 510 | | * | | | | * | | --Microwave topo 511 | | * | | mw bundled link 33 | | * | | 512 | | LTP-3 *o ------------------------o* LTP-3 | | 513 | | | | | | | | 514 | | LTP-2 o | | o LTP-2 | | 515 | | LTP-1 o | | o LTP-1 | | 516 | +-----------+ | | +-----------+ | 517 | | | | 518 +---------------+ +---------------+ 520 Figure 4: ETH transported on single microwave radio links 522 In the ETH topology, the ETH-TE-link is encoded in JSON as below: 524 ... 525 "ietf-network-topology:link": [ 526 { 527 "link-id": "N1,LTP11,N2,LTP21", 528 "source": { 529 "source-node": "N1", 530 "source-tp": "LTP11" 531 } 532 "destination": { 533 "dest-node": "N2", 534 "dest-tp": "LTP21" 535 } 536 } 537 ] 538 "ietf-te-topology:link/te/te-link-attributes/": [ 539 { 540 "enabled": ture, 541 "primary-path":{ 542 "path-element": { 543 "path-element-id": "MW-33" 544 //no backup-path 545 //no protection-type 546 } 547 } 548 "tunnel-termination-points": { 549 "source": "N1/TTP-1", 550 "destination": "N2/TTP-1" 551 } 552 "tunnels" : { 553 "sharing": "false", 554 "tunnel":{ 555 "tunnel-name": "MW-11", 556 "sharing": "false" 557 } 558 } 559 } 560 ] 562 Note that the example above just shows the specific ETH link, not the 563 full ETH topology. 565 In the microwave topology, the micorwave link is encoded in JSON as 566 below: 568 ... 569 "ietf-network-topology:link": [ 570 { 571 "link-id": "N1,LTP1,N2,LTP1", 572 "source": { 573 "source-node": "N1", 574 "source-tp": "LTP3" 575 } 576 "destination": { 577 "dest-node": "N2", 578 "dest-tp": "LTP3" 579 } 580 } 581 ] 582 "ietf-te-topology:link/te/te-link-config": [ 583 { 584 "bundle-stack-level":{ 585 "component" { 586 "component-links-1": { 587 "sequence": "mw-11", 588 "src-tp-ref": "N1-LTP1", 589 "des-tp-ref" : "N2-LTP1" 590 } 591 "component-links-2": { 592 "sequence": "mw-22", 593 "src-tp-ref": "N1-LTP2" 594 "des-tp-ref" : "N2-LTP2" 595 } 596 } 597 } 598 } 599 ] 601 Note that the example above just shows the microwave component links, 602 it doesn't show the full microwave topology. 604 Appendix B. Contributors 606 Italo Busi 607 Huawei Technologies 608 Email: italo.busi@huawei.com 610 Xufeng Liu 611 Jabil 612 Email: Xufeng_Liu@jabil.com 614 Authors' Addresses 616 Ye Min (editor) 617 Huawei Technologies 618 No.1899, Xiyuan Avenue 619 Chengdu 611731 620 P.R.China 622 Email: amy.yemin@huawei.com 624 Aihua Guo 625 Huawei Technologies 627 Email: aihuaguo@huawei.comm 629 Jonas Ahlberg 630 Ericsson AB 631 Lindholmspiren 11 632 Goteborg 417 56 633 Sweden 635 Email: jonas.ahlberg@ericsson.com 637 Xi Li 638 NEC Laboratories Europe GmbH 639 Kurfuersten-Anlage 36 640 Heidelberg 69115 641 Germany 643 Email: Xi.Li@neclab.eu 645 Daniela Spreafico 646 Nokia - IT 647 Via Energy Park, 14 648 Vimercate (MI) 20871 649 Italy 651 Email: daniela.spreafico@nokia.com