RFC 8345: A YANG Data Model for Network Topologies
Errata Exist
Internet Engineering Task Force (IETF) A. Clemm
Request for Comments: 8345 Huawei
Category: Standards Track J. Medved
ISSN: 2070-1721 Cisco
R. Varga
Pantheon Technologies SRO
N. Bahadur
Bracket Computing
H. Ananthakrishnan
Packet Design
X. Liu
Jabil
March 2018
A YANG Data Model for Network Topologies
Abstract
This document defines an abstract (generic, or base) YANG data model
for network/service topologies and inventories. The data model
serves as a base model that is augmented with technology-specific
details in other, more specific topology and inventory data models.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8345.
Clemm, et al. Standards Track [Page 1]
RFC 8345 YANG Data Model for Network Topologies March 2018BCP 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.Clemm, et al. Standards Track [Page 2]
RFC 8345 YANG Data Model for Network Topologies March 20181 . IntroductionRFC7950] data model [RFC3444] to represent networks and topologies. The data model is divided into two parts: The first part of the data model defines a network data model that enables the definition of network hierarchies, or network stacks (i.e., networks that are layered on top of each other) and maintenance of an inventory of nodes contained in a network. The second part of the data model augments the basic network data model with information to describe topology information. Specifically, it adds the concepts of "links" and "termination points" to describe how nodes in a network are connected to each other. Moreover, the data model introduces vertical layering relationships between networks that can be augmented to cover both network inventories and network/service topologies. Although it would be possible to combine both parts into a single data model, the separation facilitates integration of network topology and network inventory data models, because it allows network inventory information to be augmented separately, and without concern for topology, into the network data model. The data model can be augmented to describe the specifics of particular types of networks and topologies. For example, an augmenting data model can provide network node information with attributes that are specific to a particular network type. Examples of augmenting models include data models for Layer 2 network topologies; Layer 3 network topologies such as unicast IGP, IS-IS [RFC1195], and OSPF [RFC2328]; traffic engineering (TE) data [RFC3209]; or any of the variety of transport and service topologies. Information specific to particular network types will be captured in separate, technology-specific data models. The basic data models introduced in this document are generic in nature and can be applied to many network and service topologies and inventories. The data models allow applications to operate on an inventory or topology of any network at a generic level, where the specifics of particular inventory/topology types are not required. At the same time, where data specific to a network type comes into play and the data model is augmented, the instantiated data still adheres to the same structure and is represented in a consistent fashion. This also facilitates the representation of network hierarchies and dependencies between different network components and network types. The abstract (base) network YANG module introduced in this document, entitled "ietf-network" (Section 6.1), contains a list of abstract network nodes and defines the concept of "network hierarchy" (networkClemm, et al. Standards Track [Page 4]
RFC 8345 YANG Data Model for Network Topologies March 2018Section 6.2), defines a generic topology data model at its most general level of abstraction. The module defines a topology graph and components from which it is composed: nodes, edges, and termination points. Nodes (from the "ietf-network" module) represent graph vertices and links represent graph edges. Nodes also contain termination points that anchor the links. A network can contain multiple topologies -- for example, topologies at different layers and overlay topologies. The data model therefore allows relationships between topologies, as well as dependencies between nodes and termination points across topologies, to be captured. An example of a topology stack is shown in Figure 2.Clemm, et al. Standards Track [Page 5]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 6]
RFC 8345 YANG Data Model for Network Topologies March 2018USECASE-REQS].Clemm, et al. Standards Track [Page 7]
RFC 8345 YANG Data Model for Network Topologies March 2018RFC8342], the requirements for which are defined in Section 3 of [RFC8242]. This allows network topology data that is written, i.e., configured by a client and not system controlled, to refer to dynamically learned data that is controlled by the system, not configured by a client. A simple use case might involve creating an overlay network that is supported by the dynamically discovered IP-routed network topology. When an implementation places written data for this data model in the ephemeral datastore, such a network MAY refer to another network that is system controlled. 2 . Key WordsBCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.Clemm, et al. Standards Track [Page 8]
RFC 8345 YANG Data Model for Network Topologies March 20183 . Definitions and AbbreviationsRFC8342]). Data subtree: An instantiated data node and the data nodes that are hierarchically contained within it. IGP: Interior Gateway Protocol. IS-IS: Intermediate System to Intermediate System. OSPF: Open Shortest Path First (a link-state routing protocol). SDN: Software-Defined Networking. URI: Uniform Resource Identifier. VM: Virtual Machine. 4 . Model Structure Details4.1 . Base Network ModelRFC8340]. module: ietf-network +--rw networks +--rw network* [network-id] +--rw network-id network-id +--rw network-types +--rw supporting-network* [network-ref] | +--rw network-ref -> /networks/network/network-id +--rw node* [node-id] +--rw node-id node-id +--rw supporting-node* [network-ref node-ref] +--rw network-ref | -> ../../../supporting-network/network-ref +--rw node-ref -> /networks/network/node/node-id Figure 4: The Structure of the Abstract (Base) Network Data ModelClemm, et al. Standards Track [Page 9]
RFC 8345 YANG Data Model for Network Topologies March 2018RFC8346]. A network can in turn be part of a hierarchy of networks, building on top of other networks. Any such networks are captured in the list "supporting-network". A supporting network is, in effect, an underlay network. Furthermore, a network contains an inventory of nodes that are part of the network. The nodes of a network are captured in their own list. Each node is identified relative to its containing network by a node-id. It should be noted that a node does not exist independently of a network; instead, it is a part of the network that contains it. In cases where the same device or entity takes part in multiple networks, or at multiple layers of a networking stack, the same device or entity will be represented by multiple nodes, one for each network. In other words, the node represents an abstraction of the device for the particular network of which it is a part. To indicate that the same entity or device is part of multiple topologies or networks, it is possible to create one "physical" network with a list of nodes for each of the devices or entities. This (physical) network -- the nodes (entities) in that network -- can then be referred to as an underlay network and as nodes from the other (logical) networks and nodes, respectively. Note that the data modelClemm, et al. Standards Track [Page 10]
RFC 8345 YANG Data Model for Network Topologies March 2018RFC8342] is used to account for those possibilities. Specifically, for each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation (as defined in [RFC8342]) -- "intended" for data that was configured by a client application and "learned" for data that is discovered. Network data that is discovered is automatically populated as part of the operational state datastore. Network data that is configured is part of the configuration and intended datastores, respectively. Configured network data that is actually in effect is, in addition, reflected in the operational state datastore. Data in the operational state datastore will always have complete referential integrity. Should a configured data item (such as a node) have a dangling reference that refers to a non-existing data item (such as a supporting node), the configured data item will automatically be removed from the operational state datastore and thus only appear in the intended datastore. It will be up to the client application (such as an SDN Controller) to resolve the situation and ensure that the reference to the supporting resources is configured properly.Clemm, et al. Standards Track [Page 11]
RFC 8345 YANG Data Model for Network Topologies March 20184.2 . Base Network Topology Data ModelRFC8340]. module: ietf-network-topology augment /nw:networks/nw:network: +--rw link* [link-id] +--rw link-id link-id +--rw source | +--rw source-node? -> ../../../nw:node/node-id | +--rw source-tp? leafref +--rw destination | +--rw dest-node? -> ../../../nw:node/node-id | +--rw dest-tp? leafref +--rw supporting-link* [network-ref link-ref] +--rw network-ref | -> ../../../nw:supporting-network/network-ref +--rw link-ref leafref augment /nw:networks/nw:network/nw:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref | -> ../../../nw:supporting-node/network-ref +--rw node-ref | -> ../../../nw:supporting-node/node-ref +--rw tp-ref leafref Figure 5: The Structure of the Abstract (Base) Network Topology Data Model A node has a list of termination points that are used to terminate links. An example of a termination point might be a physical or logical port or, more generally, an interface. Like a node, a termination point can in turn be supported by an underlying termination point, contained in the supporting node of the underlay network.Clemm, et al. Standards Track [Page 12]
RFC 8345 YANG Data Model for Network Topologies March 20184.3 . Extending the Data ModelClemm, et al. Standards Track [Page 13]
RFC 8345 YANG Data Model for Network Topologies March 20184.4 . Discussion and Selected Design Decisions4.4.1 . Container Structure4.4.2 . Underlay Hierarchies and MappingsRFC8343]. Similarly, if a node maps to a particular device or network element, an augmenting module can augment the node data with a leaf that references the network element.Clemm, et al. Standards Track [Page 14]
RFC 8345 YANG Data Model for Network Topologies March 20184.4.3 . Dealing with Changes in Underlay NetworksRFC7950]. A dangling leafref of a configured object leaves the corresponding instance in a state in which it lacks referential integrity, effectively rendering it nonoperational. Any corresponding object instance is therefore removed from the operational state datastore until the situation has been resolved, i.e., until either (1) the supporting object is added to the operational state datastore or (2) the instance is reconfigured to refer to another object that is actually reflected in the operational state datastore. It will remain part of the intended datastore. It is the responsibility of the application maintaining the overlay to deal with the possibility of churn in the underlay network. When a server receives a request to configure an overlay network, it SHOULD validate whether supporting nodes / links / termination points refer to nodes in the underlay that actually exist, i.e., verify that the nodes are reflected in the operational state datastore. Configuration requests in which supporting nodes / links / termination points refer to objects currently not in existence SHOULD be rejected. It is the responsibility of the application to update the overlay when a supporting node / link / termination point is deleted at a later point in time. For this purpose, an application might subscribe to updates when changes to the underlay occur -- for example, using mechanisms defined in [YANG-Push]. 4.4.4 . Use of GroupingsClemm, et al. Standards Track [Page 15]
RFC 8345 YANG Data Model for Network Topologies March 20184.4.5 . Cardinality and Directionality of Links4.4.6 . Multihoming and Link Aggregation4.4.7 . Mapping RedundancyClemm, et al. Standards Track [Page 16]
RFC 8345 YANG Data Model for Network Topologies March 20184.4.8 . Typing4.4.9 . Representing the Same Device in Multiple NetworksClemm, et al. Standards Track [Page 17]
RFC 8345 YANG Data Model for Network Topologies March 20184.4.10 . Supporting Client-Configured and System-Controlled NetworkTopologies
YANG requires data nodes to be designated as either configuration data ("config true") or operational data ("config false"), but not both, yet it is important to have all network information, including vertical cross-network dependencies, captured in one coherent data model. In most cases, network topology information about a network is discovered; the topology is considered a property of the network that is reflected in the data model. That said, certain types of topologies need to also be configurable by an application, e.g., in the case of overlay topologies. The YANG data model for network topologies designates all data as "config true". The distinction between data that is actually configured and data that is in effect, including network data that is discovered, is provided through the datastores introduced as part of the Network Management Datastore Architecture (NMDA) [RFC8342]. Network topology data that is discovered is automatically populated as part of the operational state datastore, i.e., <operational>. It is "system controlled". Network topology that is configured is instantiated as part of a configuration datastore, e.g., <intended>. Only when it has actually taken effect will it also be instantiated as part of the operational state datastore, i.e., <operational>.Clemm, et al. Standards Track [Page 18]
RFC 8345 YANG Data Model for Network Topologies March 2018RFC7952] annotation defined in [RFC8342]. In general, the origin of discovered network data is "learned"; the origin of configured network data is "intended". 4.4.11 . Identifiers of String or URI Type5 . Interactions with Other YANG ModulesRFC6991]. This is a protocol-independent YANG data model with topology information. It is separate from, and not linked with, data models that are used to configure routing protocols or routing information. This includes, for example, the "ietf-routing" YANG module [RFC8022].Clemm, et al. Standards Track [Page 19]
RFC 8345 YANG Data Model for Network Topologies March 2018RFC8242]. For ephemeral topology data that is system controlled, the process tasked with maintaining topology information will load information from the routing process (such as OSPF) into the operational state datastore without relying on a configuration datastore. 6 . YANG Modules6.1 . Defining the Abstract Network: ietf-networkRFC 6991: Common YANG Data Types"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:[email protected]> Editor: Alexander Clemm <mailto:[email protected]> Editor: Jan Medved <mailto:[email protected]> Editor: Robert Varga <mailto:[email protected]> Editor: Nitin Bahadur <mailto:[email protected]> Editor: Hariharan Ananthakrishnan <mailto:[email protected]> Editor: Xufeng Liu <mailto:[email protected]>";Clemm, et al. Standards Track [Page 20]
RFC 8345 YANG Data Model for Network Topologies March 2018Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8345; see the RFC itself for full legal notices."; revision 2018-02-26 { description "Initial revision."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } typedef node-id { type inet:uri; description "Identifier for a node. The precise structure of the node-id will be up to the implementation. For example, some implementations MAY pick a URI that includes the network-id as part of the path. The identifier SHOULD be chosen such that the same node in a real network topology will always be identified through the same identifier, even if the data model is instantiated in separate datastores. An implementation MAY choose to capture semantics in the identifier -- for example, to indicate the type of node."; }Clemm, et al. Standards Track [Page 21]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 22]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 23]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 24]
RFC 8345 YANG Data Model for Network Topologies March 20186.2 . Creating Abstract Network Topology: ietf-network-topologyRFC 6991: Common YANG Data Types"; } import ietf-network { prefix nw; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:[email protected]> Editor: Alexander Clemm <mailto:[email protected]> Editor: Jan Medved <mailto:[email protected]> Editor: Robert Varga <mailto:[email protected]> Editor: Nitin Bahadur <mailto:[email protected]> Editor: Hariharan Ananthakrishnan <mailto:[email protected]> Editor: Xufeng Liu <mailto:[email protected]>";Clemm, et al. Standards Track [Page 25]
RFC 8345 YANG Data Model for Network Topologies March 2018Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8345; see the RFC itself for full legal notices."; revision 2018-02-26 { description "Initial revision."; reference "RFC 8345: A YANG Data Model for Network Topologies"; } typedef link-id { type inet:uri; description "An identifier for a link in a topology. The precise structure of the link-id will be up to the implementation. The identifier SHOULD be chosen such that the same link in a real network topology will always be identified through the same identifier, even if the data model is instantiated in separate datastores. An implementation MAY choose to capture semantics in the identifier -- for example, to indicate the type of link and/or the type of topology of which the link is a part."; } typedef tp-id { type inet:uri; description "An identifier for termination points on a node. The precise structure of the tp-id will be up to the implementation. The identifier SHOULD be chosen such that the same termination point in a real network topology will always be identified through the same identifier, even if the data model isClemm, et al. Standards Track [Page 26]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 27]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 28]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 29]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 30]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 31]
RFC 8345 YANG Data Model for Network Topologies March 20187 . IANA ConsiderationsRFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-network Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-topology Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-state Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-network-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-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network Prefix: nw Reference: RFC 8345 Name: ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Prefix: nt Reference: RFC 8345 Name: ietf-network-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state Prefix: nw-s Reference: RFC 8345 Name: ietf-network-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Prefix: nt-s Reference: RFC 8345Clemm, et al. Standards Track [Page 32]
RFC 8345 YANG Data Model for Network Topologies March 20188 . Security ConsiderationsRFC6241] 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 [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. The network topology and inventory created by these modules reveal information about the structure of networks that could be very helpful to an attacker. As a privacy consideration, although there is no personally identifiable information defined in these modules, it is possible that some node identifiers may be associated with devices that are in turn associated with specific users. The YANG modules define information that can be configurable in certain instances -- for example, in the case of overlay topologies that can be created by client applications. In such cases, a malicious client could introduce topologies that are undesired. Specifically, a malicious client could attempt to remove or add a node, a link, or a termination point by creating or deleting corresponding elements in node, link, or termination point lists, respectively. In the case of a topology that is learned, the server will automatically prohibit such misconfiguration attempts. In the case of a topology that is configured, i.e., whose origin is "intended", the undesired configuration could become effective and be reflected in the operational state datastore, leading to disruption of services provided via this topology. For example, the topology could be "cut" or could be configured in a suboptimal way, leading to increased consumption of resources in the underlay network due to the routing and bandwidth utilization inefficiencies that would result. Likewise, it could lead to degradation of service levels as well as possible disruption of service. For those reasons, it is important that the NETCONF access control model be vigorously applied to prevent topology misconfiguration by unauthorized clients. There are a number of data nodes defined in these YANG modules 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)Clemm, et al. Standards Track [Page 33]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 34]
RFC 8345 YANG Data Model for Network Topologies March 2018Appendix A . Model Use CasesA.1 . Fetching Topology from a Network ElementA.2 . Modifying TE Topology Imported from an Optical ControllerClemm, et al. Standards Track [Page 38]
RFC 8345 YANG Data Model for Network Topologies March 2018A.3 . Annotating Topology for Local ComputationA.4 . SDN Controller-Based Configuration of Overlays on Top of UnderlaysAppendix B . Companion YANG Data Models for Implementations NotRFC8342]. In order to allow implementations to use the data model even in cases when NMDA is not supported, the following two companion modules -- "ietf-network-state" and "ietf-network-topology-state" -- are defined; they represent the operational state of networks and network topologies, respectively. These modules mirror the "ietf-network"Clemm, et al. Standards Track [Page 39]
RFC 8345 YANG Data Model for Network Topologies March 20186.1 and 6.2 of this document); however, in the case of these modules, all data nodes are non-configurable. They represent state that comes into being by either (1) learning topology information from the network or (2) applying configuration from the mirrored modules. The "ietf-network-state" and "ietf-network-topology-state" companion modules are redundant and SHOULD NOT be supported by implementations that support NMDA; therefore, we define these modules in Appendices B.1 and B.2 (below) instead of the main body of this document. As the structure of both modules mirrors that of their underlying modules, the YANG tree is not depicted separately. B.1 . YANG Module for Network StateRFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:[email protected]> Editor: Alexander Clemm <mailto:[email protected]> Editor: Jan Medved <mailto:[email protected]> Editor: Robert Varga <mailto:[email protected]> Editor: Nitin Bahadur <mailto:[email protected]>Clemm, et al. Standards Track [Page 40]
RFC 8345 YANG Data Model for Network Topologies March 2018Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8345; see the RFC itself for full legal notices."; revision 2018-02-26 { description "Initial revision."; reference "RFC 8345: A YANG Data Model for Network Topologies"; }Clemm, et al. Standards Track [Page 41]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 42]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 43]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 44]
RFC 8345 YANG Data Model for Network Topologies March 2018B.2 . YANG Module for Network Topology StateRFC 8345: A YANG Data Model for Network Topologies"; } import ietf-network-topology { prefix nt; reference "RFC 8345: A YANG Data Model for Network Topologies"; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: <https://datatracker.ietf.org/wg/i2rs/> WG List: <mailto:[email protected]> Editor: Alexander Clemm <mailto:[email protected]> Editor: Jan Medved <mailto:[email protected]> Editor: Robert Varga <mailto:[email protected]> Editor: Nitin Bahadur <mailto:[email protected]> Editor: Hariharan Ananthakrishnan <mailto:[email protected]> Editor: Xufeng Liu <mailto:[email protected]>";Clemm, et al. Standards Track [Page 45]
RFC 8345 YANG Data Model for Network Topologies March 2018Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC 8345; see the RFC itself for full legal notices."; revision 2018-02-26 { description "Initial revision."; reference "RFC 8345: A YANG Data Model for Network Topologies"; }Clemm, et al. Standards Track [Page 46]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 47]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 48]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 49]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 50]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 51]
RFC 8345 YANG Data Model for Network Topologies March 2018Appendix C . An ExampleRFC7951]. The example instantiates "ietf-network-topology" (and "ietf-network", which "ietf-network-topology" augments) for the topology depicted in Figure 7. There are three nodes: D1, D2, and D3. D1 has three termination points (1-0-1, 1-2-1, and 1-3-1). D2 has three termination points as well (2-1-1, 2-0-1, and 2-3-1). D3 has two termination points (3-1-1 and 3-2-1). In addition, there are six links, two between each pair of nodes 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 7: A Network Topology ExampleClemm, et al. Standards Track [Page 52]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 53]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 54]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 55]
RFC 8345 YANG Data Model for Network Topologies March 2018Clemm, et al. Standards Track [Page 56]
RFC 8345 YANG Data Model for Network Topologies March 2018
![Toni Kroos là ai? [ sự thật về tiểu sử đầy đủ Toni Kroos ]](https://evbn.org/wp-content/uploads/New-Project-6635-1671934592.jpg)
