idnits 2.17.1 draft-ogondio-opsawg-ospf-topology-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 date (7 March 2022) is 781 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) == Unused Reference: 'RFC8343' is defined on line 583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG Working Group O. G. de. Dios 3 Internet-Draft S. B. Giraldo 4 Intended status: Standards Track Telefonica 5 Expires: 8 September 2022 V. Lopez 6 Nokia 7 7 March 2022 9 A YANG Data Model for Open Source Path First (OSPF) Topology 10 draft-ogondio-opsawg-ospf-topology-00 12 Abstract 14 This document defines a YANG data model for representing an abstract 15 view of the provider network topology that contains Open Source Path 16 First (OSPF) information. This document augments the 'ietf-network' 17 data model by adding OSPF concepts. 19 The YANG data model defined in this document conforms to the Network 20 Management Datastore Architecture (NMDA). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology and Notations . . . . . . . . . . . . . . . . 3 57 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 1.3. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 3 59 1.4. Prefix in Data Node Names . . . . . . . . . . . . . . . . 3 60 2. YANG Data Model for OSPF Topology . . . . . . . . . . . . . . 4 61 3. OSPF Topology Tree Diagram . . . . . . . . . . . . . . . . . 4 62 4. YANG Model for OSPF topology . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 12 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 Topology collection is a critical use case for the network operators 73 because the network topology is an abstract representation of the 74 physical nodes, links and network interconnections. Network planning 75 processes requires that the network resources are placed to meet the 76 traffic demands requirements not just in terms of bandwidth or delay, 77 but also for failure scenarios. Network operators does the network 78 planning process as an offline process, which obtains the information 79 not directly from the network, but from inventory or template 80 information. The main reason for this process was that there was a 81 lack of a dynamic and programmatic interfaces that can allow the 82 planning tools to obtain such information. 84 Thanks to the definition of the ietf-network model in [RFC8345] this 85 situation changed, because network operators can use an API with 86 dynamic topological information. On top of the work in [RFC8345], 87 [RFC8346] and [RFC8944] extends the generic network and network 88 topology data models with topology attributes that are specific to 89 Layer 3 and Layer 2. However, there is not any model that exposes 90 Open Source Path First (OSPF) information. This information is 91 required in the IP/MPLS planning process to properly assess the 92 required network resources to meet the traffic demands in normal and 93 failure scenarios. 95 The main objective of this model is to represent most relevant OSPF 96 topology attributes. 98 This document defines a YANG data model for representing, managing 99 and controlling the OSPF topology. The data model augments ietf- 100 network module [RFC8345] by adding the OSPF information. 102 This document explains the scope and purpose of the OSPF topology 103 model and how the topology and service models fit together. 105 The YANG data model defined in this document conforms to the Network 106 Management Datastore Architecture [RFC8342]. 108 1.1. Terminology and Notations 110 This document assumes that the reader is familiar with the contents 111 of [RFC8345]. The document uses terms from those documents. 113 The terminology for describing YANG data models is found in 114 [RFC7950], [RFC8795] and [RFC8346]. 116 1.2. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in 121 [RFC2119], [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 1.3. Tree Diagram 126 Authors include a simplified graphical representation of the data 127 model is used in Section 3 of this document. The meaning of the 128 symbols in these diagrams is defined in [RFC8340]. 130 1.4. Prefix in Data Node Names 132 In this document, names of data nodes and other data model objects 133 are prefixed using the standard prefix associated with the 134 corresponding YANG imported modules, as shown in the following table. 136 +========+=======================+===========+ 137 | Prefix | Yang Module | Reference | 138 +========+=======================+===========+ 139 | ospfnt | ietf-l3-ospf-topology | RFCXXX | 140 +--------+-----------------------+-----------+ 141 | yang | ietf-yang-types | [RFC6991] | 142 +--------+-----------------------+-----------+ 144 Table 1: Prefixes and corresponding YANG 145 modules 147 RFC Editor Note: Please replace XXXX with the RFC number assigned to 148 this document. Please remove this note. 150 2. YANG Data Model for OSPF Topology 152 The abstract (base) network data model is defined in the "ietf- 153 network" module of [RFC8345]. The OSPF-topology builds on the 154 network data model defined in the "ietf-network" module [RFC8345], 155 augmenting the nodes with OSPF information, which anchor the links 156 and are contained in nodes). 158 There is a set of parameters and augmentations that are included at 159 the node level. Each parameter and description are detailed 160 following: 162 * Network-types: Its presence identifies the OSPF topology type. 163 Thus, the network type MUST be ospf-topology. 165 * OSPF timer attributes: Identifies the node timer attributes 166 configured in the network element. They are wait timer, rapid 167 delay, slow delay and the timer type (linear or exponential back- 168 off). 170 * OSPF status: contains the neighbours information. 172 There is a second set of parameters and augmentations are included at 173 the link and termination point level. Each parameter is listed as 174 follows: 176 * Interface-type 178 * Area ID 180 * Metric 182 * Passive mode 184 3. OSPF Topology Tree Diagram 186 Figure 1 below shows the tree diagram of the YANG data model defined 187 in module ietf-l3-ospf-topology.yang (Section 4). 189 module: ietf-l3-ospf-topology 190 augment /nw:networks/nw:network/nw:network-types: 191 +--rw ospfv2-topology! 192 augment /nw:networks/nw:network/nw:node/ 193 l3t:l3-node-attributes: 194 +--rw ospf-timer-attributes 195 +--rw wait-timer? uint32 196 +--rw rapid-delay? uint32 197 +--rw slow-delay? uint32 198 +--rw timer-type? enumeration 199 augment /nw:networks/nw:network/nt:link/ 200 l3t:l3-link-attributes: 201 +--rw ospfv2-termination-point-attributes 202 +--rw interface-type? identityref 203 +--rw area-id? area-id-type 204 +--rw metric? uint64 205 +--rw is-passive? boolean 206 augment /nw:networks/nw:network/nw:node/nt:termination-point/ 207 l3t:l3-termination-point-attributes: 208 +--rw ospfv2-termination-point-attributes 209 +--rw interface-type? identityref 210 +--rw area-id? area-id-type 211 +--rw metric? uint64 212 +--rw is-passive? boolean 214 Figure 1: OSPF Topology tree diagram 216 4. YANG Model for OSPF topology 218 Following the YANG model is presented. 220 file "ietf-l3-ospf-topology@2022-03-07.yang" 221 module ietf-l3-ospf-topology { 222 yang-version 1.1; 223 namespace 224 "urn:ietf:params:xml:ns:yang:ietf-l3-ospf-topology"; 225 prefix "ospfnt"; 226 import ietf-yang-types { 227 prefix "yang"; 228 } 229 import ietf-network { 230 prefix "nw"; 231 } 232 import ietf-network-topology { 233 prefix "nt"; 234 } 235 import ietf-l3-unicast-topology { 236 prefix "l3t"; 238 } 240 organization 241 "IETF OPSA (Operations and Management Area) Working Group"; 242 contact 243 "WG Web: 244 WG List: 246 Editor: Oscar Gonzalez de Dios 247 248 Editor: Samier Barguil 249 250 Editor: Victor Lopez 251 "; 252 description 253 "This module defines a model for Layer 3 OSPF 254 topologies. 256 Copyright (c) 2022 IETF Trust and the persons identified as 257 authors of the code. All rights reserved. 259 Redistribution and use in source and binary forms, with or 260 without modification, is permitted pursuant to, and subject to 261 the license terms contained in, the Revised BSD License set 262 forth in Section 4.c of the IETF Trust's Legal Provisions 263 Relating to IETF Documents 264 (https://trustee.ietf.org/license-info). 266 This version of this YANG module is part of RFC XXXX 267 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself 268 for full legal notices."; 270 revision 2022-03-07 { 271 description 272 "Initial version"; 273 reference 274 "RFC XXXX: A YANG Data Model for Open Source Path First 275 (OSPF) Topology"; } 277 typedef area-id-type { 278 type yang:dotted-quad; 279 description 280 "An identifier for the OSPFv2 area."; 281 reference 282 "RFC 2328: OSPF Version 2"; 283 } 285 identity inf-type { 286 description 287 "Identity for the OSPF interface type."; 288 reference 289 "RFC 2328: OSPF Version 2"; 290 } 292 identity nbma { 293 base inf-type; 294 description 295 "Identity for the NBMA interface."; 296 reference 297 "RFC 2328: OSPF Version 2"; 298 } 300 identity p2mp { 301 base inf-type; 302 description 303 "Identity for the p2mp interface."; 304 reference 305 "RFC 2328: OSPF Version 2"; 306 } 307 identity p2mp-over-lan { 308 base inf-type; 309 description 310 "Identity for the p2mp-over-lan interface."; 311 reference 312 "RFC 2328: OSPF Version 2"; 313 } 315 identity p2p { 316 base inf-type; 317 description 318 "Identity for the p2p interface."; 319 reference 320 "RFC 2328: OSPF Version 2"; 321 } 323 grouping ospfv2-topology-type { 324 description "Identifies the topology type to be OSPF v2."; 325 container ospfv2-topology { 326 presence "indicates OSPF v2 topology"; 327 description 328 "The presence of the container node indicates OSPF v2 329 topology"; 330 } 331 } 333 grouping ospfv2-node-attributes { 334 description "OSPF v2 node scope attributes"; 335 container ospf-timer-attributes { 336 description 337 "Contains OSPFv2 node timer attributes"; 338 leaf wait-timer { 339 type uint32; 340 units msec; 341 description 342 "The amount of time to wait without detecting SPF 343 trigger events before going back to the rapid delay."; 344 reference 345 "RFC 8541: SPF Impact on IGP Micro-loops"; 346 } 347 leaf rapid-delay { 348 type uint32; 349 units msec; 350 description 351 "The amount of time to wait before running SPF after 352 the initial SPF trigger event."; 353 reference 354 "RFC 8541: SPF Impact on IGP Micro-loops"; 355 } 356 leaf slow-delay { 357 type uint32; 358 units msec; 359 description 360 "The amount of time to wait before running an SPF."; 361 reference 362 "RFC 8541: SPF Impact on IGP Micro-loops"; 363 } 364 leaf timer-type { 365 type enumeration { 366 enum LINEAR_BACKOFF { 367 description 368 "The link state routing protocol uses linear 369 back-off."; 370 } 371 enum EXPONENTIAL_BACKOFF { 372 description 373 "The link state routing protocol uses exponential 374 back-off."; 375 } 376 } 377 description 378 "The timer mode that is utilised by the SPF algorithm."; 379 reference 380 "RFC 8541: SPF Impact on IGP Micro-loops"; 381 } 383 } 384 } 386 grouping ospfv2-termination-point-attributes { 387 description "OSPF termination point scope attributes"; 388 container ospfv2-termination-point-attributes { 389 description 390 "Indicates the termination point from the 391 which the OSPF is configured. A termination 392 point can be a physical port, an interface, etc."; 393 leaf interface-type { 394 type identityref { 395 base inf-type ; 396 } 397 description 398 "OSPF interface type."; 399 reference 400 "RFC 2328: OSPF Version 2"; 401 } 402 leaf area-id { 403 type area-id-type; 404 description 405 "An identifier for the OSPFv2 area."; 406 reference 407 "RFC 2328: OSPF Version 2"; 408 } 409 leaf metric { 410 type uint64; 411 description 412 "OSFP Protocol metric"; 413 reference 414 "RFC 2328: OSPF Version 2"; 415 } 416 leaf is-passive{ 417 type boolean; 418 description 419 "Interface passive mode"; 420 reference 421 "RFC 2328: OSPF Version 2"; 422 } 423 } 424 } 426 augment "/nw:networks/nw:network/nw:network-types" { 427 description 428 "Introduces new network type for L3 Unicast topology"; 429 uses ospfv2-topology-type; 430 } 431 augment "/nw:networks/nw:network/nw:node/" 432 +"l3t:l3-node-attributes" { 433 when 434 "/nw:networks/nw:network/nw:network-types/" 435 +"ospfnt:ospfv2-topology" { 436 description 437 "Augmentation parameters apply only for networks with 438 OSPF topology"; 439 } 440 description 441 "OSPF node-level attributes "; 442 uses ospfv2-node-attributes; 443 } 445 augment "/nw:networks/nw:network/" 446 + "nt:link/l3t:l3-link-attributes" { 447 when "/nw:networks/nw:network/nw:network-types/" 448 +"ospfnt:ospfv2-topology" { 449 description 450 "Augmentation parameters apply only for networks with 451 OSFP topology"; 452 } 453 description "Augments topology link configuration"; 454 uses ospfv2-termination-point-attributes; 455 } 457 augment "/nw:networks/nw:network/nw:node/" 458 +"nt:termination-point/l3t:l3-termination-point-attributes" { 459 when "/nw:networks/nw:network/nw:network-types/" 460 +"ospfnt:ospfv2-topology" { 461 description 462 "Augmentation parameters apply only for networks with 463 OSFP topology"; 464 } 465 description "Augments topology termination point configuration"; 466 uses ospfv2-termination-point-attributes; 467 } 468 } 469 471 Figure 2: OSPF Topology YANG module 473 5. Security Considerations 475 The YANG module specified in this document defines a schema for data 476 that is designed to be accessed via network management protocols such 477 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 478 is the secure transport layer, and the mandatory-to-implement secure 479 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 480 is HTTPS, and the mandatory-to-implement secure transport is TLS 481 [RFC5246]. 483 The NETCONF access control model [RFC6536] provides the means to 484 restrict access for particular NETCONF or RESTCONF users to a 485 preconfigured subset of all available NETCONF or RESTCONF protocol 486 operations and content. 488 There are a number of data nodes defined in this YANG module that are 489 writable/creatable/deletable (i.e., config true, which is the 490 default). These data nodes may be considered sensitive or vulnerable 491 in some network environments. Write operations (e.g., edit-config) 492 to these data nodes without proper protection can have a negative 493 effect on network operations. 495 6. IANA Considerations 497 This document registers the following namespace URIs in the IETF XML 498 registry [RFC3688]: 500 -------------------------------------------------------------------- 501 URI: urn:ietf:params:xml:ns:yang:ietf-l3-ospf-topology 502 Registrant Contact: The IESG. 503 XML: N/A, the requested URI is an XML namespace. 504 -------------------------------------------------------------------- 506 This document registers the following YANG module in the YANG Module 507 Names registry [RFC6020]: 509 -------------------------------------------------------------------- 510 name: ietf-l3-ospf-topology 511 namespace: urn:ietf:params:xml:ns:yang:ietf-l3-ospf-topology 512 maintained by IANA: N 513 prefix: ietf-l3-ospf-topology 514 reference: RFC XXXX 515 -------------------------------------------------------------------- 517 7. Implementation Status 519 This section will be used to track the status of the implementations 520 of the model. It is aimed at being removed if the document becomes 521 RFC. 523 8. Normative References 525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 526 Requirement Levels", BCP 14, RFC 2119, 527 DOI 10.17487/RFC2119, March 1997, 528 . 530 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 531 DOI 10.17487/RFC3688, January 2004, 532 . 534 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 535 (TLS) Protocol Version 1.2", RFC 5246, 536 DOI 10.17487/RFC5246, August 2008, 537 . 539 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 540 the Network Configuration Protocol (NETCONF)", RFC 6020, 541 DOI 10.17487/RFC6020, October 2010, 542 . 544 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 545 and A. Bierman, Ed., "Network Configuration Protocol 546 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 547 . 549 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 550 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 551 . 553 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 554 Protocol (NETCONF) Access Control Model", RFC 6536, 555 DOI 10.17487/RFC6536, March 2012, 556 . 558 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 559 RFC 6991, DOI 10.17487/RFC6991, July 2013, 560 . 562 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 563 RFC 7950, DOI 10.17487/RFC7950, August 2016, 564 . 566 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 567 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 568 . 570 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 571 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 572 May 2017, . 574 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 575 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 576 . 578 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 579 and R. Wilton, "Network Management Datastore Architecture 580 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 581 . 583 [RFC8343] Bjorklund, M., "A YANG Data Model for Interface 584 Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, 585 . 587 [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., 588 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 589 Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 590 2018, . 592 [RFC8346] Clemm, A., Medved, J., Varga, R., Liu, X., 593 Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model 594 for Layer 3 Topologies", RFC 8346, DOI 10.17487/RFC8346, 595 March 2018, . 597 [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 598 O. Gonzalez de Dios, "YANG Data Model for Traffic 599 Engineering (TE) Topologies", RFC 8795, 600 DOI 10.17487/RFC8795, August 2020, 601 . 603 [RFC8944] Dong, J., Wei, X., Wu, Q., Boucadair, M., and A. Liu, "A 604 YANG Data Model for Layer 2 Network Topologies", RFC 8944, 605 DOI 10.17487/RFC8944, November 2020, 606 . 608 Acknowledgments 610 The authors of this document would like to thank XXX. 612 This document was prepared using kramdown. 614 Authors' Addresses 616 Oscar González de Dios 617 Telefonica 618 Email: oscar.gonzalezdedios@telefonica.com 620 Samier Barguil Giraldo 621 Telefonica 622 Email: samier.barguilgiraldo.ext@telefonica.com 624 Victor Lopez 625 Nokia 626 Email: victor.lopez@nokia.com