draft-ietf-opsawg-operations-and-management-02.txt   draft-ietf-opsawg-operations-and-management-03.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies USA Internet-Draft Huawei Technologies USA
Intended status: Best Current December 17, 2007 Intended status: Best Current February 25, 2008
Practice Practice
Expires: June 19, 2008 Expires: August 28, 2008
Guidelines for Considering Operations and Management of New Protocols Guidelines for Considering Operations and Management of New Protocols
draft-ietf-opsawg-operations-and-management-02 draft-ietf-opsawg-operations-and-management-03
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 June 19, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
New protocols or protocol extensions are best designed with due New protocols or protocol extensions are best designed with due
consideration of functionality needed to operate and manage the consideration of functionality needed to operate and manage the
protocol. Retrofitting operations and management is sub-optimal. protocol. Retrofitting operations and management is sub-optimal.
The purpose of this document is to provide guidance to authors and The purpose of this document is to provide guidance to authors and
reviewers of documents defining new protocols or protocol extensions, reviewers of documents defining new protocols or protocol extensions,
covering aspects of operations and management that should be covering aspects of operations and management that should be
considered. considered.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design for Operations and Management . . . . . . . . . . . . . 4 2. Design for Operations and Management . . . . . . . . . . . . . 4
2.1. IETF Management Framework . . . . . . . . . . . . . . . . 4 2.1. IETF Management Framework . . . . . . . . . . . . . . . . 4
3. Operational Considerations . . . . . . . . . . . . . . . . . . 5 3. Operational Considerations . . . . . . . . . . . . . . . . . . 5
3.1. Operations Model . . . . . . . . . . . . . . . . . . . . . 6 3.1. Operations Model . . . . . . . . . . . . . . . . . . . . . 6
3.2. Installation and Initial Setup . . . . . . . . . . . . . . 7 3.2. Installation and Initial Setup . . . . . . . . . . . . . . 7
3.3. Migration Path . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Migration Path . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Requirements on Other Protocols and Functional 3.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 7 Components . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Impact on Network Operation . . . . . . . . . . . . . . . 8 3.5. Impact on Network Operation . . . . . . . . . . . . . . . 8
3.6. Verifying Correct Operation . . . . . . . . . . . . . . . 9 3.6. Verifying Correct Operation . . . . . . . . . . . . . . . 10
4. Management Considerations . . . . . . . . . . . . . . . . . . 9 4. Management Considerations . . . . . . . . . . . . . . . . . . 10
4.1. Interoperability . . . . . . . . . . . . . . . . . . . . . 10 4.1. Interoperability . . . . . . . . . . . . . . . . . . . . . 11
4.2. Management Information . . . . . . . . . . . . . . . . . . 12 4.2. Management Information . . . . . . . . . . . . . . . . . . 13
4.3. Fault Management . . . . . . . . . . . . . . . . . . . . . 13 4.3. Fault Management . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Liveness Detection and Monitoring . . . . . . . . . . 13 4.3.1. Liveness Detection and Monitoring . . . . . . . . . . 14
4.3.2. Fault Determination . . . . . . . . . . . . . . . . . 14 4.3.2. Fault Determination . . . . . . . . . . . . . . . . . 14
4.3.3. Fault Isolation . . . . . . . . . . . . . . . . . . . 14 4.3.3. Fault Isolation . . . . . . . . . . . . . . . . . . . 15
4.3.4. Corrective Action . . . . . . . . . . . . . . . . . . 14 4.3.4. Corrective Action . . . . . . . . . . . . . . . . . . 15
4.4. Configuration Management . . . . . . . . . . . . . . . . . 14 4.4. Configuration Management . . . . . . . . . . . . . . . . . 15
4.4.1. Verifying Correct Operation . . . . . . . . . . . . . 16 4.4.1. Verifying Correct Operation . . . . . . . . . . . . . 17
4.4.2. Control of Function and Policy . . . . . . . . . . . . 16 4.4.2. Control of Function and Policy . . . . . . . . . . . . 17
4.5. Accounting Management . . . . . . . . . . . . . . . . . . 16 4.5. Accounting Management . . . . . . . . . . . . . . . . . . 17
4.6. Performance Management . . . . . . . . . . . . . . . . . . 17 4.6. Performance Management . . . . . . . . . . . . . . . . . . 18
4.7. Security Management . . . . . . . . . . . . . . . . . . . 18 4.7. Security Management . . . . . . . . . . . . . . . . . . . 19
5. Documentation Guidelines . . . . . . . . . . . . . . . . . . . 20 5. Documentation Guidelines . . . . . . . . . . . . . . . . . . . 20
5.1. Recommended Discussions . . . . . . . . . . . . . . . . . 20 5.1. Recommended Discussions . . . . . . . . . . . . . . . . . 21
5.2. Null Manageability Considerations Sections . . . . . . . . 20 5.2. Null Manageability Considerations Sections . . . . . . . . 21
5.3. Placement of Operations and Manageability 5.3. Placement of Operations and Manageability
Considerations Sections . . . . . . . . . . . . . . . . . 21 Considerations Sections . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. Informative References . . . . . . . . . . . . . . . . . . . . 21 9. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Operations and Management Checklist . . . . . . . . . 25 Appendix A. Review Checklist . . . . . . . . . . . . . . . . . . 25
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 25 A.1. General Document Checklist . . . . . . . . . . . . . . . . 25
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 26 A.2. Operations and Management Checklist . . . . . . . . . . . 26
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Often when new protocols or protocol extensions are developed, not Often when new protocols or protocol extensions are developed, not
enough consideration is given to how the protocol will be deployed, enough consideration is given to how the protocol will be deployed,
operated and managed. Retrofitting operations and management operated and managed. Retrofitting operations and management
mechanisms is often hard and architecturally unpleasant, and certain mechanisms is often hard and architecturally unpleasant, and certain
protocol design choices may make deployment, operations, and protocol design choices may make deployment, operations, and
management particularly hard. Since the ease of operations and management particularly hard. Since the ease of operations and
management may impact the success of IETF protocols, this document management may impact the success of IETF protocols, this document
skipping to change at page 3, line 35 skipping to change at page 3, line 35
This document discusses the importance of considering operations and This document discusses the importance of considering operations and
management. Section 3 discusses operational functionality to management. Section 3 discusses operational functionality to
consider. Section 4 discusses management functionality to consider. consider. Section 4 discusses management functionality to consider.
This document sets forth a list of subjective guidelines and a list This document sets forth a list of subjective guidelines and a list
of objective criteria by which a protocol designer can evaluate of objective criteria by which a protocol designer can evaluate
whether the protocol that he/she has developed addresses common whether the protocol that he/she has developed addresses common
operations and management needs. Operations and management is highly operations and management needs. Operations and management is highly
dependent on the environment in which it is used, so most guidelines dependent on the environment in which it is used, so most guidelines
are subjective rather than objective. We provide objective criteria are subjective rather than objective.
to promote interoperability through the use of standard management
interfaces, such as "did you design counters in a MIB module for
monitoring packets in/out of an interface?", "did you write an XML-
based data model for configuring your protocol with Netconf?", and
"did you standardize syslog message content and structured data
elements for reporting events that might occur when operating your
protocol?"
This document only provides guidelines; the (ever-changing membership We provide some objective criteria to promote interoperability
of the) IESG can make a decision about how the guidelines should be through the use of standard management interfaces, such as "did you
used by the IETF over time. design counters in a MIB module for monitoring packets in/out of an
interface?" [RFC2863], "did you write an XML-based data model for
configuring your protocol with Netconf?" [RFC4741], and "did you
standardize syslog message content and structured data elements for
reporting events that might occur when operating your protocol?"
[I-D.ietf-syslog-protocol]
This document only provides guidelines; it does not specify how the
guidelines provided should be used within the IETF.
1.1. Terminology 1.1. Terminology
This document deliberately does not use the (capitalized) key words This document deliberately does not use the (capitalized) key words
described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must
only be used where it is actually required for interoperation or to only be used where it is actually required for interoperation or to
limit behavior which has potential for causing harm (e.g., limiting limit behavior which has potential for causing harm (e.g., limiting
retransmissions). For example, they must not be used to try to retransmissions). For example, they must not be used to try to
impose a particular method on implementers where the method is not impose a particular method on implementers where the method is not
required for interoperability. This document is a set of guidelines required for interoperability. This document is a set of guidelines
skipping to change at page 5, line 16 skipping to change at page 5, line 17
related to configuration of IP-based networks. One output was related to configuration of IP-based networks. One output was
"Requirements for Configuration Management of IP-based Networks" "Requirements for Configuration Management of IP-based Networks"
[RFC3139]. [RFC3139].
In 2003, the Internet Architecture Board (IAB) held a workshop on In 2003, the Internet Architecture Board (IAB) held a workshop on
Network Management [RFC3535] that discussed the strengths and Network Management [RFC3535] that discussed the strengths and
weaknesses of some IETF network management protocols, and compared weaknesses of some IETF network management protocols, and compared
them to operational needs, especially configuration. them to operational needs, especially configuration.
One factor discussed was the user-unfriendliness of the binary format One factor discussed was the user-unfriendliness of the binary format
of SNMP and COPS-PR, and it was recommended that the IETF explore an of SNMP and COPS-PR [RFC3084], and it was recommended that the IETF
XML-based Structure of Management Information, and an XML-based explore an XML-based Structure of Management Information, and an XML-
protocol for configuration. based protocol for configuration.
Another factor discussed was that deployed tools for event/alarm Another factor discussed was that deployed tools for event/alarm
correlation, root cause analysis and logging are not sufficient, and correlation, root cause analysis and logging are not sufficient, and
there is a need to support a human interface and a programmatic there is a need to support a human interface and a programmatic
interface. The IETF decided to standardize aspects of the defacto interface. The IETF decided to standardize aspects of the defacto
standard for system logging, especially security and the need for standard for system logging, especially security and the need for
better programmatic support. better programmatic support.
In 2006, the IETF discussed whether the Management Framework should In 2006, the IETF discussed whether the Management Framework should
be updated to accommodate multiple IETF standard SMI languages, and be updated to accommodate multiple IETF standard SMI languages, and
skipping to change at page 5, line 40 skipping to change at page 5, line 41
This document provides some initial guidelines for considering This document provides some initial guidelines for considering
operations and management in this environment of multiple protocols operations and management in this environment of multiple protocols
and multiple data models, with an eye toward being flexible while and multiple data models, with an eye toward being flexible while
also striving for interoperability. also striving for interoperability.
3. Operational Considerations 3. Operational Considerations
Designers of a new protocol should carefully consider the operational Designers of a new protocol should carefully consider the operational
aspects. A protocol that is defined very precisely in a well-written aspects. A protocol that is defined very precisely in a well-written
document doesn't guarantee that it is going to be deployable in the document does not guarantee that it is going to be deployable in the
real world. Operational aspects will have a serious impact on the real world. Operational aspects will have a serious impact on the
actual success of a protocol. Such aspects include bad interactions actual success of a protocol. Such aspects include bad interactions
with existing solutions, a dififcult ugrade path, difficulty of with existing solutions, a difficult upgrade path, difficulty of
debugging problems, difficulty configuring from a central database, debugging problems, difficulty configuring from a central database,
or a complicated state diagram that operations staff will find or a complicated state diagram that operations staff will find
difficult to understand difficult to understand
BGP flap damping [RFC2439] is an example. It was designed to block
high frequency route flaps, however the design did not consider the
existence of BGP path exploration/slow convergence. In real
operations, people observed the loss of reach-ability due to false
flap damping that are caused by path exploration. As a result, most
places turned flap damping off. RIPE even issued official
recommendation for turning it off.
[DISCUSS: examples, list of current protocols characteristics and [DISCUSS: examples, list of current protocols characteristics and
their impact on the network. e.g., burst traffic impact on network their impact on the network. e.g., burst traffic impact on network
congestion.] congestion.]
Operations and manageability considerations should focus on
interoperability of externally observable behaviors. [TODO: expand
or eliminate.]
3.1. Operations Model 3.1. Operations Model
Protocol designers can analyze the operational environment and mode Protocol designers can analyze the operational environment and mode
of work in which the new protocol or extension will work. Such an of work in which the new protocol or extension will work. Such an
exercise needs not be reflected directly by text in their document, exercise needs not be reflected directly by text in their document,
but could help in visualizing the operational model related to the but could help in visualizing the operational model related to the
applicability of the protocol in the Internet environments where it applicability of the protocol in the Internet environments where it
will be deployed. The operational model should take into account will be deployed. The operational model should take into account
factors such as: factors such as:
skipping to change at page 6, line 48 skipping to change at page 7, line 6
server and/or using distributed management functionality might make server and/or using distributed management functionality might make
more sense. Auto-configuration and default parameters might be more sense. Auto-configuration and default parameters might be
possible for some new protocols. possible for some new protocols.
There may be a need to support a human interface, e.g., for There may be a need to support a human interface, e.g., for
troubleshooting, and a programmatic interface, e.g., for automated troubleshooting, and a programmatic interface, e.g., for automated
monitoring and root cause analysis. It might be important that the monitoring and root cause analysis. It might be important that the
internal method routines used by the application programming internal method routines used by the application programming
interfaces and the human interfaces should be the same to ensure that interfaces and the human interfaces should be the same to ensure that
data exchanged between these two interfaces is always consistent. data exchanged between these two interfaces is always consistent.
[DISCUSS: would the example of inconsistency between non-resettable [DISCUSS: would the example of inconsistency between MIB counters
MIB counters and CLI resettable counters be useful here? ] that cannot be reset and CLI counters that can be rest be useful
here? ]
Protocol designers should consider what management operations are Protocol designers should consider what management operations are
expected to be performed as a result of the deployment of the expected to be performed as a result of the deployment of the
protocol - such as whether write operations will be allowed on protocol - such as whether write operations will be allowed on
routers and on hosts, or if notifications for alarms or other events routers and on hosts, or if notifications for alarms or other events
will be expected. will be expected.
3.2. Installation and Initial Setup 3.2. Installation and Initial Setup
Protocol designers should consider default values that make protocol Protocol designers should consider default values that make protocol
skipping to change at page 7, line 27 skipping to change at page 7, line 34
least an indication that known default values are being used. least an indication that known default values are being used.
Protocol designers should consider how to enable operators to Protocol designers should consider how to enable operators to
concentrate on the configuration of the network as a whole rather concentrate on the configuration of the network as a whole rather
than individual devices. than individual devices.
It is also desirable to discuss the background of chosen default It is also desirable to discuss the background of chosen default
values, or perhaps why a range of values makes sense. In many cases, values, or perhaps why a range of values makes sense. In many cases,
when technology changes, the values in an RFC might make less and when technology changes, the values in an RFC might make less and
less sense (for example due to increased speeds in the network). It less sense (for example due to increased speeds in the network). It
is very useful to understand whether defaults are based on 'best is very useful to understand whether defaults are based on best
current practice' and are expected to change as technologies advance current practice and are expected to change as technologies advance
or whether they have a more universal value and should not be changed or whether they have a more universal value and should not be changed
lightly. lightly.
it is extremely important to set a sensible default value for all
parameters
the default value should stay on the conservative side rather than
on the "optimizing performance" side. (example: the initial RTT
and RTTvar values of a TCP connection)
for those parameters that are speed-dependent, instead of using a
constant, try to set the default value as a function of the link
speed or some other relevant factors. This would help reduce the
chance of technology-advancement causing problems.
3.3. Migration Path 3.3. Migration Path
If the new protocol is a new version of the protocol, or is replacing If the new protocol is a new version of an existing protocol, or is
another technology, the protocol designer should consider how replacing another technology, the protocol designer should consider
deployments should transition to the new protocol. This should how deployments should transition to the new protocol. This should
include co-existence with previously deployed protocols and/or include co-existence with previously deployed protocols and/or
previous versions of the same protocol, incompatibilities between previous versions of the same protocol, incompatibilities between
versions, translation between versions, and side effects that might versions, translation between versions, and side effects that might
occur. Are older protocols or versions disabled or do they co-exist occur. Are older protocols or versions disabled or do they co-exist
in the network with the new protocol? in the network with the new protocol?
Another point to consider is extensibility of the management approach Another point to consider is extensibility of the management approach
- How open to future protocol extensions are the management - How open to future protocol extensions are the management
techniques you are defining? techniques you are defining?
3.4. Requirements on Other Protocols and Functional Components 3.4. Requirements on Other Protocols and Functional Components
Protocol designers should consider the requirements that the new Protocol designers should consider the requirements that the new
protocol might put on other protocols and functional components, and protocol might put on other protocols and functional components, and
should also document the requirements from other protocols that have should also document the requirements from other protocols that have
been considered in designing the new protocol. [TODO: examples] been considered in designing the new protocol.
These considerations should generally remain illustrative to avoid These considerations should generally remain illustrative to avoid
creating restrictions or dependencies, or potentially impacting the creating restrictions or dependencies, or potentially impacting the
behavior of existing protocols, or restricting the extensibility of behavior of existing protocols, or restricting the extensibility of
other protocols, or assuming other protocols will not be extended in other protocols, or assuming other protocols will not be extended in
certain ways. [TODO: example] certain ways.
For example, when RSVP [RFC2205] was designed, each router looked at
the RSVP PATH message, and if the router understood RSVP, it would
adds its own address to the message to enable automatically tunneling
thru non-RSVP routers. But in reality routers cannot look at an
otherwise normal IP packet, and potentially take it off the fast
path! The initial designers overlooked that a new requirement was
being put on the functional components of a router. The "router
alert" option was finally developed to solve this problem for RSVP
and other protocols that require the router take some packets off the
fast forwarding path.
3.5. Impact on Network Operation 3.5. Impact on Network Operation
The introduction of a new protocol or extensions to an existing The introduction of a new protocol or extensions to an existing
protocol may have an impact on the operation of existing networks. protocol may have an impact on the operation of existing networks.
Protocol designers should outline such impacts (which may be Protocol designers should outline such impacts (which may be
positive) including scaling concerns and interactions with other positive) including scaling concerns and interactions with other
protocols. For example, a new protocol that doubles the number of protocols. For example, a new protocol that doubles the number of
active, reachable addresses in use within a network might need to be active, reachable addresses in use within a network might need to be
considered in the light of the impact on the scalability of the IGPs considered in the light of the impact on the scalability of the IGPs
skipping to change at page 8, line 32 skipping to change at page 9, line 15
The protocol designer should consider the potential impact on the The protocol designer should consider the potential impact on the
behavior of other protocols in the network and on the traffic levels behavior of other protocols in the network and on the traffic levels
and traffic patterns that might change, including specific types of and traffic patterns that might change, including specific types of
traffic such as multicast. Also consider the need to install new traffic such as multicast. Also consider the need to install new
components that are added to the network as result of the changes in components that are added to the network as result of the changes in
the operational model, such as servers performing auto-configuration the operational model, such as servers performing auto-configuration
operations. operations.
The protocol designer should consider also the impact on The protocol designer should consider also the impact on
infrastructure applications like the DNS, registries, or the size of infrastructure applications like the DNS [RFC1034], registries, or
routing tables. the size of routing tables. For example, SMTP [RFC2821] servers use
a reverse DNS lookup to filter out incoming connection requests.
When Berkeley installed a new spam filter, their mail server stopped
functioning because of the DNS cache resolver overload.
The impact on performance may also be noted - increased delay or The impact on performance may also be noted - increased delay or
jitter in real-time traffic applications, or response time in client- jitter in real-time traffic applications, or response time in client-
server applications when encryption or filtering are applied. server applications when encryption or filtering are applied.
It must be easy to do consistency checks of versions/revisions of It must be easy to do consistency checks of versions/revisions of
configurations over time. [DISCUSS: probably needs a bit more configurations over time. People tend to be lazy and change
discussion on database driven configurations. ] configuration on routers but not update the database. A system
better mandate database-driven configuration to reduce configuration
errors/ inconsistencies. [DISCUSS: is this paragraph really about
protocol design for operability or about operational practice? If
this stays, it probably needs a bit more discussion on database
driven configurations, and how protocol design would be impacted by
the expectation of database-driven configuration. ]
It must be easy to do consistency checks of configurations between It must be easy to do consistency checks of configurations between
the ends of a link in order to determine the differences between two the ends of a link in order to determine the differences between two
configurations and whether the configurations are consistent. configurations and whether the configurations are consistent.
[DISCUSS: this needs rewording to better describe consistency [DISCUSS: this needs rewording to better describe consistency
checking 1) over time, and 2) between ends of a link. probably needs checking 1) over time, and 2) between ends of a link. probably needs
a bit more discussion on the need to be able to understand and check a bit more discussion on the need to be able to understand and check
what it is happening on the wire actually matches what the Operator what it is happening on the wire actually matches what the Operator
tried to configure. Basically, complexity is your enemy here, and tried to configure. Basically, complexity is your enemy here, and
that cannot be stressed often enough (no idea how you can verify that cannot be stressed often enough (no idea how you can verify
whether for example a SIP application is actually doing what it is whether for example a SIP application is actually doing what it is
supposed to do due to it's complexity).] supposed to do due to the complexity).]
It is important to minimize the impact caused by configuration It is important to minimize the impact caused by configuration
changes. Given configuration A and configuration B, it should be changes. Given configuration A and configuration B, it should be
possible to generate the operations necessary to get from A to B with possible to generate the operations necessary to get from A to B with
minimal state changes and effects on network and systems. minimal state changes and effects on network and systems.
3.6. Verifying Correct Operation 3.6. Verifying Correct Operation
The protocol designer should consider techniques for testing the The protocol designer should consider techniques for testing the
effect that the protocol has had on the network by sending data effect that the protocol has had on the network by sending data
skipping to change at page 9, line 35 skipping to change at page 10, line 28
operational model, which includes identifying the entities to be operational model, which includes identifying the entities to be
managed, how the respective protocol is supposed to be installed, managed, how the respective protocol is supposed to be installed,
configured and monitored, who are the managers and what type of configured and monitored, who are the managers and what type of
management interfaces and protocols they would use. management interfaces and protocols they would use.
Considerations for management should include a discussion of what Considerations for management should include a discussion of what
needs to be managed, and how to achieve various management tasks. needs to be managed, and how to achieve various management tasks.
The "write a MIB module" approach to considering management often The "write a MIB module" approach to considering management often
focuses on monitoring a protocol endpoint on a single device. A MIB focuses on monitoring a protocol endpoint on a single device. A MIB
module document typically only considers monitoring properties module document typically only considers monitoring properties
observable at one end, while the document doesn't really cover observable at one end, while the document does not really cover
managing the *protocol* (the coordination of multiple ends), and managing the *protocol* (the coordination of multiple ends), and does
doesn't even come near managing the *service* (which includes a lot not even come near managing the *service* (which includes a lot of
of stuff that's very far away from the box). This is exactly what stuff that is very far away from the box). This is exactly what
operators hate - you need to be able to manage both ends. As RFC3535 operators hate - you need to be able to manage both ends. As
says, MIB modules can often be characterized as a list of ingredients [RFC3535] says, MIB modules can often be characterized as a list of
without a recipe. ingredients without a recipe.
WGs should consider how to configure multiple related/co-operating WGs should consider how to configure multiple related/co-operating
devices and how to back off if one of those configurations fails or devices and how to back off if one of those configurations fails or
causes trouble. NETCONF addresses this ina generic manner by causes trouble. NETCONF addresses this ina generic manner by
allowing an operator to lock the configuration on multiple devices, allowing an operator to lock the configuration on multiple devices,
perform the configuration settings/changes, check that they are OK perform the configuration settings/changes, check that they are OK
(undo if not) and then unlock the devices. (undo if not) and then unlock the devices.
Techniques for debugging protocol interactions in a network should be Techniques for debugging protocol interactions in a network should be
part of the network management discussion. Implementation source part of the network management discussion. Implementation source
code should be debugged before ever being added to a network, so code should be debugged before ever being added to a network, so
asserts and memory dumps do not normally belong in management data asserts and memory dumps do not normally belong in management data
models. However, debugging on-the-wire interactions is a protocol models. However, debugging on-the-wire interactions is a protocol
issue: it is enormously helpful if a protocol has hooks to make issue: it is enormously helpful if a protocol has hooks to make
debugging of network interactions easy, and/or is designed in such a debugging of network interactions easy, and/or is designed in such a
way that debugging protocol behaviors is easy. Handwaving this away way that debugging protocol behaviors is easy. Hand-waving this away
is not something that operators like ... is not something that operators like ...
In a client/server protocol, it may be more important to instrument In a client/server protocol, it may be more important to instrument
the server end of a protocol than the client end. the server end of a protocol than the client end.
4.1. Interoperability 4.1. Interoperability
Just as when deploying protocols that will inter-connect devices, our Just as when deploying protocols that will inter-connect devices, our
primary goal in considering management should be interoperability, primary goal in considering management should be interoperability,
whether across devices from different vendors, across models from the whether across devices from different vendors, across models from the
skipping to change at page 10, line 40 skipping to change at page 11, line 33
office small business, but when, say, a fast food company installs office small business, but when, say, a fast food company installs
similar switches from multiple vendors in hundreds or thousands of similar switches from multiple vendors in hundreds or thousands of
individual branches and wants to automate monitoring them from a individual branches and wants to automate monitoring them from a
central location, monitoring vendor-and-model-specific web pages central location, monitoring vendor-and-model-specific web pages
would be difficult to automate. would be difficult to automate.
Getting everybody to agree on a certain syntax and the protocol Getting everybody to agree on a certain syntax and the protocol
associated with that has proven to be difficult. So management associated with that has proven to be difficult. So management
systems tend to speak whatever the boxes support, whether the IETF systems tend to speak whatever the boxes support, whether the IETF
likes this or not. The IETF is moving from support for a single likes this or not. The IETF is moving from support for a single
management data modeling language (SMI) and a single management management data modeling language (SMI [RFC2578]) and a single
protocol (SNMP) towards support for additional management protocols management protocol (SNMP [RFC3410]) towards support for additional
and data models suited to different purposes, such as configuration management protocols and data models suited to different purposes,
(netconf), usage accounting (ipfix), and logging (syslog). Other such as configuration (netconf [RFC4741]), usage accounting (ipfix
Standard Development Organizations (e.g. DMTF, TMF) also define [I-D.ietf-ipfix-protocol]), and logging (syslog
management mechanisms and these mechanisms may be more suitable than [I-D.ietf-syslog-protocol])). Other Standard Development
IETF mechanisms in some cases. Organizations (e.g. DMTF, TMF) also define management mechanisms and
these mechanisms may be more suitable than IETF mechanisms in some
cases.
Interoperability needs to be considered on the syntactic level and Interoperability needs to be considered on the syntactic level and
the semantic level. While it can be irritating and time-consuming, the semantic level. While it can be irritating and time-consuming,
application designers including operators who write their own scripts application designers including operators who write their own scripts
can make their processing conditional to accommodate differences can make their processing conditional to accommodate differences
across vendors or models or releases of product. across vendors or models or releases of product.
Semantic differences are much harder to deal with on the manager side Semantic differences are much harder to deal with on the manager side
- once you have the data, its meaning is a function of the managed - once you have the data, its meaning is a function of the managed
entity. For example, if a single counter provided by vendor A counts entity. For example, if a single counter provided by vendor A counts
skipping to change at page 13, line 39 skipping to change at page 14, line 34
4.3.1. Liveness Detection and Monitoring 4.3.1. Liveness Detection and Monitoring
Liveness detection and monitoring applies both to the control plane Liveness detection and monitoring applies both to the control plane
and the data plane. Mechanisms for detecting faults in the control and the data plane. Mechanisms for detecting faults in the control
plane or for monitoring its liveness are usually built into the plane or for monitoring its liveness are usually built into the
control plane protocols or inherited from underlying data plane or control plane protocols or inherited from underlying data plane or
forwarding plane protocols. These mechanisms do not typically forwarding plane protocols. These mechanisms do not typically
require additional management capabilities. However, when a system require additional management capabilities. However, when a system
detects a control plane fault, there is often a requirement to detects a control plane fault, there is often a requirement to
coordinate recovery action through management applications or at coordinate recovery action through management applications or at
least to record the fact in an event log. [TODO: example] least to record the fact in an event log. [DISCUSS: can somebody
provide an example?]
Where the protocol is responsible for establishing data or user plane Where the protocol is responsible for establishing data or user plane
connectivity, liveness detection and monitoring usually need to be connectivity, liveness detection and monitoring usually need to be
achieved through other mechanisms. In some cases, these mechanisms achieved through other mechanisms. In some cases, these mechanisms
already exist within other protocols responsible for maintaining already exist within other protocols responsible for maintaining
lower layer connectivity, but it will often be the case that new lower layer connectivity, but it will often be the case that new
procedures are required to detect failures in the data path and to procedures are required to detect failures in the data path and to
report rapidly, allowing remedial action to be taken. report rapidly, allowing remedial action to be taken.
Protocol designers should always build in basic testing features Protocol designers should always build in basic testing features
skipping to change at page 14, line 13 skipping to change at page 15, line 8
used to test for liveness, with an option to enable and disable them. used to test for liveness, with an option to enable and disable them.
4.3.2. Fault Determination 4.3.2. Fault Determination
It can be helpful to describe how faults can be pinpointed using It can be helpful to describe how faults can be pinpointed using
management information. For example, counters might record instances management information. For example, counters might record instances
of error conditions. Some faults might be able to be pinpointed by of error conditions. Some faults might be able to be pinpointed by
comparing the outputs of one device and the inputs of another device comparing the outputs of one device and the inputs of another device
looking for anomalies. looking for anomalies.
[DISCUSS: Ralf: While this sounds good, how do ou distinguish between [DISCUSS: Ralf: While this sounds good, how do you distinguish
"faulty messages" and "good messages"? It might require complex between faulty messages and good messages? It might require complex
functions such as "deviation from normal", are you sure you want to functions such as deviation from normal, are you sure you want to
implement those at the device level?] implement those at the device level?]
4.3.3. Fault Isolation 4.3.3. Fault Isolation
It might be useful to isolate faults, such as a system that emits It might be useful to isolate faults, such as a system that emits
malformed messages necessary to coordinate connections properly. malformed messages necessary to coordinate connections properly.
Spanning tree comes to mind. This might be able to be done by Spanning tree comes to mind. This might be able to be done by
configuring next-hop devices to drop the faulty messages to prevent configuring next-hop devices to drop the faulty messages to prevent
them from entering the rest of the network. them from entering the rest of the network.
skipping to change at page 14, line 41 skipping to change at page 15, line 36
[DISCUSS: this should be expanded or eliminated.] [DISCUSS: this should be expanded or eliminated.]
4.4. Configuration Management 4.4. Configuration Management
RFC3139 [RFC3139] discusses requirements for configuration RFC3139 [RFC3139] discusses requirements for configuration
management. This document includes discussion of different levels of management. This document includes discussion of different levels of
management, including high-level-policies, network-wide configuration management, including high-level-policies, network-wide configuration
data, and device-local configuration. data, and device-local configuration.
A number of efforts have existed in the IETF to develop policy-based A number of efforts have existed in the IETF to develop policy-based
management. RFC3198 was written to standardize the terminology for management. RFC3198 [RFC3198] was written to standardize the
policy-based management across these efforts. terminology for policy-based management across these efforts.
It is highly desirable that text processing tools such as diff, and It is highly desirable that text processing tools such as diff, and
version management tools such as RCS or CVS or SVN, can be used to version management tools such as RCS or CVS or SVN, can be used to
process configurations. This approach simplifies comparing the process configurations. This approach simplifies comparing the
current operational state to the initial configuration. current operational state to the initial configuration.
With structured text such as XML, simple text diffs may be found to With structured text such as XML, simple text diffs may be found to
be inadequate and more sophisticated tools may be needed to make any be inadequate and more sophisticated tools may be needed to make any
useful comparison of versions. useful comparison of versions.
To simplify such configuration comparisons, devices should not To simplify such configuration comparisons, devices should not
arbitrarily reorder data such as access control lists. If a protocol arbitrarily reorder data such as access control lists. If a protocol
designer defines mechanisms for configuration, it would be desirable designer defines mechanisms for configuration, it would be desirable
to standardize the order of elements for consistency of configuration to standardize the order of elements for consistency of configuration
and of reporting across vendors, and across releases from vendors. and of reporting across vendors, and across releases from vendors.
[DISCUSS: Ralf: Well, there are two parts to it: 1. An NMS system [DISCUSS: Ralf: Well, there are two parts to it: 1. An NMS system
could optimze ACLs for perfomance reasons 2. Unless the device/NMS could optimize ACLs for performance reasons 2. Unless the device/NMS
systems has corect rules/a lot of experience, reordering ACLs can systems has correct rules/a lot of experience, reordering ACLs can
lead to a huge security issue, therefore I would rephrase this lead to a huge security issue, therefore I would rephrase this
paragraph. " paragraph. "
Network wide configurations are ideally stored in central master Network wide configurations are ideally stored in central master
databases and transformed into formats that can be pushed to devices, databases and transformed into formats that can be pushed to devices,
either by generating sequences of CLI commands or complete either by generating sequences of CLI commands or complete
configuration files that are pushed to devices. There is no common configuration files that are pushed to devices. There is no common
database schema for network configuration, although the models used database schema for network configuration, although the models used
by various operators are probably very similar. It is desirable to by various operators are probably very similar. It is desirable to
extract, document, and standardize the common parts of these network extract, document, and standardize the common parts of these network
skipping to change at page 15, line 35 skipping to change at page 16, line 30
consider how to standardize the common parts of configuring the new consider how to standardize the common parts of configuring the new
protocol, while recognizing the vendors will likely have proprietary protocol, while recognizing the vendors will likely have proprietary
aspects of their configurations. aspects of their configurations.
It is important to distinguish between the distribution of It is important to distinguish between the distribution of
configurations and the activation of a certain configuration. configurations and the activation of a certain configuration.
Devices should be able to hold multiple configurations. NETCONF Devices should be able to hold multiple configurations. NETCONF
[RFC4741], for example, differentiates between the "running" [RFC4741], for example, differentiates between the "running"
configuration and "candidate" configurations. configuration and "candidate" configurations.
[DISCUSS: Also add: backup configs, i.e. version n-1 and auto- [DISCUSS: Also add: backup configurations, i.e. version n-1 and auto-
fallback solutions that automatically return to the previous "known fallback solutions that automatically return to the previous known
as good config" or adding a backdoor for the operator. One of the good configuration or adding a backdoor for the operator. One of the
worst scenarios is remote device config where the new running config worst scenarios is remote device configuration where the new running
doesn't work as expected and unlocks the admin. Vendors may have configuration does not work as expected and unlocks the admin.
ways to avoid unlocking the operator but this doesn't have to be Vendors may have ways to avoid unlocking the operator but this does
vendor specific.] not have to be vendor specific.]
It is important to enable operators to concentrate on the It is important to enable operators to concentrate on the
configuration of the network as a whole rather than individual configuration of the network as a whole rather than individual
devices. Support for configuration transactions across a number of devices. Support for configuration transactions across a number of
devices would significantly simplify network configuration devices would significantly simplify network configuration
management. The ability to distribute configurations to multiple management. The ability to distribute configurations to multiple
devices, or modify "candidate configurations on multiple devices, and devices, or modify "candidate configurations on multiple devices, and
then activate them in a near-simultaneous manner might help. then activate them in a near-simultaneous manner might help.
[DISCUSS: Ralf: This might be a good place for adding the description [DISCUSS: Ralf: This might be a good place for adding the description
of config-templates.] of configuration-templates.]
Consensus of the 2002 IAB Workshop was that textual configuration Consensus of the 2002 IAB Workshop was that textual configuration
files should be able to contain international characters. Human- files should be able to contain international characters. Human-
readable strings should utilize UTF-8, and protocol elements should readable strings should utilize UTF-8, and protocol elements should
be in case insensitive ASCII. be in case insensitive ASCII.
A mechanism to dump and restore configurations is a primitive A mechanism to dump and restore configurations is a primitive
operation needed by operators. Standards for pulling and pushing operation needed by operators. Standards for pulling and pushing
configurations from/to devices are desirable. configurations from/to devices are desirable.
Given configuration A and configuration B, it should be possible to Given configuration A and configuration B, it should be possible to
skipping to change at page 17, line 6 skipping to change at page 17, line 51
4.5. Accounting Management 4.5. Accounting Management
A protocol designer should consider whether it would be appropriate A protocol designer should consider whether it would be appropriate
to collect usage information related to this protocol, and if so, to collect usage information related to this protocol, and if so,
what usage information would be appropriate to collect? what usage information would be appropriate to collect?
RFC2975 [RFC2975] Introduction to Accounting Management discusses a RFC2975 [RFC2975] Introduction to Accounting Management discusses a
number of factors relevant to monitoring usage of protocols for number of factors relevant to monitoring usage of protocols for
purposes of capacity and trend analysis, cost allocation, auditing, purposes of capacity and trend analysis, cost allocation, auditing,
and billing. This document also discusses how RADIUS, TACACS+, and and billing. This document also discusses how RADIUS [RFC2865],
SNMP protocols are used for these purposes. These factors should be TACACS+ [RFC1492], and SNMP protocols are used for these purposes.
considered when designing a protocol whose usage might need to be These factors should be considered when designing a protocol whose
monitored, or when recommending a protocol to do usage accounting. usage might need to be monitored, or when recommending a protocol to
do usage accounting.
4.6. Performance Management 4.6. Performance Management
Consider information that would be useful when trying to determine Consider information that would be useful when trying to determine
the performance characteristics of a deployed system using the target the performance characteristics of a deployed system using the target
protocol. protocol.
What are the principal performance factors that need to be looked at What are the principal performance factors that need to be looked at
when measuring the efficiency of the protocol implementations? Is it when measuring the efficiency of the protocol implementations? Is it
important to measure setup times? throughput? quality versus important to measure setup times? throughput? quality versus
skipping to change at page 19, line 28 skipping to change at page 20, line 26
Protocol designers should consider how to provide a secure transport, Protocol designers should consider how to provide a secure transport,
authentication, identity, and access control which integrates well authentication, identity, and access control which integrates well
with existing key and credential management infrastructure. with existing key and credential management infrastructure.
Protocol designers should consider how ACLs (access control lists) Protocol designers should consider how ACLs (access control lists)
are maintained and updated. are maintained and updated.
Standard SNMP notifications or SYSLOG messages Standard SNMP notifications or SYSLOG messages
[I-D.ietf-syslog-protocol] might already exist, or can be defined, to [I-D.ietf-syslog-protocol] might already exist, or can be defined, to
alert operators to the conditions identified in the security alert operators to the conditions identified in the security
considerations for the new protocol. [TODO: find existing considerations for the new protocol. [DISCUSS: can somebody provide
notificiations or syslog messages related to security] an example of an existing notifications or syslog messages related to
security, other than SNMPv3-specific notifications?]
An analysis of existing counters might help operators recognize the An analysis of existing counters might help operators recognize the
conditions identified in the security considerations for the new conditions identified in the security considerations for the new
protocol before they can impact the network. protocol before they can impact the network.
RADIUS and DIAMETER can provide authentication and authorization. A RADIUS and DIAMETER can provide authentication and authorization. A
protocol designer should consider which attributes would be protocol designer should consider which attributes would be
appropriate for their protocol. appropriate for their protocol.
Different protocols use different assumptions about message security Different protocols use different assumptions about message security
skipping to change at page 20, line 16 skipping to change at page 21, line 10
The purpose of this document is to provide guidance about what to The purpose of this document is to provide guidance about what to
consider when thinking about the management and deployment of a new consider when thinking about the management and deployment of a new
protocol, and to provide guidance about documenting the protocol, and to provide guidance about documenting the
considerations. The following guidelines are designed to help considerations. The following guidelines are designed to help
writers provide a reasonably consistent format for such writers provide a reasonably consistent format for such
documentation. Separate manageability and operational considerations documentation. Separate manageability and operational considerations
sections are desirable in many cases, but their structure and sections are desirable in many cases, but their structure and
location is a decision that can be made from case to case. location is a decision that can be made from case to case.
We want to avoid seeming to impose a solution by putting in place a
strict terminology - for example implying that a formal data model,
or even using a management protocol is mandatory. If protocol
designers conclude that its technology can be managed solely by using
proprietary CLIs, and no structured or standardized data model needs
to be in place, this might be fine, but it is a decision that should
be explicit in a manageability discussion, that this is how the
protocol will need to be operated and managed. Protocol designers
should avoid having manageability pushed for a later/never phase of
the development of the standard.
Making a Management Considerations section a mandatory publication Making a Management Considerations section a mandatory publication
requirement is the responsibility of the IESG, or specific area requirement for IETF documents is the responsibility of the IESG, or
directors, or working groups, and this document avoids recommending specific area directors, or working groups, and this document avoids
any mandatory publication requirements. For a complex protocol, a recommending any mandatory publication requirements. For a complex
completely separate draft on operations and management might be protocol, a completely separate draft on operations and management
appropriate, or even a completely separate WG. might be appropriate, or even a completely separate WG effort.
This document is focused on what to think about, and how to document This document is focused on what to think about, and how to document
the considerations of the protocol designer. the considerations of the protocol designer.
5.1. Recommended Discussions 5.1. Recommended Discussions
A Manageability Considerations section should include discussion of A Manageability Considerations section should include discussion of
the management and operations topics raised in this document, and the management and operations topics raised in this document, and
when one or more of these topics is not relevant, it would be useful when one or more of these topics is not relevant, it would be useful
to contain a simple statement explaining why the topic is not to contain a simple statement explaining why the topic is not
relevant for the new protocol. Of course, additional relevant topics relevant for the new protocol. Of course, additional relevant topics
should be included as well. should be included as well.
Existing protocols and data models can provide the management
functions identified in the previous section. Protocol designers
should consider how using existing protocols and data models might
impact network operations.
5.2. Null Manageability Considerations Sections 5.2. Null Manageability Considerations Sections
A protocol designer may seriously consider the manageability A protocol designer may seriously consider the manageability
requirements of a new protocol, and determine that no management requirements of a new protocol, and determine that no management
functionality is needed by the new protocol. It would be helpful to functionality is needed by the new protocol. It would be helpful to
those who may update or write extensions to the protocol in the those who may update or write extensions to the protocol in the
future or to those deploying the new protocol to know the thinking of future or to those deploying the new protocol to know the thinking of
the working regarding the manageability of the protocol at the time the working regarding the manageability of the protocol at the time
of its design. of its design.
skipping to change at page 22, line 7 skipping to change at page 23, line 18
[I-D.ietf-ipfix-protocol] Claise, B., "Specification of the IPFIX [I-D.ietf-ipfix-protocol] Claise, B., "Specification of the IPFIX
Protocol for the Exchange of IP Traffic Protocol for the Exchange of IP Traffic
Flow Information", Flow Information",
draft-ietf-ipfix-protocol-26 (work in draft-ietf-ipfix-protocol-26 (work in
progress), September 2007. progress), September 2007.
[I-D.ietf-syslog-protocol] Gerhards, R., "The syslog Protocol", [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog Protocol",
draft-ietf-syslog-protocol-23 (work in draft-ietf-syslog-protocol-23 (work in
progress), September 2007. progress), September 2007.
[RFC1034] Mockapetris, P., "Domain names - concepts
and facilities", STD 13, RFC 1034,
November 1987.
[RFC1052] Cerf, V., "IAB recommendations for the [RFC1052] Cerf, V., "IAB recommendations for the
development of Internet network development of Internet network
management standards", RFC 1052, management standards", RFC 1052,
April 1988. April 1988.
[RFC1492] Finseth, C., "An Access Control Protocol,
Sometimes Called TACACS", RFC 1492,
July 1993.
[RFC2119] Bradner, S., "Key words for use in RFCs [RFC2119] Bradner, S., "Key words for use in RFCs
to Indicate Requirement Levels", BCP 14, to Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S.,
Herzog, S., and S. Jamin, "Resource
ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205,
September 1997.
[RFC2439] Villamizar, C., Chandra, R., and R.
Govindan, "BGP Route Flap Damping",
RFC 2439, November 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed.,
and J. Schoenwaelder, Ed., "Structure of and J. Schoenwaelder, Ed., "Structure of
Management Information Version 2 Management Information Version 2
(SMIv2)", STD 58, RFC 2578, April 1999. (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2821] Klensin, J., "Simple Mail Transfer
Protocol", RFC 2821, April 2001.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The [RFC2863] McCloghrie, K. and F. Kastenholz, "The
Interfaces Group MIB", RFC 2863, Interfaces Group MIB", RFC 2863,
June 2000. June 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and [RFC2865] Rigney, C., Willens, S., Rubens, A., and
W. Simpson, "Remote Authentication Dial W. Simpson, "Remote Authentication Dial
In User Service (RADIUS)", RFC 2865, In User Service (RADIUS)", RFC 2865,
June 2000. June 2000.
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, [RFC2975] Aboba, B., Arkko, J., and D. Harrington,
skipping to change at page 22, line 51 skipping to change at page 24, line 35
Reichmeyer, F., Yavatkar, R., and A. Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Smith, "COPS Usage for Policy
Provisioning (COPS-PR)", RFC 3084, Provisioning (COPS-PR)", RFC 3084,
March 2001. March 2001.
[RFC3139] Sanchez, L., McCloghrie, K., and J. [RFC3139] Sanchez, L., McCloghrie, K., and J.
Saperia, "Requirements for Configuration Saperia, "Requirements for Configuration
Management of IP-based Networks", Management of IP-based Networks",
RFC 3139, June 2001. RFC 3139, June 2001.
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., [RFC3198] Westerinen, A., Schnizlein, J.,
Chan, K., Hahn, S., Sahita, R., Smith, Strassner, J., Scherling, M., Quinn, B.,
A., and F. Reichmeyer, "Structure of Herzog, S., Huynh, A., Carlson, M.,
Policy Provisioning Information (SPPI)", Perry, J., and S. Waldbusser,
RFC 3159, August 2001. "Terminology for Policy-Based
Management", RFC 3198, November 2001.
[RFC3165] Levi, D. and J. Schoenwaelder,
"Definitions of Managed Objects for the
Delegation of Management Scripts",
RFC 3165, August 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and [RFC3290] Bernet, Y., Blake, S., Grossman, D., and
A. Smith, "An Informal Management Model A. Smith, "An Informal Management Model
for Diffserv Routers", RFC 3290, for Diffserv Routers", RFC 3290,
May 2002. May 2002.
[RFC3317] Chan, K., Sahita, R., Hahn, S., and K.
McCloghrie, "Differentiated Services
Quality of Service Policy Information
Base", RFC 3317, March 2003.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. [RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability Stewart, "Introduction and Applicability
Statements for Internet-Standard Statements for Internet-Standard
Management Framework", RFC 3410, Management Framework", RFC 3410,
December 2002. December 2002.
[RFC3413] Levi, D., Meyer, P., and B. Stewart,
"Simple Network Management Protocol
(SNMP) Applications", STD 62, RFC 3413,
December 2002.
[RFC3418] Presuhn, R., "Management Information Base
(MIB) for the Simple Network Management
Protocol (SNMP)", STD 62, RFC 3418,
December 2002.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the [RFC3444] Pras, A. and J. Schoenwaelder, "On the
Difference between Information Models and Difference between Information Models and
Data Models", RFC 3444, January 2003. Data Models", RFC 3444, January 2003.
[RFC3460] Moore, B., "Policy Core Information Model [RFC3460] Moore, B., "Policy Core Information Model
(PCIM) Extensions", RFC 3460, (PCIM) Extensions", RFC 3460,
January 2003. January 2003.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 [RFC3535] Schoenwaelder, J., "Overview of the 2002
IAB Network Management Workshop", IAB Network Management Workshop",
RFC 3535, May 2003. RFC 3535, May 2003.
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, [RFC3585] Jason, J., Rafalow, L., and E. Vyncke,
"IPsec Configuration Policy Information "IPsec Configuration Policy Information
Model", RFC 3585, August 2003. Model", RFC 3585, August 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E.,
Zorn, G., and J. Arkko, "Diameter Base
Protocol", RFC 3588, September 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., [RFC3644] Snir, Y., Ramberg, Y., Strassner, J.,
Cohen, R., and B. Moore, "Policy Quality Cohen, R., and B. Moore, "Policy Quality
of Service (QoS) Information Model", of Service (QoS) Information Model",
RFC 3644, November 2003. RFC 3644, November 2003.
[RFC3670] Moore, B., Durham, D., Strassner, J., [RFC3670] Moore, B., Durham, D., Strassner, J.,
Westerinen, A., and W. Weiss, Westerinen, A., and W. Weiss,
"Information Model for Describing Network "Information Model for Describing Network
Device QoS Datapath Mechanisms", Device QoS Datapath Mechanisms",
RFC 3670, January 2004. RFC 3670, January 2004.
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, [RFC3805] Bergman, R., Lewis, H., and I. McDonald,
"Printer MIB v2", RFC 3805, June 2004. "Printer MIB v2", RFC 3805, June 2004.
[RFC4011] Waldbusser, S., Saperia, J., and T. [RFC4741] Enns, R., "NETCONF Configuration
Hongal, "Policy Based Management MIB", Protocol", RFC 4741, December 2006.
RFC 4011, March 2005.
[RFC4133] Bierman, A. and K. McCloghrie, "Entity Appendix A. Review Checklist
MIB (Version 3)", RFC 4133, August 2005.
[RFC4502] Waldbusser, S., "Remote Network This appendix provides a quick summary of issues to consider.
Monitoring Management Information Base
Version 2", RFC 4502, May 2006.
[RFC4668] Nelson, D., "RADIUS Authentication Client A.1. General Document Checklist
MIB for IPv6", RFC 4668, August 2006.
[RFC4669] Nelson, D., "RADIUS Authentication Server Is the document readable?
MIB for IPv6", RFC 4669, August 2006.
[RFC4710] Siddiqui, A., Romascanu, D., and E. Does it contain nits?
Golovinsky, "Real-time Application
Quality-of-Service Monitoring (RAQMON)
Framework", RFC 4710, October 2006.
[RFC4741] Enns, R., "NETCONF Configuration Is the document class appropriate?
Protocol", RFC 4741, December 2006.
[RFC4825] Rosenberg, J., "The Extensible Markup Is the problem well stated?
Language (XML) Configuration Access Is the problem really a problem?
Protocol (XCAP)", RFC 4825, May 2007.
[RFC4930] Hollenbeck, S., "Extensible Provisioning Does the document consider existing solutions?
Protocol (EPP)", RFC 4930, May 2007.
Appendix A. Operations and Management Checklist Does the solution break existing technology?
This appendix provides a quick summary of issues to consider. Does the solution preclude future activity?
are configuration parameters clearly identified? Is the specification complete? Can multiple interoperable
implementations be built based on the specification?
are configuration parameters normalized? A.2. Operations and Management Checklist
does each configuration parameter have a reasonable default value? Is the proposed specification deployable? If not, how could it be
improved? Does the document include a description of the
operational model - how is this protocol or technology going to be
deployed and managed? will it use centralized or distributed
management? will it require remote and/or local management
applications?
is protocol state information exposed to the user? How? Is the solution sufficiently configurable? are configuration
parameters clearly identified? are configuration parameters
normalized? does each configuration parameter have a reasonable
default value? Will configuration be pushed to a device by a
configuration manager, or pulled by a device from a configuration
server? How will the devices and managers find and authenticate
each other?
is protocol performance information exposed to the user? How? Does the solution have failure modes that are difficult to
diagnose or correct? Are faults and alarms reported and logged?
are significant state transitions logged? is protocol state information exposed to the user? How? are
significant state transitions logged?
Appendix B. Open Issues Does the protocol have an impact on network traffic and network
devices? is protocol performance information exposed to the user?
Can performance be measured? Does the solution scale well? Does
the proposed approach have any scaling issues that could affect
usability for large scale operation?
[TODO: need to verify all citations have references (in xref Are there any backward compatibility issues?
format)]
[TODO: need to remove references that are not used in the Do you anticipate any manageability issues with the specification?
guidelines]
Does the specification introduce new potential security risks or
avenues for fraud?
Does the proposed protocol have a significant operational impact
on the Internet. If it does, and the document under review
targets standards track, is their enough proof of implementation
and/or operational experience to grant Proposed Standard status?
Appendix B. Open Issues
Identify bullets for appendix checklist Identify bullets for appendix checklist
Is section 2 needed? align checklist order and guidelines order
Is section 2 needed? it seems too management-centric.
Need more reviews and suggested text, especially on operational Need more reviews and suggested text, especially on operational
considerations considerations
[DISCUSS: How much of RFC 3535 and RFC 3139 should be repeated [DISCUSS: How much of RFC 3535 and RFC 3139 should be repeated
(and updated) in these guidelines? There are many best current (and updated) in these guidelines? There are many best current
practices mentioned in those documents. Should we bring them practices mentioned in those documents. Should we bring them
together into this document and expand on how they should together into this document and expand on how they should
influence ops/mgmt considerations for a new protocol? Many of the influence ops/mgmt considerations for a new protocol? Many of the
points relate to NM protocol design, but there are also many points relate to NM protocol design, but there are also many
points about operational and management considerations.] points about operational and management considerations.]
Appendix C. Change Log Appendix C. Change Log
Changes from opsawg-01 to opsawg-02 Changes from opsawg-02 to opsawg-03
From reviews by Lixia Zhang and feedback from WG Chairs' Lunch.
added discussion of impact on the Internet to checklist
spell check
added examples
added discussion of default values
added discussion of database-driven configuration
fixed some references
expanded the checklist
Changes from opsawg-01 to opsawg-02
moved survey of protocols and data models to separate document moved survey of protocols and data models to separate document
changed "working group" to "protocol designer" throughout, as changed "working group" to "protocol designer" throughout, as
applicable. applicable.
modified wording from negative to positive spin in places. modified wording from negative to positive spin in places.
updated based on comments from Ralf Wolter and David Kessens updated based on comments from Ralf Wolter and David Kessens
Changes from opsawg-00 to opsawg-01 Changes from opsawg-00 to opsawg-01
skipping to change at page 28, line 7 skipping to change at page 30, line 7
Plano, TX 75075 Plano, TX 75075
USA USA
Phone: +1 603 436 8634 Phone: +1 603 436 8634
Fax: Fax:
EMail: dharrington@huawei.com EMail: dharrington@huawei.com
URI: URI:
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 73 change blocks. 
175 lines changed or deleted 267 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/