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