--- 1/draft-ietf-i2rs-yang-network-topo-05.txt 2016-09-19 11:15:58.665388936 -0700 +++ 2/draft-ietf-i2rs-yang-network-topo-06.txt 2016-09-19 11:15:58.729390552 -0700 @@ -1,27 +1,27 @@ Network Working Group A. Clemm Internet-Draft J. Medved Intended status: Standards Track R. Varga -Expires: January 30, 2017 Cisco +Expires: March 23, 2017 Cisco T. Tkacik N. Bahadur Bracket Computing H. Ananthakrishnan Packet Design X. Liu Ericsson - July 29, 2016 + September 19, 2016 A Data Model for Network Topologies - draft-ietf-i2rs-yang-network-topo-05.txt + draft-ietf-i2rs-yang-network-topo-06.txt Abstract This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory 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 http://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 January 30, 2017. + This Internet-Draft will expire on March 23, 2017. Copyright Notice Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -555,22 +555,21 @@ contain a list of those supporting links. Likewise, it is possible for a link at one level of a hierarchy to aggregate a bundle of links at another level of the hierarchy. 3.4.3. Dealing with changes in underlay networks 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 model - makes use of the "require-instance" construct of YANG 1.1 - [I.D.draft-ietf-netmod-rfc6020bis]. + makes use of the "require-instance" construct of YANG 1.1 [RFC7950]. 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. 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 @@ -732,25 +731,25 @@ configured, a second branch for configurable topology information is introduced. Any network topology configuration is mirrored by network state information. A configurable network will thus be represented twice: once in the read-only list of all networks, a second time in a configuration sandbox. One implication of this solution would have been significantly increased complexity of augmentations due to multiple target branches. Another alternative would make use of a YANG extension to tag specific network instances as "server-provided" instead of defining a - leaf object, or rely on the concept of YANG metadata - [I-D.draft-ietf-netmod-yang-metadata] for the same effect. The tag - would be automatically applied to any topology data that comes into - being (respectively is configured) by an embedded application on the - network, as opposed to e.g. a controller application. + leaf object, or rely on the concept of YANG metadata [RFC7952] for + the same effect. The tag would be automatically applied to any + topology data that comes into being (respectively is configured) by + an embedded application on the network, as opposed to e.g. a + controller application. 3.6. Identifiers of string or URI type The current model defines identifiers of nodes, networks, links, and termination points as URIs. An alternative would define them as string. The case for strings is that they will be easier to implement. The reason for choosing URIs is that the topology/node/tp exists in a larger context, hence it is useful to be able to correlate @@ -762,21 +761,21 @@ data. A URI makes the structure explicit and also attaches additional semantics: the URI, unlike a free-form string, can be fed into a URI resolver, which can point to additional resources associated with the URI. This property is important when the topology data is integrated into a larger, more complex system. 4. YANG Modules 4.1. Defining the Abstract Network: network.yang - file "ietf-network@2016-07-29.yang" + file "ietf-network@2016-09-19.yang" module ietf-network { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network"; prefix nd; import ietf-inet-types { prefix inet; } organization @@ -786,21 +785,21 @@ "WG Web: WG List: WG Chair: Susan Hares WG Chair: Russ White Editor: Alexander Clemm - + Editor: Jan Medved Editor: Robert Varga Editor: Tony Tkacik @@ -822,35 +821,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-05; + draft-ietf-i2rs-yang-network-topo-06; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-05 with RFC + draft-ietf-i2rs-yang-network-topo-06 with RFC number when published (i.e. RFC xxxx)."; - revision 2016-07-29 { + revision 2016-09-19 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-05 with + to draft-ietf-i2rs-yang-network-topo-06 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-network-topo-05"; + "draft-ietf-i2rs-yang-network-topo-06"; } 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 @@ -999,21 +998,21 @@ } } } } } 4.2. Creating Abstract Network Topology: network-topology.yang - file "ietf-network-topology@2016-07-29.yang" + file "ietf-network-topology@2016-09-19.yang" module ietf-network-topology { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; prefix lnk; import ietf-inet-types { prefix inet; } import ietf-network { prefix nd; @@ -1026,21 +1025,21 @@ "WG Web: WG List: WG Chair: Susan Hares WG Chair: Russ White Editor: Alexander Clemm - + Editor: Jan Medved Editor: Robert Varga Editor: Tony Tkacik @@ -1062,35 +1061,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-05; + draft-ietf-i2rs-yang-network-topo-06; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-05 with RFC + draft-ietf-i2rs-yang-network-topo-06 with RFC number when published (i.e. RFC xxxx)."; - revision 2016-07-29 { + revision 2016-09-19 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference - to draft-ietf-i2rs-yang-network-topo-05 with + to draft-ietf-i2rs-yang-network-topo-06 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-network-topo-05"; + "draft-ietf-i2rs-yang-network-topo-06"; } 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 @@ -1340,24 +1339,20 @@ We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent Watsen, and Xian Zhang. 8. References 8.1. Normative References - [I.D.draft-ietf-netmod-rfc6020bis] - Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D - draft-ietf-netmod-rfc6020bis-14, June 2016. - [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. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the @@ -1371,42 +1366,44 @@ Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, May 2014. + [RFC7950] Bjorklund, M., "The YANG 1.1 Data Modeling Language", + RFC 7950, August 2016. + + [RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", + RFC 7952, August 2016. + 8.2. Informative References [I-D.draft-ietf-netconf-yang-push] Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., and E. Nilsen-Nygaard, "Subscribing to YANG datastore push updates", I-D draft-ietf-netconf-yang-push-03, June 2016. - [I-D.draft-ietf-netmod-yang-metadata] - Lhotka, L., "Defining and Using Metadata with YANG", I-D - draft-ietf-netmod-yang-metadata-07, March 2016. - [topology-use-cases] Medved, J., Previdi, S., Lopez, V., and S. Amante, "Topology API Use Cases", I-D draft-amante-i2rs-topology- use-cases-01, October 2013. Authors' Addresses Alexander Clemm Cisco - EMail: alex@cisco.com + EMail: ludwig@clemm.org Jan Medved Cisco EMail: jmedved@cisco.com Robert Varga Cisco EMail: rovarga@cisco.com