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/