Network Working GroupInternet Engineering Task Force (IETF) A. ClemmInternet-DraftRequest for Comments: 8346 HuaweiUSA Intended status:Category: Standards Track J. MedvedExpires: June 19, 2018ISSN: 2070-1721 Cisco R. Varga Pantheon Technologies SRO X. Liu Jabil H. Ananthakrishnan Packet Design N. Bahadur Bracket ComputingDecember 16, 2017March 2018 A YANG Data Model for Layer 3 Topologiesdraft-ietf-i2rs-yang-l3-topology-16.txtAbstract This document defines a YANG data model forlayerLayer 3 network topologies. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on June 19, 2018.https://www.rfc-editor.org/info/rfc8346. Copyright Notice Copyright (c)20172018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 2....................................................3 2. Key Words. . . . . . . . . . . . . . . . . . . . . . . . . . 3.......................................................3 3. Definitions and Acronyms. . . . . . . . . . . . . . . . . . 3........................................4 4. Model Structure. . . . . . . . . . . . . . . . . . . . . . . 4.................................................5 5. Layer 3 Unicast Topology Model Overview. . . . . . . . . . . 5.........................6 6. Layer 3 Unicast Topology YANG Module. . . . . . . . . . . . 7............................7 7. Interactions with Other YANG Modules. . . . . . . . . . . . 15...........................15 8. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 15............................................15 9. Security Considerations. . . . . . . . . . . . . . . . . . . 16........................................16 10.Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 12.References. . . . . . . . . . . . . . . . . . . . . . . . . 17 12.1.....................................................17 10.1. Normative References. . . . . . . . . . . . . . . . . . 17 12.2......................................17 10.2. Informative References. . . . . . . . . . . . . . . . . 19...................................19 Appendix A. Companion YANGmodelData Model fornon-NMDA compliant implementations . . . . . . . . . . . . . . . . . . 20Implementations Not Compliant with NMDA ..................................20 Appendix B. Extending the Model. . . . . . . . . . . . . . . . 24..................................24 B.1. Example OSPF Topology. . . . . . . . . . . . . . . . . . 24.....................................24 B.1.1. Model Overview. . . . . . . . . . . . . . . . . . . 24........................................24 B.1.2. OSPF Topology YANG Module. . . . . . . . . . . . . . 26.............................26 Appendix C. An Example. . . . . . . . . . . . . . . . . . . . . 29...........................................29 Acknowledgments ...................................................34 Contributors ......................................................34 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 34................................................35 1. Introduction This document introduces a YANG [RFC7950] [RFC6991] data model for Layer 3 (L3) network topologies, specifically Layer 3 Unicast. The model allows an application to have a holistic view of the topology of a Layer 3 network, all contained in a single conceptual YANG datastore. The data model builds on top of, and augments, the data model for network topologies defined in[I-D.draft-ietf-i2rs-yang-network-topo].[RFC8345]. This document also shows how the model can be further refined to cover different Layer 3 Unicast topology types. For this purpose, an example model is introduced that covers OSPF [RFC2328]. This example is intended purely for illustrative purpose; we expect that a complete OSPF model will be more comprehensive and refined than the example shownhere.in this document. There are multiple applications for a topology data model. A number of use cases have been defined insectionSection 6 of[I-D.draft-ietf-i2rs-usecase-reqs-summary].[USECASE-REQS]. For example, nodes within the network can use the data model to capture their understanding of the overall network topology and expose it to a network controller. A network controller can then use the instantiated topology data to compare and reconcile its own view of the network topology with that of the network elements that it controls. Alternatively, nodes within the network could propagate this understanding to compare and reconcile this understanding either amongst themselves or with help of a controller. Beyond the network element itself, a network controller might even use the data model to represent its view of the topology that it controls and expose it to applications north of itself. The data model for Layer 3 Unicast topologies defined in this document is specified inathe YANG module "ietf-l3-unicast-topology".To do so, itThis YANG module augments the general network topology model defined in[I-D.draft-ietf-i2rs-yang-network-topo][RFC8345] with information specific to Layer 3 Unicast.ThisIn this way, the general topology model is extended to be able to meet the needs of Layer 3 Unicast topologies. Information that is kept in the Traffic Engineering Database (TED) will be specified in a separate model[I-D.draft-ietf-teas-yang-te-topo][YANG-TE] and is outside the scope of this specification. 2. Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Definitions and AcronymsAs thisThis document defines a YANG datamodel, in this documentmodel and thus uses many termsare used that have beendefined inconjunction withYANG [RFC7950] and NETCONF [RFC6241]. Some terms, such asdatastore"datastore" anddata tree,"data tree", are repeated here for clarity andto put them incontext. Datastore: A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof. A datastore maps to an instantiated YANG datatree. (Definitiontree (definition adopted from[I-D.draft-ietf-netmod-revised-datastores])[RFC8342]). Data subtree: An instantiated data node and the data nodes that are hierarchically contained within it.IGP: Interior Gateway ProtocolIS-IS: Intermediate System to Intermediate System protocol LSP: Label Switched Path NETCONF: Network Configuration Protocol NMDA: Network Management Datastore Architecture OSPF: Open Shortest PathFirst, a link stateFirst (a link-state routingprotocolprotocol) URI: Uniform Resource IdentifierSRLG: Shared Risk Link GroupTED: Traffic Engineering Database YANG: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols[RFC7950][RFC7950]. 4. Model Structure The Layer 3 Unicast topology model is defined by YANG module "l3- unicast-topology". The relationship of this module with other YANG modules is roughly depicted in the figure below. +-----------------------------+ | +-----------------------+ | | | ietf-network | | | +----------^------------+ | | | | | +-----------------------+ | | | ietf-network-topology | | | +----------+------------+ | +-------------^---------------+ | | +------------^-------------+ | ietf-l3-unicast-topology | +------------^-------------+ | | +-----------^-----------+ | example-ospf-topology | +-----------------------+ Figure 1: Overallmodel structureModel Structure YANG modules "ietf-network" and "ietf-network-topology" collectively define the basic network topology model[I-D.draft-ietf-i2rs-yang-network-topo].[RFC8345]. YANG module"ietf-l3- unicast-topology""ietf-l3-unicast-topology" augments those models with additional definitions needed to represent Layer 3 Unicast topologies. This module in turn can be augmented by YANG modules with additional definitions for specific types of Layer 3 Unicast topologies, such as OSPF andforIS-IS topologies. The YANG modulesietf-network"ietf-network" andietf-network-topology"ietf-network-topology" are designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) defined in[I-D.draft-ietf-netmod-revised-datastores].[RFC8342]. Accordingly, the same is true for the YANG modules that augment it. In order to allow implementations to use the model even in cases when NMDA is not supported, companion YANG modules (that SHOULD NOT be supported by implementations that support NMDA) are defined inan Appendix, seeAppendix A. 5. Layer 3 Unicast Topology Model Overview The Layer 3 Unicast topology model is defined by YANG module "ietf- l3-unicast-topology". Its structure is depicted in the following diagram. The notation syntax follows[I-D.draft-ietf-netmod-yang-tree-diagrams].[RFC8340]. For purposes of brevity, notifications are not depicted. module: ietf-l3-unicast-topology augment /nw:networks/nw:network/nw:network-types: +--rw l3-unicast-topology! augment /nw:networks/nw:network: +--rw l3-topology-attributes +--rw name? string +--rw flag* l3-flag-type augment /nw:networks/nw:network/nw:node: +--rw l3-node-attributes +--rw name? inet:domain-name +--rw flag* node-flag-type +--rw router-id* rt-types:router-id +--rw prefix* [prefix] +--rw prefix inet:ip-prefix +--rw metric? uint32 +--rw flag* prefix-flag-type augment /nw:networks/nw:network/nt:link: +--rw l3-link-attributes +--rw name? string +--rw flag* link-flag-type +--rw metric1? uint64 +--rw metric2? uint64 augment /nw:networks/nw:network/nw:node/nt:termination-point: +--rw l3-termination-point-attributes +--rw (termination-point-type)? +--:(ip) | +--rw ip-address* inet:ip-address +--:(unnumbered) | +--rw unnumbered-id? uint32 +--:(interface-name) +--rw interface-name? string The module augments the originalietf-network"ietf-network" andietf-network- topology"ietf-network- topology" modules as follows: o A new network topology type is introduced, l3-unicast-topology. The corresponding container augments the network-types of theietf-network"ietf-network" module. o Additional topology attributes are introduced, defined in agrouping, whichgrouping that augments the "network" list of the network module. The attributes include a name for thetopology, as well astopology and a set of flags (representedthroughby a leaf-list). Each type of flag is represented by a separate identity. This allowsto introduceadditional flags to be introduced in augmenting modules using additional identities without needing to revise this module. o Additional data objects for nodes are introduced by augmenting the "node" list of the network module. New objects includeagaina set offlags, as well asflags and a list of prefixes. Each prefixin turnincludes anipIP prefix, a metric, and a prefix-specific set of flags. o Links (in theietf-network-topology"ietf-network-topology" module) are augmented with a set of parametersas well, allowing to associatethat allow a link to be associated with a link name, another set of flags, and a link metric. o Termination points (in theietf-network-topology module as well)"ietf-network-topology" module) are augmented with a choice of IP address, identifier, or name. In addition, the module defines a set of notifications to alert clients of any events concerning links, nodes, prefixes, and termination points. Each notification includes an indication of the type of event, the topology from which it originated, and the affected node,orlink,orprefix, or termination point.In addition,Also, as a convenience to applications, additional data of the affected node,orlink, prefix, or termination point(respectively)is included. While this makes notifications larger in volume than theywouldneed to be, it avoids the need for subsequent retrieval of contextinformation, which alsoinformation that might have changed in the meantime. 6. Layer 3 Unicast Topology YANG Module This YANG module makes reference to the following documents: [RFC2863] and [RFC8343]. <CODE BEGINS> file"ietf-l3-unicast-topology@2017-12-16.yang""ietf-l3-unicast-topology@2018-02-26.yang" module ietf-l3-unicast-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology"; prefix "l3t"; import ietf-network { prefix "nw"; } import ietf-network-topology { prefix "nt"; } import ietf-inet-types { prefix "inet"; } import ietf-routing-types { prefix "rt-types"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web:<http://tools.ietf.org/wg/i2rs/><https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Xufeng Liu<mailto:xliu@kuatrotech.com><mailto:xufeng.liu.ietf@gmail.com> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com> Editor: Hariharan Ananthakrishnan <mailto:hari@packetdesign.com>"; description "This module defines a model for Layer 3 Unicast topologies. Copyright (c)20172018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info).(https://trustee.ietf.org/license-info). This version of this YANG module is part ofdraft-ietf-i2rs-yang-l3-topology-16;RFC 8346; see the RFC itself for full legalnotices. NOTE TO RFC EDITOR: Please replace above reference to draft-ietf-i2rs-yang-l3-topology-16 with RFC number when published (i.e. RFC xxxx).";notices."; revision"2017-12-16""2018-02-26" { description "Initialrevision. NOTE TO RFC EDITOR: Please replace the following reference to draft-ietf-i2rs-yang-l3-topology-16 with RFC number when published (i.e. RFC xxxx).";revision."; reference"draft-ietf-i2rs-yang-l3-topology-16";"RFC 8346: A YANG Data Model for Layer 3 Topologies"; } identity flag-identity { description "Base type for flags"; } typedef l3-event-type { type enumeration { enum "add" { description"An"A Layer 3node or link or prefixnode, link, prefix, ortermination-pointtermination point has been added"; } enum "remove" { description"An"A Layer 3node or link or prefixnode, link, prefix, ortermination-pointtermination point has been removed"; } enum "update" { description"An"A Layer 3node or link or prefixnode, link, prefix, ortermination-pointtermination point has been updated"; } } description "Layer 3Eventevent type for notifications"; } typedef prefix-flag-type { type identityref { base "flag-identity"; } description "Prefix flag attributes"; } typedef node-flag-type { type identityref { base "flag-identity"; } description "Node flag attributes"; } typedef link-flag-type { type identityref { base "flag-identity"; } description "Link flag attributes"; } typedef l3-flag-type { type identityref { base "flag-identity"; } description "L3 flag attributes"; } grouping l3-prefix-attributes { description "L3 prefix attributes"; leaf prefix { type inet:ip-prefix; description "IP prefix value"; } leaf metric { type uint32; description "Prefix metric"; } leaf-list flag { type prefix-flag-type; description "Prefix flags"; } } grouping l3-unicast-topology-type { description"Identify"Identifies the topology type to be L3unicast.";Unicast."; container l3-unicast-topology { presence "indicates L3 UnicastTopology";topology"; description "The presence of the container node indicates L3 UnicastTopology";topology"; } } grouping l3-topology-attributes { description "Topology scope attributes"; container l3-topology-attributes { description"Containing"Contains topology attributes"; leaf name { type string; description "Name of the topology"; } leaf-list flag { type l3-flag-type; description "Topology flags"; } } } grouping l3-node-attributes { description "L3 node scope attributes"; container l3-node-attributes { description"Containing"Contains node attributes"; leaf name { type inet:domain-name; description "Node name"; } leaf-list flag { type node-flag-type; description "Node flags"; } leaf-list router-id { type rt-types:router-id; description "Router-id for the node"; } list prefix { key "prefix"; description "A list of prefixes along with their attributes"; uses l3-prefix-attributes; } } } grouping l3-link-attributes { description "L3 link scope attributes"; container l3-link-attributes { description"Containing"Contains link attributes"; leaf name { type string; description "Link Name"; } leaf-list flag { type link-flag-type; description "Link flags"; } leaf metric1 { type uint64; description "Link Metric 1"; } leaf metric2 { type uint64; description "Link Metric 2"; } } } grouping l3-termination-point-attributes { description "L3 termination point scope attributes"; container l3-termination-point-attributes { description"Containing"Contains termination point attributes"; choice termination-point-type { description "Indicates the termination point type"; case ip { leaf-list ip-address { type inet:ip-address; description "IPv4 or IPv6 address."; } } case unnumbered { leaf unnumbered-id { type uint32; description "Unnumbered interface identifier. The identifier will correspond to the ifIndex value of the interface,i.e.i.e., the ifIndex value of the ifEntry that represents the interface in implementations where the Interfaces Group MIB (RFC 2863) is supported."; reference "RFC 2863: The Interfaces Group MIB"; } } case interface-name { leaf interface-name { type string; description"A name"Name of the interface. The name can (but does not have to) correspond to an interface reference of a containing node's interface,i.e.i.e., the path name of a corresponding interface data node on the containing node reminiscent of data typeif-refinterface-ref defined in RFC7223.8343. It should be noted that data typeif-refinterface-ref of RFC72238343 cannot be used directly, as this data type is used to reference an interface in a datastore of a single node in the network, not to uniquely reference interfaces across a network."; reference "RFC 8343: A YANG Data Model for Interface Management"; } } } } } augment "/nw:networks/nw:network/nw:network-types" { description"Introduce"Introduces new network type for L3unicastUnicast topology"; uses l3-unicast-topology-type; } augment "/nw:networks/nw:network" { when "nw:network-types/l3t:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description "L3unicastUnicast for the network as a whole"; uses l3-topology-attributes; } augment "/nw:networks/nw:network/nw:node" { when "../nw:network-types/l3t:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description "L3unicast node levelUnicast node-level attributes "; uses l3-node-attributes; } augment "/nw:networks/nw:network/nt:link" { when "../nw:network-types/l3t:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description"Augment"Augments topology link attributes"; uses l3-link-attributes; } augment "/nw:networks/nw:network/nw:node/" +"nt:termination-point" { when "../../nw:network-types/l3t:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description"Augment"Augments topology termination point configuration"; uses l3-termination-point-attributes; } notification l3-node-event { description "Notification event for L3 node"; leaf l3-event-type { type l3-event-type; description "Event type"; } uses nw:node-ref; uses l3-unicast-topology-type; uses l3-node-attributes; } notification l3-link-event { description "Notification event for L3 link"; leaf l3-event-type { type l3-event-type; description "Event type"; } uses nt:link-ref; uses l3-unicast-topology-type; uses l3-link-attributes; } notification l3-prefix-event { description "Notification event for L3 prefix"; leaf l3-event-type { type l3-event-type; description "Event type"; } uses nw:node-ref; uses l3-unicast-topology-type; container prefix { description"Containing"Contains L3 prefix attributes"; uses l3-prefix-attributes; } } notification termination-point-event { description "Notification event for L3 termination point"; leaf l3-event-type { type l3-event-type; description "Event type"; } uses nt:tp-ref; uses l3-unicast-topology-type; uses l3-termination-point-attributes; } } <CODE ENDS> 7. Interactions with Other YANG Modules As described insectionSection 4, the model defined in this document builds on top of, and augments, the YANG modules defined in[I-D.draft-ietf-i2rs-yang-network-topo].[RFC8345]. Specifically, the "ietf-l3-unicast-topology" moduleietf- l3-unicast-topologyaugmentsmodulesthe "ietf-network" and"ietf- network-topology"."ietf-network-topology" modules. In addition, the model makes use of data typesthat have beendefined in [RFC6991]. The modeldefinesdefined in this document is aprotocol independentprotocol-independent YANG data model withlayerLayer 3 topology information. It is separate from and not linked with data models that are used to configure routing protocols or routinginformation. This includes e.g. modelinformation, e.g., "ietf-routing" [RFC8022] andmodel "ietf-fb-rib" [I-D.draft-acee-rtgwg-yang-rib-extend]."ietf-rib-extension" [YANG-RIB]. That said, the model does import a type definition from model"ietf- routing-types""ietf-routing-types" [RFC8294]. The modelobeyscomplies with the requirements for the ephemeral state found inthe document[RFC8242]. For ephemeral topology data that is server provided, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the data model without relying on a configuration datastore. 8. IANA Considerations This document registers the following namespace URIs in the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. This document registers the following YANG modules in the "YANG Module Names" registry [RFC6020]: Name: ietf-l3-unicast-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology Prefix: l3t Reference:draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form)RFC 8346 Name: ietf-l3-unicast-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state Prefix: l3t-s Reference:draft-ietf-i2rs-yang-l3-topology-16.txt (RFC form)RFC 8346 9. Security Considerations The YANGmodule definedmodules specified in this document define a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC5246]. The NETCONF access control model[RFC6536][RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. In general, Layer 3 Unicast topologies are system-controlled and provide ephemeral topology information. In anNMDA-complientNMDA-compliant server, they are only part of<operational><operational>, which provides read-only access to clients, so they are less vulnerable. That said, the YANGmodule doesmodules do in principle allow information to be configurable. There are a number of data nodes defined inthisthese YANGmodulemodules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability in theietf-network"ietf-l3-unicast-topology" module: o l3-topology-attributes: A malicious client could attempt to sabotage the configuration of any of thectonainedcontained attributes,i.e.i.e., the name or the flag data nodes. o l3-node-attributes: A malicious client could attempt to sabotage the configuration of important node attributes, such as the router-id or node prefix. o l3-link-attributes: A malicious client could attempt to sabotage the configuration of important link attributes, such as name, flag, and metrics of thelink respectively corresponding data nodes.link. o l3-termination-point-attributes: A malicious client could attempt to sabotage the configuration information of a termination point, such asits ip-addressthe termination point's IP address and interfacename, respectively the corresponding data nodes.name. 10.Contributors The model presented in this document was contributed to by more people than can be listed on the author list. Additional contributors include: o Vishnu Pavan Beeram, Juniper o Igor Bryskin, Huawei o Ken Gray, Cisco o Aihua Guo, Huawei o Tom Nadeau, Brocade o Tony Tkacik o Aleksandr Zhdankin, Cisco 11. Acknowledgements We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Andy Bierman, Benoit Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, Carl Moberg, Carlos Pignataro, Juergen Schoenwaelder, Michal Vasco, and Kent Watsen. 12.References12.1.10.1. Normative References[I-D.draft-ietf-i2rs-yang-network-topo] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", I-D draft-ietf-i2rs-yang-network- topo-19, December 2017. [I-D.draft-ietf-netmod-revised-datastores] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "A Revised Conceptual Model for YANG Datastores", I-D draft-ietf-netmod-revised-datastores-06, October 2017. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.[RFC2119] Bradner, S., "Key words for use in RFCs toindicate requirement levels",Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April1998.1998, <https://www.rfc-editor.org/info/rfc2328>. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June2000.2000, <https://www.rfc-editor.org/info/rfc2863>. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January2004.2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August2008.2008, <https://www.rfc-editor.org/info/rfc5246>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October2010.2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June2011.2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June2011. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012.2011, <https://www.rfc-editor.org/info/rfc6242>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July2013.2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August2016.2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August2016.2016, <https://www.rfc-editor.org/info/rfc7951>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December2014. 12.2.2017, <https://www.rfc-editor.org/info/rfc8294>. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>. [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>. 10.2. Informative References[I-D.draft-acee-rtgwg-yang-rib-extend] Lindem,[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, DOI 10.17487/RFC8022, November 2016, <https://www.rfc-editor.org/info/rfc8022>. [RFC8242] Haas, J. andY. Qu,S. Hares, "Interface to the Routing System (I2RS) Ephemeral State Requirements", RFC 8242, DOI 10.17487/RFC8242, September 2017, <https://www.rfc-editor.org/info/rfc8242>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. [RFC8343] Bjorklund, M., "A YANG Data Model forRIB Extensions", I-D draft-acee-rtgwg-yang-rib-extend-05, October 2017. [I-D.draft-ietf-i2rs-usecase-reqs-summary]Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>. [USECASE-REQS] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements",I-D draft-ietf-i2rs-usecase-reqs-summary- 03,Work in Progress, draft-ietf-i2rs-usecase- reqs-summary-03, November 2016.[I-D.draft-ietf-netmod-yang-tree-diagrams] Bjorklund, M.[YANG-RIB] Lindem, A. andL. Berger, "YANG Tree Diagrams", I-D draft-ietf-netmod-yang-tree-diagrams, October 2017. [I-D.draft-ietf-teas-yang-te-topo]Y. Qu, "RIB YANG Data Model", Work in Progress, draft-acee-rtgwg-yang-rib-extend-06, January 2018. [YANG-TE] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. GonzalezDede Dios, "YANG Data Model forTETraffic Engineering (TE) Topologies",I-D draft-ietf-teas-yang-te-topo-13, October 2017. [RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management", RFC 7223, May 2014. [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, November 2016. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs LowercaseWork inRFC 2119 Key Words", RFC 8174, May 2017. [RFC8242] Haas, J. and S. Hares, "I2RS Ephemeral State Requirements", RFC 8242, September 2017.Progress, draft-ietf-teas-yang-te-topo-15, February 2018. Appendix A. Companion YANGmodelData Model fornon-NMDA compliant implementationsImplementations Not Compliant with NMDA The YANG moduleietf-l3-unicast-topology"ietf-l3-unicast-topology" defined in this document augments twomodules, ietf-networkmodules defined in [RFC8345]: "ietf-network" andietf-network-topology, that are"ietf- network-topology". These two modules were designed to be used in conjunction with implementations that support the Network Management Datastore Architecture (NMDA) defined in[I-D.draft-ietf-netmod-revised-datastores].[RFC8342]. In order to allow implementations to use the modelevenin cases when NMDA is not supported,a set of[RFC8345] defines two companionmodules have been definedmodules, "ietf-network- state" and "ietf-network-topology-state", that representastatemodelmodels of networks and network topologies,ietf- network-state and ietf-network-topology-state,respectively. In order to be able to use the model forlayerLayer 3 topologies defined in thisin thisdocument in conjunction withnon-NMDAimplementations not compliantimplementations,with NMDA, a corresponding companion module needs to be introduced as well. This companion module,ietf-l3-unicast-topology- state,"ietf-l3-unicast-topology-state", mirrorsietf-l3-unicast-topology."ietf-l3-unicast-topology". However, the module augmentsietf-network-state"ietf-network-state" andietf-network-topology-state"ietf-network-topology-state" (instead ofietf-network"ietf-network" andietf-network-topology)"ietf-network-topology"), and all of its data nodes are non-configurable. Similar considerations applyforto anymodulesmodule thataugment ietf-l3- unicast-topology,augments "ietf-l3- unicast-topology", such as the examplemodulesmodule defined inseeAppendixB, example-ospf-topology.B (i.e., example-ospf-topology). Fornon-NMDAimplementations that are not compliantimplementations,with NMDA, companion moduleswill need to be introducedthat represent state information and that arenon-configurable, augmenting ietf-l3-unicast-topology-statenon-configurable will need to be introduced. These modules augment "ietf-l3-unicast-topology-state" instead ofietf-l3-unicast-topology. Because they served as examples only, companion"ietf-l3-unicast-topology". Companion modules forthose examplesthe example module defined in Appendix B are notgiven.provided (since it is just an example). Likeietf-network-state"ietf-network-state" andietf-network-topology-state, ietf-l3- unicast-topology"ietf-network-topology-state", "ietf- l3-unicast-topology" SHOULD NOT be supported by implementations that support NMDA.It is for this reason that theThe module is therefore defined inthe Appendix.an appendix. The definition of the module follows below. As the structure of the module mirrors that of its underlying module, the YANG tree is not depicted separately. <CODE BEGINS> file"ietf-l3-unicast-topology-state@2017-12-16.yang""ietf-l3-unicast-topology-state@2018-02-26.yang" module ietf-l3-unicast-topology-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state"; prefix "l3t-s"; import ietf-network-state { prefix "nw-s"; } import ietf-network-topology-state { prefix "nt-s"; } import ietf-l3-unicast-topology { prefix "l3t"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web:<http://tools.ietf.org/wg/i2rs/><https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:i2rs@ietf.org> Editor: Alexander Clemm <mailto:ludwig@clemm.org> Editor: Jan Medved <mailto:jmedved@cisco.com> Editor: Robert Varga <mailto:robert.varga@pantheon.tech> Editor: Xufeng Liu<mailto:xliu@kuatrotech.com><mailto:xufeng.liu.ietf@gmail.com> Editor: Nitin Bahadur <mailto:nitin_bahadur@yahoo.com> Editor: Hariharan Ananthakrishnan <mailto:hari@packetdesign.com>"; description "This module defines a model for Layer 3 Unicast topology state, representing topology thatiseitherlearned,is learned ortopology thatresults from applying topology that has been configured per theietf-l3-unicast-topology'ietf-l3-unicast-topology' model, mirroring the corresponding data nodes in this model.TheThis model mirrorsietf-l3-unicast-topology,'ietf-l3-unicast-topology' but contains only read-only state data. The model is not needed when the underlying implementation infrastructure supports the Network Management Datastore Architecture (NMDA). Copyright (c)20172018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents(http://trustee.ietf.org/license-info).(https://trustee.ietf.org/license-info). This version of this YANG module is part ofdraft-ietf-i2rs-yang-l3-topology-16;RFC 8346; see the RFC itself for full legalnotices. NOTE TO RFC EDITOR: Please replace above reference to draft-ietf-i2rs-yang-l3-topology-16 with RFC number when published (i.e. RFC xxxx).";notices."; revision"2017-12-16""2018-02-26" { description "Initialrevision. NOTE TO RFC EDITOR: Please replace the following reference to draft-ietf-i2rs-yang-l3-topology-16 with RFC number when published (i.e. RFC xxxx).";revision."; reference"draft-ietf-i2rs-yang-l3-topology-16";"RFC 8346: A YANG Data Model for Layer 3 Topologies"; } augment "/nw-s:networks/nw-s:network/nw-s:network-types" { description "Introduce new network type for L3unicastUnicast topology"; uses l3t:l3-unicast-topology-type; } augment "/nw-s:networks/nw-s:network" { when "nw-s:network-types/l3t-s:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description "L3unicastUnicast for the network as a whole"; uses l3t:l3-topology-attributes; } augment "/nw-s:networks/nw-s:network/nw-s:node" { when "../nw-s:network-types/l3t-s:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description "L3unicast node levelUnicast node-level attributes "; uses l3t:l3-node-attributes; } augment "/nw-s:networks/nw-s:network/nt-s:link" { when "../nw-s:network-types/l3t-s:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description"Augment"Augments topology link attributes"; uses l3t:l3-link-attributes; } augment "/nw-s:networks/nw-s:network/nw-s:node/" +"nt-s:termination-point" { when "../../nw-s:network-types/l3t-s:l3-unicast-topology" { description "Augmentation parameters apply only for networks with L3unicastUnicast topology"; } description"Augment"Augments topology termination point configuration"; uses l3t:l3-termination-point-attributes; } notification l3-node-event { description "Notification event for L3 node"; leaf l3-event-type { type l3t:l3-event-type; description "Event type"; } uses nw-s:node-ref; uses l3t:l3-unicast-topology-type; uses l3t:l3-node-attributes; } notification l3-link-event { description "Notification event for L3 link"; leaf l3-event-type { type l3t:l3-event-type; description "Event type"; } uses nt-s:link-ref; uses l3t:l3-unicast-topology-type; uses l3t:l3-link-attributes; } notification l3-prefix-event { description "Notification event for L3 prefix"; leaf l3-event-type { type l3t:l3-event-type; description "Event type"; } uses nw-s:node-ref; uses l3t:l3-unicast-topology-type; container prefix { description"Containing"Contains L3 prefix attributes"; uses l3t:l3-prefix-attributes; } } notification termination-point-event { description "Notification event for L3 termination point"; leaf l3-event-type { type l3t:l3-event-type; description "Event type"; } uses nt-s:tp-ref; uses l3t:l3-unicast-topology-type; uses l3t:l3-termination-point-attributes; } } <CODE ENDS> Appendix B. Extending the Model The model can be extended for specific Layer 3 Unicast types. Examples include OSPF and IS-IS topologies.In the following, one additionalThis appendix introduces a YANG moduleis introducedthatdefinedefines a simple topology model for OSPF. This module is intended to serve as an example that illustrates how the general topology model can be refined across multiple levels. It does not constitute a full-fledged OSPF topologymodelmodel, which may be more comprehensive and refined than the model that is described here. B.1. Example OSPF Topology B.1.1. Model Overview The following model shows how the Layer 3 Unicast topology model can be extended, in thiscasecase, to coverOSFPOSPF topologies. For this purpose, a set of augmentations are introduced in a separate YANG module, "example-ospf-topology", whose structure is depicted in the following diagram. As before, the notation syntax follows[I-D.draft-ietf-netmod-yang-tree-diagrams].[RFC8340]. Note that one of the lines has been wrapped to adhere to the 72-character line limitation of RFCs. module: example-ospf-topology augment/nw:networks/nw:network/nw:network-types/l3t:l3-unicast-topology:/nw:networks/nw:network/nw:network-types/ l3t:l3-unicast-topology: +--rw ospf! augment /nw:networks/nw:network/l3t:l3-topology-attributes: +--rw ospf-topology-attributes +--rw area-id? area-id-type augment /nw:networks/nw:network/nw:node/l3t:l3-node-attributes: +--rw ospf-node-attributes +--rw (router-type)? | +--:(abr) | | +--rw abr? empty | +--:(asbr) | | +--rw asbr? empty | +--:(internal) | | +--rw internal? empty | +--:(pseudonode) | +--rw pseudonode? empty +--rw dr-interface-id? uint32 augment /nw:networks/nw:network/nt:link/l3t:l3-link-attributes: +--rw ospf-link-attributes augment /l3t:l3-node-event: +---- ospf! +---- ospf-node-attributes +---- (router-type)? | +--:(abr) | | +---- abr? empty | +--:(asbr) | | +---- asbr? empty | +--:(internal) | | +---- internal? empty | +--:(pseudonode) | +---- pseudonode? empty +---- dr-interface-id? uint32 augment /l3t:l3-link-event: +---- ospf! +---- ospf-link-attributes The module augments "ietf-l3-unicast-topology" as follows: o A new topology type for an OSPF topology is introduced. o Additional topology attributes are defined in a new groupingwhichthat augments l3-topology-attributes of theietf-l3-unicast-topology"ietf-l3-unicast-topology" module. The attributes include an OSPF area-id identifying the OSPF area. o Additional data objects for nodes are introduced by augmenting the l3-node-attributes of thel3-unicast-topology"ietf-l3-unicast-topology" module. New objects include router-type and dr-interface-id for pseudonodes. o Links are augmented withospfOSPF link attributes. In addition, the module extends notifications for events concerning Layer 3 nodes and links with OSPF attributes. It should be noted that the model defined here represents topology and is intended as an example. It does not define how to configure OSPF routers or interfaces. B.1.2. OSPF Topology YANG Module The OSPF Topology YANGModulemodule is specified below. As mentioned, the module is intended as an example for how the Layer 3 Unicast topology model can be extended to coverOSFPOSPF topologies, but it is not normative. Accordingly, the module is not delimited withCODE BEGINS<CODE BEGINS> andCODE ENDS<CODE ENDS> tags. file "example-ospf-topology@2017-12-16.yang" module example-ospf-topology { yang-version 1.1; namespace "urn:example:example-ospf-topology"; prefix "ex-ospft"; import ietf-yang-types { prefix "yang"; } import ietf-network { prefix "nw"; } import ietf-network-topology { prefix "nt"; } import ietf-l3-unicast-topology { prefix "l3t"; } description "This module is intended as an example for how the Layer 3 Unicast topology model can be extended to coverOSFPOSPF topologies."; typedef area-id-type { type yang:dotted-quad; description "Area ID type."; } grouping ospf-topology-type { description "Identifies the OSPF topology type."; container ospf { presence "indicates OSPF Topology"; description "Its presence identifies the OSPF topology type."; } } augment "/nw:networks/nw:network/nw:network-types/" + "l3t:l3-unicast-topology" { description "Defines the OSPF topology type."; uses ospf-topology-type; } augment "/nw:networks/nw:network/l3t:l3-topology-attributes" { when "../nw:network-types/l3t:l3-unicast-topology/" + "ex-ospft:ospf" { description"Augment"Augments only for OSPF topology"; } description"Augment"Augments topology configuration"; container ospf-topology-attributes { description"Containing"Contains topology attributes"; leaf area-id { type area-id-type; description "OSPF area ID"; } } } augment "/nw:networks/nw:network/nw:node/l3t:l3-node-attributes" { when "../../nw:network-types/l3t:l3-unicast-topology/" + "ex-ospft:ospf" { description"Augment"Augments only for OSPF topology"; } description"Augment"Augments node configuration"; uses ospf-node-attributes; } augment "/nw:networks/nw:network/nt:link/l3t:l3-link-attributes" { when "../../nw:network-types/l3t:l3-unicast-topology/" + "ex-ospft:ospf" { description"Augment"Augments only for OSPF topology"; } description"Augment"Augments link configuration"; uses ospf-link-attributes; } grouping ospf-node-attributes { description "OSPF node scope attributes"; container ospf-node-attributes { description"Containing"Contains node attributes"; choice router-type { description "Indicates router type"; case abr { leaf abr { type empty; description "The node is ABR"; } } case asbr { leaf asbr { type empty; description "The node is ASBR"; } } case internal { leaf internal { type empty; description "The node is internal"; } } case pseudonode { leaf pseudonode { type empty; description "The node is pseudonode"; } } } leaf dr-interface-id { when "../pseudonode" { description "Valid only for pseudonode"; } type uint32; default "0"; description "For pseudonodes, DR interface-id"; } } } grouping ospf-link-attributes { description "OSPF link scope attributes"; container ospf-link-attributes { description"Containing"Contains OSPF link attributes"; } } // ospf-link-attributes augment "/l3t:l3-node-event" { description "OSPF node event"; uses ospf-topology-type; uses ospf-node-attributes; } augment "/l3t:l3-link-event" { description "OSPF link event"; uses ospf-topology-type; uses ospf-link-attributes; } } Appendix C. An Example This section contains an example of an instance data tree in JSON encoding [RFC7951]. The example instantiatesietf-l3-unicast- topology"ietf-l3-unicast- topology" for the topology that is depicted in the following diagram. There are threenodes,nodes: D1, D2, and D3. D1 has three terminationpoints,points: 1-0-1, 1-2-1, and 1-3-1. D2 has three termination points aswell,well: 2-1-1, 2-0-1, and 2-3-1. D3 has two terminationpoints,points: 3-1-1 and 3-2-1. Inadditionaddition, there are six links, two between each pair ofnodesnodes, with one going in each direction. +------------+ +------------+ | D1 | | D2 | /-\ /-\ /-\ /-\ | | 1-0-1 | |---------------->| | 2-1-1 | | | | 1-2-1 | |<----------------| | 2-0-1 | | \-/ 1-3-1 \-/ \-/ 2-3-1 \-/ | /----\ | | /----\ | +---| |---+ +---| |---+ \----/ \----/ A | A | | | | | | | | | | | +------------+ | | | | | D3 | | | | | /-\ /-\ | | | +----->| | 3-1-1 | |-------+ | +---------| | 3-2-1 | |<---------+ \-/ \-/ | | +------------+ Figure 2: Anetwork topology exampleNetwork Topology Example The corresponding instance data tree is depictedbelow:below. Note that some lines have been wrapped to adhere to the 72-character line limitation of RFCs. { "ietf-network:networks": { "network": [ { "network-types": { "ietf-l3-unicast-topology:l3-unicast-topology": {} }, "network-id": "l3-topo-example", "node": [ { "node-id": "D1", "termination-point": [ { "tp-id": "1-0-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 101 } }, { "tp-id": "1-2-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 121 } }, { "tp-id": "1-3-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 131 } } ], "ietf-l3-unicast-topology:l3-node-attributes": { "router-id": ["203.0.113.1"] } }, { "node-id": "D2", "termination-point": [ { "tp-id": "2-0-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 201 } }, { "tp-id": "2-1-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 211 } }, { "tp-id": "2-3-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 231 } } ], "ietf-l3-unicast-topology:l3-node-attributes": { "router-id": ["203.0.113.2"] } }, { "node-id": "D3", "termination-point": [ { "tp-id": "3-1-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 311 } }, { "tp-id": "3-2-1","ietf-l3-unicast-topology:l3-termination-point-attributes":"ietf-l3-unicast-topology: l3-termination-point-attributes": { "unnumbered-id:": 321 } } ], "ietf-l3-unicast-topology:l3-node-attributes": { "router-id": ["203.0.113.3"] } } ], "ietf-network-topology:link": [ { "link-id": "D1,1-2-1,D2,2-1-1","destination":"source": { "source-node": "D1", "source-tp": "1-2-1" } "destination": { "dest-node": "D2", "dest-tp": "2-1-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } }, { "link-id": "D2,2-1-1,D1,1-2-1","destination":"source": { "source-node": "D2", "source-tp": "2-1-1" } "destination": { "dest-node": "D1", "dest-tp": "1-2-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } }, { "link-id": "D1,1-3-1,D3,3-1-1","destination":"source": { "source-node": "D1", "source-tp": "1-3-1" } "destination": { "dest-node": "D3", "dest-tp": "3-1-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } }, { "link-id": "D3,3-1-1,D1,1-3-1","destination":"source": { "source-node": "D3", "source-tp": "3-1-1" } "destination": { "dest-node": "D1", "dest-tp": "1-3-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } }, { "link-id": "D2,2-3-1,D3,3-2-1","destination":"source": { "source-node": "D2", "source-tp": "2-3-1" } "destination": { "dest-node": "D3", "dest-tp": "3-2-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } }, { "link-id": "D3,3-2-1,D2,2-3-1","destination":"source": { "source-node": "D3", "source-tp": "3-2-1" } "destination": { "dest-node": "D2", "dest-tp": "2-3-1" }, "ietf-l3-unicast-topology:l3-link-attributes": { "metric1": "100" } } ] } ] } } Figure 3: Instancedata treeData Tree Acknowledgments We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Andy Bierman, Benoit Claise, Joel Halpern, Susan Hares, Ladislav Lhotka, Carl Moberg, Carlos Pignataro, Juergen Schoenwaelder, Michal Vasco, and Kent Watsen. Contributors The model presented in this document was contributed to by more people than can be listed on the author list. Additional contributors include: o Vishnu Pavan Beeram, Juniper o Igor Bryskin, Huawei o Ken Gray, Cisco o Aihua Guo, Huawei o Tom Nadeau, Brocade o Tony Tkacik o Aleksandr Zhdankin, Cisco Authors' Addresses Alexander Clemm Huawei USAEMail: ludwig@clemm.org- Futurewei Technologies Inc. Santa Clara, CA United States of America Email: ludwig@clemm.org, alexander.clemm@huawei.com Jan Medved CiscoEMail:Email: jmedved@cisco.com Robert Varga Pantheon Technologies SROEMail:Email: robert.varga@pantheon.tech Xufeng Liu JabilEMail: Xufeng_Liu@jabil.comEmail: xufeng.liu.ietf@gmail.com Hariharan Ananthakrishnan Packet DesignEMail:Email: hari@packetdesign.com Nitin Bahadur Bracket ComputingEMail:Email: nitin_bahadur@yahoo.com