draft-ietf-i2rs-yang-network-topo-05.txt   draft-ietf-i2rs-yang-network-topo-06.txt 
Network Working Group A. Clemm Network Working Group A. Clemm
Internet-Draft J. Medved Internet-Draft J. Medved
Intended status: Standards Track R. Varga Intended status: Standards Track R. Varga
Expires: January 30, 2017 Cisco Expires: March 23, 2017 Cisco
T. Tkacik T. Tkacik
N. Bahadur N. Bahadur
Bracket Computing Bracket Computing
H. Ananthakrishnan H. Ananthakrishnan
Packet Design Packet Design
X. Liu X. Liu
Ericsson Ericsson
July 29, 2016 September 19, 2016
A Data Model for Network Topologies A Data Model for Network Topologies
draft-ietf-i2rs-yang-network-topo-05.txt draft-ietf-i2rs-yang-network-topo-06.txt
Abstract Abstract
This document defines an abstract (generic) YANG data model for This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in base model which is augmented with technology-specific details in
other, more specific topology and inventory models. other, more specific topology and inventory models.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 13, line 11 skipping to change at page 13, line 11
contain a list of those supporting links. Likewise, it is possible 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 for a link at one level of a hierarchy to aggregate a bundle of links
at another level of the hierarchy. at another level of the hierarchy.
3.4.3. Dealing with changes in underlay networks 3.4.3. Dealing with changes in underlay networks
It is possible for a network to undergo churn even as other 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 are layered on top of it. When a supporting node, link, or
termination point is deleted, the supporting leafrefs in the overlay termination point is deleted, the supporting leafrefs in the overlay
will be left dangling. To allow for this possibility, the model will be left dangling. To allow for this possibility, the model
makes use of the "require-instance" construct of YANG 1.1 makes use of the "require-instance" construct of YANG 1.1 [RFC7950].
[I.D.draft-ietf-netmod-rfc6020bis].
It is the responsibility of the application maintaining the overlay It is the responsibility of the application maintaining the overlay
to deal with the possibility of churn in the underlay network. When to deal with the possibility of churn in the underlay network. When
a server receives a request to configure an overlay network, it a server receives a request to configure an overlay network, it
SHOULD validate whether supporting nodes/links/tps refer to nodes in SHOULD validate whether supporting nodes/links/tps refer to nodes in
the underlay are actually in existence. Configuration requests in the underlay are actually in existence. Configuration requests in
which supporting nodes/links/tps refer to objects currently not in which supporting nodes/links/tps refer to objects currently not in
existence SHOULD be rejected. It is the responsibility of the existence SHOULD be rejected. It is the responsibility of the
application to update the overlay when a supporting node/link/tp is application to update the overlay when a supporting node/link/tp is
deleted at a later point in time. For this purpose, an application deleted at a later point in time. For this purpose, an application
skipping to change at page 16, line 43 skipping to change at page 16, line 43
configured, a second branch for configurable topology information is configured, a second branch for configurable topology information is
introduced. Any network topology configuration is mirrored by introduced. Any network topology configuration is mirrored by
network state information. A configurable network will thus be network state information. A configurable network will thus be
represented twice: once in the read-only list of all networks, a represented twice: once in the read-only list of all networks, a
second time in a configuration sandbox. One implication of this second time in a configuration sandbox. One implication of this
solution would have been significantly increased complexity of solution would have been significantly increased complexity of
augmentations due to multiple target branches. augmentations due to multiple target branches.
Another alternative would make use of a YANG extension to tag Another alternative would make use of a YANG extension to tag
specific network instances as "server-provided" instead of defining a specific network instances as "server-provided" instead of defining a
leaf object, or rely on the concept of YANG metadata leaf object, or rely on the concept of YANG metadata [RFC7952] for
[I-D.draft-ietf-netmod-yang-metadata] for the same effect. The tag the same effect. The tag would be automatically applied to any
would be automatically applied to any topology data that comes into topology data that comes into being (respectively is configured) by
being (respectively is configured) by an embedded application on the an embedded application on the network, as opposed to e.g. a
network, as opposed to e.g. a controller application. controller application.
3.6. Identifiers of string or URI type 3.6. Identifiers of string or URI type
The current model defines identifiers of nodes, networks, links, and The current model defines identifiers of nodes, networks, links, and
termination points as URIs. An alternative would define them as termination points as URIs. An alternative would define them as
string. string.
The case for strings is that they will be easier to implement. The 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 reason for choosing URIs is that the topology/node/tp exists in a
larger context, hence it is useful to be able to correlate larger context, hence it is useful to be able to correlate
skipping to change at page 17, line 29 skipping to change at page 17, line 29
data. A URI makes the structure explicit and also attaches data. A URI makes the structure explicit and also attaches
additional semantics: the URI, unlike a free-form string, can be fed additional semantics: the URI, unlike a free-form string, can be fed
into a URI resolver, which can point to additional resources into a URI resolver, which can point to additional resources
associated with the URI. This property is important when the associated with the URI. This property is important when the
topology data is integrated into a larger, more complex system. topology data is integrated into a larger, more complex system.
4. YANG Modules 4. YANG Modules
4.1. Defining the Abstract Network: network.yang 4.1. Defining the Abstract Network: network.yang
<CODE BEGINS> file "ietf-network@2016-07-29.yang" <CODE BEGINS> file "ietf-network@2016-09-19.yang"
module ietf-network { module ietf-network {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network"; namespace "urn:ietf:params:xml:ns:yang:ietf-network";
prefix nd; prefix nd;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
organization organization
skipping to change at page 18, line 4 skipping to change at page 18, line 4
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Russ White WG Chair: Russ White
<mailto:russ@riw.us> <mailto:russ@riw.us>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@cisco.com> <mailto:ludwig@clemm.org>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:rovarga@cisco.com> <mailto:rovarga@cisco.com>
Editor: Tony Tkacik Editor: Tony Tkacik
<mailto:tony.tkacik@gmail.com> <mailto:tony.tkacik@gmail.com>
skipping to change at page 18, line 40 skipping to change at page 18, line 40
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of 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. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to 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)."; number when published (i.e. RFC xxxx).";
revision 2016-07-29 { revision 2016-09-19 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference 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)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-05"; "draft-ietf-i2rs-yang-network-topo-06";
} }
typedef node-id { typedef node-id {
type inet:uri; type inet:uri;
description description
"Identifier for a node. The precise structure of the node-id "Identifier for a node. The precise structure of the node-id
will be up to the implementation. Some implementations MAY will be up to the implementation. Some implementations MAY
for example, pick a uri that includes the network-id as for example, pick a uri that includes the network-id as
part of the path. The identifier SHOULD be chosen such that part of the path. The identifier SHOULD be chosen such that
the same node in a real network topology will always be the same node in a real network topology will always be
skipping to change at page 22, line 24 skipping to change at page 22, line 24
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
4.2. Creating Abstract Network Topology: network-topology.yang 4.2. Creating Abstract Network Topology: network-topology.yang
<CODE BEGINS> file "ietf-network-topology@2016-07-29.yang" <CODE BEGINS> file "ietf-network-topology@2016-09-19.yang"
module ietf-network-topology { module ietf-network-topology {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology"; namespace "urn:ietf:params:xml:ns:yang:ietf-network-topology";
prefix lnk; prefix lnk;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
} }
import ietf-network { import ietf-network {
prefix nd; prefix nd;
skipping to change at page 22, line 51 skipping to change at page 22, line 51
"WG Web: <http://tools.ietf.org/wg/i2rs/> "WG Web: <http://tools.ietf.org/wg/i2rs/>
WG List: <mailto:i2rs@ietf.org> WG List: <mailto:i2rs@ietf.org>
WG Chair: Susan Hares WG Chair: Susan Hares
<mailto:shares@ndzh.com> <mailto:shares@ndzh.com>
WG Chair: Russ White WG Chair: Russ White
<mailto:russ@riw.us> <mailto:russ@riw.us>
Editor: Alexander Clemm Editor: Alexander Clemm
<mailto:alex@cisco.com> <mailto:ludwig@clemm.org>
Editor: Jan Medved Editor: Jan Medved
<mailto:jmedved@cisco.com> <mailto:jmedved@cisco.com>
Editor: Robert Varga Editor: Robert Varga
<mailto:rovarga@cisco.com> <mailto:rovarga@cisco.com>
Editor: Tony Tkacik Editor: Tony Tkacik
<mailto:tony.tkacik@gmail.com> <mailto:tony.tkacik@gmail.com>
skipping to change at page 23, line 39 skipping to change at page 23, line 39
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of 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. see the RFC itself for full legal notices.
NOTE TO RFC EDITOR: Please replace above reference to 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)."; number when published (i.e. RFC xxxx).";
revision 2016-07-29 { revision 2016-09-19 {
description description
"Initial revision. "Initial revision.
NOTE TO RFC EDITOR: Please replace the following reference 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)."; RFC number when published (i.e. RFC xxxx).";
reference reference
"draft-ietf-i2rs-yang-network-topo-05"; "draft-ietf-i2rs-yang-network-topo-06";
} }
typedef link-id { typedef link-id {
type inet:uri; type inet:uri;
description description
"An identifier for a link in a topology. "An identifier for a link in a topology.
The precise structure of the link-id The precise structure of the link-id
will be up to the implementation. will be up to the implementation.
The identifier SHOULD be chosen such that the same link in a The identifier SHOULD be chosen such that the same link in a
real network topology will always be identified through the real network topology will always be identified through the
skipping to change at page 29, line 29 skipping to change at page 29, line 29
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Alia Atlas, Vishnu Pavan Beeram, suggestions that were received from Alia Atlas, Vishnu Pavan Beeram,
Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan Andy Bierman, Martin Bjorklund, Igor Bryskin, Benoit Claise, Susan
Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent Hares, Ladislav Lhotka, Carlos Pignataro, Juergen Schoenwaelder, Kent
Watsen, and Xian Zhang. Watsen, and Xian Zhang.
8. References 8. References
8.1. Normative 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 [RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Dual Environments", RFC 1195, December 1990. Dual Environments", RFC 1195, December 1990.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
skipping to change at page 30, line 12 skipping to change at page 30, line 8
Bierman, "Network Configuration Protocol (NETCONF)", Bierman, "Network Configuration Protocol (NETCONF)",
RFC 6241, June 2011. RFC 6241, June 2011.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014. 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 8.2. Informative References
[I-D.draft-ietf-netconf-yang-push] [I-D.draft-ietf-netconf-yang-push]
Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A., Clemm, A., Voit, E., Gonzalez Prieto, A., Tripathy, A.,
and E. Nilsen-Nygaard, "Subscribing to YANG datastore push and E. Nilsen-Nygaard, "Subscribing to YANG datastore push
updates", I-D draft-ietf-netconf-yang-push-03, June 2016. 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] [topology-use-cases]
Medved, J., Previdi, S., Lopez, V., and S. Amante, Medved, J., Previdi, S., Lopez, V., and S. Amante,
"Topology API Use Cases", I-D draft-amante-i2rs-topology- "Topology API Use Cases", I-D draft-amante-i2rs-topology-
use-cases-01, October 2013. use-cases-01, October 2013.
Authors' Addresses Authors' Addresses
Alexander Clemm Alexander Clemm
Cisco Cisco
EMail: alex@cisco.com EMail: ludwig@clemm.org
Jan Medved Jan Medved
Cisco Cisco
EMail: jmedved@cisco.com EMail: jmedved@cisco.com
Robert Varga Robert Varga
Cisco Cisco
EMail: rovarga@cisco.com EMail: rovarga@cisco.com
 End of changes. 24 change blocks. 
34 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/