draft-ietf-netmod-revised-datastores-02.txt		draft-ietf-netmod-revised-datastores-03.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Intended status: Standards Track J. Schoenwaelder		Intended status: Standards Track J. Schoenwaelder
	Expires: November 12, 2017 Jacobs University		Expires: January 4, 2018 Jacobs University
	P. Shafer		P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	May 11, 2017		July 3, 2017
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-02		draft-ietf-netmod-revised-datastores-03
	Abstract		Abstract
	Datastores are a fundamental concept binding the data models written		Datastores are a fundamental concept binding the data models written
	in the YANG data modeling language to network management protocols		in the YANG data modeling language to network management protocols
	such as NETCONF and RESTCONF. This document defines an architectural		such as NETCONF and RESTCONF. This document defines an architectural
	framework for datastores based on the experience gained with the		framework for datastores based on the experience gained with the
	initial simpler model, addressing requirements that were not well		initial simpler model, addressing requirements that were not well
	supported in the initial model.		supported in the initial model.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 November 12, 2017.		This Internet-Draft will expire on January 4, 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 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Original Model of Datastores . . . . . . . . . . . . . . 6		3.1. Original Model of Datastores . . . . . . . . . . . . . . 6
	4. Architectural Model of Datastores . . . . . . . . . . . . . . 8		4. Architectural Model of Datastores . . . . . . . . . . . . . . 8
	4.1. The Startup Configuration Datastore (<startup>) . . . . . 9		4.1. The Startup Configuration Datastore (<startup>) . . . . . 9
	4.2. The Candidate Configuration Datastore (<candidate>) . . . 10		4.2. The Candidate Configuration Datastore (<candidate>) . . . 10
	4.3. The Running Configuration Datastore (<running>) . . . . . 10		4.3. The Running Configuration Datastore (<running>) . . . . . 10
	4.4. The Intended Configuration Datastore (<intended>) . . . . 10		4.4. The Intended Configuration Datastore (<intended>) . . . . 10
	4.5. Conventional Configuration Datastores . . . . . . . . . . 10		4.5. Conventional Configuration Datastores . . . . . . . . . . 11
	4.6. Dynamic Datastores . . . . . . . . . . . . . . . . . . . 11		4.6. Dynamic Datastores . . . . . . . . . . . . . . . . . . . 11
	4.7. The Operational State Datastore (<operational>) . . . . . 11		4.7. The Operational State Datastore (<operational>) . . . . . 11
	4.7.1. Missing Resources . . . . . . . . . . . . . . . . . . 12		4.7.1. Missing Resources . . . . . . . . . . . . . . . . . . 12
	4.7.2. System-controlled Resources . . . . . . . . . . . . . 12		4.7.2. System-controlled Resources . . . . . . . . . . . . . 13
	4.7.3. Origin Metadata Annotation . . . . . . . . . . . . . 12		4.7.3. Origin Metadata Annotation . . . . . . . . . . . . . 13
	5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 14		5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 14
	5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 14		5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 14
	6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15		6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 20		7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 21
	7.2. Updates to the YANG Module Names Registry . . . . . . . . 20		7.2. Updates to the YANG Module Names Registry . . . . . . . . 22
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 20		8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 23
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 23		Appendix A. Guidelines for Defining Datastores . . . . . . . . . 24
	A.1. Define which YANG modules can be used in the datastore . 23		A.1. Define which YANG modules can be used in the datastore . 24
	A.2. Define which subset of YANG-modeled data applies . . . . 23		A.2. Define which subset of YANG-modeled data applies . . . . 25
	A.3. Define how data is actualized . . . . . . . . . . . . . . 23		A.3. Define how data is actualized . . . . . . . . . . . . . . 25
	A.4. Define which protocols can be used . . . . . . . . . . . 23		A.4. Define which protocols can be used . . . . . . . . . . . 25
	A.5. Define YANG identities for the datastore . . . . . . . . 24		A.5. Define YANG identities for the datastore . . . . . . . . 25
	Appendix B. Ephemeral Dynamic Datastore Example . . . . . . . . 24		Appendix B. Ephemeral Dynamic Datastore Example . . . . . . . . 25
	Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 25		Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 27
	C.1. System Example . . . . . . . . . . . . . . . . . . . . . 26		C.1. System Example . . . . . . . . . . . . . . . . . . . . . 27
	C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 28		C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 29
	C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 30		C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 31
	C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 30		C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 31
	C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 31		C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 32
	C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 32		C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 33
	C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 32		C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 33
	C.3.2. System-provided Interface . . . . . . . . . . . . . . 33		C.3.2. System-provided Interface . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	1. Introduction		1. Introduction
	This document provides an architectural framework for datastores as		This document provides an architectural framework for datastores as
	they are used by network management protocols such as NETCONF		they are used by network management protocols such as NETCONF
	[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling		[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling
	language. Datastores are a fundamental concept binding network		language. Datastores are a fundamental concept binding network
	management data models to network management protocols. Agreement on		management data models to network management protocols. Agreement on
	a common architectural model of datastores ensures that data models		a common architectural model of datastores ensures that data models
	can be written in a network management protocol agnostic way. This		can be written in a network management protocol agnostic way. This
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	2. Terminology		2. Terminology
	This document defines the following terms:		This document defines the following terms:
	o datastore: A conceptual place to store and access information. A		o datastore: A conceptual place to store and access information. A
	datastore might be implemented, for example, using files, a		datastore might be implemented, for example, using files, a
	database, flash memory locations, or combinations thereof. A		database, flash memory locations, or combinations thereof. A
	datastore maps to an instantiated YANG data tree.		datastore maps to an instantiated YANG data tree.
	o configuration: Data that determines how a device behaves. This		o configuration: Data that is required to get a device from its
	data is modeled in YANG using "config true" nodes. Configuration		initial default state into a desired operational state. This data
	can originate from different sources.		is modeled in YANG using "config true" nodes. Configuration can
			originate from different sources.
	o configuration datastore: A datastore holding configuration.		o configuration datastore: A datastore holding configuration.
	o running configuration datastore: A configuration datastore holding		o running configuration datastore: A configuration datastore holding
	the current configuration of the device. It may include inactive		the current configuration of the device. It may include inactive
	configuration or template-mechanism-oriented configuration that		configuration or template-mechanism-oriented configuration that
	require further expansion. This datastore is commonly referred to		require further expansion. This datastore is commonly referred to
	as "<running>".		as "<running>".
	o candidate configuration datastore: A configuration datastore that		o candidate configuration datastore: A configuration datastore that
	skipping to change at page 10, line 5 ¶		skipping to change at page 10, line 5 ¶
	The startup configuration datastore (<startup>) is an optional		The startup configuration datastore (<startup>) is an optional
	configuration datastore holding the configuration loaded by the		configuration datastore holding the configuration loaded by the
	device when it boots. <startup> is only present on devices that		device when it boots. <startup> is only present on devices that
	separate the startup configuration from the running configuration		separate the startup configuration from the running configuration
	datastore.		datastore.
	The startup configuration datastore may not be supported by all		The startup configuration datastore may not be supported by all
	protocols or implementations.		protocols or implementations.
			On devices that support non-volatile storage, the contents of
			<startup> will typically persist across reboots via that storage. At
			boot time, the device loads the saved startup configuration into
			<running>. To save a new startup configuration, data is copied to
			<startup>, either via implicit or explicit protocol operations.
	4.2. The Candidate Configuration Datastore (<candidate>)		4.2. The Candidate Configuration Datastore (<candidate>)
	The candidate configuration datastore (<candidate>) is an optional		The candidate configuration datastore (<candidate>) is an optional
	configuration datastore that can be manipulated without impacting the		configuration datastore that can be manipulated without impacting the
	device's current configuration and that can be committed to		device's current configuration and that can be committed to
	<running>.		<running>.
	The candidate configuration datastore may not be supported by all		The candidate configuration datastore may not be supported by all
	protocols or implementations.		protocols or implementations.
			<candidate> does not typically persist across reboots, even in the
			presence of non-volatile storage. If <candidate> is stored using
			non-volatile storage, it should be reset at boot time to the contents
			of <running>.
	4.3. The Running Configuration Datastore (<running>)		4.3. The Running Configuration Datastore (<running>)
	The running configuration datastore (<running>) holds the complete		The running configuration datastore (<running>) holds the complete
	current configuration on the device. It may include inactive		current configuration on the device. It may include inactive
	configuration or template-mechanism-oriented configuration that		configuration or template-mechanism-oriented configuration that
	require further expansion.		require further expansion.
			If a device does not have a distinct <startup> and non-volatile is
			available, the device will typically use that non-volatile storage to
			allow <running> to persist across reboots.
	4.4. The Intended Configuration Datastore (<intended>)		4.4. The Intended Configuration Datastore (<intended>)
	The intended configuration datastore (<intended>) is a read-only		The intended configuration datastore (<intended>) is a read-only
	configuration datastore. It is tightly coupled to <running>. When		configuration datastore. It is tightly coupled to <running>. When
	data is written to <running>, the data that is to be validated is		data is written to <running>, the data that is to be validated is
	also conceptually written to <intended>. Validation is performed on		also conceptually written to <intended>. Validation is performed on
	the contents of <intended>.		the contents of <intended>.
	For simple implementations, <running> and <intended> are identical.		For simple implementations, <running> and <intended> are identical.
			<intended> does not persist across reboots; its relationship with
			<running> makes that unnecessary.
	Currently there are no standard mechanisms defined that affect		Currently there are no standard mechanisms defined that affect
	<intended> so that it would have different contents than <running>,		<intended> so that it would have different contents than <running>,
	but this architecture allows for such mechanisms to be defined.		but this architecture allows for such mechanisms to be defined.
	One example of such a mechanism is support for marking nodes as		One example of such a mechanism is support for marking nodes as
	inactive in <running>. Inactive nodes are not copied to <intended>,		inactive in <running>. Inactive nodes are not copied to <intended>,
	and are thus not taken into account when validating the		and are thus not taken into account when validating the
	configuration.		configuration.
	Another example is support for templates. Templates are expanded		Another example is support for templates. Templates are expanded
	skipping to change at page 11, line 43 ¶		skipping to change at page 12, line 13 ¶
	state only had "config false" nodes. The reason for incorporating		state only had "config false" nodes. The reason for incorporating
	"config true" nodes here is to be able to expose all operational		"config true" nodes here is to be able to expose all operational
	settings without having to replicate definitions in the data models.		settings without having to replicate definitions in the data models.
	<operational> contains system state and all configuration actually		<operational> contains system state and all configuration actually
	used by the system. This includes all applied configuration from		used by the system. This includes all applied configuration from
	<intended>, system-provided configuration, and default values defined		<intended>, system-provided configuration, and default values defined
	by any supported data models. In addition, <operational> also		by any supported data models. In addition, <operational> also
	contains applied data from dynamic datastores.		contains applied data from dynamic datastores.
			Requests to retrieve nodes from <operational> always return the value
			in use if the node exists, regardless of any default value specified
			in the YANG module. If no value is returned for a given node, then
			this implies that the node is not used by the device.
			<operational> does not persist across reboots.
	Changes to configuration may take time to percolate through to		Changes to configuration may take time to percolate through to
	<operational>. During this period, <operational> may contain nodes		<operational>. During this period, <operational> may contain nodes
	for both the previous and current configuration, as closely as		for both the previous and current configuration, as closely as
	possible tracking the current operation of the device. Such remnant		possible tracking the current operation of the device. Such remnant
	configuration from the previous configuration persists until the		configuration from the previous configuration persists until the
	system has released resources used by the newly-deleted configuration		system has released resources used by the newly-deleted configuration
	(e.g., network connections, memory allocations, file handles).		(e.g., network connections, memory allocations, file handles).
	As a result of remnant configuration, the semantic constraints		As a result of remnant configuration, the semantic constraints
	defined in the data model cannot be relied upon for <operational>,		defined in the data model cannot be relied upon for <operational>,
	skipping to change at page 15, line 38 ¶		skipping to change at page 16, line 12 ¶
	Author: Phil Shafer		Author: Phil Shafer
	<mailto:phil@juniper.net>		<mailto:phil@juniper.net>
	Author: Kent Watsen		Author: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Author: Rob Wilton		Author: Rob Wilton
	<rwilton@cisco.com>";		<rwilton@cisco.com>";
	description		description
	"This YANG module defines a set of identities for datastores.		"This YANG module defines two sets of identities for datastores.
	These identities can be used to identify datastores in protocol		The first identifies the datastores themselves, the second
	operations.		identifies are for datastore protperties.
	Copyright (c) 2017 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 to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		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).
	skipping to change at page 16, line 29 ¶		skipping to change at page 17, line 4 ¶
	description		description
	"Abstract base identity for datastore identities.";		"Abstract base identity for datastore identities.";
	}		}
	identity conventional {		identity conventional {
	base datastore;		base datastore;
	description		description
	"Abstract base identity for conventional configuration		"Abstract base identity for conventional configuration
	datastores.";		datastores.";
	}		}
	identity dynamic {
	base datastore;
	description
	"Abstract base identity for dynamic datastores.";
	}
	identity running {		identity running {
	base conventional;		base conventional;
	description		description
	"The running configuration datastore.";		"The running configuration datastore.";
	}		}
	identity candidate {		identity candidate {
	base conventional;		base conventional;
	description		description
	"The candidate configuration datastore.";		"The candidate configuration datastore.";
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 20 ¶
	identity candidate {		identity candidate {
	base conventional;		base conventional;
	description		description
	"The candidate configuration datastore.";		"The candidate configuration datastore.";
	}		}
	identity startup {		identity startup {
	base conventional;		base conventional;
	description		description
	"The startup configuration datastore.";		"The startup configuration datastore.";
	}		}
	identity intended {		identity intended {
	base conventional;		base conventional;
	description		description
	"The intended configuration datastore.";		"The intended configuration datastore.";
	}		}
			identity dynamic {
			base datastore;
			description
			"Abstract base identity for dynamic datastores.";
			}
	identity operational {		identity operational {
	base datastore;		base datastore;
	description		description
	"The operational state datastore.";		"The operational state datastore.";
	}		}
			identity property {
			description
			"Abstract base identity for datastore identities.";
			}
			identity writable {
			base property;
			description
			"Used on the 'running' datastore to indicate that it can be
			written to.";
			}
			identity auto-persist {
			base property;
			description
			"Used on the 'running' datastore to indicate that writes to
			it will be automatically persisted.
			If the 'startup' datastore is also supported, clients may
			query its contents to ensure its synchronization.
			If the 'startup' datastore is not supported, and this
			property is not set, then clients must use a mechanism
			provided by the protocol to explicitly persist the
			'running' datastore's contents.";
			}
			identity rollback-on-error {
			base property;
			description
			"Used on either the 'running' or 'candidate' datastores to
			indicate that clients may request atomic update behavior.";
			}
			identity confirmed-commit {
			base property;
			description
			"Used on the 'candidate' datastore to indicate that
			clients may request confirmed-commit update behavior.";
			}
			identity validate {
			base property;
			description
			"Used on the 'candidate' datastore to indicate that
			clients may request datastore validation.";
			}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-origin@2017-04-26.yang"		<CODE BEGINS> file "ietf-origin@2017-04-26.yang"
	module ietf-origin {		module ietf-origin {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-origin";		namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
	prefix or;		prefix or;
	skipping to change at page 22, line 5 ¶		skipping to change at page 23, line 31 ¶
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<http://www.rfc-editor.org/info/rfc6241>.		<http://www.rfc-editor.org/info/rfc6241>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<http://www.rfc-editor.org/info/rfc7950>.		<http://www.rfc-editor.org/info/rfc7950>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG",
	7952, DOI 10.17487/RFC7952, August 2016,		RFC 7952, DOI 10.17487/RFC7952, August 2016,
	<http://www.rfc-editor.org/info/rfc7952>.		<http://www.rfc-editor.org/info/rfc7952>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<http://www.rfc-editor.org/info/rfc8040>.		<http://www.rfc-editor.org/info/rfc8040>.
	10.2. Informative References		10.2. Informative References
	[I-D.bjorklund-netmod-operational]		[I-D.bjorklund-netmod-operational]
	Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF		Bjorklund, M. and L. Lhotka, "Operational Data in NETCONF
	skipping to change at page 28, line 20 ¶		skipping to change at page 29, line 27 ¶
	<interface or:origin="or:intended">		<interface or:origin="or:intended">
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<enabled or:origin="or:default">true</enabled>		<enabled or:origin="or:default">true</enabled>
	<speed>1000</speed>		<speed>1000</speed>
	</auto-negotiation>		</auto-negotiation>
	<speed>100</speed>		<speed>100</speed>
	<address>		<address>
	<ip>2001:db8::10</ip>		<ip>2001:db8::10</ip>
	<prefix-length>32</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	<address or:origin="or:dynamic">		<address or:origin="or:dynamic">
	<ip>2001:db8::1:100</ip>		<ip>2001:db8::1:100</ip>
	<prefix-length>32</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	</interface>		</interface>
	<interface or:origin="or:system">		<interface or:origin="or:system">
	<name>lo0</name>		<name>lo0</name>
	<address>		<address>
	<ip>::1</ip>		<ip>::1</ip>
	<prefix-length>128</prefix-length>		<prefix-length>128</prefix-length>
	</address>		</address>
	</interface>		</interface>
	skipping to change at page 31, line 11 ¶		skipping to change at page 32, line 11 ¶
	the operational view, this means that every peer will have values for		the operational view, this means that every peer will have values for
	their local-as and peer-as, even if those values are not explicitly		their local-as and peer-as, even if those values are not explicitly
	configured but are provided by bgp/local-as and bgp/peer-as.		configured but are provided by bgp/local-as and bgp/peer-as.
	Each BGP peer has a TCP connection associated with it, using the		Each BGP peer has a TCP connection associated with it, using the
	values of local-port and remote-port from <intended>. If those		values of local-port and remote-port from <intended>. If those
	values are not supplied, the system will select values. When the		values are not supplied, the system will select values. When the
	connection is established, <operational> will contain the current		connection is established, <operational> will contain the current
	values for the local-port and remote-port nodes regardless of the		values for the local-port and remote-port nodes regardless of the
	origin. If the system has chosen the values, the "origin" attribute		origin. If the system has chosen the values, the "origin" attribute
	will be set to "operational". Before the connection is established,		will be set to "system". Before the connection is established, one
	one or both of the nodes may not appear, since the system may not yet		or both of the nodes may not appear, since the system may not yet
	have their values.		have their values.
	<bgp origin="or:intended" xmlns="urn:example:bgp">		<bgp origin="or:intended" xmlns="urn:example:bgp">
	<local-as origin="or:intended">64642</local-as>		<local-as origin="or:intended">64642</local-as>
	<peer-as origin="or:intended">65000</peer-as>		<peer-as origin="or:intended">65000</peer-as>
	<peer origin="or:intended">		<peer origin="or:intended">
	<name origin="or:intended">10.1.2.3</name>		<name origin="or:intended">10.1.2.3</name>
	<local-as origin="or:default">64642</local-as>		<local-as origin="or:default">64642</local-as>
	<peer-as origin="or:default">65000</peer-as>		<peer-as origin="or:default">65000</peer-as>
	<local-port origin="or:system">60794</local-port>		<local-port origin="or:system">60794</local-port>
	skipping to change at page 32, line 12 ¶		skipping to change at page 33, line 12 ¶
	with the "origin" attribute set to indicate the origin of the		with the "origin" attribute set to indicate the origin of the
	original data.		original data.
	<bgp origin="or:intended">		<bgp origin="or:intended">
	<local-as origin="or:intended">64642</local-as>		<local-as origin="or:intended">64642</local-as>
	<peer-as origin="or:intended">65000</peer-as>		<peer-as origin="or:intended">65000</peer-as>
	<peer origin="or:intended">		<peer origin="or:intended">
	<name origin="or:intended">10.1.2.3</name>		<name origin="or:intended">10.1.2.3</name>
	<local-as origin="or:default">64642</local-as>		<local-as origin="or:default">64642</local-as>
	<peer-as origin="or:default">65000</peer-as>		<peer-as origin="or:default">65000</peer-as>
	<local-port origin="or:intended">60794</local-port>		<local-port origin="or:system">60794</local-port>
	<remote-port origin="or:intended">179</remote-port>		<remote-port origin="or:default">179</remote-port>
	</peer>		</peer>
	</bgp>		</bgp>
	Once resources are released and the connection is closed, the peer's		Once resources are released and the connection is closed, the peer's
	data is removed from <operational>.		data is removed from <operational>.
	C.3. Interface Example		C.3. Interface Example
	In this section, we'll use this simple interface data model:		In this section, we'll use this simple interface data model:
	skipping to change at page 34, line 35 ¶		skipping to change at page 35, line 35 ¶
	Phil Shafer		Phil Shafer
	Juniper Networks		Juniper Networks
	Email: phil@juniper.net		Email: phil@juniper.net
	Kent Watsen		Kent Watsen
	Juniper Networks		Juniper Networks
	Email: kwatsen@juniper.net		Email: kwatsen@juniper.net
	Rob Wilton		Robert Wilton
	Cisco Systems		Cisco Systems
	Email: rwilton@cisco.com		Email: rwilton@cisco.com
End of changes. 24 change blocks.
	55 lines changed or deleted		128 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/