idnits 2.17.1 draft-ietf-i2rs-yang-l3-topology-13.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 : ---------------------------------------------------------------------------- ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 235 has weird spacing: '... prefix ine...' -- The document date (November 15, 2017) is 2346 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: 'RFC1195' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 800, but no explicit reference was found in the text == Unused Reference: 'RFC7223' is defined on line 854, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-i2rs-yang-network-topo-18 == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-02 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-10) exists of draft-acee-rtgwg-yang-rib-extend-04 == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-12 -- Obsolete informational reference (is this intentional?): RFC 7223 (Obsoleted by RFC 8343) -- Obsolete informational reference (is this intentional?): RFC 8022 (Obsoleted by RFC 8349) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Clemm 3 Internet-Draft Huawei 4 Intended status: Standards Track J. Medved 5 Expires: May 19, 2018 Cisco 6 R. Varga 7 Pantheon Technologies SRO 8 X. Liu 9 Jabil 10 H. Ananthakrishnan 11 Packet Design 12 N. Bahadur 13 Bracket Computing 14 November 15, 2017 16 A YANG Data Model for Layer 3 Topologies 17 draft-ietf-i2rs-yang-l3-topology-13.txt 19 Abstract 21 This document defines a YANG data model for layer 3 network 22 topologies. 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 May 19, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 61 4. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5 63 6. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7 64 7. Interactions with Other YANG Modules . . . . . . . . . . . . 15 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 67 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 71 12.2. Informative References . . . . . . . . . . . . . . . . . 18 72 Appendix A. Companion YANG model for non-NMDA compliant 73 implementations . . . . . . . . . . . . . . . . . . 20 74 Appendix B. Extending the Model . . . . . . . . . . . . . . . . 24 75 B.1. Example OSPF Topology . . . . . . . . . . . . . . . . . . 24 76 B.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 24 77 B.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 26 78 Appendix C. An Example . . . . . . . . . . . . . . . . . . . . . 30 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 81 1. Introduction 83 This document introduces a YANG [RFC7950] [RFC6991] data model for 84 Layer 3 network topologies, specifically Layer 3 Unicast. The model 85 allows an application to have a holistic view of the topology of a 86 Layer 3 network, all contained in a single conceptual YANG datastore. 87 The data model builds on top of, and augments, the data model for 88 network topologies defined in 89 [I-D.draft-ietf-i2rs-yang-network-topo]. 91 This document also shows how the model can be further refined to 92 cover different Layer 3 Unicast topology types. For this purpose, 93 example model is introduced that covers OSPF [RFC2328]. This example 94 is intended purely for illustrative purpose; we expect that full- 95 blown OSPF model will be more comprehensive and refined than the 96 example shown here. 98 There are multiple applications for a topology data model. A number 99 of use cases have been defined in section 6 of 100 [I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes 101 within the network can use the data model to capture their 102 understanding of the overall network topology and expose it to a 103 network controller. A network controller can then use the 104 instantiated topology data to compare and reconcile its own view of 105 the network topology with that of the network elements that it 106 controls. Alternatively, nodes within the network could propagate 107 this understanding to compare and reconcile this understanding either 108 amongst themselves or with help of a controller. Beyond the network 109 element itself, a network controller might even use the data model to 110 represent its view of the topology that it controls and expose it to 111 applications north of itself. 113 The data model for Layer 3 Unicast topologies defined in this 114 document is specified in a YANG module "ietf-l3-unicast-topology". 115 To do so, it augments general network topology model defined in 116 [I-D.draft-ietf-i2rs-yang-network-topo] with information specific to 117 Layer 3 Unicast. This way, the general topology model is extended to 118 be able to meet the needs of Layer 3 Unicast topologies. 120 Information that is kept in the Traffic Engineering Database (TED) 121 will be specified in a separate model 122 [I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this 123 specification. 125 2. Key Words 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Definitions and Acronyms 135 As this document defines a YANG data model, in this document many 136 terms are used that have been defined in conjunction with YANG 137 [RFC7950] and NETCONF [RFC6241]. Some terms, such as datastore and 138 data tree, are repeated here for clarity and to put them in context. 140 Datastore: A conceptual place to store and access information. A 141 datastore might be implemented, for example, using files, a database, 142 flash memory locations, or combinations thereof. A datastore maps to 143 an instantiated YANG data tree. (Definition adopted from 144 [I-D.draft-ietf-netmod-revised-datastores]) 145 Data subtree: An instantiated data node and the data nodes that are 146 hierarchically contained within it. 148 IGP: Interior Gateway Protocol 150 IS-IS: Intermediate System to Intermediate System protocol 152 LSP: Label Switched Path 154 NETCONF: Network Configuration Protocol 156 NMDA: Network Management Datastore Architecture 158 OSPF: Open Shortest Path First, a link state routing protocol 160 URI: Uniform Resource Identifier 162 SRLG: Shared Risk Link Group 164 TED: Traffic Engineering Database 166 YANG: A data definition language for NETCONF 168 4. Model Structure 170 The Layer 3 Unicast topology model is defined by YANG module "l3- 171 unicast-topology". The relationship of this module with other YANG 172 modules is roughly depicted in the figure below. 174 +-----------------------------+ 175 | +-----------------------+ | 176 | | ietf-network | | 177 | +----------^------------+ | 178 | | | 179 | +-----------------------+ | 180 | | ietf-network-topology | | 181 | +----------+------------+ | 182 +-------------^---------------+ 183 | 184 | 185 +-----------^-------------+ 186 | L3-UNICAST-TOPOLOGY | 187 +----+------^--------+----+ 188 | 189 | 190 +-------^-------+ 191 | ospf-topology | 192 +---------------+ 194 Figure 1: Overall model structure 196 YANG modules "ietf-network" and "ietf-network-topology" collectively 197 define the basic network topology model. YANG module "ietf-l3- 198 unicast-topology" augments those models with additional definitions 199 needed to represent Layer 3 Unicast topologies. This module in turn 200 can be augmented by YANG modules with additional definitions for 201 specific types of Layer 3 Unicast topologies, such as OSPF and for 202 IS-IS topologies. 204 The YANG modules ietf-network and ietf-network are designed to be 205 used in conjunction with implementations that support the Network 206 Management Datastore Architecture (NMDA) defined in 207 [I-D.draft-ietf-netmod-revised-datastores]. Accordingly, the same is 208 true for the YANG modules that augment it. In order to allow 209 implementations to use the model even in cases when NMDA is not 210 supported, companion YANG modules (that SHOULD NOT be supported by 211 implementations that support NMDA) are defined in an Appendix, see 212 Appendix A. 214 5. Layer 3 Unicast Topology Model Overview 216 The Layer 3 Unicast topology model is defined by YANG module "ietf- 217 l3-unicast-topology". Its structure is depicted in the following 218 diagram. The notation syntax follows 219 [I-D.draft-ietf-netmod-yang-tree-diagrams]. For purposes of brevity, 220 notifications are not depicted. 222 module: ietf-l3-unicast-topology 223 augment /nw:networks/nw:network/nw:network-types: 224 +--rw l3-unicast-topology! 225 augment /nw:networks/nw:network: 226 +--rw l3-topology-attributes 227 +--rw name? string 228 +--rw flag* l3-flag-type 229 augment /nw:networks/nw:network/nw:node: 230 +--rw l3-node-attributes 231 +--rw name? inet:domain-name 232 +--rw flag* node-flag-type 233 +--rw router-id* inet:ip-address 234 +--rw prefix* [prefix] 235 +--rw prefix inet:ip-prefix 236 +--rw metric? uint32 237 +--rw flag* prefix-flag-type 238 augment /nw:networks/nw:network/nt:link: 239 +--rw l3-link-attributes 240 +--rw name? string 241 +--rw flag* link-flag-type 242 +--rw metric1? uint64 243 +--rw metric2? uint64 244 augment /nw:networks/nw:network/nw:node/nt:termination-point: 245 +--rw l3-termination-point-attributes 246 +--rw (termination-point-type)? 247 +--:(ip) 248 | +--rw ip-address* inet:ip-address 249 +--:(unnumbered) 250 | +--rw unnumbered-id? uint32 251 +--:(interface-name) 252 +--rw interface-name? string 254 The module augments the original ietf-network and ietf-network- 255 topology modules as follows: 257 o A new network topology type is introduced, l3-unicast-topology. 258 The corresponding container augments the network-types of the 259 ietf-network module. 261 o Additional topology attributes are introduced, defined in a 262 grouping, which augments the "network" list of the network module. 263 The attributes include a name for the topology, as well as a set 264 of flags (represented through a leaf-list). Each type of flag is 265 represented by a separate identity. This allows to introduce 266 additional flags in augmenting modules using additional identities 267 without needing to revise this module. 269 o Additional data objects for nodes are introduced by augmenting the 270 "node" list of the network module. New objects include again a 271 set of flags, as well as a list of prefixes. Each prefix in turn 272 includes an ip prefix, a metric, and a prefix-specific set of 273 flags. 275 o Links (in the ietf-network-topology module) are augmented with a 276 set of parameters as well, allowing to associate a link with a 277 link name, another set of flags, and a link metric. 279 o Termination points (in the ietf-network-topology module as well) 280 are augmented with a choice of IP address, identifier, or name. 282 In addition, the module defines a set of notifications to alert 283 clients of any events concerning links, nodes, prefixes, and 284 termination points. Each notification includes an indication of the 285 type of event, the topology from which it originated, and the 286 affected node, or link, or prefix, or termination point. In 287 addition, as a convenience to applications, additional data of the 288 affected node, or link, or termination point (respectively) is 289 included. While this makes notifications larger in volume than they 290 would need to be, it avoids the need for subsequent retrieval of 291 context information, which also might have changed in the meantime. 293 6. Layer 3 Unicast Topology YANG Module 295 file "ietf-l3-unicast-topology@2017-11-15.yang" 296 module ietf-l3-unicast-topology { 297 yang-version 1.1; 298 namespace 299 "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology"; 300 prefix "l3t"; 301 import ietf-network { 302 prefix "nw"; 303 } 304 import ietf-network-topology { 305 prefix "nt"; 306 } 307 import ietf-inet-types { 308 prefix "inet"; 309 } 310 organization 311 "IETF I2RS (Interface to the Routing System) Working Group"; 312 contact 313 "WG Web: 314 WG List: 315 Editor: Alexander Clemm 316 318 Editor: Jan Medved 319 320 Editor: Robert Varga 321 322 Editor: Xufeng Liu 323 324 Editor: Nitin Bahadur 325 326 Editor: Hariharan Ananthakrishnan 327 "; 328 description 329 "This module defines a model for Layer 3 Unicast 330 topologies. 331 Copyright (c) 2017 IETF Trust and the persons identified as 332 authors of the code. All rights reserved. 333 Redistribution and use in source and binary forms, with or 334 without modification, is permitted pursuant to, and subject 335 to the license terms contained in, the Simplified BSD License 336 set forth in Section 4.c of the IETF Trust's Legal Provisions 337 Relating to IETF Documents 338 (http://trustee.ietf.org/license-info). 339 This version of this YANG module is part of 340 draft-ietf-i2rs-yang-l3-topology-13; 341 see the RFC itself for full legal notices. 342 NOTE TO RFC EDITOR: Please replace above reference to 343 draft-ietf-i2rs-yang-l3-topology-13 with RFC 344 number when published (i.e. RFC xxxx)."; 345 revision "2017-11-15" { 346 description 347 "Initial revision. 348 NOTE TO RFC EDITOR: Please replace the following reference 349 to draft-ietf-i2rs-yang-l3-topology-13 with 350 RFC number when published (i.e. RFC xxxx)."; 351 reference 352 "draft-ietf-i2rs-yang-l3-topology-13"; 353 } 355 identity flag-identity { 356 description "Base type for flags"; 357 } 359 typedef l3-event-type { 360 type enumeration { 361 enum "add" { 362 description 363 "An Layer 3 node or link or prefix or termination-point has 364 been added"; 365 } 366 enum "remove" { 367 description 368 "An Layer 3 node or link or prefix or termination-point has 369 been removed"; 370 } 371 enum "update" { 372 description 373 "An Layer 3 node or link or prefix or termination-point has 374 been updated"; 375 } 376 } 377 description "Layer 3 Event type for notifications"; 378 } 380 typedef prefix-flag-type { 381 type identityref { 382 base "flag-identity"; 383 } 384 description "Prefix flag attributes"; 385 } 387 typedef node-flag-type { 388 type identityref { 389 base "flag-identity"; 390 } 391 description "Node flag attributes"; 392 } 394 typedef link-flag-type { 395 type identityref { 396 base "flag-identity"; 397 } 398 description "Link flag attributes"; 399 } 401 typedef l3-flag-type { 402 type identityref { 403 base "flag-identity"; 404 } 405 description "L3 flag attributes"; 406 } 408 grouping l3-prefix-attributes { 409 description 410 "L3 prefix attributes"; 411 leaf prefix { 412 type inet:ip-prefix; 413 description 414 "IP prefix value"; 415 } 416 leaf metric { 417 type uint32; 418 description 419 "Prefix metric"; 420 } 421 leaf-list flag { 422 type prefix-flag-type; 423 description 424 "Prefix flags"; 425 } 426 } 427 grouping l3-unicast-topology-type { 428 description "Identify the topology type to be L3 unicast."; 429 container l3-unicast-topology { 430 presence "indicates L3 Unicast Topology"; 431 description 432 "The presence of the container node indicates L3 Unicast 433 Topology"; 434 } 435 } 436 grouping l3-topology-attributes { 437 description "Topology scope attributes"; 438 container l3-topology-attributes { 439 description "Containing topology attributes"; 440 leaf name { 441 type string; 442 description 443 "Name of the topology"; 444 } 445 leaf-list flag { 446 type l3-flag-type; 447 description 448 "Topology flags"; 449 } 450 } 451 } 452 grouping l3-node-attributes { 453 description "L3 node scope attributes"; 454 container l3-node-attributes { 455 description 456 "Containing node attributes"; 457 leaf name { 458 type inet:domain-name; 459 description 460 "Node name"; 461 } 462 leaf-list flag { 463 type node-flag-type; 464 description 465 "Node flags"; 466 } 467 leaf-list router-id { 468 type inet:ip-address; 469 description 470 "Router-id for the node"; 471 } 472 list prefix { 473 key "prefix"; 474 description 475 "A list of prefixes along with their attributes"; 476 uses l3-prefix-attributes; 477 } 478 } 479 } 480 grouping l3-link-attributes { 481 description 482 "L3 link scope attributes"; 483 container l3-link-attributes { 484 description 485 "Containing link attributes"; 486 leaf name { 487 type string; 488 description 489 "Link Name"; 490 } 491 leaf-list flag { 492 type link-flag-type; 493 description 494 "Link flags"; 495 } 496 leaf metric1 { 497 type uint64; 498 description 499 "Link Metric 1"; 500 } 501 leaf metric2 { 502 type uint64; 503 description 504 "Link Metric 2"; 505 } 506 } 507 } 508 grouping l3-termination-point-attributes { 509 description "L3 termination point scope attributes"; 510 container l3-termination-point-attributes { 511 description 512 "Containing termination point attributes"; 513 choice termination-point-type { 514 description 515 "Indicates the termination point type"; 516 case ip { 517 leaf-list ip-address { 518 type inet:ip-address; 519 description 520 "IPv4 or IPv6 address."; 521 } 522 } 523 case unnumbered { 524 leaf unnumbered-id { 525 type uint32; 526 description 527 "Unnumbered interface identifier. 528 The identifier will correspond to the ifIndex value 529 of the interface, i.e. the ifIndex value of the 530 ifEntry that represents the interface in 531 implementations where the Interfaces Group MIB 532 (RFC 2863) is supported."; 533 reference 534 "RFC 2863: The Interfaces Group MIB"; 535 } 536 } 537 case interface-name { 538 leaf interface-name { 539 type string; 540 description 541 "A name of the interface. The name can (but does not 542 have to) correspond to an interface reference of a 543 containing node's interface, i.e. the path name of a 544 corresponding interface data node on the containing 545 node reminiscent of data type if-ref defined in 546 RFC 7223. It should be noted that data type if-ref of 547 RFC 7223 cannot be used directly, as this data type 548 is used to reference an interface in a datastore of 549 a single node in the network, not to uniquely 550 reference interfaces across a network."; 551 } 552 } 553 } 554 } 555 } 556 augment "/nw:networks/nw:network/nw:network-types" { 557 description 558 "Introduce new network type for L3 unicast topology"; 559 uses l3-unicast-topology-type; 560 } 561 augment "/nw:networks/nw:network" { 562 when "nw:network-types/l3-unicast-topology" { 563 description 564 "Augmentation parameters apply only for networks with 565 L3 unicast topology"; 566 } 567 description 568 "L3 unicast for the network as a whole"; 569 uses l3-topology-attributes; 570 } 571 augment "/nw:networks/nw:network/nw:node" { 572 when "../nw:network-types/l3-unicast-topology" { 573 description 574 "Augmentation parameters apply only for networks with 575 L3 unicast topology"; 576 } 577 description 578 "L3 unicast node level attributes "; 579 uses l3-node-attributes; 580 } 581 augment "/nw:networks/nw:network/nt:link" { 582 when "../nw:network-types/l3-unicast-topology" { 583 description 584 "Augmentation parameters apply only for networks with 585 L3 unicast topology"; 586 } 587 description 588 "Augment topology link attributes"; 589 uses l3-link-attributes; 590 } 591 augment "/nw:networks/nw:network/nw:node/" 592 +"nt:termination-point" { 593 when "../../nw:network-types/l3-unicast-topology" { 594 description 595 "Augmentation parameters apply only for networks with 596 L3 unicast topology"; 597 } 598 description "Augment topology termination point configuration"; 599 uses l3-termination-point-attributes; 600 } 601 notification l3-node-event { 602 description 603 "Notification event for L3 node"; 604 leaf l3-event-type { 605 type l3-event-type; 606 description 607 "Event type"; 608 } 609 uses nw:node-ref; 610 uses l3-unicast-topology-type; 611 uses l3-node-attributes; 612 } 613 notification l3-link-event { 614 description 615 "Notification event for L3 link"; 616 leaf l3-event-type { 617 type l3-event-type; 618 description 619 "Event type"; 620 } 621 uses nt:link-ref; 622 uses l3-unicast-topology-type; 623 uses l3-link-attributes; 624 } 625 notification l3-prefix-event { 626 description 627 "Notification event for L3 prefix"; 628 leaf l3-event-type { 629 type l3-event-type; 630 description 631 "Event type"; 632 } 633 uses nw:node-ref; 634 uses l3-unicast-topology-type; 635 container prefix { 636 description 637 "Containing L3 prefix attributes"; 638 uses l3-prefix-attributes; 639 } 640 } 641 notification termination-point-event { 642 description 643 "Notification event for L3 termination point"; 644 leaf l3-event-type { 645 type l3-event-type; 646 description 647 "Event type"; 648 } 649 uses nt:tp-ref; 650 uses l3-unicast-topology-type; 651 uses l3-termination-point-attributes; 652 } 653 } 654 656 7. Interactions with Other YANG Modules 658 As described in section Section 4, the model builds on top of, and 659 augments, the YANG modules defined in 660 [I-D.draft-ietf-i2rs-yang-network-topo]. Specifically, module ietf- 661 l3-unicast-topology augments modules "ietf-network" and "ietf- 662 network-topology". In addition, the model makes use of data types 663 that have been defined in [RFC6991]. 665 The moodel defines a protocol independent YANG data model with layer 666 3 topology information. It is separate from and not linked with data 667 models that are used to configure routing protocols or routing 668 information. This includes e.g. model "ietf-routing" [RFC8022] and 669 model "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend]. 671 The model obeys the requirements for the ephemeral state found in the 672 document [RFC8242]. For ephemeral topology data that is server 673 provided, the process tasked with maintaining topology information 674 will load information from the routing process (such as OSPF) into 675 the data model without relying on a configuration datastore. 677 8. IANA Considerations 679 This document registers the following namespace URIs in the "IETF XML 680 Registry" [RFC3688]: 682 URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology 683 Registrant Contact: The IESG. 684 XML: N/A; the requested URI is an XML namespace. 686 URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 687 Registrant Contact: The IESG. 688 XML: N/A; the requested URI is an XML namespace. 690 This document registers the following YANG modules in the "YANG 691 Module Names" registry [RFC6020]: 693 Name: ietf-l3-unicast-topology 694 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology 695 Prefix: l3t 696 Reference: draft-ietf-i2rs-yang-l3-topology-13.txt (RFC form) 698 Name: ietf-l3-unicast-topology-state 699 Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 700 Prefix: l3t-s 701 Reference: draft-ietf-i2rs-yang-l3-topology-13.txt (RFC form) 703 9. Security Considerations 705 The YANG module defined in this document is designed to be accessed 706 via network management protocols such as NETCONF [RFC6241] or 707 RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport 708 layer, and the mandatory-to-implement secure transport is Secure 709 Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the 710 mandatory-to-implement secure transport is TLS [RFC5246]. 712 The NETCONF access control model [RFC6536] provides the means to 713 restrict access for particular NETCONF or RESTCONF users to a 714 preconfigured subset of all available NETCONF or RESTCONF protocol 715 operations and content. 717 In general, Layer 3 Unicast topologies are system-controlled and 718 provide ephemeral topology information. In an NMDA-complient server, 719 they are only part of which provides read-only access 720 to clients, they are less vulnerable. That said, the YANG module 721 does in principle allow information to be configurable. 723 There are a number of data nodes defined in this YANG module that are 724 writable/creatable/deletable (i.e., config true, which is the 725 default). These data nodes may be considered sensitive or vulnerable 726 in some network environments. Write operations (e.g., edit-config) 727 to these data nodes without proper protection can have a negative 728 effect on network operations. These are the subtrees and data nodes 729 and their sensitivity/vulnerability in the ietf-network module: 731 l3-topology-attributes: A malicious client could attempt to 732 sabotage the configuration of any of the ctonained attributes, 733 i.e. the name or the flag data nodes. 735 l3-node-attributes: A malicious client could attempt to sabotage 736 the configuration of important node attributes, such as the 737 router-id or node prefix. 739 l3-link-attributes: A malicious client could attempt to sabotage 740 the configuration of important link attributes, such as name, 741 flag, and metrics of the link respectively corresponding data 742 nodes. 744 l3-termination-point-attributes: A malicious client could attempt 745 to sabotage the configuration information of a termination point, 746 such as its ip-address and interface name, respectively the 747 corresponding data nodes. 749 10. Contributors 751 The model presented in this document was contributed to by more 752 people than can be listed on the author list. Additional 753 contributors include: 755 o Vishnu Pavan Beeram, Juniper 757 o Igor Bryskin, Huawei 759 o Ken Gray, Cisco 761 o Aihua Guo, Huawei 763 o Tom Nadeau, Brocade 765 o Tony Tkacik 767 o Aleksandr Zhdankin, Cisco 769 11. Acknowledgements 771 We wish to acknowledge the helpful contributions, comments, and 772 suggestions that were received from Alia Atlas, Andy Bierman, Benoit 773 Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, Carl Moberg, 774 Carlos Pignataro, Juergen Schoenwaelder, and Kent Watsen. 776 12. References 778 12.1. Normative References 780 [I-D.draft-ietf-i2rs-yang-network-topo] 781 Clemm, A., Medved, J., Varga, R., Bahadur, N., 782 Ananthakrishnan, H., and X. Liu, "A YANG Data Model for 783 Network Topologies", I-D draft-ietf-i2rs-yang-network- 784 topo-18, November 2017. 786 [I-D.draft-ietf-netmod-revised-datastores] 787 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 788 and R. Wilton, "A Revised Conceptual Model for YANG 789 Datastores", I-D draft-ietf-netmod-revised-datastores-02, 790 May 2017. 792 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 793 Dual Environments", RFC 1195, December 1990. 795 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 796 requirement levels", RFC 2119, March 1997. 798 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 800 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 801 MIB", RFC 2863, June 2000. 803 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 804 2004. 806 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 807 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 809 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 810 Network Configuration Protocol (NETCONF)", RFC 6020, 811 October 2010. 813 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 814 Bierman, "Network Configuration Protocol (NETCONF)", 815 RFC 6241, June 2011. 817 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 818 Shell (SSH)", RFC 6242, June 2011. 820 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 821 Protocol (NETCONF) Access Control Model", RFC 6536, March 822 2012. 824 [RFC6991] Schoenwaelder, J., "Common YANG Data Types", RFC 6991, 825 July 2013. 827 [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", 828 RFC 7950, August 2016. 830 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 831 RFC 7951, August 2016. 833 12.2. Informative References 835 [I-D.draft-acee-rtgwg-yang-rib-extend] 836 Lindem, A. and Y. Qu, "YANG Data Model for RIB 837 Extensions", I-D draft-acee-rtgwg-yang-rib-extend-04, 838 October 2017. 840 [I-D.draft-ietf-i2rs-usecase-reqs-summary] 841 Hares, S. and M. Chen, "Summary of I2RS Use Case 842 Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 843 03, November 2016. 845 [I-D.draft-ietf-netmod-yang-tree-diagrams] 846 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D 847 draft-ietf-netmod-yang-tree-diagrams, June 2017. 849 [I-D.draft-ietf-teas-yang-te-topo] 850 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 851 O. Gonzalez De Dios, "YANG Data Model for TE Topologies", 852 I-D draft-ietf-teas-yang-te-topo-12, July 2017. 854 [RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management", 855 RFC 7223, May 2014. 857 [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 858 Management", RFC 8022, November 2016. 860 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 861 Protocol", RFC 8040, January 2017. 863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 864 2119 Key Words", RFC 8174, May 2017. 866 [RFC8242] Haas, J. and S. Hares, "I2RS Ephemeral State 867 Requirements", RFC 8242, September 2017. 869 Appendix A. Companion YANG model for non-NMDA compliant implementations 871 The YANG module ietf-l3-unicast-topology defined in this document 872 augments two modules, ietf-network and ietf-network-topology, that 873 are designed to be used in conjunction with implementations that 874 support the Network Management Datastore Architecture (NMDA) defined 875 in [I-D.draft-ietf-netmod-revised-datastores]. In order to allow 876 implementations to use the model even in cases when NMDA is not 877 supported, a set of companion modules have been defined that 878 represent a state model of networks and network topologies, ietf- 879 network-state and ietf-network-topology-state, respectively. 881 In order to be able to use the model for layer 3 topologies defined 882 in this in this document in conjunction with non-NMDA compliant 883 implementations, a corresponding companion module needs to be 884 introduced as well. This companion module, ietf-l3-unicast-topology- 885 state, mirrors ietf-l3-unicast-topology. However, the module 886 augments ietf-network-state and ietf-network-topology-state (instead 887 of ietf-network and ietf-network-topology) and all of its data nodes 888 are non-configurable. 890 Similar considerations apply for any modules that augment ietf-l3- 891 unicast-topology, such as the example modules defined in see 892 Appendix B, example-ietf-ospf-topology. For non-NMDA compliant 893 implementations, companion modules will need to be introduced that 894 represent state information and are non-configurable, augmenting 895 ietf-l3-unicast-topology-state instead of ietf-l3-unicast-topology. 896 Because they served as examples only, companion modules for those 897 examples are not given. 899 Like ietf-network-state and ietf-network-topology-state, ietf-l3- 900 unicast-topology SHOULD NOT be supported by implementations that 901 support NMDA. It is for this reason that the module is defined in 902 the Appendix. 904 The definition of the module follows below. As the structure of the 905 module mirrors that of its underlying module, the YANG tree is not 906 depicted separately. 908 file "ietf-l3-unicast-topology-state@2017-11-15.yang" 909 module ietf-l3-unicast-topology-state { 910 yang-version 1.1; 911 namespace 912 "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state"; 913 prefix "l3t-s"; 914 import ietf-network-state { 915 prefix "nw-s"; 916 } 917 import ietf-network-topology-state { 918 prefix "nt-s"; 919 } 920 import ietf-l3-unicast-topology { 921 prefix "l3t"; 922 } 923 organization 924 "IETF I2RS (Interface to the Routing System) Working Group"; 925 contact 926 "WG Web: 927 WG List: 928 Editor: Alexander Clemm 929 930 Editor: Jan Medved 931 932 Editor: Robert Varga 933 934 Editor: Xufeng Liu 935 936 Editor: Nitin Bahadur 937 938 Editor: Hariharan Ananthakrishnan 939 "; 940 description 941 "This module defines a model for Layer 3 Unicast topology 942 state, representing topology that is either learned, or topology 943 that results from applying topology that has been configured per 944 the ietf-l3-unicast-topology model, mirroring the corresponding 945 data nodes in this model. 947 The model mirrors ietf-l3-unicast-topology, but contains only 948 read-only state data. The model is not needed when the 949 underlying implementation infrastructure supports the Network 950 Management Datastore Architecture (NMDA). 952 Copyright (c) 2017 IETF Trust and the persons identified as 953 authors of the code. All rights reserved. 954 Redistribution and use in source and binary forms, with or 955 without modification, is permitted pursuant to, and subject 956 to the license terms contained in, the Simplified BSD License 957 set forth in Section 4.c of the IETF Trust's Legal Provisions 958 Relating to IETF Documents 959 (http://trustee.ietf.org/license-info). 960 This version of this YANG module is part of 961 draft-ietf-i2rs-yang-l3-topology-13; 962 see the RFC itself for full legal notices. 963 NOTE TO RFC EDITOR: Please replace above reference to 964 draft-ietf-i2rs-yang-l3-topology-13 with RFC 965 number when published (i.e. RFC xxxx)."; 966 revision "2017-11-15" { 967 description 968 "Initial revision. 969 NOTE TO RFC EDITOR: Please replace the following reference 970 to draft-ietf-i2rs-yang-l3-topology-13 with 971 RFC number when published (i.e. RFC xxxx)."; 972 reference 973 "draft-ietf-i2rs-yang-l3-topology-13"; 974 } 975 augment "/nw-s:networks/nw-s:network/nw-s:network-types" { 976 description 977 "Introduce new network type for L3 unicast topology"; 978 uses l3t:l3-unicast-topology-type; 979 } 980 augment "/nw-s:networks/nw-s:network" { 981 when "nw-s:network-types/l3-unicast-topology" { 982 description 983 "Augmentation parameters apply only for networks with 984 L3 unicast topology"; 985 } 986 description 987 "L3 unicast for the network as a whole"; 988 uses l3t:l3-topology-attributes; 989 } 990 augment "/nw-s:networks/nw-s:network/nw-s:node" { 991 when "../nw-s:network-types/l3-unicast-topology" { 992 description 993 "Augmentation parameters apply only for networks with 994 L3 unicast topology"; 995 } 996 description 997 "L3 unicast node level attributes "; 998 uses l3t:l3-node-attributes; 999 } 1000 augment "/nw-s:networks/nw-s:network/nt-s:link" { 1001 when "../nw-s:network-types/l3-unicast-topology" { 1002 description 1003 "Augmentation parameters apply only for networks with 1004 L3 unicast topology"; 1005 } 1006 description 1007 "Augment topology link attributes"; 1008 uses l3t:l3-link-attributes; 1009 } 1010 augment "/nw-s:networks/nw-s:network/nw-s:node/" 1011 +"nt-s:termination-point" { 1012 when "../../nw-s:network-types/l3-unicast-topology" { 1013 description 1014 "Augmentation parameters apply only for networks with 1015 L3 unicast topology"; 1016 } 1017 description "Augment topology termination point configuration"; 1018 uses l3t:l3-termination-point-attributes; 1019 } 1020 notification l3-node-event { 1021 description 1022 "Notification event for L3 node"; 1023 leaf l3-event-type { 1024 type l3t:l3-event-type; 1025 description 1026 "Event type"; 1027 } 1028 uses nw-s:node-ref; 1029 uses l3t:l3-unicast-topology-type; 1030 uses l3t:l3-node-attributes; 1031 } 1032 notification l3-link-event { 1033 description 1034 "Notification event for L3 link"; 1035 leaf l3-event-type { 1036 type l3t:l3-event-type; 1037 description 1038 "Event type"; 1039 } 1040 uses nt-s:link-ref; 1041 uses l3t:l3-unicast-topology-type; 1042 uses l3t:l3-link-attributes; 1043 } 1044 notification l3-prefix-event { 1045 description 1046 "Notification event for L3 prefix"; 1047 leaf l3-event-type { 1048 type l3t:l3-event-type; 1049 description 1050 "Event type"; 1051 } 1052 uses nw-s:node-ref; 1053 uses l3t:l3-unicast-topology-type; 1054 container prefix { 1055 description 1056 "Containing L3 prefix attributes"; 1057 uses l3t:l3-prefix-attributes; 1058 } 1059 } 1060 notification termination-point-event { 1061 description 1062 "Notification event for L3 termination point"; 1063 leaf l3-event-type { 1064 type l3t:l3-event-type; 1065 description 1066 "Event type"; 1067 } 1068 uses nt-s:tp-ref; 1069 uses l3t:l3-unicast-topology-type; 1070 uses l3t:l3-termination-point-attributes; 1071 } 1072 } 1074 1076 Appendix B. Extending the Model 1078 The model can be extended for specific Layer 3 Unicast types. 1079 Examples include OSPF and IS-IS topologies. In the following, one 1080 additional YANG module is introduced that define simple topology 1081 model for OSPF. This module is intended to serve as an example that 1082 illustrates how the general topology model can be refined across 1083 multiple levels. It does not constitute full-fledged OSPF topology 1084 model which may be more comprehensive and refined than the model that 1085 is described here. 1087 B.1. Example OSPF Topology 1089 B.1.1. Model Overview 1091 The following model shows how the Layer 3 Unicast topology model can 1092 be extended to cover OSFP topologies. For this purpose, a set of 1093 augmentations are introduced in a separate YANG module, "example- 1094 ietf-ospf-topology", whose structure is depicted in the following 1095 diagram. As before, the notation syntax follows 1096 [I-D.draft-ietf-netmod-yang-tree-diagrams]. 1098 module: example-ietf-ospf-topology 1099 augment /nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology: 1100 +--rw ospf! 1101 augment /nw:networks/nw:network/l3t:l3-topology-attributes: 1102 +--rw ospf-topology-attributes 1103 +--rw area-id? area-id-type 1104 augment /nw:networks/nw:network/nw:node/l3t:l3-node-attributes: 1105 +--rw ospf-node-attributes 1106 +--rw (router-type)? 1107 | +--:(abr) 1108 | | +--rw abr? empty 1109 | +--:(asbr) 1110 | | +--rw asbr? empty 1111 | +--:(internal) 1112 | | +--rw internal? empty 1113 | +--:(pseudonode) 1114 | +--rw pseudonode? empty 1115 +--rw dr-interface-id? uint32 1116 augment /nw:networks/nw:network/nt:link/l3t:l3-link-attributes: 1117 +--rw ospf-link-attributes 1118 augment /l3t:l3-node-event: 1119 +---- ospf! 1120 +---- ospf-node-attributes 1121 +---- (router-type)? 1122 | +--:(abr) 1123 | | +---- abr? empty 1124 | +--:(asbr) 1125 | | +---- asbr? empty 1126 | +--:(internal) 1127 | | +---- internal? empty 1128 | +--:(pseudonode) 1129 | +---- pseudonode? empty 1130 +---- dr-interface-id? uint32 1131 augment /l3t:l3-link-event: 1132 +---- ospf! 1133 +---- ospf-link-attributes 1135 The module augments "ietf-l3-unicast-topology" as follows: 1137 o A new topology type for an OSPF topology is introduced. 1139 o Additional topology attributes are defined in a new grouping which 1140 augments l3-topology-attributes of the ietf-l3-unicast-topology 1141 module. The attributes include an OSPF area-id identifying the 1142 OSPF area. 1144 o Additional data objects for nodes are introduced by augmenting the 1145 l3-node-attributes of the l3-unicast-topology module. New objects 1146 include router-type and dr-interface-id for pseudonodes. 1148 o Links are augmented with ospf link attributes. 1150 In addition, the module extends notifications for events concerning 1151 Layer 3 nodes and links with OSPF attributes. 1153 It should be noted that the model defined here represents topology 1154 and is intended as an example. It does not define how to configure 1155 OSPF routers or interfaces. 1157 B.1.2. OSPF Topology YANG Module 1159 The OSPF Topology YANG Module is specified below. As mentioned, the 1160 module is intended as an example for how the Layer 3 Unicast topology 1161 model can be extended to cover OSFP topologies, but it is not 1162 normative. Accordingly, the module is not delimited with CODE BEGINS 1163 and CODE ENDS tags. 1165 file "example-ietf-ospf-topology@2017-11-15.yang" 1166 module example-ietf-ospf-topology { 1167 yang-version 1.1; 1168 namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology"; 1169 prefix "ospft"; 1170 import ietf-yang-types { 1171 prefix "yang"; 1172 } 1173 import ietf-network { 1174 prefix "nw"; 1175 } 1176 import ietf-network-topology { 1177 prefix "nt"; 1178 } 1179 import ietf-l3-unicast-topology { 1180 prefix "l3t"; 1181 } 1182 organization 1183 "IETF I2RS (Interface to the Routing System) Working Group"; 1184 contact 1185 "WG Web: 1186 WG List: 1187 Editor: Alexander Clemm 1188 1189 Editor: Jan Medved 1190 1191 Editor: Robert Varga 1192 1193 Editor: Xufeng Liu 1194 1195 Editor: Nitin Bahadur 1196 1197 Editor: Hariharan Ananthakrishnan 1198 "; 1199 description 1200 "This module defines a model for OSPF network topologies. 1201 Copyright (c) 2017 IETF Trust and the persons identified as 1202 authors of the code. All rights reserved. 1203 Redistribution and use in source and binary forms, with or 1204 without modification, is permitted pursuant to, and subject 1205 to the license terms contained in, the Simplified BSD License 1206 set forth in Section 4.c of the IETF Trust's Legal Provisions 1207 Relating to IETF Documents 1208 (http://trustee.ietf.org/license-info). 1209 This version of this YANG module is part of 1210 draft-ietf-i2rs-yang-l3-topology-13; 1211 see the RFC itself for full legal notices. 1212 NOTE TO RFC EDITOR: Please replace above reference to 1213 draft-ietf-i2rs-yang-l3-topology-13 with RFC 1214 number when published (i.e. RFC xxxx)."; 1215 revision "2017-11-15" { 1216 description 1217 "Initial revision. 1218 NOTE TO RFC EDITOR: Please replace the following reference 1219 to draft-ietf-i2rs-yang-l3-topology-13 with 1220 RFC number when published (i.e. RFC xxxx)."; 1221 reference 1222 "draft-ietf-i2rs-yang-l3-topology-13"; 1223 } 1224 typedef area-id-type { 1225 type yang:dotted-quad; 1226 description 1227 "Area ID type."; 1228 } 1229 grouping ospf-topology-type { 1230 description 1231 "Identifies the OSPF topology type."; 1232 container ospf { 1233 presence "indiates OSPF Topology"; 1234 description 1235 "Its presence identifies the OSPF topology type."; 1236 } 1237 } 1238 augment "/nw:networks/nw:network/nw:network-types/" 1239 + "l3t:l3-unicast-topology" { 1240 description 1241 "Defines the OSPF topology type."; 1242 uses ospf-topology-type; 1243 } 1244 augment "/nw:networks/nw:network/l3t:l3-topology-attributes" { 1245 when "../nw:network-types/l3t:l3-unicast-topology/ospf" { 1246 description 1247 "Augment only for OSPF topology"; 1248 } 1249 description 1250 "Augment topology configuration"; 1251 container ospf-topology-attributes { 1252 description 1253 "Containing topology attributes"; 1254 leaf area-id { 1255 type area-id-type; 1256 description 1257 "OSPF area ID"; 1258 } 1259 } 1260 } 1261 augment "/nw:networks/nw:network/nw:node/l3t:l3-node-attributes" { 1262 when "../../nw:network-types/l3t:l3-unicast-topology/ospf" { 1263 description 1264 "Augment only for OSPF topology"; 1265 } 1266 description 1267 "Augment node configuration"; 1268 uses ospf-node-attributes; 1269 } 1270 augment "/nw:networks/nw:network/nt:link/l3t:l3-link-attributes" { 1271 when "../../nw:network-types/l3t:l3-unicast-topology/ospf" { 1272 description 1273 "Augment only for OSPF topology"; 1274 } 1275 description 1276 "Augment link configuration"; 1277 uses ospf-link-attributes; 1278 } 1279 grouping ospf-node-attributes { 1280 description 1281 "OSPF node scope attributes"; 1282 container ospf-node-attributes { 1283 description 1284 "Containing node attributes"; 1285 choice router-type { 1286 description 1287 "Indicates router type"; 1289 case abr { 1290 leaf abr { 1291 type empty; 1292 description 1293 "The node is ABR"; 1294 } 1295 } 1296 case asbr { 1297 leaf asbr { 1298 type empty; 1299 description 1300 "The node is ASBR"; 1301 } 1302 } 1303 case internal { 1304 leaf internal { 1305 type empty; 1306 description 1307 "The node is internal"; 1308 } 1309 } 1310 case pseudonode { 1311 leaf pseudonode { 1312 type empty; 1313 description 1314 "The node is pseudonode"; 1315 } 1316 } 1317 } 1318 leaf dr-interface-id { 1319 when "../pseudonode" { 1320 description 1321 "Valid only for pseudonode"; 1322 } 1323 type uint32; 1324 default "0"; 1325 description 1326 "For pseudonodes, DR interface-id"; 1327 } 1328 } 1329 } 1330 grouping ospf-link-attributes { 1331 description 1332 "OSPF link scope attributes"; 1333 container ospf-link-attributes { 1334 description 1335 "Containing OSPF link attributes"; 1336 } 1338 } // ospf-link-attributes 1339 augment "/l3t:l3-node-event" { 1340 description 1341 "OSPF node event"; 1342 uses ospf-topology-type; 1343 uses ospft:ospf-node-attributes; 1344 } 1345 augment "/l3t:l3-link-event" { 1346 description 1347 "OSPF link event"; 1348 uses ospf-topology-type; 1349 uses ospft:ospf-link-attributes; 1350 } 1351 } 1353 Appendix C. An Example 1355 This section contains an example of an instance data tree in JSON 1356 encoding [RFC7951]. The example instantiates ietf-l3-unicast- 1357 topology for the topology that is depicted in the following diagram. 1358 There are three nodes, D1, D2, and D3. D1 has three termination 1359 points, 1-0-1, 1-2-1, and 1-3-1. D2 has three termination points as 1360 well, 2-1-1, 2-0-1, and 2-3-1. D3 has two termination points, 3-1-1 1361 and 3-2-1. In addition there are six links, two between each pair of 1362 nodes with one going in each direction. 1364 +------------+ +------------+ 1365 | D1 | | D2 | 1366 /-\ /-\ /-\ /-\ 1367 | | 1-0-1 | |---------------->| | 2-1-1 | | 1368 | | 1-2-1 | |<----------------| | 2-0-1 | | 1369 \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ 1370 | /----\ | | /----\ | 1371 +---| |---+ +---| |---+ 1372 \----/ \----/ 1373 A | A | 1374 | | | | 1375 | | | | 1376 | | +------------+ | | 1377 | | | D3 | | | 1378 | | /-\ /-\ | | 1379 | +----->| | 3-1-1 | |-------+ | 1380 +---------| | 3-2-1 | |<---------+ 1381 \-/ \-/ 1382 | | 1383 +------------+ 1385 Figure 2: A network topology example 1387 The corresponding instance data tree is depicted below: 1389 { 1390 "ietf-network:networks": { 1391 "network": [ 1392 { 1393 "network-types": { 1394 "ietf-l3-unicast-topology:l3-unicast-topology": {} 1395 }, 1396 "network-id": "l3-topo-example", 1397 "node": [ 1398 { 1399 "node-id": "D1", 1400 "termination-point": [ 1401 { 1402 "tp-id": "1-0-1", 1403 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1404 "unnumbered-id:": 101 1405 } 1406 }, 1407 { 1408 "tp-id": "1-2-1", 1409 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1410 "unnumbered-id:": 121 1412 } 1413 }, 1414 { 1415 "tp-id": "1-3-1", 1416 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1417 "unnumbered-id:": 131 1418 } 1419 } 1420 ], 1421 "ietf-l3-unicast-topology:l3-node-attributes": { 1422 "router-id": ["203.0.113.1"] 1423 } 1424 }, 1425 { 1426 "node-id": "D2", 1427 "termination-point": [ 1428 { 1429 "tp-id": "2-0-1", 1430 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1431 "unnumbered-id:": 201 1432 } 1433 }, 1434 { 1435 "tp-id": "2-1-1", 1436 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1437 "unnumbered-id:": 211 1438 } 1439 }, 1440 { 1441 "tp-id": "2-3-1", 1442 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1443 "unnumbered-id:": 231 1444 } 1445 } 1446 ], 1447 "ietf-l3-unicast-topology:l3-node-attributes": { 1448 "router-id": ["203.0.113.2"] 1449 } 1450 }, 1451 { 1452 "node-id": "D3", 1453 "termination-point": [ 1454 { 1455 "tp-id": "3-1-1", 1456 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1457 "unnumbered-id:": 311 1458 } 1459 }, 1460 { 1461 "tp-id": "3-2-1", 1462 "ietf-l3-unicast-topology:l3-termination-point-attributes": { 1463 "unnumbered-id:": 321 1464 } 1465 } 1466 ], 1467 "ietf-l3-unicast-topology:l3-node-attributes": { 1468 "router-id": ["203.0.113.3"] 1469 } 1470 } 1471 ], 1472 "ietf-network-topology:link": [ 1473 { 1474 "link-id": "D1,1-2-1,D2,2-1-1", 1475 "destination": { 1476 "source-node": "D1", 1477 "source-tp": "1-2-1" 1478 } 1479 "destination": { 1480 "dest-node": "D2", 1481 "dest-tp": "2-1-1" 1482 }, 1483 "ietf-l3-unicast-topology:l3-link-attributes": { 1484 "metric1": "100" 1485 } 1486 }, 1487 { 1488 "link-id": "D2,2-1-1,D1,1-2-1", 1489 "destination": { 1490 "source-node": "D2", 1491 "source-tp": "2-1-1" 1492 } 1493 "destination": { 1494 "dest-node": "D1", 1495 "dest-tp": "1-2-1" 1496 }, 1497 "ietf-l3-unicast-topology:l3-link-attributes": { 1498 "metric1": "100" 1499 } 1500 }, 1501 { 1502 "link-id": "D1,1-3-1,D3,3-1-1", 1503 "destination": { 1504 "source-node": "D1", 1505 "source-tp": "1-3-1" 1506 } 1507 "destination": { 1508 "dest-node": "D3", 1509 "dest-tp": "3-1-1" 1510 }, 1511 "ietf-l3-unicast-topology:l3-link-attributes": { 1512 "metric1": "100" 1513 } 1514 }, 1515 { 1516 "link-id": "D3,3-1-1,D1,1-3-1", 1517 "destination": { 1518 "source-node": "D3", 1519 "source-tp": "3-1-1" 1520 } 1521 "destination": { 1522 "dest-node": "D1", 1523 "dest-tp": "1-3-1" 1524 }, 1525 "ietf-l3-unicast-topology:l3-link-attributes": { 1526 "metric1": "100" 1527 } 1528 }, 1529 { 1530 "link-id": "D2,2-3-1,D3,3-2-1", 1531 "destination": { 1532 "source-node": "D2", 1533 "source-tp": "2-3-1" 1534 } 1535 "destination": { 1536 "dest-node": "D3", 1537 "dest-tp": "3-2-1" 1538 }, 1539 "ietf-l3-unicast-topology:l3-link-attributes": { 1540 "metric1": "100" 1541 } 1542 }, 1543 { 1544 "link-id": "D3,3-2-1,D2,2-3-1", 1545 "destination": { 1546 "source-node": "D3", 1547 "source-tp": "3-2-1" 1548 } 1549 "destination": { 1550 "dest-node": "D2", 1551 "dest-tp": "2-3-1" 1552 }, 1553 "ietf-l3-unicast-topology:l3-link-attributes": { 1554 "metric1": "100" 1555 } 1557 } 1558 ] 1559 } 1560 ] 1561 } 1562 } 1564 Figure 3: Instance data tree 1566 Authors' Addresses 1568 Alexander Clemm 1569 Huawei 1571 EMail: ludwig@clemm.org 1573 Jan Medved 1574 Cisco 1576 EMail: jmedved@cisco.com 1578 Robert Varga 1579 Pantheon Technologies SRO 1581 EMail: robert.varga@pantheon.sk 1583 Xufeng Liu 1584 Jabil 1586 EMail: Xufeng_Liu@jabil.com 1588 Hariharan Ananthakrishnan 1589 Packet Design 1591 EMail: hari@packetdesign.com 1593 Nitin Bahadur 1594 Bracket Computing 1596 EMail: nitin_bahadur@yahoo.com