draft-ietf-i2rs-rib-data-model-08.txt		draft-ietf-i2rs-rib-data-model-09.txt
	Network Working Group L. Wang		Network Working Group L. Wang
	Internet-Draft Individual		Internet-Draft Individual
	Intended status: Standards Track H. Ananthakrishnan		Intended status: Standards Track H. Ananthakrishnan
	Expires: January 4, 2018 Packet Design		Expires: June 9, 2018 Packet Design
	M. Chen		M. Chen
	Huawei		Huawei
	A. Dass		A. Dass
	S. Kini
	Ericsson		Ericsson
			S. Kini
			Individual
	N. Bahadur		N. Bahadur
	Bracket Computing		Bracket Computing
	July 3, 2017		December 6, 2017
	A YANG Data Model for Routing Information Base (RIB)		A YANG Data Model for Routing Information Base (RIB)
	draft-ietf-i2rs-rib-data-model-08		draft-ietf-i2rs-rib-data-model-09
	Abstract		Abstract
	This document defines a YANG data model for Routing Information Base		This document defines a YANG data model for Routing Information Base
	(RIB) that aligns with the I2RS RIB information model.		(RIB) that aligns with the I2RS RIB information model.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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.
	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 https://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 4, 2018.		This Internet-Draft will expire on June 9, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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		(https://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
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 36 ¶
	2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7		2.1. RIB Capability . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8		2.2. Routing Instance and Rib . . . . . . . . . . . . . . . . 8
	2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10		2.4. Nexthop . . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14		2.5. RPC Operations . . . . . . . . . . . . . . . . . . . . . 14
	2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18		2.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 18
	3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20		3. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 20
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 64		5. Security Considerations . . . . . . . . . . . . . . . . . . . 64
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 65		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
	8.1. Normative References . . . . . . . . . . . . . . . . . . 65		8.1. Normative References . . . . . . . . . . . . . . . . . . 66
	8.2. Informative References . . . . . . . . . . . . . . . . . 65		8.2. Informative References . . . . . . . . . . . . . . . . . 67
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
	1. Introduction		1. Introduction
	The Interface to the Routing System (I2RS)		The Interface to the Routing System (I2RS) [RFC7921] provides read
	[I-D.ietf-i2rs-architecture] provides read and write access to the		and write access to the information and state within the routing
	information and state within the routing process that exists inside		process that exists inside the routing elements, this is achieved via
	the routing elements, this is achieved via protocol message exchange		protocol message exchange between I2RS clients and I2RS agents
	between I2RS clients and I2RS agents associated with the routing		associated with the routing system. One of the functions of I2RS is
	system. One of the functions of I2RS is to read and write data of		to read and write data of Routing Information Base (RIB).
	Routing Information Base (RIB). [I-D.ietf-i2rs-usecase-reqs-summary]		[I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use
	introduces a set of RIB use cases. The RIB information model is		cases. The RIB information model is defined in
	defined in [I-D.ietf-i2rs-rib-info-model].		[I-D.ietf-i2rs-rib-info-model].
	This document defines a YANG [RFC6020][RFC6991] data model for the		This document defines a YANG [RFC6020][RFC6991] data model for the
	RIB that satisfies the RIB use cases and aligns with the RIB		RIB that satisfies the RIB use cases and aligns with the RIB
	information model.		information model.
	1.1. Definitions and Acronyms		1.1. Definitions and Acronyms
	RIB: Routing Information Base		RIB: Routing Information Base
	Information Model (IM): An abstract model of a conceptual domain,		Information Model (IM): An abstract model of a conceptual domain,
	skipping to change at page 3, line 50 ¶		skipping to change at page 3, line 50 ¶
	The following figure shows an overview of structure tree of the ietf-		The following figure shows an overview of structure tree of the ietf-
	i2rs-rib module. To give a whole view of the structure tree, some		i2rs-rib module. To give a whole view of the structure tree, some
	details of the tree are omitted. The relevant details are introduced		details of the tree are omitted. The relevant details are introduced
	in the subsequent sub-sections.		in the subsequent sub-sections.
	module: ietf-i2rs-rib		module: ietf-i2rs-rib
	+--rw routing-instance		+--rw routing-instance
	+--rw name string		+--rw name string
	+--rw interface-list* [name]		+--rw interface-list* [name]
	| +--rw name if:interface-ref		| +--rw name if:interface-ref
	+--rw router-id? yang:dotted-quad		+--rw router-id? yang:dotted-quad
	+--rw lookup-limit? uint8		+--rw lookup-limit? uint8
	+--rw rib-list* [name]		+--rw rib-list* [name]
	+--rw name string		+--rw name string
	+--rw address-family rib-family-def		+--rw address-family rib-family-def
	+--rw ip-rpf-check? boolean		+--rw ip-rpf-check? boolean
	+--rw route-list* [route-index]		+--rw route-list* [route-index]
	| +--rw route-index uint64		| +--rw route-index uint64
	| +--rw match		| +--rw match
	| | +--rw (route-type)?		| | +--rw (route-type)?
	| | +--:(ipv4)		| | +--:(ipv4)
	| | | ...		| | | ...
	| | +--:(ipv6)		| | +--:(ipv6)
	| | | ...		| | | ...
	| | +--:(mpls-route)		| | +--:(mpls-route)
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	| | +--:(nexthop-protection) {nexthop-protection}?		| | +--:(nexthop-protection) {nexthop-protection}?
	| | | ...		| | | ...
	| | +--:(nexthop-load-balance) {nexthop-load-balance}?		| | +--:(nexthop-load-balance) {nexthop-load-balance}?
	| | ...		| | ...
	| +--rw route-status		| +--rw route-status
	| | ...		| | ...
	| +--rw route-attributes		| +--rw route-attributes
	| | ...		| | ...
	| +--rw route-vendor-attributes		| +--rw route-vendor-attributes
	+--rw nexthop-list* [nexthop-member-id]		+--rw nexthop-list* [nexthop-member-id]
	+--rw nexthop-member-id uint32		+--rw nexthop-member-id uint32
	rpcs:		rpcs:
	+---x rib-add		+---x rib-add
	| +---w input		| +---w input
	| | +---w name string		| | +---w name string
	| | +---w address-family rib-family-def		| | +---w address-family rib-family-def
	| | +---w ip-rpf-check? boolean		| | +---w ip-rpf-check? boolean
	| +--ro output		| +--ro output
	| +--ro result uint32		| +--ro result uint32
	| +--ro reason? string		| +--ro reason? string
	+---x rib-delete		+---x rib-delete
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	| +--:(interface-route)		| +--:(interface-route)
	| ...		| ...
	+--ro route-installed-state route-installed-state-def		+--ro route-installed-state route-installed-state-def
	+--ro route-state route-state-def		+--ro route-state route-state-def
	+--ro route-change-reason route-change-reason-def		+--ro route-change-reason route-change-reason-def
	Figure 7: Notifications Structure		Figure 7: Notifications Structure
	3. YANG Modules		3. YANG Modules
	<CODE BEGINS> file "ietf-i2rs-rib@2016-07-04.yang"		<CODE BEGINS> file "ietf-i2rs-rib@2017-12-05.yang"
	module ietf-i2rs-rib {		module ietf-i2rs-rib {
	namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib";		namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-rib";
	// replace with iana namespace when assigned		// replace with iana namespace when assigned
	prefix "iir";		prefix "iir";
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	//rfc6991		//rfc6991
	}		}
	skipping to change at page 21, line 11 ¶		skipping to change at page 21, line 11 ¶
	Editor: Sriganesh Kini		Editor: Sriganesh Kini
	<mailto:sriganesh.kini@ericsson.com>		<mailto:sriganesh.kini@ericsson.com>
	Editor: Nitin Bahadur		Editor: Nitin Bahadur
	<mailto:nitin_bahadur@yahoo.com>";		<mailto:nitin_bahadur@yahoo.com>";
	description		description
	"This module defines a YANG data model for		"This module defines a YANG data model for
	Routing Information Base (RIB) that aligns		Routing Information Base (RIB) that aligns
	with the I2RS RIB information model.";		with the I2RS RIB information model.";
	revision "2016-07-04" {		revision "2017-12-05" {
	description "initial revision";		description "initial revision";
	reference "draft-ietf-i2rs-data-model-06";		reference "draft-ietf-i2rs-data-model-09";
	}		}
	//Features		//Features
	feature nexthop-tunnel {		feature nexthop-tunnel {
	description		description
	"This feature means that a node supports		"This feature means that a node supports
	tunnel nexthop capability.";		tunnel nexthop capability.";
	}		}
	feature nexthop-chain {		feature nexthop-chain {
	skipping to change at page 64, line 40 ¶		skipping to change at page 64, line 40 ¶
	--------------------------------------------------------------------		--------------------------------------------------------------------
	name: ietf-i2rs-rib		name: ietf-i2rs-rib
	namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib		namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib
	prefix: iir		prefix: iir
	reference: RFC XXXX		reference: RFC XXXX
	--------------------------------------------------------------------		--------------------------------------------------------------------
	5. Security Considerations		5. Security Considerations
	I2RS protocol provides read and write access to the information and		The YANG module defined in this document is designed to be accessed
	state (e.g., RIB) within the routing process that exists inside the		via network management protocols such as NETCONF [RFC6241] or
	routing elements. These information and state are normally		RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport
	considered sensitive or vulnerable. Improper write operations to		layer, and the mandatory-to-implement secure transport is Secure
	these information and state can have negative effects on the network.		Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the
			mandatory-to-implement secure transport is TLS [RFC5246].
	The I2RS protocol will provide security mechanisms as required in		The NETCONF access control model [RFC6536] provides the means to
	[I-D.ietf-i2rs-security-environment-reqs] and		restrict access for particular NETCONF or RESTCONF users to a
	[I-D.ietf-i2rs-protocol-security-requirements].		preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content.
	The YANG data model defined in this document itself does not		The YANG modules define information that can be configurable in
	introduce extra security issues.		certain instances, for example, a rib, a route, a nexthop can be
			created or deleted by client applications, the YANG modules also
			define RPCs that can be used by client applications to add/delete
			ribs, routes and nexthops. In such cases, a malicious client could
			attempt to remove, add or update a rib, a route, a nexthop, by
			creating or deleting corresponding elements in the rib, route and
			nexthop lists, respectively. Removing a rib or a route could lead to
			disruption or impact in performance of a service, updating a route
			may lead to suboptimal path and 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 misconfiguration by unauthorized clients.
			Specifically, there are a number of data nodes defined in the 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-i2rs-rib
			module:
			o rib: A malicious client could attempt to remove a rib from a
			routing instance, for example in order to sabotage the services
			provided by the rib, or to add a rib to a routing instance, hence
			to inject unauthorized traffic into the nexthop.
			o route:A malicious client could attempt to remove or add a route
			from/to a rib, for example in order to sabotage the services
			provided by the rib.
			o nexthop: A malicious client could attempt to remove or add a
			nexthop from/to rib, which may lead to suboptimal path and
			degradation of service levels as well as possibly disruption of
			service.
	6. Contributors		6. Contributors
	The following individuals also contribute to this document.		The following individuals also contribute to this document.
	o Zekun He, Tencent Holdings Ltd		o Zekun He, Tencent Holdings Ltd
	o Sujian Lu, Tencent Holdings Ltd		o Sujian Lu, Tencent Holdings Ltd
	o Jeffery Zhang, Juniper Networks		o Jeffery Zhang, Juniper Networks
	skipping to change at page 65, line 27 ¶		skipping to change at page 66, line 17 ¶
	The authors would like to thank Chris Bowers and John Scudder for his		The authors would like to thank Chris Bowers and John Scudder for his
	review, suggestion and comments to this document.		review, suggestion and comments to this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246,
			DOI 10.17487/RFC5246, August 2008,
			<https://www.rfc-editor.org/info/rfc5246>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<http://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
			[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
			[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
			Protocol (NETCONF) Access Control Model", RFC 6536,
			DOI 10.17487/RFC6536, March 2012,
			<https://www.rfc-editor.org/info/rfc6536>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<http://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	8.2. Informative References
	[I-D.ietf-i2rs-architecture]		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Atlas, A., Halpern, J., Hares, S., Ward, D., and T.		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	Nadeau, "An Architecture for the Interface to the Routing		<https://www.rfc-editor.org/info/rfc8040>.
	System", draft-ietf-i2rs-architecture-15 (work in
	progress), April 2016.
	[I-D.ietf-i2rs-protocol-security-requirements]		8.2. Informative References
	Hares, S., Migault, D., and J. Halpern, "I2RS Security
	Related Requirements", draft-ietf-i2rs-protocol-security-
	requirements-17 (work in progress), September 2016.
	[I-D.ietf-i2rs-rib-info-model]		[I-D.ietf-i2rs-rib-info-model]
	Bahadur, N., Kini, S., and J. Medved, "Routing Information		Bahadur, N., Kini, S., and J. Medved, "Routing Information
	Base Info Model", draft-ietf-i2rs-rib-info-model-11 (work		Base Info Model", draft-ietf-i2rs-rib-info-model-12 (work
	in progress), June 2017.		in progress), November 2017.
	[I-D.ietf-i2rs-security-environment-reqs]
	Migault, D., Halpern, J., and S. Hares, "I2RS Environment
	Security Requirements", draft-ietf-i2rs-security-
	environment-reqs-05 (work in progress), March 2017.
	[I-D.ietf-i2rs-usecase-reqs-summary]		[I-D.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", draft-ietf-i2rs-usecase-reqs-summary-03		Requirements", draft-ietf-i2rs-usecase-reqs-summary-03
	(work in progress), November 2016.		(work in progress), November 2016.
			[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
			Nadeau, "An Architecture for the Interface to the Routing
			System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
			<https://www.rfc-editor.org/info/rfc7921>.
	Authors' Addresses		Authors' Addresses
	Lixing Wang		Lixing Wang
	Individual		Individual
	Email: wang_little_star@sina.com		Email: wang_little_star@sina.com
	Hariharan Ananthakrishnan		Hariharan Ananthakrishnan
	Packet Design		Packet Design
	Email: hari@packetdesign.com		Email: hari@packetdesign.com
	Mach(Guoyi) Chen		Mach(Guoyi) Chen
	Huawei		Huawei
	Email: mach.chen@huawei.com		Email: mach.chen@huawei.com
	Amit Dass		Amit Dass
	Ericsson		Ericsson
	Torshamnsgatan 48.
	Stockholm 16480
	Sweden
	Email: amit.dass@ericsson.com		Email: amit.dass@ericsson.com
	Sriganesh Kini		Sriganesh Kini
	Ericsson		Individual
	Email: sriganesh.kini@ericsson.com		Email: sriganeshkini@gmail.com
	Nitin Bahadur		Nitin Bahadur
	Bracket Computing		Bracket Computing
	Email: nitin_bahadur@yahoo.com		Email: nitin_bahadur@yahoo.com
End of changes. 30 change blocks.
	64 lines changed or deleted		110 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/