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