draft-ietf-teas-yang-te-topo-10.txt		draft-ietf-teas-yang-te-topo-11.txt
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Huawei Technologies		Huawei Technologies
	Vishnu Pavan Beeram		Vishnu Pavan Beeram
	Juniper Networks		Juniper Networks
	Tarek Saad		Tarek Saad
	Cisco Systems Inc		Cisco Systems Inc
	Himanshu Shah		Himanshu Shah
	Ciena		Ciena
	Oscar Gonzalez De Dios		Oscar Gonzalez De Dios
	Telefonica		Telefonica
	Expires: January 2, 2018 July 2, 2017		Expires: January 3, 2018 July 3, 2017
	YANG Data Model for TE Topologies		YANG Data Model for TE Topologies
	draft-ietf-teas-yang-te-topo-10		draft-ietf-teas-yang-te-topo-11
	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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on January 2, 2018.		This Internet-Draft will expire on January 3, 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		(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 3, line 14 ¶		skipping to change at page 3, line 14 ¶
	4.3. Merging TE Topologies Provided by Multiple Providers.....18		4.3. Merging TE Topologies Provided by Multiple Providers.....18
	4.4. Dealing with Multiple Abstract TE Topologies Provided by the		4.4. Dealing with Multiple Abstract TE Topologies Provided by the
	Same Provider.................................................21		Same Provider.................................................21
	5. Modeling Considerations.......................................24		5. Modeling Considerations.......................................24
	5.1. Network topology building blocks.........................24		5.1. Network topology building blocks.........................24
	5.2. Technology agnostic TE Topology model....................24		5.2. Technology agnostic TE Topology model....................24
	5.3. Model Structure..........................................25		5.3. Model Structure..........................................25
	5.4. Topology Identifiers.....................................26		5.4. Topology Identifiers.....................................26
	5.5. Generic TE Link Attributes...............................26		5.5. Generic TE Link Attributes...............................26
	5.6. Generic TE Node Attributes...............................27		5.6. Generic TE Node Attributes...............................27
	5.7. TED Information Sources..................................29		5.7. TED Information Sources..................................28
	5.8. Overlay/Underlay Relationship............................30		5.8. Overlay/Underlay Relationship............................29
	5.9. Templates................................................31		5.9. Templates................................................30
	5.10. Scheduling Parameters...................................32		5.10. Scheduling Parameters...................................31
	5.11. Notifications...........................................32		5.11. Notifications...........................................31
	6. Tree Structure................................................32		6. Tree Structure................................................32
	7. TE Topology Yang Module.......................................68		7. TE Topology Yang Module.......................................68
	8. Security Considerations......................................116		8. Security Considerations......................................115
	9. IANA Considerations..........................................116		9. IANA Considerations..........................................115
	10. References..................................................116		10. References..................................................116
	10.1. Normative References...................................116		10.1. Normative References...................................116
	10.2. Informative References.................................117		10.2. Informative References.................................116
	11. Acknowledgments.............................................117		11. Acknowledgments.............................................116
	Appendix A. Companion YANG Model for Non-NMDA Compliant		Appendix A. Companion YANG Model for Non-NMDA Compliant
	Implementations.................................................118		Implementations.................................................118
	A.1. TE Topology State Yang Module...........................118		A.1. TE Topology State Yang Module...........................118
	Contributors....................................................125		Contributors....................................................125
	Authors' Addresses..............................................126		Authors' Addresses..............................................126
	1. Introduction		1. Introduction
	The Traffic Engineering Database (TED) is an essential component of		The Traffic Engineering Database (TED) is an essential component of
	Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702]		Traffic Engineered (TE) systems that are based on MPLS-TE [RFC2702]
	skipping to change at page 25, line 44 ¶		skipping to change at page 25, line 44 ¶
	+--rw node-template* [name] {template}?		+--rw node-template* [name] {template}?
	| ............		| ............
	+--rw link-template* [name] {template}?		+--rw link-template* [name] {template}?
	............		............
	augment /nw:networks/nw:network:		augment /nw:networks/nw:network:
	+--rw provider-id? te-types:te-global-id		+--rw provider-id? te-types:te-global-id
	+--rw client-id? te-types:te-global-id		+--rw client-id? te-types:te-global-id
	+--rw te-topology-id? te-types:te-topology-id		+--rw te-topology-id? te-types:te-topology-id
	+--rw te!		+--rw te!
	+--rw config
	| ............		| ............
	+--ro state
	............
	augment /nw:networks/nw:network/nw:node:		augment /nw:networks/nw:network/nw:node:
	+--rw te-node-id? te-types:te-node-id		+--rw te-node-id? te-types:te-node-id
	+--rw te!		+--rw te!
	+--rw config
	| ............
	+--ro state
	| ............		| ............
	+--rw tunnel-termination-point* [tunnel-tp-id]		+--rw tunnel-termination-point* [tunnel-tp-id]
	+--rw tunnel-tp-id binary		+--rw tunnel-tp-id binary
	+--rw config
	| ............		| ............
	+--ro state		+--rw supporting-tunnel-termination-point* [node-ref tunnel-
			tp-ref]
			| ............
	augment /nw:networks/nw:network/nt:link:		augment /nw:networks/nw:network/nt:link:
	+--rw te!		+--rw te!
	+--rw config
	| ..........		| ..........
	+--ro state
	..........
	augment /nw:networks/nw:network/nw:node/nt:termination-point:		augment /nw:networks/nw:network/nw:node/nt:termination-point:
	+--rw te-tp-id? te-types:te-tp-id		+--rw te-tp-id? te-types:te-tp-id
	+--rw te!		+--rw te!
	+--rw config
	| ............		| ............
	+--ro state
	............
	5.4. Topology Identifiers		5.4. Topology Identifiers
	The TE-Topology is uniquely identified by a key that has 3		The TE-Topology is uniquely identified by a key that has 3
	constituents - te-topology-id, provider-id and client-id. The		constituents - te-topology-id, provider-id and client-id. The
	combination of provider-id and te-topology-id uniquely identifies a		combination of provider-id and te-topology-id uniquely identifies a
	native TE Topology on a given provider. The client-id is used only		native TE Topology on a given provider. The client-id is used only
	when Customized TE Topologies come into play; a value of "0" is used		when Customized TE Topologies come into play; a value of "0" is used
	as the client-id for native TE Topologies.		as the client-id for native TE Topologies.
	skipping to change at page 27, line 33 ¶		skipping to change at page 27, line 24 ¶
	The definition of a generic connectivity matrix is shown below:		The definition of a generic connectivity matrix is shown below:
	+--rw te-node-attributes		+--rw te-node-attributes
	...........		...........
	+--rw connectivity-matrices		+--rw connectivity-matrices
	...........		...........
	| +--rw connectivity-matrix* [id]		| +--rw connectivity-matrix* [id]
	| | +--rw id uint32		| | +--rw id uint32
	| | +--rw from		| | +--rw from
	| | | +--rw tp-ref? leafref		| | | +--rw tp-ref? leafref
			| | | +--rw label-restriction* [inclusive-exclusive label-
			start]
	| | +--rw to		| | +--rw to
	| | | +--rw tp-ref? leafref		| | | +--rw tp-ref? leafref
			| | | +--rw label-restriction* [inclusive-exclusive label-
			start]
	| | +--rw is-allowed? boolean		| | +--rw is-allowed? boolean
	| | +--rw label-restriction* [inclusive-exclusive label-start]
	...........		...........
	| | +--rw underlay! {te-topology-hierarchy}?		| | +--rw underlay! {te-topology-hierarchy}?
	...........		...........
	| | +--rw max-link-bandwidth? te-bandwidth		| | +--rw path-constraints
	| | +--rw max-resv-link-bandwidth? te-bandwidth
	| | +--rw unreserved-bandwidth* [priority]
	...........
	| | +--rw te-default-metric? uint32
	| | +--rw te-delay-metric? uint32
	| | +--rw te-srlgs
	| | +--rw te-nsrlgs {nsrlg}? ...........The definition of
	a TTP Local Link Connectivity List is shown below:
	+--rw tunnel-termination-point* [tunnel-tp-id]
	+--rw tunnel-tp-id binary
	+--rw config
	| +--rw switching-capability? identityref
	| +--rw encoding? identityref
	| +--rw inter-layer-lock-id? uint32
	| +--rw protection-type? identityref
	| +--rw local-link-connectivities
	...........		...........
	| +--rw local-link-connectivity* [link-tp-ref]		| | +--rw optimizations
	| +--rw link-tp-ref leafref
	| +--rw label-restriction* [inclusive-exclusive label-
	start]
	...........		...........
	| +--rw max-lsp-bandwidth* [priority]		| | +--ro computed-path-properties
	...........		...........
	| +--rw max-link-bandwidth? te-bandwidth
	| +--rw max-resv-link-bandwidth? te-bandwidth		The definition of a TTP Local Link Connectivity List is shown below:
	| +--rw unreserved-bandwidth* [priority]
			+--rw tunnel-termination-point* [tunnel-tp-id]
			+--rw tunnel-tp-id binary
			+--rw admin-status? te-types:te-admin-status
			+--rw name? string
			+--rw switching-capability? identityref
			+--rw encoding? identityref
			+--rw inter-layer-lock-id? uint32
			+--rw protection-type? Identityref
			+--rw client-layer-adaptation
	...........		...........
	| +--rw te-default-metric? uint32		+--rw local-link-connectivities
	| +--rw te-delay-metric? uint32
	| +--rw te-srlgs
	| +--rw te-nsrlgs {nsrlg}?
	...........		...........
	+--ro state		| +--rw local-link-connectivity* [link-tp-ref]
	| +--ro switching-capability? identityref		| +--rw link-tp-ref leafref
	| +--ro encoding? identityref		| +--rw label-restriction* [inclusive-exclusive label-start]
	| +--ro inter-layer-lock-id? uint32
	| +--ro protection-type? identityref
	| +--ro local-link-connectivities
	...........		...........
	| +--ro local-link-connectivity* [link-tp-ref]		| +--rw is-allowed? boolean
	| | +--ro link-tp-ref leafref		| +--rw underlay {te-topology-hierarchy}?
	| | +--ro label-restriction* [inclusive-exclusive label-
	start]
	...........		...........
	| | +--ro max-lsp-bandwidth* [priority]		| +--rw path-constraints
	...........		...........
	| | +--ro max-link-bandwidth? te-bandwidth		| +--rw optimizations
	| | +--ro max-resv-link-bandwidth? te-bandwidth
	| | +--ro unreserved-bandwidth* [priority]
	...........		...........
	| | +--ro te-default-metric? uint32		| +--ro computed-path-properties
	| | +--ro te-delay-metric? uint32
	| | +--ro te-srlgs
	| | +--ro te-nsrlgs {nsrlg}?
	...........		...........
	+--rw supporting-tunnel-termination-point* [node-ref tunnel-tp-		+--rw supporting-tunnel-termination-point* [node-ref tunnel-tp-
	ref]		ref]
	+--rw node-ref union		+--rw node-ref inet:uri
	+--rw tunnel-tp-ref union		+--rw tunnel-tp-ref binary
	The attributes directly under container connectivity-matrices are the		The attributes directly under container connectivity-matrices are the
	default attributes for all connectivity-matrix entries when the per		default attributes for all connectivity-matrix entries when the per
	entry corresponding attribute is not specified. When a per entry		entry corresponding attribute is not specified. When a per entry
	attribute is specified, it overrides the cooresponding attribute		attribute is specified, it overrides the cooresponding attribute
	directly under the container connectivity-matrices. The same rule		directly under the container connectivity-matrices. The same rule
	applies to the attributes directly under container local-link-		applies to the attributes directly under container local-link-
	connectivities.		connectivities.
	Each TTP (Tunnel Termination Point) MAY be supported by one or more		Each TTP (Tunnel Termination Point) MAY be supported by one or more
	skipping to change at page 29, line 38 ¶		skipping to change at page 29, line 8 ¶
	information sources (OSPF-TE, ISIS-TE, BGP-LS, User-Configured,		information sources (OSPF-TE, ISIS-TE, BGP-LS, User-Configured,
	System-Processed, Other). Each information source is associated with		System-Processed, Other). Each information source is associated with
	a credibility preference to indicate precedence. In scenarios where a		a credibility preference to indicate precedence. In scenarios where a
	customized TE Topology is merged into a Client's native TE Topology,		customized TE Topology is merged into a Client's native TE Topology,
	the merged topological elements would point to the corresponding		the merged topological elements would point to the corresponding
	customized TE Topology as its information source.		customized TE Topology as its information source.
	augment /nw:networks/nw:network/nw:node:		augment /nw:networks/nw:network/nw:node:
	+--rw te!		+--rw te!
	...........		...........
	+--ro state		+--ro information-source? te-info-source
	........		+--ro information-source-state
	| +--ro information-source? te-info-source		| +--ro credibility-preference? uint16
	| +--ro information-source-state		| +--ro logical-network-element? string
	| | +--ro credibility-preference? uint16		| +--ro network-instance? string
	| | +--ro logical-network-element? string		| +--ro topology
	| | +--ro network-instance? string		| +--ro node-ref? leafref
	| | +--ro topology		| +--ro network-ref? leafref
	| | +--ro network-ref? leafref		+--ro information-source-entry* [information-source]
	| | +--ro node-ref? leafref		| +--ro information-source te-info-source
	| +--ro information-source-entry* [information-source]
	............		............
	augment /nw:networks/nw:network/nt:link:		augment /nw:networks/nw:network/nt:link:
	+--rw te!		+--rw te!
	...........		...........
	+--ro state		+--ro information-source? te-info-source
	.........		+--ro information-source-state
	| +--ro information-source? te-info-source		| +--ro credibility-preference? uint16
	| +--ro information-source-state		| +--ro logical-network-element? string
	| | +--ro credibility-preference? uint16		| +--ro network-instance? string
	| | +--ro logical-network-element? string		| +--ro topology
	| | +--ro network-instance? string		| +--ro link-ref? leafref
	| | +--ro topology		| +--ro network-ref? leafref
	| | +--ro network-ref? leafref		+--ro information-source-entry* [information-source]
	| | +--ro link-ref? leafref		| +--ro information-source te-info-source
	| +--ro information-source-entry* [information-source]
	............		............
	5.8. Overlay/Underlay Relationship		5.8. Overlay/Underlay Relationship
	The model captures overlay and underlay relationship for TE		The model captures overlay and underlay relationship for TE
	nodes/links. For example - in networks where multiple TE Topologies		nodes/links. For example - in networks where multiple TE Topologies
	are built hierarchically, this model allows the user to start from a		are built hierarchically, this model allows the user to start from a
	specific topological element in the top most topology and traverse		specific topological element in the top most topology and traverse
	all the way down to the supporting topological elements in the bottom		all the way down to the supporting topological elements in the bottom
	most topology.		most topology.
	This relationship is captured via the "underlay-topology" field for		This relationship is captured via the "underlay-topology" field for
	the node and via the "underlay" field for the link. The use of these		the node and via the "underlay" field for the link. The use of these
	fields is optional and this functionality is tagged as a "feature"		fields is optional and this functionality is tagged as a "feature"
	("te-topology-hierarchy").		("te-topology-hierarchy").
	augment /nw:networks/nw:network/nw:node:		augment /nw:networks/nw:network/nw:node:
			+--rw te-node-id? te-types:te-node-id
	+--rw te!		+--rw te!
	+--rw te-node-id te-node-id		+--rw te-node-template* leafref {template}?
	+--rw config		+--rw te-node-attributes
	| +--rw te-node-template* leafref {template}?		| +--rw admin-status? te-types:te-admin-status
	| +--rw te-node-attributes		| | ....................
	| ....................		| +--rw underlay-topology {te-topology-hierarchy}?
	| +--rw underlay-topology {te-topology-hierarchy}?		| +--rw network-ref? leafref
	| +--rw network-ref? leafref
	augment /nw:networks/nw:network/nt:link:		augment /nw:networks/nw:network/nt:link:
	+--rw te!		+--rw te!
	+--rw config		+--rw te-link-attributes
	| .........		| ....................
	| +--rw te-link-attributes		| +--rw underlay {te-topology-hierarchy}?
	| ....................		| | +--rw enabled? boolean
			| | +--rw primary-path
	| +--rw underlay! {te-topology-hierarchy}?		| | | +--rw network-ref? leafref
	| | +--rw primary-path		| | | ....................
	| | | +--rw network-ref? leafref		| | +--rw backup-path* [index]
	| | | +--rw path-element* [path-element-id]		| | | +--rw index uint32
	| | | ...............		| | | +--rw network-ref? leafref
	| | +--rw backup-path* [index]		| | | ....................
	| | | +--rw index uint32		| | +--rw protection-type? identityref
	| | | +--rw network-ref? leafref		| | +--rw tunnel-termination-points
	| | | +--rw path-element* [path-element-id]		| | | +--rw source? binary
	| | | ...............		| | | +--rw destination? binary
	| | +--rw underlay-protection-type? uint16		| | +--rw tunnels
	| | +--rw underlay-tunnel-src		| | | ....................
	| | | ...........
	| | +--rw underlay-tunnel-des
	| | ...........
	5.9. Templates		5.9. Templates
	The data model provides the users with the ability to define		The data model provides the users with the ability to define
	templates and apply them to link and node configurations. The use of		templates and apply them to link and node configurations. The use of
	"template" configuration is optional and this functionality is tagged		"template" configuration is optional and this functionality is tagged
	as a "feature" ("template").		as a "feature" ("template").
	+--rw topology* [provider-id client-id te-topology-id]		+--rw topology* [provider-id client-id te-topology-id]
	| ...........		| ...........
	skipping to change at page 116, line 27 ¶		skipping to change at page 115, line 36 ¶
	9. IANA Considerations		9. IANA Considerations
	This document registers the following URIs in the IETF XML registry		This document registers the following URIs in the IETF XML registry
	[RFC3688]. Following the format in [RFC3688], the following		[RFC3688]. Following the format in [RFC3688], the following
	registration is requested to be made.		registration is requested to be made.
	URI: urn:ietf:params:xml:ns:yang:ietf-te-topology		URI: urn:ietf:params:xml:ns:yang:ietf-te-topology
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
			URI: urn:ietf:params:xml:ns:yang:ietf-te-topology-state
			XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the YANG Module Names
	registry [RFC6020].		registry [RFC6020].
	name: ietf-te-topology		name: ietf-te-topology
	namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology		namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology
	prefix: tet		prefix: tet
			name: ietf-te-topology-state
			namespace: urn:ietf:params:xml:ns:yang:ietf-te-topology-state
			prefix: tet-s
	10. References		10. References
	10.1. Normative References		10.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	skipping to change at page 126, line 5 ¶		skipping to change at page 125, line 47 ¶
	Contributors		Contributors
	Sergio Belotti		Sergio Belotti
	Nokia		Nokia
	Email: sergio.belotti@nokia.com		Email: sergio.belotti@nokia.com
	Dieter Beller		Dieter Beller
	Nokia		Nokia
	Email: Dieter.Beller@nokia.com		Email: Dieter.Beller@nokia.com
			Carlo Perocchio
			Ericsson
			Email: carlo.perocchio@ericsson.com
			Italo Busi
			Huawei Technologies
			Email: Italo.Busi@huawei.com
	Authors' Addresses		Authors' Addresses
	Xufeng Liu		Xufeng Liu
	Jabil		Jabil
	Email: Xufeng_Liu@jabil.com		Email: Xufeng_Liu@jabil.com
	Igor Bryskin		Igor Bryskin
	Huawei Technologies		Huawei Technologies
	Email: Igor.Bryskin@huawei.com		Email: Igor.Bryskin@huawei.com
End of changes. 37 change blocks.
	127 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/