--- 1/draft-ietf-i2rs-yang-network-topo-02.txt 2016-06-09 15:16:08.636681991 -0700 +++ 2/draft-ietf-i2rs-yang-network-topo-03.txt 2016-06-09 15:16:08.696683499 -0700 @@ -1,24 +1,26 @@ Network Working Group A. Clemm Internet-Draft J. Medved Intended status: Standards Track R. Varga -Expires: June 10, 2016 T. Tkacik +Expires: December 11, 2016 T. Tkacik Cisco N. Bahadur Bracket Computing H. Ananthakrishnan Packet Design - December 8, 2015 + X. Liu + Kuatro Technologies + June 9, 2016 A Data Model for Network Topologies - draft-ietf-i2rs-yang-network-topo-02.txt + draft-ietf-i2rs-yang-network-topo-03.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 @@ -28,25 +30,25 @@ 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 June 10, 2016. + This Internet-Draft will expire on December 11, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 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 @@ -78,31 +80,31 @@ 3.4.3. Dealing with changes in underlay networks . . . . . . 13 3.4.4. Use of groupings . . . . . . . . . . . . . . . . . . 13 3.4.5. Cardinality and directionality of links . . . . . . . 13 3.4.6. Multihoming and link aggregation . . . . . . . . . . 14 3.4.7. Mapping redundancy . . . . . . . . . . . . . . . . . 14 3.4.8. Typing . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.9. Representing the same device in multiple networks . . 14 3.5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.1. Supporting client as well as server provided network topology . . . . . . . . . . . . . . . . . . . . . . 16 - 3.5.2. Identifiers of string or URI type . . . . . . . . . . 16 + 3.5.2. Identifiers of string or URI type . . . . . . . . . . 17 4. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1. Defining the Abstract Network: network.yang . . . . . . . 17 - 4.2. Creating Abstract Network Topology: network-topology.yang 21 + 4.2. Creating Abstract Network Topology: network-topology.yang 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction This document introduces an abstract (base) YANG [RFC6020] [RFC6021] data model to represent networks and topologies. The data model is divided into two parts. The first part of the model defines a network model that allows to define network hierarchies (i.e. network stacks) and to maintain an inventory of nodes contained in a network. The second part of the model augments the basic network model with information to describe topology information. Specifically, it adds @@ -435,21 +437,21 @@ +--rw source | +--rw source-node -> ../../../nd:node/node-id | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+ | ../source-node]/termination-point/tp-id +--rw destination | +--rw dest-node -> ../../../nd:node/node-id | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+ | ../dest-node]/termination-point/tp-id +--rw link-id link-id +--rw supporting-link* [network-ref link-ref] - +--rw network-ref -> ../../../nd:supporting-network/ + +--rw network-ref -> ../../../nd:supporting-network/+ | network-ref +--rw link-ref -> /nd:networks/network[nd:network-id=+ current()/../network-ref]/link/link-id augment /nd:networks/nd:network/nd:node: +--rw termination-point* [tp-id] +--rw tp-id tp-id +--rw supporting-termination-point* [network-ref node-ref tp-ref] +--rw network-ref -> ../../../nd:supporting-node/network-ref +--rw node-ref -> ../../../nd:supporting-node/node-ref +--rw tp-ref -> /nd:networks/network[nd:network-id=+ @@ -701,39 +703,50 @@ captured in one coherent model. In most cases network topology information is discovered about a network; the topology is considered a property of the network that is reflected in the model. That said, it is conceivable that certain types of topology need to also be configurable by an application. There are several alternatives in which this can be addressed. The alternative chosen in this draft does not restrict network topology information as read-only, but includes a state that indicates for each network whether it is populated by the server or by a client - application. (The drawback of this solution is that it stretches its - use of the configuration concept. Configuration information is - subject to backup and restore, which is not applicable to server- - provided information. Perhaps more serious is the ability of a - client to lock a configuration and thus prevent changes to server- + application. The drawback of this solution is that it stretches its + use of the configuration concept. Configuration information in + general is subject to backup and restore, which is not applicable to + server-provided information. Perhaps more serious is the ability of + a client to lock a configuration and thus prevent changes to server- provided network topology while the lock is in effect. Preventing this requires special treatment of network topology related - configuration information.) + configuration information. In another alternative, all information about network topology that is in effect is represented as network state, i.e. as read-only information, regardless of how it came into being. For cases where network topology needs to be 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. (The drawback of this solution is slightly increased - complexity of augmentations due to two target branches. + sandbox. The drawback of this solution is increased complexity of + augmentations due to two target branches. + + A third alternative would make use of YANG metadata + [I-D.draft-ietf-netmod-yang-metadata]. Topology information + represents configuration data. In addition, a new metadata tag is + introduced to be able to tag data populated by the server as server- + provided. This could be a boolean, or even a type "empty". The + semantics of the tag is that it is 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. The metadata will be set automatically by the server as + applicable. 3.5.2. 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 @@ -745,92 +758,95 @@ 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@2015-12-08.yang" + file "ietf-network@2016-06-09.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 "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: WG Chair: Susan Hares - WG Chair: Jeffrey Haas - + WG Chair: Russ White + Editor: Alexander Clemm Editor: Jan Medved Editor: Robert Varga Editor: Tony Tkacik Editor: Nitin Bahadur Editor: Hariharan Ananthakrishnan - "; + + + Editor: Xufeng Liu + "; description "This module defines a common base model for a collection of nodes in a network. Node definitions are further used in network topologies and inventories. - Copyright (c) 2015 IETF Trust and the persons identified as + Copyright (c) 2016 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-02; + draft-ietf-i2rs-yang-network-topo-03; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-02 with RFC + draft-ietf-i2rs-yang-network-topo-03 with RFC number when published (i.e. RFC xxxx)."; - revision 2015-12-08 { + revision 2016-06-09 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference to draft-ietf-i2rs-yang-network-topo-02 with RFC number when published (i.e. RFC xxxx)."; reference - "draft-ietf-i2rs-yang-network-topo-02"; + "draft-ietf-i2rs-yang-network-topo-03"; } typedef node-id { type inet:uri; description "Identifier for a node."; } typedef network-id { type inet:uri; @@ -960,30 +974,31 @@ leaf server-provided { type boolean; description "Indicates whether the information concerning this particular network is populated by the server (server-provided true, the general case for network information discovered from the server), or whether it is configured by a client (server-provided true, possible e.g. for service overlays managed through a controller)."; + } } } } 4.2. Creating Abstract Network Topology: network-topology.yang - file "ietf-network-topology@2015-12-08.yang" + file "ietf-network-topology@2016-06-09.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; @@ -992,65 +1007,68 @@ organization "IETF I2RS (Interface to the Routing System) Working Group"; contact "WG Web: WG List: WG Chair: Susan Hares - WG Chair: Jeffrey Haas - + WG Chair: Russ White + Editor: Alexander Clemm Editor: Jan Medved Editor: Robert Varga Editor: Tony Tkacik Editor: Nitin Bahadur Editor: Hariharan Ananthakrishnan - "; + + + Editor: Xufeng Liu + "; description "This module defines a common base model for network topology, augmenting the base network model with links to connect nodes, as well as termination points to terminate links on nodes. - Copyright (c) 2015 IETF Trust and the persons identified as + Copyright (c) 2016 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-02; + draft-ietf-i2rs-yang-network-topo-03; see the RFC itself for full legal notices. NOTE TO RFC EDITOR: Please replace above reference to - draft-ietf-i2rs-yang-network-topo-02 with RFC + draft-ietf-i2rs-yang-network-topo-03 with RFC number when published (i.e. RFC xxxx)."; - revision 2015-12-08 { + revision 2016-06-09 { description "Initial revision. NOTE TO RFC EDITOR: Please replace the following reference to draft-ietf-i2rs-yang-network-topo-02 with RFC number when published (i.e. RFC xxxx)."; reference "draft-ietf-i2rs-yang-network-topo-02."; } typedef link-id { @@ -1329,27 +1349,31 @@ [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, May 2014. 8.2. Informative References [I-D.draft-ietf-netconf-yang-push] - Clemm, A., Voit, E., and A. Gonzalez Prieto, "Subscribing - to YANG datastore push updates", I-D draft-ietf-netconf- - yang-push-00, October 2015. + 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-02, March 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. [I.D.draft-ietf-netmod-rfc6020bis] Bjorklund, M., "The YANG 1.1 Data Modeling Language", I-D - draft-ietf-netmod-rfc6020bis-08, October 2015. + draft-ietf-netmod-rfc6020bis-12, April 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 @@ -1372,10 +1397,14 @@ Nitin Bahadur Bracket Computing EMail: nitin_bahadur@yahoo.com Hariharan Ananthakrishnan Packet Design EMail: hari@packetdesign.com + Xufeng Liu + Kuatro Technologies + + EMail: xliu@kuatrotech.com