--- 1/draft-ietf-i2rs-yang-network-topo-18.txt 2017-12-13 11:13:13.594461680 -0800 +++ 2/draft-ietf-i2rs-yang-network-topo-19.txt 2017-12-13 11:13:13.690463942 -0800 @@ -1,27 +1,27 @@ Network Working Group A. Clemm Internet-Draft Huawei Intended status: Standards Track J. Medved -Expires: May 19, 2018 Cisco +Expires: June 16, 2018 Cisco R. Varga Pantheon Technologies SRO N. Bahadur Bracket Computing H. Ananthakrishnan Packet Design X. Liu Jabil - November 15, 2017 + December 13, 2017 A Data Model for Network Topologies - draft-ietf-i2rs-yang-network-topo-18.txt + draft-ietf-i2rs-yang-network-topo-19.txt Abstract This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The data model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory data models. Status of This Memo @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any 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 May 19, 2018. + This Internet-Draft will expire on June 16, 2018. Copyright Notice Copyright (c) 2017 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 @@ -286,40 +286,39 @@ among themselves or with help of a controller. Beyond the network element and the immediate context of I2RS 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. Further use cases that the data model can be applied to are described in [I-D.draft-ietf-i2rs-usecase-reqs-summary]. In this data model, a network is categorized as either system controlled or not. If a network is system controlled, then it is automatically populated by the server and represents dynamically - learned information that can be read from the operational datastore. - The data model can also be used to create or modify network - topologies such as might be associated with an inventory or with an - overlay network. Such a network is not system controlled but - configured by a client. + learned information that can be read from the operational state + datastore. The data model can also be used to create or modify + network topologies that might be associated with an inventory model + or with an overlay network. Such a network is not system controlled + but configured by a client. The data model allows a network to refer to a supporting-network, supporting-nodes, supporting-links, etc. The data model also allows to layer a network that is configured on top of one that is system controlled. This permits the configuration of overlay networks on top of networks that are discovered. Specifically, this data model is structured to support being implemented as part of the ephemeral datastore [I-D.draft-ietf-netmod-revised-datastores], defined as - requirement Ephemeral-REQ-03 in - [I-D.draft-ietf-i2rs-ephemeral-state]. This allows network topology - data that is written, i.e. configured by a client and not system - controlled, to refer to a 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 + requirement Ephemeral-REQ-03 in [RFC8242]. This allows network + topology data that is written, i.e. configured by a client and not + system controlled, to refer to a 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 data store, then such a network MAY refer to another network that is system controlled. 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 @@ -437,31 +436,32 @@ be discovered. It is possible for a configured (overlay) network to refer to a (discovered) underlay network. The revised datastore architecture [I-D.draft-ietf-netmod-revised-datastores] is used to account for those possibilities. Specifically, for each network, the origin of its data is indicated per the "origin" metadata annotation - "intended" for data that was configured by a client application, "learned" for data that is discovered. Network data that is discovered is automatically populated as part of the operational - datastore. Network data that is configured is part of the + 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 datastore. Data in the operational 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 datastore and - thus only appear in the intended datastore. It will be up to the - client application to resolve the situation and ensure that the - reference to the supporting resources is configured properly. + 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. 4.2. Base Network Topology Data Model The abstract (base) network topology data model is defined in the "ietf-network-topology.yang" module. It builds on the network data model defined in the "ietf-network.yang" module, augmenting it with links (defining how nodes are connected) and termination-points (which anchor the links and are contained in nodes). The structure of the network topology module is shown in the following figure. The notation syntax follows [I-D.draft-ietf-netmod-yang-tree-diagrams]. @@ -518,21 +518,21 @@ 4.3. Extending the data model In order to derive a data model for a specific type of network, the base data model can be extended. This can be done roughly as follows: for the new network type, a new YANG module is introduced. In this module, a number of augmentations are defined against the network and network-topology YANG modules. We start with augmentations against the ietf-network.yang module. First, a new network type needs to be defined. For this, a presence - container that resembles the new network type is defined. It is + container that represents the new network type is defined. It is inserted by means of augmentation below the network-types container. Subsequently, data nodes for any network-type specific node parameters are defined and augmented into the node list. The new data nodes can be defined as conditional ("when") on the presence of the corresponding network type in the containing network. In cases where there are any requirements or restrictions in terms of network hierarchies, such as when a network of a new network-type requires a specific type of underlay network, it is possible to define corresponding constraints as well and augment the supporting-network list accordingly. However, care should be taken to avoid excessive @@ -556,27 +556,27 @@ a network "sub-type" augmenting the module of a network "super-type". 4.4. Discussion and selected design decisions 4.4.1. Container structure Rather than maintaining lists in separate containers, the data model is kept relatively flat in terms of its containment structure. Lists of nodes, links, termination-points, and supporting-nodes, supporting-links, and supporting-termination-points are not kept in - separate containers. Therefore, path specifiers used to refer to - specific nodes, be it in management operations or in specifications - of constraints, can remain relatively compact. Of course, this means - there is no separate structure in instance information that separates - elements of different lists from one another. Such structure is - semantically not required, although it might enhance human - readability in some cases. + separate containers. Therefore, path identifiers are used to refer + to specific nodes, be it in management operations or in + specifications of constraints, can remain relatively compact. Of + course, this means there is no separate structure in instance + information that separates elements of different lists from one + another. Such structure is semantically not required, although it + might enhance human readability in some cases. 4.4.2. Underlay hierarchies and mappings To minimize assumptions of what a particular entity might actually represent, mappings between networks, nodes, links, and termination points are kept strictly generic. For example, no assumptions are made whether a termination point actually refers to an interface, or whether a node refers to a specific "system" or device; the data model at this generic level makes no provisions for that. @@ -602,34 +602,34 @@ It is possible for a network to undergo churn even as other networks are layered on top of it. When a supporting node, link, or termination point is deleted, the supporting leafrefs in the overlay will be left dangling. To allow for this possibility, the data model makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. A dangling leafref of a configured object leaves the corresponding instance in a state in which it lacks referential integrity, rendering it in effect inoperational. Any corresponding object - instance is therefore removed from the operational datastore until - the situation has been resolved, i.e. until either the supporting - object is added to the operational datastore, or until the instance - is reconfigured to refer to another object that is actually reflected - in the operational datastore. It does remain part of the intended - datastore. + instance is therefore removed from the operational state datastore + until the situation has been resolved, i.e. until either the + supporting object is added to the operational state datastore, or + until the instance is reconfigured to refer to another object that is + actually reflected in the operational state datastore. It does + 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/tps refer to nodes in the underlay are actually in existence, i.e. nodes which are - reflected in the operational datastore. Configuration requests in - which supporting nodes/links/tps refer to objects currently not in + reflected in the operational state datastore. Configuration requests + in which supporting nodes/links/tps 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/tp 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 [I-D.draft-ietf-netconf-yang-push]. 4.4.4. Use of groupings The data model makes use of groupings, instead of simply defining @@ -755,39 +755,39 @@ topology need to also be configurable by an application, such as in the case of overlay topologies. The YANG data model for network topology designates all data as "config true". The distinction between data that is actually configured and data that is in effect, including data that is discovered about the network, is provided through the datastores introduced as part of the Network Management Datastore Architecture, NMDA [I-D.draft-ietf-netmod-revised-datastores]. Network topology data that is discovered is automatically populated as part of the - operational datastore, . It is "system controlled". - Network topology that is configured is instantiated as part of a - configuration datastore, e.g. . Only when it has actually - taken effect, it is also instantiated as part of the operational - datastore, i.e. . + operational state datastore, . It is "system + controlled". Network topology that is configured is instantiated as + part of a configuration datastore, e.g. . Only when it has + actually taken effect, it is also instantiated as part of the + operational state datastore, i.e. . Configured network topology will in general refer to an underlay topology and include layering information, such as the supporting node(s) underlying a node, supporting link(s) underlying a link, and supporting termination point(s) underlying a termination point. The - supporting objects must be instantiated in the operational datastore - in order for the dependent overlay object to be reflected in the - operational datastore. 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 and show up only in the - . It will be up to the client application to resolve the - situation and ensure that the reference to the supporting resources - is configured properly. + supporting objects must be instantiated in the operational state + datastore in order for the dependent overlay object to be reflected + in the operational state datastore. 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 and show up + only in . It will be up to the client application to + resolve the situation and ensure that the reference to the supporting + resources is configured properly. For each network, the origin of its data is indicated per the "origin" metadata [RFC7952] annotation defined in [I-D.draft-ietf-netmod-revised-datastores]. 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 type The current data model defines identifiers of nodes, networks, links, @@ -812,34 +812,34 @@ The data model makes use of data types that have been defined in [RFC6991]. 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 e.g. data model "ietf-routing" [RFC8022]. The data model obeys the requirements for the ephemeral state found - in the document [I-D.draft-ietf-i2rs-ephemeral-state]. 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 without relying - on a configuration datastore. + in the document [RFC8242]. 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 Modules 6.1. Defining the Abstract Network: ietf-network.yang NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of publication when published. - file "ietf-network@2017-11-15.yang" + file "ietf-network@2017-12-13.yang" module ietf-network { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nw; import ietf-inet-types { prefix inet; reference "RFC 6991"; } @@ -877,38 +877,38 @@ 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). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-18; + draft-ietf-i2rs-yang-network-topo-19; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-11-15 { + revision 2017-12-13 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-18 with + to draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published. "; reference - "draft-ietf-i2rs-yang-network-topo-18"; + "draft-ietf-i2rs-yang-network-topo-19"; } typedef node-id { type inet:uri; description "Identifier for a node. The precise structure of the node-id will be up to the implementation. Some implementations MAY for example, 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 @@ -1036,38 +1036,38 @@ } } 6.2. Creating Abstract Network Topology: ietf-network-topology.yang NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of publication when published. - file "ietf-network-topology@2017-11-15.yang" + file "ietf-network-topology@2017-12-13.yang" module ietf-network-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; prefix nt; import ietf-inet-types { prefix inet; reference "RFC 6991"; } import ietf-network { prefix nw; reference - "draft-ietf-i2rs-yang-network-topo-18 + "draft-ietf-i2rs-yang-network-topo-19 NOTE TO RFC EDITOR: (1) Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: @@ -1100,35 +1100,35 @@ 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). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-18; + draft-ietf-i2rs-yang-network-topo-19; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-11-15 { + revision 2017-12-13 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-18 with + to draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-network-topo-18"; + "draft-ietf-i2rs-yang-network-topo-19"; } 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 @@ -1375,42 +1375,42 @@ 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]: NOTE TO THE RFC EDITOR: In the list below, please replace references - to "draft-ietf-i2rs-yang-network-topo-18 (RFC form)" with RFC number + to "draft-ietf-i2rs-yang-network-topo-19 (RFC form)" with RFC number when published (i.e. RFC xxxx). Name: ietf-network Namespace: urn:ietf:params:xml:ns:yang:ietf-network Prefix: nw - Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-19.txt (RFC form) Name: ietf-network-topology Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology Prefix: nt - Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-19.txt (RFC form) Name: ietf-network-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-state Prefix: nw-s - Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-19.txt (RFC form) Name: ietf-network-topology-state Namespace: urn:ietf:params:xml:ns:yang:ietf-network-topology-state Prefix: nt-s - Reference: draft-ietf-i2rs-yang-network-topo-18.txt (RFC form) + Reference: draft-ietf-i2rs-yang-network-topo-19.txt (RFC form) 8. Security Considerations The YANG modules defined in this document are 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]. @@ -1423,29 +1423,29 @@ 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, a termination point, by creating or deleting corresponding elements in the node, link, and 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 datastore, leading to disruption of services provided via - this topology might be disrupted. For example, the topology could be - "cut" or be configured in a suboptimal way, leading to increased - consumption of resources in the underlay network due to resulting - routing and bandwidth utilization inefficiencies. Likewise, it could - lead to degradation of service levels as well as possibly disruption - of service. For those reasons, it is important that the NETCONF - access control model is vigorously applied to prevent topology - misconfiguration by unauthorized clients. + operational state datastore, leading to disruption of services + provided via this topology might be disrupted. For example, the + topology could be "cut" or be configured in a suboptimal way, leading + to increased consumption of resources in the underlay network due to + resulting routing and bandwidth utilization inefficiencies. + Likewise, it could lead to degradation of service levels as well as + possibly disruption of service. For those reasons, it is important + that the NETCONF access control model is vigorously applied to + prevent topology misconfiguration by unauthorized clients. Specifically, there are a number of data nodes defined in these YANG module 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 the ietf-network module: @@ -1509,22 +1509,22 @@ Carlos Pignataro, Juergen Schoenwaelder, Robert Wilton, and Xian Zhang. 11. References 11.1. Normative References [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-02, - May 2017. + Datastores", I-D draft-ietf-netmod-revised-datastores-07, + November 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. @@ -1550,45 +1550,40 @@ RFC 7950, August 2016. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, January 2017. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", RFC 8174, May 2017. 11.2. Informative References - [I-D.draft-ietf-i2rs-ephemeral-state] - Haas, J. and S. Hares, "I2RS Ephemeral State - Requirements", I-D draft-ietf-i2rs-ephemeral-state-23, - November 2016. - [I-D.draft-ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary- 03, November 2016. [I-D.draft-ietf-i2rs-yang-l3-topology] Clemm, A., Medved, J., Varga, R., Liu, X., Ananthakrishnan, H., and N. Bahadur, "A YANG Data Model for Layer 3 Topologies", I-D draft-ietf-i2rs-yang-l3- - topology-11, September 2017. + topology-13, November 2017. [I-D.draft-ietf-netconf-yang-push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Nilsen-Nygaard, E., Bierman, A., and B. Lengyel, "Subscribing to YANG datastore push updates", I-D draft- - ietf-netconf-yang-push-10, October 2017. + ietf-netconf-yang-push-11, October 2017. [I-D.draft-ietf-netmod-yang-tree-diagrams] Bjorklund, M. and L. Berger, "YANG Tree Diagrams", I-D - draft-ietf-netmod-yang-tree-diagrams, June 2017. + draft-ietf-netmod-yang-tree-diagrams, October 2017. [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. @@ -1601,20 +1596,23 @@ [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, August 2016. [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC 7952, August 2016. [RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Management", RFC 8022, November 2016. + [RFC8242] Haas, J. and S. Hares, "I2RS Ephemeral State + Requirements", RFC 8242, September 2017. + Appendix A. Model Use Cases A.1. Fetching Topology from a Network Element In its simplest form, topology is learned by a network element (e.g., a router) through its participation in peering protocols (IS-IS, BGP, etc.). This learned topology can then be exported (e.g., to a Network Management System) for external utilization. Typically, any network element in a domain can be queried for its topology and expected to return the same result. @@ -1713,32 +1711,32 @@ defined in an appendix. As the structure of both modules mirrors that of their underlying modules, the YANG tree is not depicted separately. B.1. YANG Model for Network State NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of the publication when published. - file "ietf-network-state@2017-11-15.yang" + file "ietf-network-state@2017-12-13.yang" module ietf-network-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-state"; prefix nw-s; import ietf-network { prefix nw; reference - "draft-ietf-i2rs-yang-network-topo-18 + "draft-ietf-i2rs-yang-network-topo-19 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: @@ -1778,38 +1776,38 @@ 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). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-18; + draft-ietf-i2rs-yang-network-topo-19; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-11-15 { + revision 2017-12-13 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-18 with + to draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of the publication when published."; reference - "draft-ietf-i2rs-yang-network-topo-18"; + "draft-ietf-i2rs-yang-network-topo-19"; } grouping network-ref { description "Contains the information necessary to reference a network, for example an underlay network."; leaf network-ref { type leafref { path "/nw-s:networks/nw-s:network/nw-s:network-id"; require-instance false; @@ -1914,40 +1912,40 @@ } } } B.2. YANG Data Model for Network Topology State NOTE TO RFC EDITOR: Please change the date in the file name after the CODE BEGINS statement to the date of the publication when published. - file "ietf-network-topology-state@2017-11-15.yang" + file "ietf-network-topology-state@2017-12-13.yang" module ietf-network-topology-state { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology-state"; prefix nt-s; import ietf-network-state { prefix nw-s; reference - "draft-ietf-i2rs-yang-network-topo-18 + "draft-ietf-i2rs-yang-network-topo-19 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; } import ietf-network-topology { prefix nt; reference - "draft-ietf-i2rs-yang-network-topo-18 + "draft-ietf-i2rs-yang-network-topo-19 NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; } organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: Editor: Alexander Clemm @@ -1985,38 +1983,38 @@ Copyright (c) 2017 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). This version of this YANG module is part of - draft-ietf-i2rs-yang-network-topo-18; + draft-ietf-i2rs-yang-network-topo-19; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-18 with RFC + draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx)."; - revision 2017-11-15 { + revision 2017-12-13 { description "Initial revision. NOTE TO RFC EDITOR: (1) Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-18 with + to draft-ietf-i2rs-yang-network-topo-19 with RFC number when published (i.e. RFC xxxx). (2) Please replace the date in the revision statement with the date of publication when published."; reference - "draft-ietf-i2rs-yang-network-topo-18"; + "draft-ietf-i2rs-yang-network-topo-19"; } grouping link-ref { description "References a link in a specific network. While this grouping is not used in this module, it is defined here for the convenience of augmenting modules."; leaf link-ref { type leafref { path "/nw-s:networks/nw-s:network[nw-s:network-id=current()"+