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