draft-ietf-i2rs-yang-l3-topology-06.txt		draft-ietf-i2rs-yang-l3-topology-07.txt
	Network Working Group A. Clemm		Network Working Group A. Clemm
	Internet-Draft Sympotech		Internet-Draft Huawei
	Intended status: Standards Track J. Medved		Intended status: Standards Track J. Medved
	Expires: June 3, 2017 Cisco		Expires: July 7, 2017 Cisco
	R. Varga		R. Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	X. Liu		X. Liu
	Ericsson		Ericsson
	I. Bryskin
	Huawei
	A. Guo
	Adva Optical
	H. Ananthakrishnan		H. Ananthakrishnan
	Packet Design		Packet Design
	N. Bahadur		N. Bahadur
	Bracket Computing		Bracket Computing
	V. Beeram		January 3, 2017
	Juniper Networks
	November 30, 2016
	A YANG Data Model for Layer 3 Topologies		A YANG Data Model for Layer 3 Topologies
	draft-ietf-i2rs-yang-l3-topology-06.txt		draft-ietf-i2rs-yang-l3-topology-07.txt
	Abstract		Abstract
	This document defines a YANG data model for layer 3 network		This document defines a YANG data model for layer 3 network
	topologies.		topologies.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 40 ¶
	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 June 3, 2017.		This Internet-Draft will expire on July 7, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 4		2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
	3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4		3. Model Structure . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5		4. Layer 3 Unicast Topology Model Overview . . . . . . . . . . . 5
	5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7		5. Layer 3 Unicast Topology YANG Module . . . . . . . . . . . . 7
	6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 14		6. Extending the Model . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 14		6.1. Example 1: OSPF Topology . . . . . . . . . . . . . . . . 15
	6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 14		6.1.1. Model Overview . . . . . . . . . . . . . . . . . . . 15
	6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 16		6.1.2. OSPF Topology YANG Module . . . . . . . . . . . . . . 17
	6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 21		6.2. Example 2: IS-IS Topology . . . . . . . . . . . . . . . . 22
	6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 21		6.2.1. Model Overview . . . . . . . . . . . . . . . . . . . 22
	6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23		6.2.2. IS-IS Topology YANG Module . . . . . . . . . . . . . 23
	7. Interactions with Other YANG Modules . . . . . . . . . . . . 28		7. Interactions with Other YANG Modules . . . . . . . . . . . . 28
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 29		9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12.1. Normative References . . . . . . . . . . . . . . . . . . 30		12.1. Normative References . . . . . . . . . . . . . . . . . . 30
	12.2. Informative References . . . . . . . . . . . . . . . . . 30		12.2. Informative References . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	This document introduces a YANG [RFC7950] [RFC6991] data model for		This document introduces a YANG [RFC7950] [RFC6991] data model for
	Layer 3 network topologies, specifically Layer 3 Unicast. The model		Layer 3 network topologies, specifically Layer 3 Unicast. The model
	allows an application to have a holistic view of the topology of a		allows an application to have a holistic view of the topology of a
	Layer 3 network, all contained in a single conceptual YANG datastore.		Layer 3 network, all contained in a single conceptual YANG datastore.
	The data model builds on top of, and augments, the data model for		The data model builds on top of, and augments, the data model for
	network topologies defined in		network topologies defined in
			[I-D.draft-ietf-i2rs-yang-network-topo].
	[I-D.draft-ietf-i2rs-yang-network-topo]. An earlier revision of that		This document also shows how the model can be further refined to
	Internet Draft contained not just the general model for network		cover different Layer 3 Unicast topology types. For this purpose,
	topologies, but also the model for layer 3 network topologies that is		example models are introduced that cover IS-IS [RFC1195] and OSPF
	being specified here. However, we decided to "split" the earlier		[RFC2328]. Those examples are intended purely for illustrative
	draft to separate the truly general aspects of a topology data model,		purposes; we expect that full-blown IS-IS and OSPF models will be
	which apply to any type of topology, from the application of this		more comprehensive and refined than the examples shown here.
	model to a particular domain, here: a Layer 3 network.
	The document also shows how the model can be further refined to cover
	different Layer 3 Unicast topology types. For this purpose, example
	models are introduced that cover IS-IS [RFC1195] and OSPF [RFC2328].
	Those examples are intended purely for illustrative purposes; we
	expect that full-blown IS-IS and OSPF models will be more
	comprehensive and refined than the examples shown here.
	There are multiple applications for a topology data model. A number		There are multiple applications for a topology data model. A number
	of use cases have been defined in section 6 of		of use cases have been defined in section 6 of
	[I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes		[I-D.draft-ietf-i2rs-usecase-reqs-summary]. For example, nodes
	within the network can use the data model to capture their		within the network can use the data model to capture their
	understanding of the overall network topology and expose it to a		understanding of the overall network topology and expose it to a
	network controller. A network controller can then use the		network controller. A network controller can then use the
	instantiated topology data to compare and reconcile its own view of		instantiated topology data to compare and reconcile its own view of
	the network topology with that of the network elements that it		the network topology with that of the network elements that it
	controls. Alternatively, nodes within the network could propagate		controls. Alternatively, nodes within the network could propagate
	this understanding to compare and reconcile this understanding either		this understanding to compare and reconcile this understanding either
	amongst themselves or with help of a controller. Beyond the network		amongst themselves or with help of a controller. Beyond the network
	element itself, a network controller might even use the data model to		element itself, a network controller might even use the data model to
	represent its view of the topology that it controls and expose it to		represent its view of the topology that it controls and expose it to
	applications north of itself.		applications north of itself.
	There are several reasons to choose YANG to define the data model.
	Data defined using YANG can be exposed by a server to client
	applications and controllers via Netconf [RFC6241]. The fact that
	YANG can potentially be used with different protocols and interfaces
	provides for a degree of "future-proofing" of model implementations.
	Also, YANG can serve as the basis for model-driven toolchains, such
	as used in the Open Daylight project [OpenDaylight].
	The data model for Layer 3 Unicast topologies defined in this		The data model for Layer 3 Unicast topologies defined in this
	document is specified in a YANG module "ietf-l3-unicast-topology".		document is specified in a YANG module "ietf-l3-unicast-topology".
	To do so, it augments general network topology model defined in		To do so, it augments general network topology model defined in
	[I-D.draft-ietf-i2rs-yang-network-topo] with information specific to		[I-D.draft-ietf-i2rs-yang-network-topo] with information specific to
	Layer 3 Unicast. This way, the general topology model is extended to		Layer 3 Unicast. This way, the general topology model is extended to
	be able to meet the needs of Layer 3 Unicast topologies.		be able to meet the needs of Layer 3 Unicast topologies.
	Information that is kept in the Traffic Engineering Database (TED) is		Information that is kept in the Traffic Engineering Database (TED)
	specified in a separate model and outside the scope of this		will be specified in a separate model
			[I-D.draft-ietf-teas-yang-te-topo] and outside the scope of this
	specification.		specification.
	2. Definitions and Acronyms		2. Definitions and Acronyms
	Datastore: A conceptual store of instantiated management information,		As this document defines a YANG data model, in this document many
	with individual data items represented by data nodes which are		terms are used that have been defined in conjunction with YANG
			[RFC7950] and Netconf [RFC6241]. Some terms, such as datastore and
			data tree, are repeated here for clarity and to put them in context.
			Datastore: A conceptual place to store and access information, such
			as instantiated YANG data.
			Data tree: An instantiated tree of data modeled with YANG, in which
			individual data items are represented by data nodes which are
	arranged in hierarchical manner.		arranged in hierarchical manner.
	Data subtree: An instantiated data node and the data nodes that are		Data subtree: An instantiated data node and the data nodes that are
	hierarchically contained within it.		hierarchically contained within it.
	HTTP: Hyper-Text Transfer Protocol		HTTP: Hyper-Text Transfer Protocol
	IGP: Interior Gateway Protocol		IGP: Interior Gateway Protocol
	IS-IS: Intermediate System to Intermediate System protocol		IS-IS: Intermediate System to Intermediate System protocol
	LSP: Label Switched Path		LSP: Label Switched Path
	NETCONF: Network Configuration Protocol		NETCONF: Network Configuration Protocol
	OSPF: Open Shortest Path First, a link state routing protocol		OSPF: Open Shortest Path First, a link state routing protocol
	URI: Uniform Resource Identifier		URI: Uniform Resource Identifier
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 32 ¶
	+--rw l3-link-attributes		+--rw l3-link-attributes
	+--rw name? string		+--rw name? string
	+--rw flag* link-flag-type		+--rw flag* link-flag-type
	+--rw metric? uint32		+--rw metric? uint32
	augment /nd:networks/nd:network/nd:node/lnk:termination-point:		augment /nd:networks/nd:network/nd:node/lnk:termination-point:
	+--rw l3-termination-point-attributes		+--rw l3-termination-point-attributes
	+--rw (termination-point-type)?		+--rw (termination-point-type)?
	+--:(ip)		+--:(ip)
	| +--rw ip-address* inet:ip-address		| +--rw ip-address* inet:ip-address
	+--:(unnumbered)		+--:(unnumbered)
	+--rw unnumbered-id? uint32		| +--rw unnumbered-id? uint32
			+--:(interface-name)
			+--ro interface-name? string
	The module augments the original ietf-network and ietf-network-		The module augments the original ietf-network and ietf-network-
	topology modules as follows:		topology modules as follows:
	o A new network topology type is introduced, l3-unicast-topology.		o A new network topology type is introduced, l3-unicast-topology.
	The corresponding container augments the network-types of the		The corresponding container augments the network-types of the
	ietf-network module.		ietf-network module.
	o Additional topology attributes are introduced, defined in a		o Additional topology attributes are introduced, defined in a
	grouping, which augments the "network" list of the network module.		grouping, which augments the "network" list of the network module.
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 13 ¶
	"node" list of the network module. New objects include again a		"node" list of the network module. New objects include again a
	set of flags, as well as a list of prefixes. Each prefix in turn		set of flags, as well as a list of prefixes. Each prefix in turn
	includes an ip prefix, a metric, and a prefix-specific set of		includes an ip prefix, a metric, and a prefix-specific set of
	flags.		flags.
	o Links (in the ietf-network-topology module) are augmented with a		o Links (in the ietf-network-topology module) are augmented with a
	set of parameters as well, allowing to associate a link with a		set of parameters as well, allowing to associate a link with a
	link name, another set of flags, and a link metric.		link name, another set of flags, and a link metric.
	o Termination points (in the ietf-network-topology module as well)		o Termination points (in the ietf-network-topology module as well)
	are augmented with a choice of IP address or identifier.		are augmented with a choice of IP address, identifier, or name.
	In addition, the module defines a set of notifications to alert		In addition, the module defines a set of notifications to alert
	clients of any events concerning links, nodes, prefixes, and		clients of any events concerning links, nodes, prefixes, and
	termination points. Each notification includes an indication of the		termination points. Each notification includes an indication of the
	type of event, the topology from which it originated, and the		type of event, the topology from which it originated, and the
	affected node, or link, or prefix, or termination point. In		affected node, or link, or prefix, or termination point. In
	addition, as a convenience to applications, additional data of the		addition, as a convenience to applications, additional data of the
	affected node, or link, or termination point (respectively) is		affected node, or link, or termination point (respectively) is
	included. While this makes notifications larger in volume than they		included. While this makes notifications larger in volume than they
	would need to be, it avoids the need for subsequent retrieval of		would need to be, it avoids the need for subsequent retrieval of
	context information, which also might have changed in the meantime.		context information, which also might have changed in the meantime.
	5. Layer 3 Unicast Topology YANG Module		5. Layer 3 Unicast Topology YANG Module
	<CODE BEGINS> file "ietf-l3-unicast-topology@2016-11-30.yang"		<CODE BEGINS> file "ietf-l3-unicast-topology@2017-01-03.yang"
	module ietf-l3-unicast-topology {		module ietf-l3-unicast-topology {
	yang-version 1.1;		yang-version 1.1;
	namespace		namespace
	"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";		"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology";
	prefix "l3t";		prefix "l3t";
	import ietf-network {		import ietf-network {
	prefix "nd";		prefix "nd";
	}		}
	import ietf-network-topology {		import ietf-network-topology {
	prefix "lnk";		prefix "lnk";
	skipping to change at page 7, line 51 ¶		skipping to change at page 8, line 4 ¶
	}		}
	organization		organization
	"IETF I2RS (Interface to the Routing System) Working Group";		"IETF I2RS (Interface to the Routing System) Working Group";
	contact		contact
	"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@sympotech.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:robert.varga@pantheon.sk>		<mailto:robert.varga@pantheon.sk>
	Editor: Xufeng Liu		Editor: Xufeng Liu
	<mailto:xliu@kuatrotech.com>		<mailto:xliu@kuatrotech.com>
	Editor: Igor Bryskin
	<mailto:Igor.Bryskin@huawei.com>
	Editor: Aihua Guo
	<mailto:aguo@advaoptical.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Hariharan Ananthakrishnan		Editor: Hariharan Ananthakrishnan
	<mailto:hari@packetdesign.com>		<mailto:hari@packetdesign.com>";
	Editor: Vishnu Pavan Beeram
	<mailto:vbeeram@juniper.net>";
	description		description
	"This module defines a model for Layer 3 Unicast		"This module defines a model for Layer 3 Unicast
	topologies.		topologies.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2017 IETF Trust and the persons identified as
	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-l3-topology-06;		draft-ietf-i2rs-yang-l3-topology-07;
	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-l3-topology-06 with RFC		draft-ietf-i2rs-yang-l3-topology-07 with RFC
	number when published (i.e. RFC xxxx).";		number when published (i.e. RFC xxxx).";
	revision "2016-11-30" {		revision "2017-01-03" {
	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-l3-topology-06 with		to draft-ietf-i2rs-yang-l3-topology-07 with
	RFC number when published (i.e. RFC xxxx).";		RFC number when published (i.e. RFC xxxx).";
	reference		reference
	"draft-ietf-i2rs-yang-l3-topology-06";		"draft-ietf-i2rs-yang-l3-topology-07";
	}		}
	identity flag-identity {		identity flag-identity {
	description "Base type for flags";		description "Base type for flags";
	}		}
	typedef l3-event-type {		typedef l3-event-type {
	type enumeration {		type enumeration {
	enum "add" {		enum "add" {
	description		description
	"An Layer 3 node or link or prefix or termination-point has		"An Layer 3 node or link or prefix or termination-point has
	been added";		been added";
	}		}
	enum "remove" {		enum "remove" {
	description		description
	"An Layer 3 node or link or prefix or termination-point has		"An Layer 3 node or link or prefix or termination-point has
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 38 ¶
	type identityref {		type identityref {
	base "flag-identity";		base "flag-identity";
	}		}
	description "Node flag attributes";		description "Node flag attributes";
	}		}
	typedef link-flag-type {		typedef link-flag-type {
	type identityref {		type identityref {
	base "flag-identity";		base "flag-identity";
	}		}
	description "Prefix flag attributes";		description "Link flag attributes";
	}		}
	typedef l3-flag-type {		typedef l3-flag-type {
	type identityref {		type identityref {
	base "flag-identity";		base "flag-identity";
	}		}
	description "L3 flag attributes";		description "L3 flag attributes";
	}		}
	grouping l3-prefix-attributes {		grouping l3-prefix-attributes {
	description		description
	"L3 prefix attributes";		"L3 prefix attributes";
	leaf prefix {		leaf prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	description		description
	"IP prefix value";		"IP prefix value";
	}		}
	leaf metric {		leaf metric {
	type uint32;		type uint32;
	skipping to change at page 12, line 25 ¶		skipping to change at page 12, line 22 ¶
	"IPv4 or IPv6 address";		"IPv4 or IPv6 address";
	}		}
	}		}
	case unnumbered {		case unnumbered {
	leaf unnumbered-id {		leaf unnumbered-id {
	type uint32;		type uint32;
	description		description
	"Unnumbered interface identifier";		"Unnumbered interface identifier";
	}		}
	}		}
			case interface-name {
			leaf interface-name {
			type string;
			description
			"A name of the interface. The name can (but does not
			have to) correspond to an interface reference of a
			containing node's interface, i.e. the path name of a
			corresponding interface data node on the containing
			node reminiscent of data type if-ref defined in
			RFC 7223. It should be noted that data type if-ref of
			RFC 7223 cannot be used directly, as this data type
			is used to reference an interface in a datastore of
			a single node in the network, not to uniquely
			reference interfaces across a network.";
			}
			}
	}		}
	}		}
	}		}
	augment "/nd:networks/nd:network/nd:network-types" {		augment "/nd:networks/nd:network/nd:network-types" {
	description		description
	"Introduce new network type for L3 unicast topology";		"Introduce new network type for L3 unicast topology";
	uses l3-unicast-topology-type;		uses l3-unicast-topology-type;
	}		}
	augment "/nd:networks/nd:network" {		augment "/nd:networks/nd:network" {
	when "nd:network-types/l3-unicast-topology" {		when "nd:network-types/l3-unicast-topology" {
	skipping to change at page 16, line 41 ¶		skipping to change at page 17, line 37 ¶
	OSPF routers or interfaces.		OSPF routers or interfaces.
	6.1.2. OSPF Topology YANG Module		6.1.2. OSPF Topology YANG Module
	The OSPF Topology YANG Module is specified below. As mentioned, the		The OSPF Topology YANG Module is specified below. As mentioned, the
	module is intended as an example for how the Layer 3 Unicast topology		module is intended as an example for how the Layer 3 Unicast topology
	model can be extended to cover OSFP topologies, but it is not		model can be extended to cover OSFP topologies, but it is not
	normative. Accordingly, the module is not delimited with <CODE		normative. Accordingly, the module is not delimited with <CODE
	BEGINS> and <CODE ENDS> tags.		BEGINS> and <CODE ENDS> tags.
	file "example-ietf-ospf-topology@2016-11-30.yang"		file "example-ietf-ospf-topology@2017-01-03.yang"
	module example-ietf-ospf-topology {		module example-ietf-ospf-topology {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";		namespace "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
	prefix "ospft";		prefix "ospft";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	import ietf-network {		import ietf-network {
	prefix "nd";		prefix "nd";
	}		}
	skipping to change at page 17, line 19 ¶		skipping to change at page 18, line 16 ¶
	organization		organization
	"IETF I2RS (Interface to the Routing System) Working Group";		"IETF I2RS (Interface to the Routing System) Working Group";
	contact		contact
	"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@sympotech.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:robert.varga@pantheon.sk>		<mailto:robert.varga@pantheon.sk>
	Editor: Xufeng Liu		Editor: Xufeng Liu
	<mailto:xliu@kuatrotech.com>		<mailto:xliu@kuatrotech.com>
	Editor: Igor Bryskin
	<mailto:Igor.Bryskin@huawei.com>
	Editor: Aihua Guo
	<mailto:aguo@advaoptical.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Hariharan Ananthakrishnan		Editor: Hariharan Ananthakrishnan
	<mailto:hari@packetdesign.com>		<mailto:hari@packetdesign.com>";
	Editor: Vishnu Pavan Beeram
	<mailto:vbeeram@juniper.net>";
	description		description
	"This module defines a model for OSPF network topologies.		"This module defines a model for OSPF network topologies.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2017 IETF Trust and the persons identified as
	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-l3-topology-06;		draft-ietf-i2rs-yang-l3-topology-07;
	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-l3-topology-06 with RFC		draft-ietf-i2rs-yang-l3-topology-07 with RFC
	number when published (i.e. RFC xxxx).";		number when published (i.e. RFC xxxx).";
			revision "2017-01-03" {
	revision "2016-11-30" {
	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-l3-topology-06 with		to draft-ietf-i2rs-yang-l3-topology-07 with
	RFC number when published (i.e. RFC xxxx).";		RFC number when published (i.e. RFC xxxx).";
	reference		reference
	"draft-ietf-i2rs-yang-l3-topology-06";		"draft-ietf-i2rs-yang-l3-topology-07";
	}		}
	typedef area-id-type {		typedef area-id-type {
	type yang:dotted-quad;		type yang:dotted-quad;
	description		description
	"Area ID type.";		"Area ID type.";
	}		}
	grouping ospf-topology-type {		grouping ospf-topology-type {
	description		description
	"Identifies the OSPF topology type.";		"Identifies the OSPF topology type.";
	container ospf {		container ospf {
	skipping to change at page 23, line 23 ¶		skipping to change at page 23, line 38 ¶
	configure IS-IS routers or interfaces.		configure IS-IS routers or interfaces.
	6.2.2. IS-IS Topology YANG Module		6.2.2. IS-IS Topology YANG Module
	The IS-IS Topology YANG Module is specified as follows. As		The IS-IS Topology YANG Module is specified as follows. As
	mentioned, the module is intended as an example for how the Layer 3		mentioned, the module is intended as an example for how the Layer 3
	Unicast topology model can be extended to cover IS-IS topologies, but		Unicast topology model can be extended to cover IS-IS topologies, but
	it is not normative. Accordingly, the module is not delimited with		it is not normative. Accordingly, the module is not delimited with
	<CODE BEGINS> and <CODE ENDS> tags.		<CODE BEGINS> and <CODE ENDS> tags.
	file "example-ietf-isis-topology@2016-11-30.yang"		file "example-ietf-isis-topology@2017-01-03.yang"
	module example-ietf-isis-topology {		module example-ietf-isis-topology {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:example-ietf-isis-topology";		namespace "urn:ietf:params:xml:ns:yang:example-ietf-isis-topology";
	prefix "isist";		prefix "isist";
	import ietf-network {		import ietf-network {
	prefix "nd";		prefix "nd";
	}		}
	import ietf-network-topology {		import ietf-network-topology {
	prefix "lnk";		prefix "lnk";
	}		}
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 20 ¶
	WG Chair: Russ White		WG Chair: Russ White
	<mailto:russ@riw.us>		<mailto:russ@riw.us>
	Editor: Alexander Clemm		Editor: Alexander Clemm
	<mailto:sympotech.com>		<mailto:sympotech.com>
	Editor: Jan Medved		Editor: Jan Medved
	<mailto:jmedved@cisco.com>		<mailto:jmedved@cisco.com>
	Editor: Robert Varga		Editor: Robert Varga
	<mailto:robert.varga@pantheon.sk>		<mailto:robert.varga@pantheon.sk>
	Editor: Xufeng Liu		Editor: Xufeng Liu
	<mailto:xliu@kuatrotech.com>		<mailto:xliu@kuatrotech.com>
	Editor: Igor Bryskin
	<mailto:Igor.Bryskin@huawei.com>
	Editor: Aihua Guo
	<mailto:aguo@advaoptical.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>		<mailto:nitin_bahadur@yahoo.com>
	Editor: Hariharan Ananthakrishnan		Editor: Hariharan Ananthakrishnan
	<mailto:hari@packetdesign.com>		<mailto:hari@packetdesign.com>";
	Editor: Vishnu Pavan Beeram
	<mailto:vbeeram@juniper.net>";
	description		description
	"This module defines a model for IS-IS network topologies.		"This module defines a model for IS-IS network topologies.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2017 IETF Trust and the persons identified as
	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-l3-topology-06;		draft-ietf-i2rs-yang-l3-topology-07;
	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-l3-topology-06 with RFC		draft-ietf-i2rs-yang-l3-topology-07 with RFC
	number when published (i.e. RFC xxxx).";		number when published (i.e. RFC xxxx).";
	revision "2016-11-30" {		revision "2017-01-03" {
	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-l3-topology-06 with		to draft-ietf-i2rs-yang-l3-topology-07 with
	RFC number when published (i.e. RFC xxxx).";		RFC number when published (i.e. RFC xxxx).";
	reference		reference
	draft-ietf-i2rs-yang-l3-topology-06;		draft-ietf-i2rs-yang-l3-topology-07;
	}		}
	typedef iso-pseudonode-id {		typedef iso-pseudonode-id {
	type string {		type string {
	pattern '[0-9a-fA-F]{2}';		pattern '[0-9a-fA-F]{2}';
	}		}
	description		description
	"ISO pseudonode id for broadcast network.";		"ISO pseudonode id for broadcast network.";
	}		}
	typedef area-address{		typedef area-address{
	type string {		type string {
	pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}';		pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}';
	}		}
	description		description
	"This type defines the area address.";		"This type defines the area address.";
	skipping to change at page 28, line 49 ¶		skipping to change at page 29, line 11 ¶
	URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology		URI: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	This document registers the following YANG module in the "YANG Module		This document registers the following YANG module in the "YANG Module
	Names" registry [RFC6020]:		Names" registry [RFC6020]:
	Name: ietf-l3-unicast-topology		Name: ietf-l3-unicast-topology
	Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology		Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology
	Prefix: l3t		Prefix: l3t
	Reference: draft-ietf-i2rs-yang-l3-topology-06.txt (RFC form)		Reference: draft-ietf-i2rs-yang-l3-topology-07.txt (RFC form)
	9. Security Considerations		9. Security Considerations
	The YANG module defined in this memo is designed to be accessed via		The YANG module defined in this memo is designed to be accessed via
	the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the		the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the
	secure transport layer, and the mandatory-to-implement secure		secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The NETCONF access		transport is Secure Shell (SSH) [RFC6242]. The NETCONF access
	control model [RFC6536] provides the means to restrict access for		control model [RFC6536] provides the means to restrict access for
	particular NETCONF users to a pre-configured subset of all available		particular NETCONF users to a pre-configured subset of all available
	NETCONF protocol operations and content.		NETCONF protocol operations and content.
	skipping to change at page 29, line 34 ¶		skipping to change at page 29, line 42 ¶
	network utilization. It is therefore important that the NETCONF		network utilization. It is therefore important that the NETCONF
	access control model is vigorously applied to prevent topology		access control model is vigorously applied to prevent topology
	configuration by unauthorized clients.		configuration by unauthorized clients.
	10. Contributors		10. Contributors
	The model presented in this paper was contributed to by more people		The model presented in this paper was contributed to by more people
	than can be listed on the author list. Additional contributors		than can be listed on the author list. Additional contributors
	include:		include:
	o Ken Gray, Juniper Networks		o Vishnu Pavan Beeram, Juniper
			o Igor Bryskin, Huawei
			o Ken Gray, Cisco
			o Aihua Guo, Adva Optical
	o Tom Nadeau, Brocade		o Tom Nadeau, Brocade
	o Tony Tkacik		o Tony Tkacik
	o Aleksandr Zhdankin, Cisco		o Aleksandr Zhdankin, Cisco
	11. Acknowledgements		11. Acknowledgements
	We wish to acknowledge the helpful contributions, comments, and		We wish to acknowledge the helpful contributions, comments, and
	suggestions that were received from Ladislav Lhotka, Andy Bierman,		suggestions that were received from Ladislav Lhotka, Andy Bierman,
	Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas,		Carlos Pignataro, Joel Halpern, Juergen Schoenwaelder, Alia Atlas,
	Susan Hares, Benoit Claise, and Carl Moberg.		Susan Hares, Benoit Claise, and Carl Moberg.
	12. References		12. References
	skipping to change at page 30, line 13 ¶		skipping to change at page 30, line 21 ¶
	Susan Hares, Benoit Claise, and Carl Moberg.		Susan Hares, Benoit Claise, and Carl Moberg.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.draft-ietf-i2rs-yang-network-topo]		[I-D.draft-ietf-i2rs-yang-network-topo]
	Clemm, A., Medved, J., Varga, R., Bahadur, N.,		Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for		Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", I-D draft-ietf-i2rs-yang-network-		Network Topologies", I-D draft-ietf-i2rs-yang-network-
	topo-09, November 2016.		topo-10, January 2017.
	[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.
	[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January		[RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January
	2004.		2004.
	[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 31, line 7 ¶		skipping to change at page 31, line 14 ¶
	12.2. Informative References		12.2. Informative References
	[I-D.draft-acee-rtgwg-yang-rib-extend]		[I-D.draft-acee-rtgwg-yang-rib-extend]
	Lindem, A. and Y. Qu, "YANG Data Model for RIB		Lindem, A. and Y. Qu, "YANG Data Model for RIB
	Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02,		Extensions", I-D draft-acee-rtgwg-yang-rib-extend-02,
	October 2016.		October 2016.
	[I-D.draft-ietf-i2rs-ephemeral-state]		[I-D.draft-ietf-i2rs-ephemeral-state]
	Haas, J. and S. Hares, "I2RS Ephemeral State		Haas, J. and S. Hares, "I2RS Ephemeral State
	Requirements", I-D draft-ietf-i2rs-ephemeral-state-22,		Requirements", I-D draft-ietf-i2rs-ephemeral-state-23,
	November 2016.		November 2016.
	[I-D.draft-ietf-i2rs-usecase-reqs-summary]		[I-D.draft-ietf-i2rs-usecase-reqs-summary]
	Hares, S. and M. Chen, "Summary of I2RS Use Case		Hares, S. and M. Chen, "Summary of I2RS Use Case
	Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-		Requirements", I-D draft-ietf-i2rs-usecase-reqs-summary-
	03, November 2016.		03, November 2016.
	[OpenDaylight]		[I-D.draft-ietf-teas-yang-te-topo]
	Medved, J., Varga, R., Tkacik, T., and K. Gray,		Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
	"OpenDaylight: Towards a Model-Driven SDN Controller		O. Gonzelz De Dios, "YANG Data Model for TE Topologies",
	architecture", IEEE 15th Int. Symposium on World of		I-D draft-ietf-teas-yang-te-topo-06, October 2016.
	Wireless, Mobile and Multimedia Networks (IEEE WoWMoM
	2014), June 2014.		[RFC7223] Bjorklund, M., "A YANG Data Model for Routing Management",
			RFC 7223, May 2014.
	[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing		[RFC8022] Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
	Management", RFC 8022, November 2016.		Management", RFC 8022, November 2016.
	Authors' Addresses		Authors' Addresses
	Alexander Clemm		Alexander Clemm
	Sympotech		Huawei
	EMail: alex@sympotech.com		EMail: ludwig@clemm.org
	Jan Medved		Jan Medved
	Cisco		Cisco
	EMail: jmedved@cisco.com		EMail: jmedved@cisco.com
	Robert Varga		Robert Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	EMail: robert.varga@pantheon.sk		EMail: robert.varga@pantheon.sk
	skipping to change at page 31, line 41 ¶		skipping to change at page 32, line 4 ¶
	Jan Medved		Jan Medved
	Cisco		Cisco
	EMail: jmedved@cisco.com		EMail: jmedved@cisco.com
	Robert Varga		Robert Varga
	Pantheon Technologies SRO		Pantheon Technologies SRO
	EMail: robert.varga@pantheon.sk		EMail: robert.varga@pantheon.sk
	Xufeng Liu		Xufeng Liu
	Ericsson		Ericsson
	EMail: xliu@kuatrotech.com		EMail: xliu@kuatrotech.com
	Igor Bryskin
	Huawei
	EMail: Igor.Bryskin@huawei.com
	Aihua Guo
	Adva Optical
	EMail: aguo@advaoptical.com
	Hariharan Ananthakrishnan		Hariharan Ananthakrishnan
	Packet Design		Packet Design
	EMail: hari@packetdesign.com		EMail: hari@packetdesign.com
	Nitin Bahadur		Nitin Bahadur
	Bracket Computing		Bracket Computing
	EMail: nitin_bahadur@yahoo.com		EMail: nitin_bahadur@yahoo.com
	Vishnu Pavan Beeram
	Juniper Networks
	EMail: vbeeram@juniper.net
End of changes. 66 change blocks.
	119 lines changed or deleted		104 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/