< draft-ietf-spring-sr-yang-27.txt		draft-ietf-spring-sr-yang-28.txt >
	SPRING Working Group S. Litkowski		SPRING Working Group S. Litkowski
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track Y. Qu		Intended status: Standards Track Y. Qu
	Expires: May 31, 2021 Futurewei		Expires: June 1, 2021 Futurewei
	A. Lindem		A. Lindem
	Cisco Systems		Cisco Systems
	P. Sarkar		P. Sarkar
	Arrcus Networks		Arrcus Networks
	J. Tantsura		J. Tantsura
	Apstra		Apstra
	November 27, 2020		November 28, 2020
	YANG Data Model for Segment Routing		YANG Data Model for Segment Routing
	draft-ietf-spring-sr-yang-27		draft-ietf-spring-sr-yang-28
	Abstract		Abstract
	This document defines a YANG data model for segment routing		This document defines a YANG data model for segment routing
	configuration and operation, which is to be augmented by different		configuration and operation, which is to be augmented by different
	segment routing data planes. The document also defines a YANG model		segment routing data planes. The document also defines a YANG model
	that is intended to be used on network elements to configure or		that is intended to be used on network elements to configure or
	operate segment routing MPLS data plane, as well as some generic		operate segment routing MPLS data plane, as well as some generic
	containers to be reused by IGP protocol modules to support segment		containers to be reused by IGP protocol modules to support segment
	routing.		routing.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 https://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 May 31, 2021.		This Internet-Draft will expire on June 1, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	8.1. YANG Module for Segment Routing . . . . . . . . . . . . . 9		8.1. YANG Module for Segment Routing . . . . . . . . . . . . . 9
	8.2. YANG Module for Segment Routing Common Types . . . . . . 10		8.2. YANG Module for Segment Routing Common Types . . . . . . 10
	8.3. YANG Module for Segment Routing MPLS . . . . . . . . . . 16		8.3. YANG Module for Segment Routing MPLS . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 28		9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12.1. Normative References . . . . . . . . . . . . . . . . . . 31		12.1. Normative References . . . . . . . . . . . . . . . . . . 31
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Configuration examples . . . . . . . . . . . . . . . 33		Appendix A. Configuration examples . . . . . . . . . . . . . . . 33
	A.1. SR MPLS with IPv4 . . . . . . . . . . . . . . . . . . . . 33		A.1. SR MPLS with IPv4 . . . . . . . . . . . . . . . . . . . . 34
	A.2. SR MPLS with IPv6 . . . . . . . . . . . . . . . . . . . . 36		A.2. SR MPLS with IPv6 . . . . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	This document defines a YANG data model [RFC7950] for segment routing		This document defines a YANG data model [RFC7950] for segment routing
	[RFC8402] configuration and operation. The document also defines a		[RFC8402] configuration and operation. The document also defines a
	YANG model that is intended to be used on network elements to		YANG model that is intended to be used on network elements to
	configure or operate segment routing MPLS data plane [RFC8660]. This		configure or operate segment routing MPLS data plane [RFC8660]. This
	document does not define the IGP extensions to support segment		document does not define the IGP extensions to support segment
	routing but defines generic groupings that SHOULD be reused by IGP		routing but defines generic groupings that SHOULD be reused by IGP
	extension modules. The reason of this design choice is to not		extension modules. The reason of this design choice is to not
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	module: ietf-segment-routing		module: ietf-segment-routing
	augment /rt:routing:		augment /rt:routing:
	+--rw segment-routing		+--rw segment-routing
	module: ietf-segment-routing-mpls		module: ietf-segment-routing-mpls
	augment /rt:routing/sr:segment-routing:		augment /rt:routing/sr:segment-routing:
	+--rw sr-mpls		+--rw sr-mpls
	+--ro node-capabilities		+--ro node-capabilities
	| +--ro entropy-readable-label-depth? uint8		| +--ro entropy-readable-label-depth? uint8
	+--rw msd {max-sid-depth}?		+--ro msd {max-sid-depth}?
	| +--rw node-msd? uint8		| +--ro node-msd? uint8
	| +--rw link-msds		| +--ro link-msds
	| +--rw link-msds* [interface]		| +--ro link-msds* [interface]
	| +--rw interface if:interface-ref		| +--ro interface if:interface-ref
	| +--rw msd? uint8		| +--ro msd? uint8
	+--rw bindings		+--rw bindings
	| +--rw mapping-server {mapping-server}?		| +--rw mapping-server {mapping-server}?
	| | +--rw policy* [name]		| | +--rw policy* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw entries		| | +--rw entries
	| | +--rw mapping-entry* [prefix algorithm]		| | +--rw mapping-entry* [prefix algorithm]
	| | +--rw prefix inet:ip-prefix		| | +--rw prefix inet:ip-prefix
	| | +--rw value-type? enumeration		| | +--rw value-type? enumeration
	| | +--rw start-sid uint32		| | +--rw start-sid uint32
	| | +--rw range? uint32		| | +--rw range? uint32
	skipping to change at page 16, line 22 ¶		skipping to change at page 16, line 22 ¶
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	8.3. YANG Module for Segment Routing MPLS		8.3. YANG Module for Segment Routing MPLS
	ietf-segment-routing-mpls.yang: This module defines the configuration		ietf-segment-routing-mpls.yang: This module defines the configuration
	and operational states for Segment Routing MPLS data plane.		and operational states for Segment Routing MPLS data plane.
	<CODE BEGINS> file "ietf-segment-routing-mpls@2020-11-27.yang		<CODE BEGINS> file "ietf-segment-routing-mpls@2020-11-28
	module ietf-segment-routing-mpls {		module ietf-segment-routing-mpls {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls";		namespace "urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls";
	prefix sr-mpls;		prefix sr-mpls;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference "RFC 6991: Common YANG Data Types";		reference "RFC 6991: Common YANG Data Types";
	}		}
	import ietf-routing {		import ietf-routing {
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 4 ¶
	This version of this YANG module is part of RFC XXXX;		This version of this YANG module is part of RFC XXXX;
	see the RFC itself for full legal notices.		see the RFC itself for full legal notices.
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	'MAY', and 'OPTIONAL' in this document are to be interpreted as		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	they appear in all capitals, as shown here.";		they appear in all capitals, as shown here.";
	reference "RFC XXXX: YANG Data Model for Segment Routing.";		reference "RFC XXXX: YANG Data Model for Segment Routing.";
	revision 2020-11-27 {		revision 2020-11-28 {
	description		description
	"Initial Version";		"Initial Version";
	reference "RFC XXXX: YANG Data Model for Segment Routing.";		reference "RFC XXXX: YANG Data Model for Segment Routing.";
	}		}
	feature mapping-server {		feature mapping-server {
	description		description
	"Support for Segment Routing Mapping Server (SRMS).";		"Support for Segment Routing Mapping Server (SRMS).";
	reference "RFC 8661: Segment Routing MPLS Interworking		reference "RFC 8661: Segment Routing MPLS Interworking
	with LDP";		with LDP";
	skipping to change at page 21, line 39 ¶		skipping to change at page 21, line 39 ¶
	Section 6.1		Section 6.1
	RFC 8667: IS-IS Extensions for Segment		RFC 8667: IS-IS Extensions for Segment
	Routing Section 2.2.1";		Routing Section 2.2.1";
	}		}
	}		}
	}		}
	}		}
	grouping max-sid-depth {		grouping max-sid-depth {
	description		description
	"Maximum SID Depth (MSD) configuration grouping.";		"Maximum SID Depth (MSD) operational state grouping.";
	leaf node-msd {		leaf node-msd {
	type uint8;		type uint8;
	description		description
	"Node MSD is the lowest MSD supported by the node.";		"Node MSD is the lowest MSD supported by the node.";
	}		}
	container link-msds {		container link-msds {
	description		description
	"MSD supported by an individual interface.";		"MSD supported by an individual interface.";
	list link-msds {		list link-msds {
	key "interface";		key "interface";
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 25 ¶
	}		}
	}		}
	}		}
	augment "/rt:routing/sr:segment-routing" {		augment "/rt:routing/sr:segment-routing" {
	description		description
	"This augments routing data model (RFC 8349)		"This augments routing data model (RFC 8349)
	with Segment Routing (SR).";		with Segment Routing (SR).";
	container sr-mpls {		container sr-mpls {
	description		description
	"Segment Routing global configuration.";		"Segment Routing global configuration and
			operational state.";
	uses sr-cmn:node-capabilities;		uses sr-cmn:node-capabilities;
	container msd {		container msd {
	if-feature "max-sid-depth";		if-feature "max-sid-depth";
			config false;
	description		description
	"MSD configuration.";		"Maximum Segment Depth (MSD) Operational State.";
	uses max-sid-depth;		uses max-sid-depth;
	}		}
	container bindings {		container bindings {
	description		description
	"List of bindings.";		"List of bindings.";
	container mapping-server {		container mapping-server {
	if-feature "mapping-server";		if-feature "mapping-server";
	description		description
	"Configuration of mapping-server local entries.";		"Configuration of mapping-server local entries.";
	list policy {		list policy {
	skipping to change at page 29, line 10 ¶		skipping to change at page 29, line 12 ¶
	The NETCONF access control model [RFC6536] provides the means to		The NETCONF access control model [RFC6536] provides the means to
	restrict access for particular NETCONF or RESTCONF users to a pre-		restrict access for particular NETCONF or RESTCONF users to a pre-
	configured subset of all available NETCONF or RESTCONF protocol		configured subset of all available NETCONF or RESTCONF protocol
	operations and content.		operations and content.
	There are a number of data nodes defined in the modules that are		There are a number of data nodes defined in the modules that are
	writable/creatable/deletable (i.e., config true, which is the		writable/creatable/deletable (i.e., config true, which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)		in some network environments. Write operations (e.g., edit-config)
	to these data nodes without proper protection can have a negative		to these data nodes without proper protection can have a negative
	effect on network operations. Writable data node represent		effect on network operations. Writable data nodes represent
	configuration of the router's MSD, Bindings, and the global and local		configuration of the router's bindings and the global and local label
	label blocks. These correspond to the following schema nodes:		blocks. These correspond to the following schema nodes:
	/segment-routing		/segment-routing
	/segment-routing/mpls		/segment-routing/mpls
	/segment-routing/mpls/bindings - Modification to the local		/segment-routing/mpls/bindings - Modification to the local
	bindings could result in a Denial of Service (DoS) attack.		bindings could result in a Denial of Service (DoS) attack.
	Additionally, the addition of bindings could result in traffic		Additionally, the addition of bindings could result in traffic
	being redirected to the router.		being redirected to the router.
	skipping to change at page 30, line 5 ¶		skipping to change at page 30, line 5 ¶
	/segment-routing/mpls/bindings - Knowledge of these data nodes can		/segment-routing/mpls/bindings - Knowledge of these data nodes can
	be used to attack the local router with either a a Denial of		be used to attack the local router with either a a Denial of
	Service (DoS) attack or rediection of traffic destined to the		Service (DoS) attack or rediection of traffic destined to the
	local router.		local router.
	/segment-routing/mpls/sid-db - Knowledge of these data nodes can		/segment-routing/mpls/sid-db - Knowledge of these data nodes can
	be used to attack the other routers in the segment routing domain		be used to attack the other routers in the segment routing domain
	with either a a Denial of Service (DoS) attack or rediection		with either a a Denial of Service (DoS) attack or rediection
	traffic destined for those routers.		traffic destined for those routers.
			Furthermore exposure the node's capabilities and maximum segment
			depth may be useful in mounting a Denial-of-Service (DOS) attack by
			sending the node SR packets that the router can't process. These
			correspond to the following schema nodes:
			/segment-routing/mpls/node-capabilities
			/segment-routing/mpls/msd
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank Derek Yeung, Greg Hankins, Hannes		The authors would like to thank Derek Yeung, Greg Hankins, Hannes
	Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for		Gredler, Uma Chunduri, Jeffrey Zhang, Shradda Hedge, Les Ginsberg for
	their contributions.		their contributions.
	Thanks to Ladislav Lhotka and Tom Petch for their thorough reviews		Thanks to Ladislav Lhotka and Tom Petch for their thorough reviews
	and helpful comments.		and helpful comments.
	11. IANA Considerations		11. IANA Considerations
	skipping to change at page 34, line 10 ¶		skipping to change at page 35, line 10 ¶
	A.1. SR MPLS with IPv4		A.1. SR MPLS with IPv4
	The following is an XML example using the SR MPLS YANG modules with		The following is an XML example using the SR MPLS YANG modules with
	IPv4 addresses.		IPv4 addresses.
	<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">		<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
	<segment-routing		<segment-routing
	xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">		xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">
	<sr-mpls		<sr-mpls
	xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">		xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">
	<msd>
	<node-msd>5</node-msd>
	</msd>
	<bindings>		<bindings>
	<mapping-server>		<mapping-server>
	<policy>		<policy>
	<name>mapping 1</name>		<name>mapping 1</name>
	<entries>		<entries>
	<mapping-entry>		<mapping-entry>
	<prefix>198.51.100.0/24</prefix>		<prefix>198.51.100.0/24</prefix>
	<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\		<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\
	:ietf-segment-routing-common">\		:ietf-segment-routing-common">\
	sr-cmn:prefix-sid-algorithm-shortest-path\		sr-cmn:prefix-sid-algorithm-shortest-path\
	skipping to change at page 35, line 4 ¶		skipping to change at page 35, line 48 ¶
	</bindings>		</bindings>
	<global-srgb>		<global-srgb>
	<srgb>		<srgb>
	<lower-bound>45000</lower-bound>		<lower-bound>45000</lower-bound>
	<upper-bound>55000</upper-bound>		<upper-bound>55000</upper-bound>
	</srgb>		</srgb>
	</global-srgb>		</global-srgb>
	</sr-mpls>		</sr-mpls>
	</segment-routing>		</segment-routing>
	</routing>		</routing>
	The following is the same example using JSON format.		The following is the same example using JSON format.
	{		{
	"ietf-routing:routing": {		"ietf-routing:routing": {
	"ietf-segment-routing:segment-routing": {		"ietf-segment-routing:segment-routing": {
	"ietf-segment-routing-mpls:sr-mpls": {		"ietf-segment-routing-mpls:sr-mpls": {
	"msd": {
	"node-msd": 5
	},
	"bindings": {		"bindings": {
	"mapping-server": {		"mapping-server": {
	"policy": [		"policy": [
	{		{
	"name": "mapping 1",		"name": "mapping 1",
	"entries": {		"entries": {
	"mapping-entry": [		"mapping-entry": [
	{		{
	"prefix": "198.51.100.0/24",		"prefix": "198.51.100.0/24",
	"algorithm": "ietf-segment-routing-common:\		"algorithm": "ietf-segment-routing-common:\
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 46 ¶
	]		]
	}		}
	},		},
	"global-srgb": {		"global-srgb": {
	"srgb": [		"srgb": [
	{		{
	"lower-bound": 45000,		"lower-bound": 45000,
	"upper-bound": 55000		"upper-bound": 55000
	}		}
	]		]
	}		}
	}		}
	}		}
	}		}
	}		}
	A.2. SR MPLS with IPv6		A.2. SR MPLS with IPv6
	The following is an XML example using the SR MPLS YANG modules with		The following is an XML example using the SR MPLS YANG modules with
	IPv6 addresses.		IPv6 addresses.
	<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">		<routing xmlns="urn:ietf:params:xml:ns:yang:ietf-routing">
	<segment-routing		<segment-routing
	xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">		xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing">
	<sr-mpls		<sr-mpls
	xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">		xmlns="urn:ietf:params:xml:ns:yang:ietf-segment-routing-mpls">
	<msd>
	<node-msd>5</node-msd>
	</msd>
	<bindings>		<bindings>
	<mapping-server>		<mapping-server>
	<policy>		<policy>
	<name>mapping 1</name>		<name>mapping 1</name>
	<entries>		<entries>
	<mapping-entry>		<mapping-entry>
	<prefix>2001:db8:aaaa:bbbb::/64</prefix>		<prefix>2001:db8:aaaa:bbbb::/64</prefix>
	<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\		<algorithm xmlns:sr-cmn="urn:ietf:params:xml:ns:yang\
	:ietf-segment-routing-common">\		:ietf-segment-routing-common">\
	sr-cmn:prefix-sid-algorithm-shortest-path\		sr-cmn:prefix-sid-algorithm-shortest-path\
	skipping to change at page 38, line 4 ¶		skipping to change at page 38, line 48 ¶
	</bindings>		</bindings>
	<global-srgb>		<global-srgb>
	<srgb>		<srgb>
	<lower-bound>45000</lower-bound>		<lower-bound>45000</lower-bound>
	<upper-bound>55000</upper-bound>		<upper-bound>55000</upper-bound>
	</srgb>		</srgb>
	</global-srgb>		</global-srgb>
	</sr-mpls>		</sr-mpls>
	</segment-routing>		</segment-routing>
	</routing>		</routing>
	The following is the same example using JSON format.		The following is the same example using JSON format.
	{		{
	"ietf-routing:routing": {		"ietf-routing:routing": {
	"ietf-segment-routing:segment-routing": {		"ietf-segment-routing:segment-routing": {
	"ietf-segment-routing-mpls:sr-mpls": {		"ietf-segment-routing-mpls:sr-mpls": {
	"msd": {
	"node-msd": 5
	},
	"bindings": {		"bindings": {
	"mapping-server": {		"mapping-server": {
	"policy": [		"policy": [
	{		{
	"name": "mapping 1",		"name": "mapping 1",
	"entries": {		"entries": {
	"mapping-entry": [		"mapping-entry": [
	{		{
	"prefix": "2001:db8:aaaa:bbbb::/64",		"prefix": "2001:db8:aaaa:bbbb::/64",
	"algorithm": "ietf-segment-routing-common:\		"algorithm": "ietf-segment-routing-common:\
End of changes. 21 change blocks.
	34 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/