draft-ietf-opsawg-operations-and-management-09.txt   rfc5706.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft HuaweiSymantec USA Request for Comments: 5706 HuaweiSymantec USA
Intended status: Informational September 10, 2009 Category: Informational November 2009
Expires: March 14, 2010
Guidelines for Considering Operations and Management of New Protocols
and Protocol Extensions
draft-ietf-opsawg-operations-and-management-09
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Guidelines for Considering Operations and Management of
Task Force (IETF), its areas, and its working groups. Note that New Protocols and Protocol Extensions
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Abstract
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at New protocols or protocol extensions are best designed with due
http://www.ietf.org/ietf/1id-abstracts.txt. consideration of the functionality needed to operate and manage the
protocols. Retrofitting operations and management is sub-optimal.
The purpose of this document is to provide guidance to authors and
reviewers of documents that define new protocols or protocol
extensions regarding aspects of operations and management that should
be considered.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 14, 2010. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Abstract This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
New protocols or protocol extensions are best designed with due RFC 5706 Ops and Mgmt Guidelines November 2009
consideration of functionality needed to operate and manage the
protocols. Retrofitting operations and management is sub-optimal. not be created outside the IETF Standards Process, except to format
The purpose of this document is to provide guidance to authors and it for publication as an RFC or to translate it into languages other
reviewers of documents defining new protocols or protocol extensions, than English.
about covering aspects of operations and management that should be
considered. RFC 5706 Ops and Mgmt Guidelines November 2009
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction ....................................................4
1.1. Designing for Operations and Management . . . . . . . . . 5 1.1. Designing for Operations and Management ....................4
1.2. This Document . . . . . . . . . . . . . . . . . . . . . . 5 1.2. This Document ..............................................5
1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Motivation .................................................5
1.4. Background . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Background .................................................6
1.5. Available Management Technologies . . . . . . . . . . . . 8 1.5. Available Management Technologies ..........................7
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Terminology ................................................8
2. Operational Considerations - How Will the New Protocol Fit 2. Operational Considerations - How Will the New Protocol
Into the Current Environment? . . . . . . . . . . . . . . . . 9 Fit into the Current Environment? ...............................8
2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. Operations .................................................9
2.2. Installation and Initial Setup . . . . . . . . . . . . . . 10 2.2. Installation and Initial Setup .............................9
2.3. Migration Path . . . . . . . . . . . . . . . . . . . . . . 11 2.3. Migration Path ............................................10
2.4. Requirements on Other Protocols and Functional 2.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 11 Components ................................................11
2.5. Impact on Network Operation . . . . . . . . . . . . . . . 12 2.5. Impact on Network Operation ...............................11
2.6. Verifying Correct Operation . . . . . . . . . . . . . . . 13 2.6. Verifying Correct Operation ...............................12
3. Management Considerations - How Will The Protocol be 3. Management Considerations - How Will the Protocol Be Managed? ..12
Managed? . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. Interoperability ..........................................14
3.1. Interoperability . . . . . . . . . . . . . . . . . . . . . 15 3.2. Management Information ....................................17
3.2. Management Information . . . . . . . . . . . . . . . . . . 18 3.2.1. Information Model Design ...........................18
3.2.1. Information Model Design . . . . . . . . . . . . . . . 19 3.3. Fault Management ..........................................18
3.3. Fault Management . . . . . . . . . . . . . . . . . . . . . 19 3.3.1. Liveness Detection and Monitoring ..................19
3.3.1. Liveness Detection and Monitoring . . . . . . . . . . 20 3.3.2. Fault Determination ................................19
3.3.2. Fault Determination . . . . . . . . . . . . . . . . . 20 3.3.3. Root Cause Analysis ................................20
3.3.3. Root Cause Analysis . . . . . . . . . . . . . . . . . 20 3.3.4. Fault Isolation ....................................20
3.3.4. Fault Isolation . . . . . . . . . . . . . . . . . . . 21 3.4. Configuration Management ..................................20
3.4. Configuration Management . . . . . . . . . . . . . . . . . 21 3.4.1. Verifying Correct Operation ........................22
3.4.1. Verifying Correct Operation . . . . . . . . . . . . . 22 3.5. Accounting Management .....................................22
3.5. Accounting Management . . . . . . . . . . . . . . . . . . 23 3.6. Performance Management ....................................22
3.6. Performance Management . . . . . . . . . . . . . . . . . . 23 3.6.1. Monitoring the Protocol ............................23
3.6.1. Monitoring the Protocol . . . . . . . . . . . . . . . 24 3.6.2. Monitoring the Device ..............................24
3.6.2. Monitoring the Device . . . . . . . . . . . . . . . . 25 3.6.3. Monitoring the Network .............................24
3.6.3. Monitoring the Network . . . . . . . . . . . . . . . . 25 3.6.4. Monitoring the Service .............................25
3.6.4. Monitoring the Service . . . . . . . . . . . . . . . . 25 3.7. Security Management .......................................25
3.7. Security Management . . . . . . . . . . . . . . . . . . . 25 4. Documentation Guidelines .......................................26
4. Documentation Guidelines . . . . . . . . . . . . . . . . . . . 27 4.1. Recommended Discussions ...................................27
4.1. Recommended Discussions . . . . . . . . . . . . . . . . . 27 4.2. Null Manageability Considerations Sections ................27
4.2. Null Manageability Considerations Sections . . . . . . . . 27 4.3. Placement of Operations and Manageability
4.3. Placement of Operations and Manageability Considerations Sections ...................................28
Considerations Sections . . . . . . . . . . . . . . . . . 28 5. Security Considerations ........................................28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 6. Acknowledgements ...............................................28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7. Informative References .........................................29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Operations and Management Review Checklist ..........32
8. Informative References . . . . . . . . . . . . . . . . . . . . 29 A.1. Operational Considerations ................................32
Appendix A. Operations and Management Review Checklist . . . . . 32 A.2. Management Considerations ................................34
A.1. Operational Considerations . . . . . . . . . . . . . . . . 32 A.3. Documentation .............................................35
A.2. Management Considerations . . . . . . . . . . . . . . . . 35
A.3. Documentation . . . . . . . . . . . . . . . . . . . . . . 36 RFC 5706 Ops and Mgmt Guidelines November 2009
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. This document provides guidelines to management particularly hard. This document provides guidelines to
help protocol designers and working groups consider the operations help protocol designers and working groups consider the operations
and management functionality for their new IETF protocol or protocol and management functionality for their new IETF protocol or protocol
extension at an earlier phase. extension at an earlier phase.
1.1. Designing for Operations and Management 1.1. Designing for Operations and Management
The operational environment and manageability of the protocol should The operational environment and manageability of the protocol should
be considered from the start when new protocols are designed. be considered from the start when new protocols are designed.
Most of the existing IETF management standards are focused on using Most of the existing IETF management standards are focused on using
SMI-based data models (MIB modules) to monitor and manage networking Structure of Management Information (SMI)-based data models (MIB
devices. As the Internet has grown, IETF protocols have addressed a modules) to monitor and manage networking devices. As the Internet
constantly growing set of needs, such as web servers and has grown, IETF protocols have addressed a constantly growing set of
collaboration services and applications. The number of IETF needs, such as web servers, collaboration services, and applications.
management technologies has been expanding and the IETF management The number of IETF management technologies has been expanding and the
strategy has been changing to address the emerging management IETF management strategy has been changing to address the emerging
requirements. The discussion of emerging sets of management management requirements. The discussion of emerging sets of
requirements has a long history in the IETF. The set of management management requirements has a long history in the IETF. The set of
protocols you should use depends on what you are managing. management protocols you should use depends on what you are managing.
Protocol designers should consider which operations and management Protocol designers should consider which operations and management
needs are relevant to their protocol, document how those needs could needs are relevant to their protocol, document how those needs could
be addressed, and suggest (preferably standard) management protocols be addressed, and suggest (preferably standard) management protocols
and data models that could be used to address those needs. This is and data models that could be used to address those needs. This is
similar to a working group (WG) that considers which security threats similar to a working group (WG) that considers which security threats
are relevant to their protocol, documents how threats should be are relevant to their protocol, documents how threats should be
mitigated, and then suggests appropriate standard protocols that mitigated, and then suggests appropriate standard protocols that
could mitigate the threats. could mitigate the threats.
When a WG considers operation and management functionality for a When a WG considers operation and management functionality for a
protocol, the document should contain enough information to protocol, the document should contain enough information for readers
understand how the protocol will be deployed and managed, and the WG to understand how the protocol will be deployed and managed. The WG
should expect that considerations for operations and management may should expect that considerations for operations and management may
need to be updated in the future, after further operational need to be updated in the future, after further operational
experience has been gained. experience has been gained.
RFC 5706 Ops and Mgmt Guidelines November 2009
1.2. This Document 1.2. This Document
This document makes a distinction between "Operational This document makes a distinction between "Operational
Considerations" and "Management Considerations", although the two are Considerations" and "Management Considerations", although the two are
closely related. The section on manageability is focused on closely related. The section on manageability is focused on
management technology such as how to utilize management protocols and management technology, such as how to utilize management protocols
how to design management data models. The operational considerations and how to design management data models. The operational
apply to operating the protocol within a network, even if there were considerations apply to operating the protocol within a network, even
no management protocol actively being used. if there were no management protocol actively being used.
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.
This document does not impose a solution, or imply that a formal data This document does not impose a solution, imply that a formal data
model is needed, or imply that using a specific management protocol model is needed, or imply that using a specific management protocol
is mandatory. If protocol designers conclude that the technology can is mandatory. If protocol designers conclude that the technology can
be managed solely by using proprietary command line interfaces be managed solely by using proprietary command line interfaces (CLIs)
(CLIs), and no structured or standardized data model needs to be in and that no structured or standardized data model needs to be in
place, this might be fine, but it is a decision that should be place, this might be fine, but it is a decision that should be
explicit in a manageability discussion, that this is how the protocol explicit in a manageability discussion -- that this is how the
will need to be operated and managed. Protocol designers should protocol will need to be operated and managed. Protocol designers
avoid having manageability pushed for a later phase of the should avoid having manageability pushed for a later phase of the
development of the standard. development of the standard.
This document discusses the importance of considering operations and In discussing the importance of considering operations and
management by setting forth a list of guidelines and a checklist of management, this document sets forth a list of guidelines and a
questions to consider, which a protocol designer or reviewer can use checklist of questions to consider (see Appendix A), which a protocol
to evaluate whether the protocol and documentation address common designer or reviewer can use to evaluate whether the protocol and
operations and management needs. Operations and management are documentation address common operations and management needs.
highly dependent on their environment, so most guidelines are Operations and management are highly dependent on their environment,
subjective rather than objective. so most guidelines are subjective rather than objective.
1.3. Motivation 1.3. Motivation
For years the IETF community has used the IETF Standard Management For years the IETF community has used the IETF Standard Management
Framework, including the Simple Network Management Protocol Framework, including the Simple Network Management Protocol
[RFC3410], the Structure of Management Information [RFC2578], and MIB [RFC3410], the Structure of Management Information [RFC2578], and MIB
data models for managing new protocols. As the Internet has evolved, data models for managing new protocols. As the Internet has evolved,
operators have found the reliance on one protocol and one schema operators have found the reliance on one protocol and one schema
language for managing all aspects of the Internet inadequate. The language for managing all aspects of the Internet inadequate. The
IESG policy to require working groups to write a MIB module to IESG policy to require working groups to write a MIB module to
RFC 5706 Ops and Mgmt Guidelines November 2009
provide manageability for new protocols is being replaced by a policy provide manageability for new protocols is being replaced by a policy
that is more open to using a variety of management protocols and data that is more open to using a variety of management protocols and data
models designed to achieve different goals. models designed to achieve different goals.
This document provides some initial guidelines for considering This document provides some initial guidelines for considering
operations and management in an IETF Management Framework that operations and management in an IETF Management Framework that
consists of multiple protocols and multiple data modeling languages, consists of multiple protocols and multiple data-modeling languages,
with an eye toward being flexible while also striving for with an eye toward being flexible while also striving for
interoperability. interoperability.
Fully new protocols may require significant consideration of expected Fully new protocols may require significant consideration of expected
operations and management, while extensions to existing widely- operations and management, while extensions to existing, widely
deployed protocols may have established defacto operations and deployed protocols may have established de facto operations and
management practices that are already well understood. management practices that are already well understood.
Suitable management approaches may vary for different areas, working Suitable management approaches may vary for different areas, working
groups, and protocols in the IETF. This document does not prescribe groups, and protocols in the IETF. This document does not prescribe
a fixed solution or format in dealing with operational and management a fixed solution or format in dealing with operational and management
aspects of IETF protocols. However, these aspects should be aspects of IETF protocols. However, these aspects should be
considered for any IETF protocol, because we develop technologies and considered for any IETF protocol because we develop technologies and
protocols to be deployed and operated in the real world Internet. It protocols to be deployed and operated in the real-world Internet. It
is fine if a WG decides that its protocol does not need interoperable is fine if a WG decides that its protocol does not need interoperable
management or no standardized data model, but this should be a management or no standardized data model, but this should be a
deliberate decision, not the result of omission. This document deliberate decision, not the result of omission. This document
provides some guidelines for those considerations. provides some guidelines for those considerations.
1.4. Background 1.4. Background
There have been a significant number of efforts, meetings, and There have been a significant number of efforts, meetings, and
documents that are related to Internet operations and management. documents that are related to Internet operations and management.
Some of them are mentioned here, to help protocol designers find Some of them are mentioned here to help protocol designers find
documentation of previous efforts. Hopefully, providing these documentation of previous efforts. Hopefully, providing these
references will help the IETF avoid rehashing old discussions and references will help the IETF avoid rehashing old discussions and
reinventing old solutions. reinventing old solutions.
In 1988, the IAB published IAB Recommendations for the Development of In 1988, the IAB published "IAB Recommendations for the Development
Internet Network Management Standards [RFC1052] which recommended a of Internet Network Management Standards" [RFC1052], which
solution that, where possible, deliberately separates modeling recommended a solution that, where possible, deliberately separates
languages, data models, and the protocols that carry data. The goal modeling languages, data models, and the protocols that carry data.
is to allow standardized information and data models to be used by The goal is to allow standardized information and data models to be
different protocols. used by different protocols.
In 2001, OPS Area design teams were created to document requirements In 2001, Operations and Management Area design teams were created to
related to configuration of IP-based networks. One output was document requirements related to the configuration of IP-based
"Requirements for Configuration Management of IP-based Networks" networks. One output was "Requirements for Configuration Management
[RFC3139]. of IP-based Networks" [RFC3139].
RFC 5706 Ops and Mgmt Guidelines November 2009
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 issue discussed was the user-unfriendliness of the binary format One issue discussed was the user-unfriendliness of the binary format
of SNMP [RFC3410] and COPS Usage for Policy Provisioning (COPS-PR) of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for
[RFC3084], and it was recommended that the IETF explore an XML-based Policy Provisioning (COPS-PR) [RFC3084], and it was recommended that
Structure of Management Information, and an XML-based protocol for the IETF explore an XML-based Structure of Management Information and
configuration. an XML-based protocol for configuration.
Another conclusion was that the tools for event/alarm correlation and Another conclusion was that the tools for event/alarm correlation and
for root cause analysis and logging are not sufficient, and that for root cause analysis and logging are not sufficient and that there
there is a need to support a human interface and a programmatic is a need to support a human interface and a programmatic interface.
interface. The IETF decided to standardize aspects of the de facto The IETF decided to standardize aspects of the de facto standard for
standard for system logging security and programmatic support. system-logging security and 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 schema languages for be updated to accommodate multiple IETF schema languages for
describing the structure of management information, and multiple IETF describing the structure of management information and multiple IETF
standard protocols for performing management tasks. The IESG asked standard protocols for performing management tasks. The IESG asked
that a document be written to discuss how protocol designers and that a document be written to discuss how protocol designers and
working groups should address management in this emerging multi- working groups should address management in this emerging multi-
protocol environment. This document, and some planned companion protocol environment. This document and some planned companion
documents, attempt to provide some guidelines for navigating the documents attempt to provide some guidelines for navigating the
rapidly-shifting operating and management environments. rapidly shifting operating and management environments.
1.5. Available Management Technologies 1.5. Available Management Technologies
The IETF has a number of standard management protocols available that The IETF has a number of standard management protocols available that
are suitable for different purposes. These include are suitable for different purposes. These include:
SNMP [RFC3410], Simple Network Management Protocol - SNMP [RFC3410]
SYSLOG [RFC5424], Syslog [RFC5424]
RADIUS [RFC2865], Remote Authentication Dial-In User Service - RADIUS [RFC2865]
DIAMETER [RFC3588], DIAMETER [RFC3588]
NETCONF [RFC4741], Network Configuration Protocol - NETCONF [RFC4741]
IPFIX [RFC5101]. IP Flow Information Export - IPFIX [RFC5101]
A planned supplement to this document will discuss these protocol A planned supplement to this document will discuss these protocol
standards, and discuss some standard information and data models for standards, discuss some standard information and data models for
specific functionality, and provide pointers to the documents that specific functionality, and provide pointers to the documents that
define them. define them.
RFC 5706 Ops and Mgmt Guidelines November 2009
1.6. Terminology 1.6. Terminology
This document deliberately does not use the (capitalized) keywords This document deliberately does not use the (capitalized) keywords
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 informational document is a set
based on current practices of protocol designers and operators. This of guidelines based on current practices of **some** protocol
document does not describe requirements, so the key words from designers and operators. This document is biased toward router
RFC2119 have no place here. operations and management and some advice may not be directly
applicable to protocols with a different purpose, such as application
server protocols. This document **does not** describe
interoperability requirements, so the capitalized keywords from RFC
2119 do not apply here.
o CLI: Command Line Interface o CLI: Command Line Interface
o Data model: A mapping of the contents of an information model into o Data model: a mapping of the contents of an information model into
a form that is specific to a particular type of data store or a form that is specific to a particular type of data store or
repository. [RFC3444] repository [RFC3444].
o Information model: An abstraction and representation of the o Information model: an abstraction and representation of the
entities in a managed environment, their properties, attributes entities in a managed environment, their properties, attributes
and operations, and the way that they relate to each other. It is and operations, and the way that they relate to each other. It is
independent of any specific repository, software usage, protocol, independent of any specific repository, software usage, protocol,
or platform. [RFC3444] or platform [RFC3444].
o "new protocol" includes new protocols, protocol extensions, data o New protocol: includes new protocols, protocol extensions, data
models, or other functionality being designed. models, or other functionality being designed.
o "protocol designer" represents individuals and working groups o Protocol designer: represents individuals and working groups
involved in the development of new protocols or extensions. involved in the development of new protocols or extensions.
2. Operational Considerations - How Will the New Protocol Fit Into the 2. Operational Considerations - How Will the New Protocol Fit into the
Current Environment? Current Environment?
Designers of a new protocol should carefully consider the operational Designers of a new protocol should carefully consider the operational
aspects. To ensure that a protocol will be practical to deploy in aspects. To ensure that a protocol will be practical to deploy in
the real world, it is not enough to merely define it very precisely the real world, it is not enough to merely define it very precisely
in a well-written document. Operational aspects will have a serious in a well-written document. Operational aspects will have a serious
impact on the actual success of a protocol. Such aspects include bad impact on the actual success of a protocol. Such aspects include bad
interactions with existing solutions, a difficult upgrade path, interactions with existing solutions, a difficult upgrade path,
difficulty of debugging problems, difficulty configuring from a difficulty of debugging problems, difficulty configuring from a
central database, or a complicated state diagram that operations central database, or a complicated state diagram that operations
staff will find difficult to understand. staff will find difficult to understand.
RFC 5706 Ops and Mgmt Guidelines November 2009
BGP flap damping [RFC2439] is an example. It was designed to block BGP flap damping [RFC2439] is an example. It was designed to block
high frequency route flaps, however the design did not consider the high-frequency route flaps; however, the design did not consider the
existence of BGP path exploration/slow convergence. In real existence of BGP path exploration / slow convergence. In real
operations, path exploration caused false flap damping, resulting in operations, path exploration caused false flap damping, resulting in
loss of reachability. As a result, many networks turned flap damping loss of reachability. As a result, many networks turned flap damping
off. off.
2.1. Operations 2.1. Operations
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 need not be reflected directly by text in their document, exercise need not be reflected directly by text in their document,
but could help in visualizing how to apply the protocol in the but could help in visualizing how to apply the protocol in the
skipping to change at page 10, line 29 skipping to change at page 9, line 38
troubleshooting, and a programmatic interface, e.g., for automated troubleshooting, and a programmatic interface, e.g., for automated
monitoring and root cause analysis. The application programming monitoring and root cause analysis. The application programming
interfaces and the human interfaces might benefit from being similar interfaces and the human interfaces might benefit from being similar
to ensure that the information exposed by these two interfaces is to ensure that the information exposed by these two interfaces is
consistent when presented to an operator. Identifying consistent consistent when presented to an operator. Identifying consistent
methods of determining information, such as what gets counted in a methods of determining information, such as what gets counted in a
specific counter, is relevant. specific counter, is relevant.
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 whether notifications for alarms or other routers and on hosts, or whether notifications for alarms or other
events will be expected. events will be expected.
2.2. Installation and Initial Setup 2.2. Installation and Initial Setup
Anything that can be configured can be misconfigured. "Architectural Anything that can be configured can be misconfigured. "Architectural
Principles of the Internet" [RFC1958] Section 3.8 states: "Avoid Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid
options and parameters whenever possible. Any options and parameters options and parameters whenever possible. Any options and parameters
should be configured or negotiated dynamically rather than manually." should be configured or negotiated dynamically rather than manually."
To simplify configuration, protocol designers should consider To simplify configuration, protocol designers should consider
specifying reasonable defaults, including default modes and specifying reasonable defaults, including default modes and
parameters. For example, it could be helpful or necessary to specify parameters. For example, it could be helpful or necessary to specify
default values for modes, timers, default state of logical control default values for modes, timers, default state of logical control
RFC 5706 Ops and Mgmt Guidelines November 2009
variables, default transports, and so on. Even if default values are variables, default transports, and so on. Even if default values are
used, it must be possible to retrieve all the actual values or at used, it must be possible to retrieve all the actual values or at
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 on individual devices. Of course, how one accomplishes this is than on individual devices. Of course, how one accomplishes this is
the hard part. the hard part.
It is desirable to discuss the background of chosen default values, It is desirable to discuss the background of chosen default values,
skipping to change at page 11, line 17 skipping to change at page 10, line 28
technology changes, the values in an RFC might make less and less technology changes, the values in an RFC might make less and less
sense. It is very useful to understand whether defaults are based on sense. It is very useful to understand whether defaults are based on
best current practice and are expected to change as technologies best current practice and are expected to change as technologies
advance or whether they have a more universal value that should not advance or whether they have a more universal value that should not
be changed lightly. For example, the default interface speed might be changed lightly. For example, the default interface speed might
be expected to change over time due to increased speeds in the be expected to change over time due to increased speeds in the
network, and cryptographical algorithms might be expected to change network, and cryptographical algorithms might be expected to change
over time as older algorithms are "broken". over time as older algorithms are "broken".
It is extremely important to set a sensible default value for all It is extremely important to set a sensible default value for all
parameters parameters.
The default value should stay on the conservative side rather than on The default value should stay on the conservative side rather than on
the "optimizing performance" side. (example: the initial RTT and the "optimizing performance" side (example: the initial RTT and
RTTvar values of a TCP connection) RTTvar values of a TCP connection).
For those parameters that are speed-dependent, instead of using a For those parameters that are speed-dependent, instead of using a
constant, try to set the default value as a function of the link constant, try to set the default value as a function of the link
speed or some other relevant factors. This would help reduce the speed or some other relevant factors. This would help reduce the
chance of problems caused by technology advancement. chance of problems caused by technology advancement.
2.3. Migration Path 2.3. Migration Path
If the new protocol is a new version of an existing one, or if it is If the new protocol is a new version of an existing one, or if it is
replacing another technology, the protocol designer should consider replacing another technology, the protocol designer should consider
how 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 coexistence 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 coexist
in the network with the new protocol? in the network with the new protocol?
Many protocols benefit from being incrementally deployable - Many protocols benefit from being incrementally deployable --
operators may deploy aspects of a protocol before deploying the operators may deploy aspects of a protocol before deploying the
protocol fully. protocol fully.
RFC 5706 Ops and Mgmt Guidelines November 2009
2.4. Requirements on Other Protocols and Functional Components 2.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 and should also document the requirements from other protocols and
functional elements that have been considered in designing the new functional elements that have been considered in designing the new
protocol. 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. If restrictions or dependencies exist, they should be certain ways. If restrictions or dependencies exist, they should be
stated. stated.
For example, the design of Resource ReSerVation Protocol (RSVP) For example, the design of the Resource ReSerVation Protocol (RSVP)
[RFC2205] required each router to look at the RSVP PATH message, and [RFC2205] required each router to look at the RSVP PATH message and,
if the router understood RSVP, to add its own address to the message if the router understood RSVP, add its own address to the message to
to enable automatically tunneling through non-RSVP routers. But in enable automatic tunneling through non-RSVP routers. But in reality,
reality routers cannot look at an otherwise normal IP packet, and routers cannot look at an otherwise normal IP packet and potentially
potentially take it off the fast path! The initial designers take it off the fast path! The initial designers overlooked that a
overlooked that a new "deep packet inspection" requirement was being new "deep packet inspection" requirement was being put on the
put on the functional components of a router. The "router alert" functional components of a router. The "router alert" option
option [RFC2113] [RFC2711] was finally developed to solve this ([RFC2113], [RFC2711]) was finally developed to solve this problem
problem for RSVP and other protocols that require the router to take for RSVP and other protocols that require the router to take some
some packets off the fast forwarding path. Router alert has its own packets off the fast-forwarding path. Yet, router alert has its own
problems in impacting router performance. problems in impacting router performance.
2.5. Impact on Network Operation 2.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 considered in the light of the impact on the scalability of the
interior gateway protocols operating within the network. interior gateway protocols operating within the network.
A protocol could send active monitoring packets on the wire. If we A protocol could send active monitoring packets on the wire. If we
don't pay attention, we might get very good accuracy, but could send don't pay attention, we might get very good accuracy, but could send
too many active monitoring packets. too many active monitoring packets.
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
RFC 5706 Ops and Mgmt Guidelines November 2009
components that are added to the network as a result of changes in
the configuration, such as servers performing auto-configuration the configuration, 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 DNS [RFC1034], the registries, or infrastructure applications like DNS [RFC1034], the registries, or
the size of routing tables. For example, Simple Mail Transfer the size of routing tables. For example, Simple Mail Transfer
Protocol (SMTP) [RFC5321] servers use a reverse DNS lookup to filter Protocol (SMTP) [RFC5321] servers use a reverse DNS lookup to filter
out incoming connection requests. When Berkeley installed a new spam out incoming connection requests. When Berkeley installed a new spam
filter, their mail server stopped functioning because of the DNS filter, their mail server stopped functioning because of overload of
cache resolver overload. the DNS cache resolver.
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 increased response time
server applications when encryption or filtering are applied. in client-server applications when encryption or filtering are
applied.
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.
2.6. Verifying Correct Operation 2.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
through the network and observing its behavior (aka active through the network and observing its behavior (aka active
monitoring). Protocol designers should consider how the correct end- monitoring). Protocol designers should consider how the correct end-
to-end operation of the new protocol in the network can be tested to-end operation of the new protocol in the network can be tested
actively and passively, and how the correct data or forwarding plane actively and passively, and how the correct data or forwarding plane
function of each network element can be verified to be working function of each network element can be verified to be working
properly with the new protocol. Which metrics are of interest? properly with the new protocol. Which metrics are of interest?
Having simple protocol status and health indicators on network Having simple protocol status and health indicators on network
devices is a recommended means to check correct operation. devices is a recommended means to check correct operation.
3. Management Considerations - How Will The Protocol be Managed? 3. Management Considerations - How Will the Protocol Be Managed?
The considerations of manageability should start from identifying the The considerations of manageability should start from identifying the
entities to be managed, and how the managed protocol is supposed to entities to be managed, as well as how the managed protocol is
be installed, configured and monitored. supposed to be installed, configured, and monitored.
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.
Where are the managers and what type of management interfaces and Where are the managers and what type of management interfaces and
protocols will they need? The "write a MIB module" approach to protocols will they need? The "write a MIB module" approach to
considering management often focuses on monitoring a protocol considering management often focuses on monitoring a protocol
endpoint on a single device. A MIB module document typically only endpoint on a single device. A MIB module document typically only
RFC 5706 Ops and Mgmt Guidelines November 2009
considers monitoring properties observable at one end, while the considers monitoring properties observable at one end, while the
document does not really cover managing the *protocol* (the document does not really cover managing the *protocol* (the
coordination of multiple ends), and does not even come near managing coordination of multiple ends), and does not even come near managing
the *service* (which includes a lot of stuff that is very far away the *service* (which includes a lot of stuff that is very far away
from the box). This is exactly what operators hate - you need to be from the box). This is exactly what operators hate -- you need to be
able to manage both ends. As [RFC3535] says, MIB modules can often able to manage both ends. As [RFC3535] says, "MIB modules can often
be characterized as a list of ingredients without a recipe. be characterized as a list of ingredients without a recipe".
The management model should take into account factors such as: The management model should take into account factors such as:
o what type of management entities will be involved (agents, network o What type of management entities will be involved (agents, network
management systems)? management systems)?
o what is the possible architecture (client-server, manager-agent, o What is the possible architecture (client-server, manager-agent,
poll-driven or event-driven, autoconfiguration, two levels or poll-driven or event-driven, auto-configuration, two levels or
hierarchical)? hierarchical)?
o what are the management operations - initial configuration, o What are the management operations (initial configuration, dynamic
dynamic configuration, alarm and exception reporting, logging, configuration, alarm and exception reporting, logging, performance
performance monitoring, performance reporting, debugging? monitoring, performance reporting, debugging)?
o how are these operations performed - locally, remotely, atomic o How are these operations performed (locally, remotely, atomic
operation, scripts? Are they performed immediately or time operation, scripts)? Are they performed immediately or are they
scheduled or event triggered? time scheduled or event triggered?
Protocol designers should consider how the new protocol will be Protocol designers should consider how the new protocol will be
managed in different deployment scales. It might be sensible to use managed in different deployment scales. It might be sensible to use
a local management interface to manage the new protocol on a single a local management interface to manage the new protocol on a single
device, but in a large network, remote management using a centralized device, but in a large network, remote management using a centralized
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.
Management needs to be considered not only from the perspective of a Management needs to be considered not only from the perspective of a
device, but also from the perspective of network and service device, but also from the perspective of network and service
management perspectives. A service might be network and operational management. A service might be network and operational functionality
functionality derived from the implementation and deployment of a new derived from the implementation and deployment of a new protocol.
protocol. Often an individual network element is not aware of the Often an individual network element is not aware of the service being
service being delivered. delivered.
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 [RFC4741] addresses this in a generic manner causes trouble. NETCONF [RFC4741] addresses this in a generic manner
by allowing an operator to lock the configuration on multiple by allowing an operator to lock the configuration on multiple
devices, perform the configuration settings/changes, check that they devices, perform the configuration settings/changes, check that they
are OK (undo if not) and then unlock the devices. are OK (undo if not), and then unlock the devices.
RFC 5706 Ops and Mgmt Guidelines November 2009
Techniques for debugging protocol interactions in a network must be Techniques for debugging protocol interactions in a network must 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: while the messages can be seen by sniffing, it is enormously issue: while the messages can be seen by sniffing, it is enormously
helpful if a protocol specification supports features that make helpful if a protocol specification supports features that make
debugging of network interactions and behaviors easier. There could debugging of network interactions and behaviors easier. There could
be alerts issued when messages are received, or when there are state be alerts issued when messages are received or when there are state
transitions in the protocol state machine. However, the state transitions in the protocol state machine. However, the state
machine is often not part of the on-the-wire protocol; the state machine is often not part of the on-the-wire protocol; the state
machine explains how the protocol works so that an implementer can machine explains how the protocol works so that an implementer can
decide, in an implementation-specific manner, how to react to a decide, in an implementation-specific manner, how to react to a
received event. received event.
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, since the the server end of a protocol than the client end, since the
performance of the server might impact more nodes than the performance of the server might impact more nodes than the
performance of a specific client. performance of a specific client.
3.1. Interoperability 3.1. Interoperability
Just as when deploying protocols that will inter-connect devices, Just as when deploying protocols that will inter-connect devices,
management interoperability should be considered, whether across management interoperability should be considered -- whether across
devices from different vendors, across models from the same vendor, devices from different vendors, across models from the same vendor,
or across different releases of the same product. Management or across different releases of the same product. Management
interoperability refers to allowing information sharing and interoperability refers to allowing information sharing and
operations between multiple devices and multiple management operations between multiple devices and multiple management
applications, often from different vendors. Interoperability allows applications, often from different vendors. Interoperability allows
for the use of 3rd party applications and the outsourcing of for the use of third-party applications and the outsourcing of
management services. management services.
Some product designers and protocol designers assume that if a device Some product designers and protocol designers assume that if a device
can be managed individually using a command line interface or a web can be managed individually using a command line interface or a web
page interface, that such a solution is enough. But when equipment page interface, that such a solution is enough. But when equipment
from multiple vendors is combined into a large network, scalability from multiple vendors is combined into a large network, scalability
of management may become a problem. It may be important to have of management may become a problem. It may be important to have
consistency in the management interfaces so network-wide operational consistency in the management interfaces so network-wide operational
processes can be automated. For example, a single switch might be processes can be automated. For example, a single switch might be
easily managed using an interactive web interface when installed in a easily managed using an interactive web interface when installed in a
single office small business, but when, say, a fast food company single-office small business, but when, say, a fast-food company
installs similar switches from multiple vendors in hundreds or installs similar switches from multiple vendors in hundreds or
thousands of individual branches and wants to automate monitoring thousands of individual branches and wants to automate monitoring
them from a central location, monitoring vendor-and-model-specific them from a central location, monitoring vendor- and model-specific
web pages would be difficult to automate. web pages would be difficult to automate.
RFC 5706 Ops and Mgmt Guidelines November 2009
The primary goal is the ability to roll out new useful functions and The primary goal is the ability to roll out new useful functions and
services in a way in which they can be managed in a scalable manner, services in a way in which they can be managed in a scalable manner,
where one understands the network impact (as part of the total cost where one understands the network impact (as part of the total cost
of operations) of that service. of operations) of that service.
Getting everybody to agree on a single syntax and an associated Getting everybody to agree on a single syntax and an associated
protocol to do all management has proven to be difficult. So protocol to do all management has proven to be difficult. So
management systems tend to speak whatever the boxes support, whether management systems tend to speak whatever the boxes support, whether
the IETF likes this or not. The IETF is moving from support for one or not the IETF likes this. The IETF is moving from support for one
schema language for modeling the structure of management information schema language for modeling the structure of management information
(Structure of Management Information Version 2 (SMIv2) [RFC2578]) and (Structure of Management Information Version 2 (SMIv2) [RFC2578]) and
one simple network management protocol (Simple Network Management one simple network management protocol (Simple Network Management
Protocol (SNMP) [RFC3410]) towards support for additional schema Protocol (SNMP) [RFC3410]) towards support for additional schema
languages and additional management protocols suited to different languages and additional management protocols suited to different
purposes. Other Standard Development Organizations (e.g. DMTF, TMF) purposes. Other Standard Development Organizations (e.g., the
also define schemas and protocols for management and these may be Distributed Management Task Force - DMTF, the Tele-Management Forum -
more suitable than IETF schemas and protocols in some cases. Some of TMF) also define schemas and protocols for management and these may
the alternatives being considered include be more suitable than IETF schemas and protocols in some cases. Some
of the alternatives being considered include:
XML Schema Definition [W3C.REC-xmlschema-0-20010502]
and others o XML Schema Definition [W3C.REC-xmlschema-0-20010502]
and and
NETCONF Configuration Protocol [RFC4741] o NETCONF Configuration Protocol [RFC4741]
IP Flow Information Export (IPFIX) Protocol [RFC5101]) for usage
accounting
The syslog Protocol [RFC5424] for logging o the IP Flow Information Export (IPFIX) Protocol [RFC5101]) for
usage accounting
and others o the syslog protocol [RFC5424] for logging
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
can make their processing conditional to accommodate syntactic scripts, can make their processing conditional to accommodate
differences across vendors or models or releases of product. syntactic differences across vendors, 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. entity.
Information models are helpful to try to focus interoperability on Information models are helpful to try to focus interoperability on
the semantic level - they establish standards for what information the semantic level -- they establish standards for what information
should be gathered, and how gathered information might be used should be gathered and how gathered information might be used,
regardless of which management interface carries the data or which regardless of which management interface carries the data or which
vendor produces the product. The use of an information model might vendor produces the product. The use of an information model might
help improve the ability of operators to correlate messages in help improve the ability of operators to correlate messages in
different protocols where the data overlaps, such as a SYSLOG message different protocols where the data overlaps, such as a syslog message
RFC 5706 Ops and Mgmt Guidelines November 2009
and an SNMP notification about the same event. An information model and an SNMP notification about the same event. An information model
might identify which error conditions should be counted separately, might identify which error conditions should be counted separately
and which error conditions can be counted together in a single and which error conditions can be counted together in a single
counter. Then, whether the counter is gathered via SNMP or a CLI counter. Then, whether the counter is gathered via SNMP, a CLI
command or a SYSLOG message, the counter will have the same meaning. command, or a syslog message, the counter will have the same meaning.
Protocol designers should consider which information might be useful Protocol designers should consider which information might be useful
for managing the new protocol or protocol extensions. for managing the new protocol or protocol extensions.
IM --> conceptual/abstract model IM --> conceptual/abstract model
| for designers and operators | for designers and operators
+----------+---------+ +----------+---------+
| | | | | |
DM DM DM --> concrete/detailed model DM DM DM --> concrete/detailed model
for implementers for implementers
Information Models and Data Models Information Models and Data Models
Figure 1 Figure 1
Protocol designers may decide an information model or data model Protocol designers may decide an information model or data model
would be appropriate for managing the new protocol or protocol would be appropriate for managing the new protocol or protocol
extensions. extensions.
On the Difference between Information Models and Data Models "On the Difference between Information Models and Data Models"
[RFC3444] can be helpful in determining what information to consider [RFC3444] can be helpful in determining what information to consider
regarding information models, as compared to data models. regarding information models (IMs), as compared to data models (DMs).
Information models should come from the protocol WGs and include Information models should come from the protocol WGs and include
lists of events, counters and configuration parameters that are lists of events, counters, and configuration parameters that are
relevant. There are a number of information models contained in relevant. There are a number of information models contained in
protocol WG RFCs. Some examples: protocol WG RFCs. Some examples:
o [RFC3060] - Policy Core Information Model version 1 o [RFC3060] - Policy Core Information Model version 1
o [RFC3290] - An Informal Management Model for DiffServ Routers o [RFC3290] - An Informal Management Model for Diffserv Routers
o [RFC3460] - Policy Core Information Model Extensions o [RFC3460] - Policy Core Information Model Extensions
o [RFC3585] - IPsec Configuration Policy Information Model o [RFC3585] - IPsec Configuration Policy Information Model
o [RFC3644] - Policy Quality of Service Information Model o [RFC3644] - Policy Quality of Service Information Model
o [RFC3670] - Information Model for Describing Network Device QoS o [RFC3670] - Information Model for Describing Network Device QoS
Datapath Mechanisms Datapath Mechanisms
o [RFC3805] - Printer MIB v2 contains both an IM and a DM o [RFC3805] - Printer MIB v2 (contains both an IM and a DM)
RFC 5706 Ops and Mgmt Guidelines November 2009
Management protocol standards and management data model standards Management protocol standards and management data model standards
often contain compliance clauses to ensure interoperability. often contain compliance clauses to ensure interoperability.
Manageability considerations should include discussion of which level Manageability considerations should include discussion of which level
of compliance is expected to be supported for interoperability. of compliance is expected to be supported for interoperability.
3.2. Management Information 3.2. Management Information
Languages used to describe an information model can influence the Languages used to describe an information model can influence the
nature of the model. Using a particular data modeling language, such nature of the model. Using a particular data-modeling language, such
as the SMIv2, influence the model to use certain types of structures, as the SMIv2, influences the model to use certain types of
such as two-dimensional tables. This document recommends using structures, such as two-dimensional tables. This document recommends
English text (the official language for IETF specifications) to using English text (the official language for IETF specifications) to
describe an information model. A sample data model could be describe an information model. A sample data model could be
developed to demonstrate the information model. developed to demonstrate the information model.
A management information model should include a discussion of what is A management information model should include a discussion of what is
manageable, which aspects of the protocol need to be configured, what manageable, which aspects of the protocol need to be configured, what
types of operations are allowed, what protocol-specific events might types of operations are allowed, what protocol-specific events might
occur, which events can be counted, and for which events should an occur, which events can be counted, and for which events an operator
operator be notified. should be notified.
Operators find it important to be able to make a clear distinction Operators find it important to be able to make a clear distinction
between configuration data, operational state, and statistics. They between configuration data, operational state, and statistics. They
need to determine which parameters were administratively configured need to determine which parameters were administratively configured
and which parameters have changed since configuration as the result and which parameters have changed since configuration as the result
of mechanisms such as routing protocols or network management of mechanisms such as routing protocols or network management
protocols. It is important to be able to separately fetch current protocols. It is important to be able to separately fetch current
configuration information, initial configuration information, configuration information, initial configuration information,
operational state information, and statistics from devices, and to be operational state information, and statistics from devices; to be
able to compare current state to initial state, and to compare able to compare current state to initial state; and to compare
information between devices. So when deciding what information information between devices. So when deciding what information
should exist, do not conflate multiple information elements into a should exist, do not conflate multiple information elements into a
single element. single element.
What is typically difficult to work through are relationships between What is typically difficult to work through are relationships between
abstract objects. Ideally an information model would describe the abstract objects. Ideally, an information model would describe the
relationships between the objects and concepts in the information relationships between the objects and concepts in the information
model. model.
Is there always just one instance of this object or can there be Is there always just one instance of this object or can there be
multiple instances? Does this object relate to exactly one other multiple instances? Does this object relate to exactly one other
object or may it relate to multiple? When is it possible to change a object or may it relate to multiple? When is it possible to change a
relationship? relationship?
RFC 5706 Ops and Mgmt Guidelines November 2009
Do objects (such as rows in tables) share fate? For example, if a Do objects (such as rows in tables) share fate? For example, if a
row in table A must exist before a related row in table B can be row in table A must exist before a related row in table B can be
created, what happens to the row in table B if the related row in created, what happens to the row in table B if the related row in
table A is deleted? Does the existence of relationships between table A is deleted? Does the existence of relationships between
objects have an impact on fate sharing? objects have an impact on fate sharing?
3.2.1. Information Model Design 3.2.1. Information Model Design
This document recommends keeping the information model as simple as This document recommends keeping the information model as simple as
possible by applying the following criteria: possible by applying the following criteria:
skipping to change at page 19, line 28 skipping to change at page 18, line 36
5. Exclude objects that are simply derivable from others in this or 5. Exclude objects that are simply derivable from others in this or
other information models. other information models.
6. Avoid causing critical sections to be heavily instrumented. A 6. Avoid causing critical sections to be heavily instrumented. A
guideline is one counter per critical section per layer. guideline is one counter per critical section per layer.
3.3. Fault Management 3.3. Fault Management
The protocol designer should document the basic faults and health The protocol designer should document the basic faults and health
indicators that need to be instrumented for the new protocol, and the indicators that need to be instrumented for the new protocol, as well
alarms and events that must be propagated to management applications as the alarms and events that must be propagated to management
or exposed through a data model. applications or exposed through a data model.
The protocol designer should consider how fault information will be The protocol designer should consider how fault information will be
propagated. Will it be done using asynchronous notifications or propagated. Will it be done using asynchronous notifications or
polling of health indicators? polling of health indicators?
If notifications are used to alert operators to certain conditions, If notifications are used to alert operators to certain conditions,
then the protocol designer should discuss mechanisms to throttle then the protocol designer should discuss mechanisms to throttle
notifications to prevent congestion and duplications of event notifications to prevent congestion and duplications of event
notifications. Will there be a hierarchy of faults, and will the notifications. Will there be a hierarchy of faults, and will the
fault reporting be done by each fault in the hierarchy, or will only fault reporting be done by each fault in the hierarchy, or will only
the lowest fault be reported and the higher levels be suppressed? the lowest fault be reported and the higher levels be suppressed?
Should there be aggregated status indicators based on concatenation Should there be aggregated status indicators based on concatenation
of propagated faults from a given domain or device? of propagated faults from a given domain or device?
SNMP notifications and SYSLOG messages can alert an operator when an RFC 5706 Ops and Mgmt Guidelines November 2009
SNMP notifications and syslog messages can alert an operator when an
aspect of the new protocol fails or encounters an error or failure aspect of the new protocol fails or encounters an error or failure
condition, and SNMP is frequently used as a heartbeat monitor. condition, and SNMP is frequently used as a heartbeat monitor.
Should the event reporting provide guaranteed accurate delivery of Should the event reporting provide guaranteed accurate delivery of
the event information within a given (high) margin of confidence? the event information within a given (high) margin of confidence?
Can we poll the latest events in the box? Can we poll the latest events in the box?
3.3.1. Liveness Detection and Monitoring 3.3.1. Liveness Detection and Monitoring
Protocol designers should always build in basic testing features Protocol designers should always build in basic testing features
(e.g. ICMP echo, UDP/TCP echo service, NULL RPC calls) that can be (e.g., ICMP echo, UDP/TCP echo service, NULL RPCs (remote procedure
used to test for liveness, with an option to enable and disable them. calls)) that can be used to test for liveness, with an option to
enable and disable them.
Mechanisms for monitoring the liveness of the protocol and for Mechanisms for monitoring the liveness of the protocol and for
detecting faults in protocol connectivity are usually built into detecting faults in protocol connectivity are usually built into
protocols. In some cases, mechanisms already exist within other protocols. In some cases, mechanisms already exist within other
protocols responsible for maintaining lower layer connectivity (e.g. protocols responsible for maintaining lower-layer connectivity (e.g.,
ICMP echo), but often new procedures are required to detect failures ICMP echo), but often new procedures are required to detect failures
and to report rapidly, allowing remedial action to be taken. and to report rapidly, allowing remedial action to be taken.
These liveness monitoring mechanisms do not typically require These liveness monitoring mechanisms do not typically require
additional management capabilities. However, when a system detects a additional management capabilities. However, when a system detects a
fault, there is often a requirement to coordinate recovery action fault, there is often a requirement to coordinate recovery action
through management applications or at least to record the fact in an through management applications or at least to record the fact in an
event log. event log.
3.3.2. Fault Determination 3.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. Protocol designers should consider what looking for anomalies. Protocol designers should consider what
counters should count. If a single counter provided by vendor A counters should count. If a single counter provided by vendor A
counts three types of error conditions, while the corresponding counts three types of error conditions, while the corresponding
counter provided by vendor B counts seven types of error conditions, counter provided by vendor B counts seven types of error conditions,
these counters cannot be compared effectively - they are not these counters cannot be compared effectively -- they are not
interoperable counters. interoperable counters.
How do you distinguish between faulty messages and good messages? How do you distinguish between faulty messages and good messages?
Would some threshold-based mechanisms, such as RMON events/alarms or Would some threshold-based mechanisms, such as Remote Monitoring
the EVENT-MIB, be useable to help determine error conditions? Are (RMON) events/alarms or the EVENT-MIB, be usable to help determine
SNMP notifications for all events needed, or are there some error conditions? Are SNMP notifications for all events needed, or
"standard" notifications that could be used? or can relevant counters are there some "standard" notifications that could be used? Or can
be polled as needed? relevant counters be polled as needed?
RFC 5706 Ops and Mgmt Guidelines November 2009
3.3.3. Root Cause Analysis 3.3.3. Root Cause Analysis
Root cause analysis is about working out where in the network the Root cause analysis is about working out where in the network the
fault is. For example, if end-to-end data delivery is failing fault is. For example, if end-to-end data delivery is failing
(reported by a notification), root cause analysis can help find the (reported by a notification), root cause analysis can help find the
failed link or node in the end-to-end path. failed link or node in the end-to-end path.
3.3.4. Fault Isolation 3.3.4. Fault Isolation
skipping to change at page 21, line 24 skipping to change at page 20, line 33
A protocol designer should document the basic configuration A protocol designer should document the basic configuration
parameters that need to be instrumented for a new protocol, as well parameters that need to be instrumented for a new protocol, as well
as default values and modes of operation. as default values and modes of operation.
What information should be maintained across reboots of the device, What information should be maintained across reboots of the device,
or restarts of the management system? or restarts of the management system?
"Requirements for Configuration Management of IP-based Networks" "Requirements for Configuration Management of IP-based Networks"
[RFC3139] discusses requirements for configuration management, [RFC3139] discusses requirements for configuration management,
including discussion of different levels of management, high-level- including discussion of different levels of management, high-level
policies, network-wide configuration data, and device-local policies, network-wide configuration data, and device-local
configuration. Network configuration is not just multi-device push configuration. Network configuration is not just multi-device push
or pull. It is knowing that the configurations being pushed are or pull. It is knowing that the configurations being pushed are
semantically compatible. Is the circuit between them configured semantically compatible. Is the circuit between them configured
compatibly on both ends? is the is-is metric the same? ... now do compatibly on both ends? Is the IS-IS metric the same? ... Now
that for 1,000 devices. answer those questions for 1,000 devices.
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
configuration management. "Terminology for Policy-Based Management" configuration management. "Terminology for Policy-Based Management"
[RFC3198] was written to standardize the terminology across these [RFC3198] was written to standardize the terminology across these
efforts. efforts.
Implementations should not arbitrarily modify configuration data. In Implementations should not arbitrarily modify configuration data. In
some cases (such as Access Control Lists) the order of data items is some cases (such as access control lists (ACLs)), the order of data
significant and comprises part of the configured data. If a protocol items is significant and comprises part of the configured data. If a
designer defines mechanisms for configuration, it would be desirable protocol designer defines mechanisms for configuration, it would be
to standardize the order of elements for consistency of configuration desirable to standardize the order of elements for consistency of
and of reporting across vendors, and across releases from vendors. configuration and of reporting across vendors and across releases
from vendors.
There are two parts to this: 1. An NMS system could optimize access RFC 5706 Ops and Mgmt Guidelines November 2009
control lists (ACLs) for performance reasons 2. Unless the device/
NMS systems has correct rules/a lot of experience, reordering ACLs
can lead to a huge security issue.
Network wide configurations may be stored in central master databases There are two parts to this:
1. A Network Management System (NMS) could optimize ACLs for
performance reasons.
2. Unless the device/NMS systems has correct rules / a lot of
experience, reordering ACLs can lead to a huge security issue.
Network-wide configurations may be stored in central master databases
and transformed into formats that can be pushed to devices, either by and transformed into formats that can be pushed to devices, either by
generating sequences of CLI commands or complete configuration files generating sequences of CLI commands or complete configuration files
that are pushed to devices. There is no common database schema for that are pushed to devices. There is no common database schema for
network configuration, although the models used by various operators network configuration, although the models used by various operators
are probably very similar. Many operators consider it desirable to are probably very similar. Many operators consider it desirable to
extract, document, and standardize the common parts of these network extract, document, and standardize the common parts of these network-
wide configuration database schemas. A protocol designer should wide configuration database schemas. A protocol designer should
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 that vendors may also have proprietary protocol, while recognizing that vendors may also have proprietary
aspects of their configurations. aspects of their configurations.
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 could significantly simplify network configuration devices could 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 to modify candidate configurations on multiple devices,
then activate them in a near-simultaneous manner might help. and then activate them in a near-simultaneous manner might help.
Protocol designers can consider how it would make sense for their Protocol designers can consider how it would make sense for their
protocol to be configured across multiple devices. Configuration- protocol to be configured across multiple devices. Configuration
templates might also be helpful. templates might also be helpful.
Consensus of the 2002 IAB Workshop [RFC3535] was that textual Consensus of the 2002 IAB Workshop [RFC3535] was that textual
configuration files should be able to contain international configuration files should be able to contain international
characters. Human-readable strings should utilize UTF-8, and characters. Human-readable strings should utilize UTF-8, and
protocol elements should be in case insensitive ASCII. protocol elements should 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
generate the operations necessary to get from A to B with minimal generate the operations necessary to get from A to B with minimal
state changes and effects on network and systems. It is important to state changes and effects on network and systems. It is important to
minimize the impact caused by configuration changes. minimize the impact caused by configuration changes.
A protocol designer should consider the configurable items that exist A protocol designer should consider the configurable items that exist
for the control of function via the protocol elements described in for the control of function via the protocol elements described in
the protocol specification. For example, sometimes the protocol the protocol specification. For example, sometimes the protocol
RFC 5706 Ops and Mgmt Guidelines November 2009
requires that timers can be configured by the operator to ensure requires that timers can be configured by the operator to ensure
specific policy-based behavior by the implementation. These timers specific policy-based behavior by the implementation. These timers
should have default values suggested in the protocol specification should have default values suggested in the protocol specification
and may not need to be otherwise configurable. and may not need to be otherwise configurable.
3.4.1. Verifying Correct Operation 3.4.1. Verifying Correct Operation
An important function that should be provided is guidance on how to An important function that should be provided is guidance on how to
verify the correct operation of a protocol. A protocol designer verify the correct operation of a protocol. A protocol designer
could suggest techniques for testing the impact of the protocol on could suggest techniques for testing the impact of the protocol on
the network before it is deployed, and techniques for testing the the network before it is deployed as well as techniques for testing
effect that the protocol has had on the network after being deployed. the effect that the protocol has had on the network after being
deployed.
Protocol designers should consider how to test the correct end-to-end Protocol designers should consider how to test the correct end-to-end
operation of the network or service, and how to verify the correct operation of the service or network, how to verify the correct
functioning of the protocol, whether it is the data or forwarding functioning of the protocol, and whether that is verified by testing
plane function of each network element, or the function of service. the service function and/or by testing the forwarding function of
This may be achieved through status and statistical information each network element. This may be achieved through status and
gathered from devices. statistical information gathered from devices.
3.5. Accounting Management 3.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.
"Introduction to Accounting Management" [RFC2975] discusses a number "Introduction to Accounting Management" [RFC2975] discusses a number
of factors relevant to monitoring usage of protocols for purposes of of factors relevant to monitoring usage of protocols for purposes of
capacity and trend analysis, cost allocation, auditing, and billing. capacity and trend analysis, cost allocation, auditing, and billing.
The document also discusses how some existing protocols can be used The document also discusses how some existing protocols can be used
for these purposes. These factors should be considered when for these purposes. These factors should be considered when
designing a protocol whose usage might need to be monitored, or when designing a protocol whose usage might need to be monitored or when
recommending a protocol to do usage accounting. recommending a protocol to do usage accounting.
3.6. Performance Management 3.6. Performance Management
From a manageability point of view it is important to determine how From a manageability point of view, it is important to determine how
well a network deploying the protocol or technology defined in the well a network deploying the protocol or technology defined in the
document is doing. In order to do this the network operators need to document is doing. In order to do this, the network operators need
consider information that would be useful to determine the to consider information that would be useful to determine the
performance characteristics of a deployed system using the target performance characteristics of a deployed system using the target
protocol. protocol.
The IETF, via the Benchmarking Methodology WG (BMWG), has defined The IETF, via the Benchmarking Methodology WG (BMWG), has defined
recommendations for the measurement of the performance recommendations for the measurement of the performance
characteristics of various internetworking technologies in a characteristics of various internetworking technologies in a
laboratory environment, including the systems or services that are laboratory environment, including the systems or services that are
RFC 5706 Ops and Mgmt Guidelines November 2009
built from these technologies. Each benchmarking recommendation built from these technologies. Each benchmarking recommendation
describes the class of equipment, system, or service being addressed; describes the class of equipment, system, or service being addressed;
discuss the performance characteristics that are pertinent to that discusses the performance characteristics that are pertinent to that
class; clearly identify a set of metrics that aid in the description class; clearly identifies a set of metrics that aid in the
of those characteristics; specify the methodologies required to description of those characteristics; specifies the methodologies
collect said metrics; and lastly, present the requirements for the required to collect said metrics; and lastly, presents the
common, unambiguous reporting of benchmarking results. Search for requirements for the common, unambiguous reporting of benchmarking
"benchmark" in the RFC search tool. results. Search for "benchmark" in the RFC search tool.
Performance metrics may be useful in multiple environments, and for Performance metrics may be useful in multiple environments and for
different protocols. The IETF, via the IP Performance Monitoring different protocols. The IETF, via the IP Performance Monitoring
(IPPM) WG, has developed a set of standard metrics that can be (IPPM) WG, has developed a set of standard metrics that can be
applied to the quality, performance, and reliability of Internet data applied to the quality, performance, and reliability of Internet data
delivery services. These metrics are designed such that they can be delivery services. These metrics are designed such that they can be
performed by network operators, end users, or independent testing performed by network operators, end users, or independent testing
groups. The existing metrics might be applicable to the new groups. The existing metrics might be applicable to the new
protocol. Search for "metric" in the RFC search tool. In some protocol. Search for "metric" in the RFC search tool. In some
cases, new metrics need to be defined. It would be useful if the cases, new metrics need to be defined. It would be useful if the
protocol documentation identified the need for such new metrics. For protocol documentation identified the need for such new metrics. For
performance monitoring, it is often important to report the time performance monitoring, it is often important to report the time
spent in a state rather than the current state. Snapshots are of spent in a state, rather than reporting the current state. Snapshots
less value for performance monitoring. are of less value for performance monitoring.
There are several parts to performance management to be considered: There are several parts to performance management to be considered:
protocol monitoring, device monitoring (the impact of the new protocol monitoring, device monitoring (the impact of the new
protocol/service activation on the device), network monitoring, and protocol / service activation on the device), network monitoring, and
service monitoring (the impact of service activation on the network). service monitoring (the impact of service activation on the network).
3.6.1. Monitoring the Protocol 3.6.1. Monitoring the Protocol
Certain properties of protocols are useful to monitor. The number of Certain properties of protocols are useful to monitor. The number of
protocol packets received, the number of packets sent, and the number protocol packets received, the number of packets sent, and the number
of packets dropped are usually very helpful to operators. of packets dropped are usually very helpful to operators.
Packet drops should be reflected in counter variable(s) somewhere Packet drops should be reflected in counter variable(s) somewhere
that can be inspected - both from the security point of view and from that can be inspected -- both from the security point of view and
the troubleshooting point of view. from the troubleshooting point of view.
Counter definitions should be unambiguous about what is included in Counter definitions should be unambiguous about what is included in
the count, and what is not included in the count. the count and what is not included in the count.
Consider the expected behaviors for counters - what is a reasonable Consider the expected behaviors for counters -- what is a reasonable
maximum value for expected usage? Should they stop counting at the maximum value for expected usage? Should they stop counting at the
maximum value and retain the maximum value, or should they rollover? maximum value and retain the maximum value, or should they rollover?
How can users determine if a rollover has occurred, and how can users How can users determine if a rollover has occurred, and how can users
determine if more than one rollover has occurred? determine if more than one rollover has occurred?
RFC 5706 Ops and Mgmt Guidelines November 2009
Consider whether multiple management applications will share a Consider whether multiple management applications will share a
counter; if so, then no one management application should be allowed counter; if so, then no one management application should be allowed
to reset the value to zero since this will impact other applications. to reset the value to zero since this will impact other applications.
Could events, such as hot-swapping a blade in a chassis, cause Could events, such as hot-swapping a blade in a chassis, cause
discontinuities in counter? Does this make any difference in discontinuities in counter? Does this make any difference in
evaluating the performance of a protocol? evaluating the performance of a protocol?
The protocol document should make clear the limitations implicit The protocol document should make clear the limitations implicit
within the protocol and the behavior when limits are exceeded. This within the protocol and the behavior when limits are exceeded. This
should be considered in a data-modeling independent manner - what should be considered in a data-modeling-independent manner -- what
makes managed-protocol sense, not what makes management-protocol- makes managed-protocol sense, not what makes management-protocol-
sense. If constraints are not managed-protocol-dependent, then it sense. If constraints are not managed-protocol-dependent, then it
should be left for the management-protocol data modelers to decide. should be left for the management-protocol data modelers to decide.
For example, VLAN identifiers have a range of 1..4095 because of the For example, VLAN identifiers have a range of 1..4095 because of the
VLAN standards. A MIB implementing a VLAN table should be able to VLAN standards. A MIB implementing a VLAN table should be able to
support 4096 entries because the content being modeled requires it. support 4096 entries because the content being modeled requires it.
3.6.2. Monitoring the Device 3.6.2. Monitoring the Device
Consider whether device performance will be affected by the number of Consider whether device performance will be affected by the number of
skipping to change at page 25, line 30 skipping to change at page 24, line 48
number of instances, and the expected behavior when the current number of instances, and the expected behavior when the current
instances exceed the capacity of the device. instances exceed the capacity of the device.
3.6.3. Monitoring the Network 3.6.3. Monitoring the Network
Consider whether network performance will be affected by the number Consider whether network performance will be affected by the number
of protocol entities being deployed. of protocol entities being deployed.
Consider the capability of determining the operational activity, such Consider the capability of determining the operational activity, such
as the number of messages in and the messages out, the number of as the number of messages in and the messages out, the number of
received messages rejected due to format problems, the expected received messages rejected due to format problems, and the expected
behaviors when a malformed message is received. behaviors when a malformed message is received.
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 operational performance of the network built using when measuring the operational performance of the network built using
the protocol? Is it important to measure setup times? end-to-end the protocol? Is it important to measure setup times? End-to-end
connectivity? hop-to-hop connectivity? network throughput? connectivity? Hop-to-hop connectivity? Network throughput?
RFC 5706 Ops and Mgmt Guidelines November 2009
3.6.4. Monitoring the Service 3.6.4. Monitoring the Service
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 performance of a service using the protocol? Is when measuring the performance of a service using the protocol? Is
it important to measure application-specific throughput? client- it important to measure application-specific throughput? Client-
server associations? end-to-end application quality? service server associations? End-to-end application quality? Service
interruptions? user experience? interruptions? User experience?
3.7. Security Management 3.7. Security Management
Protocol designers should consider how to monitor and to manage Protocol designers should consider how to monitor and manage security
security aspects and vulnerabilities of the new protocol. aspects and vulnerabilities of the new protocol.
There will be security considerations related to the new protocol. There will be security considerations related to the new protocol.
To make it possible for operators to be aware of security-related To make it possible for operators to be aware of security-related
events, it is recommended that system logs should record events, such events, it is recommended that system logs should record events, such
as failed logins, but the logs must be secured. as failed logins, but the logs must be secured.
Should a system automatically notify operators of every event Should a system automatically notify operators of every event
occurrence, or should an operator-defined threshold control when a occurrence, or should an operator-defined threshold control when a
notification is sent to an operator? notification is sent to an operator?
Should certain statistics be collected about the operation of the new Should certain statistics be collected about the operation of the new
protocol that might be useful for detecting attacks, such as the protocol that might be useful for detecting attacks, such as the
skipping to change at page 26, line 15 skipping to change at page 25, line 31
To make it possible for operators to be aware of security-related To make it possible for operators to be aware of security-related
events, it is recommended that system logs should record events, such events, it is recommended that system logs should record events, such
as failed logins, but the logs must be secured. as failed logins, but the logs must be secured.
Should a system automatically notify operators of every event Should a system automatically notify operators of every event
occurrence, or should an operator-defined threshold control when a occurrence, or should an operator-defined threshold control when a
notification is sent to an operator? notification is sent to an operator?
Should certain statistics be collected about the operation of the new Should certain statistics be collected about the operation of the new
protocol that might be useful for detecting attacks, such as the protocol that might be useful for detecting attacks, such as the
receipt of malformed messages, or messages out of order, or messages receipt of malformed messages, messages out of order, or messages
with invalid timestamps? If such statistics are collected, is it with invalid timestamps? If such statistics are collected, is it
important to count them separately for each sender to help identify important to count them separately for each sender to help identify
the source of attacks? the source of attacks?
Manageability considerations that are security-oriented might include Manageability considerations that are security-oriented might include
discussion of the security implications when no monitoring is in discussion of the security implications when no monitoring is in
place, the regulatory implications of absence of audit-trail or logs place, the regulatory implications of absence of audit-trail or logs
in enterprises, exceeding the capacity of logs, and security in enterprises, exceeding the capacity of logs, and security
exposures present in chosen / recommended management mechanisms. exposures present in chosen/recommended management mechanisms.
Consider security threats that may be introduced by management Consider security threats that may be introduced by management
operations. For example CAPWAP breaks the structure of monolithic operations. For example, Control and Provisioning of Wireless Access
Access Points (AP) into Access Controllers and Wireless Termination Points (CAPWAP) breaks the structure of monolithic Access Points
Points (WTP). By using a management interface, internal information (APs) into Access Controllers and Wireless Termination Points (WTPs).
that was previously not accessible is now exposed over the network By using a management interface, internal information that was
and to management applications and may become a source of potential previously not accessible is now exposed over the network and to
security threats. management applications and may become a source of potential security
threats.
RFC 5706 Ops and Mgmt Guidelines November 2009
The granularity of access control needed on management interfaces The granularity of access control needed on management interfaces
needs to match operational needs. Typical requirements are a role- needs to match operational needs. Typical requirements are a role-
based access control model and the principle of least privilege, based access control model and the principle of least privilege,
where a user can be given only the minimum access necessary to where a user can be given only the minimum access necessary to
perform a required task. perform a required task.
Some operators wish to do consistency checks of access control lists Some operators wish to do consistency checks of access control lists
across devices. Protocol designers should consider information across devices. Protocol designers should consider information
models to promote comparisons across devices and across vendors to models to promote comparisons across devices and across vendors to
permit checking the consistency of security configurations. permit checking the consistency of security configurations.
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 that integrates well
with existing key and credential management infrastructure. It is a with existing key and credential management infrastructure. It is a
good idea to start with defining the threat model for the protocol, good idea to start with defining the threat model for the protocol,
and from that deducing what is required. and from that deducing what is required.
Protocol designers should consider how access control lists are Protocol designers should consider how access control lists are
maintained and updated. maintained and updated.
Standard SNMP notifications or SYSLOG messages [RFC5424] might Standard SNMP notifications or syslog messages [RFC5424] might
already exist, or can be defined, to alert operators to the already exist, or can be defined, to alert operators to the
conditions identified in the security considerations for the new conditions identified in the security considerations for the new
protocol. For example, you can log all the commands entered by the protocol. For example, you can log all the commands entered by the
operator using syslog (giving you some degree of audit trail), or you operator using syslog (giving you some degree of audit trail), or you
can see who has logged on/off using SSH from where, failed SSH logins can see who has logged on/off using the Secure SHell Protocol (SSH)
can be logged using syslog, etc. and from where; failed SSH logins can be logged using syslog, etc.
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.
Different management protocols use different assumptions about Different management protocols use different assumptions about
message security and data access controls. A protocol designer that message security and data-access controls. A protocol designer that
recommends using different protocols should consider how security recommends using different protocols should consider how security
will be applied in a balanced manner across multiple management will be applied in a balanced manner across multiple management
interfaces. SNMP authority levels and policy are data-oriented, interfaces. SNMP authority levels and policy are data-oriented,
while CLI authority levels and policy are usually command (task) while CLI authority levels and policy are usually command-oriented
oriented. Depending on the management function, sometimes data- (i.e., task-oriented). Depending on the management function,
oriented or task-oriented approaches make more sense. Protocol sometimes data-oriented or task-oriented approaches make more sense.
designers should consider both data-oriented and task-oriented Protocol designers should consider both data-oriented and task-
authority levels and policy. oriented authority levels and policy.
4. Documentation Guidelines 4. Documentation Guidelines
This document is focused on what to think about, and how to document This document is focused on what a protocol designer should think
the considerations of the protocol designer. about and how those considerations might be documented.
RFC 5706 Ops and Mgmt Guidelines November 2009
This document does not describe interoperability requirements but
rather describes practices that are useful to follow when dealing
with manageability aspects in IETF documents, so the capitalized
keywords from [RFC2119] do not apply here. Any occurrence of words
like 'must' or 'should' needs to be interpreted only in the context
of their natural, English-language meaning.
4.1. Recommended Discussions 4.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 Existing protocols and data models can provide the management
functions identified in the previous section. Protocol designers functions identified in the previous section. Protocol designers
should consider how using existing protocols and data models might should consider how using existing protocols and data models might
impact network operations. impact network operations.
4.2. Null Manageability Considerations Sections 4.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 group regarding the manageability of the protocol at the
of its design. time of its design.
If there are no new manageability or deployment considerations, it is If there are no new manageability or deployment considerations, it is
recommended that a Manageability Considerations section contain a recommended that a Manageability Considerations section contain a
simple statement such as "There are no new manageability requirements simple statement such as, "There are no new manageability
introduced by this document," and a brief explanation of why that is requirements introduced by this document," and a brief explanation of
the case. The presence of such a Manageability Considerations why that is the case. The presence of such a Manageability
section would indicate to the reader that due consideration has been Considerations section would indicate to the reader that due
given to manageability and operations. consideration has been given to manageability and operations.
In the case where the new protocol is an extension, and the base In the case where the new protocol is an extension and the base
protocol discusses all the relevant operational and manageability protocol discusses all the relevant operational and manageability
considerations, it would be helpful to point out the considerations considerations, it would be helpful to point out the considerations
section in the base document. section in the base document.
RFC 5706 Ops and Mgmt Guidelines November 2009
4.3. Placement of Operations and Manageability Considerations Sections 4.3. Placement of Operations and Manageability Considerations Sections
If a protocol designer develops a Manageability Considerations If a protocol designer develops a Manageability Considerations
section for a new protocol, it is recommended that the section be section for a new protocol, it is recommended that the section be
placed immediately before the Security Considerations section. placed immediately before the Security Considerations section.
Reviewers interested in such sections could find it easily, and this Reviewers interested in such sections could find it easily, and this
placement could simplify the development of tools to detect the placement could simplify the development of tools to detect the
presence of such a section. presence of such a section.
5. IANA Considerations 5. Security Considerations
This document does not introduce any new codepoints or name spaces
for registration with IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
This document is informational and provides guidelines for This document is informational and provides guidelines for
considering manageability and operations. It introduces no new considering manageability and operations. It introduces no new
security concerns. security concerns.
The provision of a management portal to a network device provides a The provision of a management portal to a network device provides a
doorway through which an attack on the device may be launched. doorway through which an attack on the device may be launched.
Making the protocol under development be manageable through a Making the protocol under development be manageable through a
management protocol creates a vulnerability to a new source of management protocol creates a vulnerability to a new source of
attacks. Only management protocols with adequate security apparatus, attacks. Only management protocols with adequate security apparatus,
such as authentication, message integrity checking, and authorization such as authentication, message integrity checking, and
should be used. authorization, should be used.
A standard description of the manageable knobs and whistles on a A standard description of the manageable knobs and whistles on a
protocol makes it easier for an attacker to understand what they may protocol makes it easier for an attacker to understand what they may
try to control and how to tweak it. try to control and how to tweak it.
A well-designed protocol is usually more stable and secure. A A well-designed protocol is usually more stable and secure. A
protocol that can be managed and inspected offers the operator a protocol that can be managed and inspected offers the operator a
better chance of spotting and quarantining any attacks. Conversely better chance of spotting and quarantining any attacks. Conversely,
making a protocol easy to inspect is a risk if the wrong person making a protocol easy to inspect is a risk if the wrong person
inspects it. inspects it.
If security events cause logs and or notifications/alerts, a If security events cause logs and/or notifications/alerts, a
concerted attack might be able to be mounted by causing an excess of concerted attack might be able to be mounted by causing an excess of
these events. In other words, the security management mechanisms these events. In other words, the security-management mechanisms
could constitute a security vulnerability. The management of could constitute a security vulnerability. The management of
security aspects is important (see Section 3.7). security aspects is important (see Section 3.7).
7. Acknowledgements 6. Acknowledgements
This document started from an earlier document edited by Adrian This document started from an earlier document edited by Adrian
Farrel, which itself was based on work exploring the need for Farrel, which itself was based on work exploring the need for
Manageability Considerations sections in all Internet-Drafts produced Manageability Considerations sections in all Internet-Drafts produced
within the Routing Area of the IETF. That earlier work was produced within the Routing Area of the IETF. That earlier work was produced
by Avri Doria, Loa Andersson, and Adrian Farrel, with valuable by Avri Doria, Loa Andersson, and Adrian Farrel, with valuable
feedback provided by Pekka Savola and Bert Wijnen. feedback provided by Pekka Savola and Bert Wijnen.
RFC 5706 Ops and Mgmt Guidelines November 2009
Some of the discussion about designing for manageability came from Some of the discussion about designing for manageability came from
private discussions between Dan Romascanu, Bert Wijnen, Juergen private discussions between Dan Romascanu, Bert Wijnen, Juergen
Schoenwaelder, Andy Bierman, and David Harrington. Schoenwaelder, Andy Bierman, and David Harrington.
Thanks to reviewers who helped fashion this document, including Thanks to reviewers who helped fashion this document, including
Harald Alvestrand, Ron Bonica, Brian Carpenter, Benoit Claise, Adrian Harald Alvestrand, Ron Bonica, Brian Carpenter, Benoit Claise, Adrian
Farrell, David Kessens, Dan Romascanu, Pekka Savola, Juergen Farrel, David Kessens, Dan Romascanu, Pekka Savola, Juergen
Schoenwaelder, Bert Wijnen, Ralf Wolter, and Lixia Zhang. Schoenwaelder, Bert Wijnen, Ralf Wolter, and Lixia Zhang.
8. Informative References 7. Informative References
[RFC1034] Mockapetris, P., "Domain names - [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
concepts and facilities", STD 13, STD 13, RFC 1034, November 1987.
RFC 1034, November 1987.
[RFC1052] Cerf, V., "IAB recommendations for [RFC1052] Cerf, V., "IAB recommendations for the development of
the development of Internet network Internet network management standards", RFC 1052,
management standards", RFC 1052, April 1988.
April 1988.
[RFC1958] Carpenter, B., "Architectural [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
Principles of the Internet", RFC 1958, June 1996.
RFC 1958, June 1996.
[RFC2113] Katz, D., "IP Router Alert Option", [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
RFC 2113, February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
RFCs to Indicate Requirement Levels", Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Herzog, S., and S. Jamin, "Resource Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
ReSerVation Protocol (RSVP) -- Functional Specification", RFC 2205, September 1997.
Version 1 Functional Specification",
RFC 2205, September 1997.
[RFC2439] Villamizar, C., Chandra, R., and R. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Govindan, "BGP Route Flap Damping", Flap Damping", RFC 2439, November 1998.
RFC 2439, November 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Ed., and J. Schoenwaelder, Ed., Schoenwaelder, Ed., "Structure of Management Information
"Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
Router Alert Option", RFC 2711, RFC 2711, October 1999.
October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
and W. Simpson, "Remote "Remote Authentication Dial In User Service (RADIUS)",
Authentication Dial In User Service RFC 2865, June 2000.
(RADIUS)", RFC 2865, June 2000.
[RFC2975] Aboba, B., Arkko, J., and D. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to
Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
Accounting Management", RFC 2975,
October 2000.
[RFC3060] Moore, B., Ellesson, E., Strassner, RFC 5706 Ops and Mgmt Guidelines November 2009
J., and A. Westerinen, "Policy Core
Information Model -- Version 1
Specification", RFC 3060,
February 2001.
[RFC3084] Chan, K., Seligson, J., Durham, D., [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen,
Gai, S., McCloghrie, K., Herzog, S., "Policy Core Information Model -- Version 1
Reichmeyer, F., Yavatkar, R., and A. Specification", RFC 3060, February 2001.
Smith, "COPS Usage for Policy
Provisioning (COPS-PR)", RFC 3084,
March 2001.
[RFC3139] Sanchez, L., McCloghrie, K., and J. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
Saperia, "Requirements for K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Configuration Management of IP-based Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
Networks", RFC 3139, June 2001. RFC 3084, March 2001.
[RFC3198] Westerinen, A., Schnizlein, J., [RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements
Strassner, J., Scherling, M., Quinn, for Configuration Management of IP-based Networks",
B., Herzog, S., Huynh, A., Carlson, RFC 3139, June 2001.
M., Perry, J., and S. Waldbusser,
"Terminology for Policy-Based
Management", RFC 3198, November 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., [RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling,
and A. Smith, "An Informal Management M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry,
Model for Diffserv Routers", J., and S. Waldbusser, "Terminology for Policy-Based
RFC 3290, May 2002. Management", RFC 3198, November 2001.
[RFC3410] Case, J., Mundy, R., Partain, D., and [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
B. Stewart, "Introduction and Informal Management Model for Diffserv Routers", RFC 3290,
Applicability Statements for May 2002.
Internet-Standard Management
Framework", RFC 3410, December 2002.
[RFC3444] Pras, A. and J. Schoenwaelder, "On [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
the Difference between Information "Introduction and Applicability Statements for Internet-
Models and Data Models", RFC 3444, Standard Management Framework", RFC 3410, December 2002.
January 2003.
[RFC3460] Moore, B., "Policy Core Information [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Model (PCIM) Extensions", RFC 3460, Information Models and Data Models", RFC 3444,
January 2003. January 2003.
[RFC3535] Schoenwaelder, J., "Overview of the [RFC3460] Moore, B., "Policy Core Information Model (PCIM)
2002 IAB Network Management Extensions", RFC 3460, January 2003.
Workshop", RFC 3535, May 2003.
[RFC3585] Jason, J., Rafalow, L., and E. [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Vyncke, "IPsec Configuration Policy Management Workshop", RFC 3535, May 2003.
Information Model", RFC 3585,
August 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, [RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec
E., Zorn, G., and J. Arkko, "Diameter Configuration Policy Information Model", RFC 3585,
Base Protocol", RFC 3588, August 2003.
September 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Cohen, R., and B. Moore, "Policy Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
Quality of Service (QoS) Information
Model", RFC 3644, November 2003.
[RFC3670] Moore, B., Durham, D., Strassner, J., [RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B.
Westerinen, A., and W. Weiss, Moore, "Policy Quality of Service (QoS) Information
"Information Model for Describing Model", RFC 3644, November 2003.
Network Device QoS Datapath
Mechanisms", RFC 3670, January 2004.
[RFC3805] Bergman, R., Lewis, H., and I. RFC 5706 Ops and Mgmt Guidelines November 2009
McDonald, "Printer MIB v2", RFC 3805,
June 2004.
[RFC4741] Enns, R., "NETCONF Configuration [RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and
Protocol", RFC 4741, December 2006. W. Weiss, "Information Model for Describing Network Device
QoS Datapath Mechanisms", RFC 3670, January 2004.
[RFC5101] Claise, B., "Specification of the IP [RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2",
Flow Information Export (IPFIX) RFC 3805, June 2004.
Protocol for the Exchange of IP
Traffic Flow Information", RFC 5101,
January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
Protocol", RFC 5321, October 2008. December 2006.
[RFC5424] Gerhards, R., "The Syslog Protocol", [RFC5101] Claise, B., "Specification of the IP Flow Information
RFC 5424, March 2009. Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[W3C.REC-xmlschema-0-20010502] Fallside, D., "XML Schema Part 0: [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
Primer", World Wide Web Consortium October 2008.
FirstEdition REC-xmlschema-0-
20010502, May 2001, <http:// [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
www.w3.org/TR/2001/
REC-xmlschema-0-20010502>. [W3C.REC-xmlschema-0-20010502]
Fallside, D., "XML Schema Part 0: Primer", World Wide Web
Consortium FirstEdition REC-xmlschema-0-20010502,
May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-0-20010502>.
RFC 5706 Ops and Mgmt Guidelines November 2009
Appendix A. Operations and Management Review Checklist Appendix A. Operations and Management Review Checklist
This appendix provides a quick checklist of issues that protocol This appendix provides a quick checklist of issues that protocol
designers should expect operations and management expert reviewers to designers should expect operations and management expert reviewers to
look for when reviewing a document being proposed for consideration look for when reviewing a document being proposed for consideration
as a protocol standard. as a protocol standard.
A.1. Operational Considerations A.1. Operational Considerations
Has deployment been discussed? see Section 2.1 1. Has deployment been discussed? See Section 2.1.
Does the document include a description of how this protocol or
technology is going to be deployed and managed?
Is the proposed specification deployable? If not, how could it be * Does the document include a description of how this protocol
improved? or technology is going to be deployed and managed?
Does the solution scale well from the operational and management * Is the proposed specification deployable? If not, how could
perspective? Does the proposed approach have any scaling issues it be improved?
that could affect usability for large scale operation?
Are there any coexistence issues? * Does the solution scale well from the operational and
management perspective? Does the proposed approach have any
scaling issues that could affect usability for large-scale
operation?
Has installation and initial setup been discussed? see Section 2.2 * Are there any coexistence issues?
Is the solution sufficiently configurable? 2. Has installation and initial setup been discussed? See
Section 2.2.
Are configuration parameters clearly identified? * Is the solution sufficiently configurable?
Are configuration parameters normalized? * Are configuration parameters clearly identified?
Does each configuration parameter have a reasonable default value? * Are configuration parameters normalized?
Will configuration be pushed to a device by a configuration * Does each configuration parameter have a reasonable default
manager, or pulled by a device from a configuration server? value?
How will the devices and managers find and authenticate each * Will configuration be pushed to a device by a configuration
other? manager, or pulled by a device from a configuration server?
Has the migration path been discussed? see Section 2.3 * How will the devices and managers find and authenticate each
other?
Are there any backward compatibility issues? 3. Has the migration path been discussed? See Section 2.3.
Have the Requirements on Other Protocols and Functional Components * Are there any backward compatibility issues?
been discussed? see Section 2.4.
What protocol operations are expected to be performed relative to 4. Have the Requirements on other protocols and functional
the new protocol or technology, and what protocols and data models components been discussed? See Section 2.4.
are expected to be in place or recommended to ensure for
interoperable management?
Has the Impact on Network Operation been discussed? see Section 2.5 RFC 5706 Ops and Mgmt Guidelines November 2009
Will the new protocol significantly increase traffic load on * What protocol operations are expected to be performed relative
existing networks? to the new protocol or technology, and what protocols and data
models are expected to be in place or recommended to ensure
for interoperable management?
Will the proposed management for the new protocol significantly 5. Has the impact on network operation been discussed? See
increase traffic load on existing networks? Section 2.5.
How will the new protocol impact the behavior of other protocols
in the network? Will it impact performance (e.g. jitter) of
certain types of applications running in the same network?
Does the new protocol need supporting services (e.g. DNS or AAA) * Will the new protocol significantly increase traffic load on
added to an existing network? existing networks?
Have suggestions for verifying correct operation been discussed? see * Will the proposed management for the new protocol
Section 2.6 significantly increase traffic load on existing networks?
How can one test end-to-end connectivity and throughput? * How will the new protocol impact the behavior of other
protocols in the network? Will it impact performance (e.g.,
jitter) of certain types of applications running in the same
network?
Which metrics are of interest? * Does the new protocol need supporting services (e.g., DNS or
Authentication, Authorization, and Accounting - AAA) added to
an existing network?
Will testing have an impact on the protocol or the network? 6. Have suggestions for verifying correct operation been discussed?
See Section 2.6.
Has management interoperability been discussed? see Section 3.1 * How can one test end-to-end connectivity and throughput?
Is a standard protocol needed for interoperable management? * Which metrics are of interest?
Is a standard information or data model needed to make properties * Will testing have an impact on the protocol or the network?
comparable across devices from different vendors?
Are there fault or threshold conditions that should be reported? see 7. Has management interoperability been discussed? See Section 3.1.
Section 3.3
Does specific management information have time utility? * Is a standard protocol needed for interoperable management?
Should the information be reported by notifications? polling? * Is a standard information or data model needed to make
event-driven polling? properties comparable across devices from different vendors?
Is notification throttling discussed? 8. Are there fault or threshold conditions that should be reported?
See Section 3.3.
Is there support for saving state that could be used for root- * Does specific management information have time utility?
cause analysis?
Is configuration discussed? see Section 3.4 * Should the information be reported by notifications? Polling?
Event-driven polling?
Are configuration defaults, and default modes of operation * Is notification throttling discussed?
considered?
Is there discussion of what information should be preserved across RFC 5706 Ops and Mgmt Guidelines November 2009
reboots of the device or the management system? Can devices
realistically preserve this information through hard reboots where * Is there support for saving state that could be used for root
physical configuration might change (e.g. cards might be swapped cause analysis?
while a chassis is powered down)?
9. Is configuration discussed? See Section 3.4.
* Are configuration defaults and default modes of operation
considered?
* Is there discussion of what information should be preserved
across reboots of the device or the management system? Can
devices realistically preserve this information through hard
reboots where physical configuration might change (e.g., cards
might be swapped while a chassis is powered down)?
A.2. Management Considerations A.2. Management Considerations
Do you anticipate any manageability issues with the specification? Do you anticipate any manageability issues with the specification?
Is Management interoperability discussed? see Section 3.1 1. Is management interoperability discussed? See Section 3.1.
Will it use centralized or distributed management? * Will it use centralized or distributed management?
Will it require remote and/or local management applications? * Will it require remote and/or local management applications?
Are textual or graphical user interfaces required? * Are textual or graphical user interfaces required?
Is textual or binary format for management information * Is textual or binary format for management information
preferred? preferred?
Is Management Information discussed? see Section 3.2 2. Is management information discussed? See Section 3.2.
What is the minimal set of management (configuration, faults, * What is the minimal set of management (configuration, faults,
performance monitoring) objects that need to be instrumented in performance monitoring) objects that need to be instrumented
order to manage the new protocol? in order to manage the new protocol?
Is Fault Management discussed? see Section 3.3 3. Is fault management discussed? See Section 3.3.
Is Liveness Detection and Monitoring discussed? * Is Liveness Detection and Monitoring discussed?
Does the solution have failure modes that are difficult to * Does the solution have failure modes that are difficult to
diagnose or correct? Are faults and alarms reported and diagnose or correct? Are faults and alarms reported and
logged? logged?
Is Configuration Management discussed? see Section 3.4 4. Is configuration management discussed? See Section 3.4.
Is protocol state information exposed to the user? How? are * Is protocol state information exposed to the user? How? Are
significant state transitions logged? significant state transitions logged?
Is Accounting Management discussed? see Section 3.5 RFC 5706 Ops and Mgmt Guidelines November 2009
Is Performance Management discussed? see Section 3.6 5. Is accounting management discussed? See Section 3.5.
Does the protocol have an impact on network traffic and network 6. Is performance management discussed? See Section 3.6.
devices? Can performance be measured?
Is protocol performance information exposed to the user?
Is Security Management discussed? see Section 3.7 * Does the protocol have an impact on network traffic and
network devices? Can performance be measured?
Does the specification discuss how to manage aspects of * Is protocol performance information exposed to the user?
security, such as access controls, managing key distribution,
etc. 7. Is security management discussed? See Section 3.7.
* Does the specification discuss how to manage aspects of
security, such as access controls, managing key distribution,
etc.
A.3. Documentation A.3. Documentation
Is an operational considerations and/or manageability section part of Is an operational considerations and/or manageability section part of
the document? the document?
Does the proposed protocol have a significant operational impact on Does the proposed protocol have a significant operational impact on
the Internet? the Internet?
Is there proof of implementation and/or operational experience? Is there proof of implementation and/or operational experience?
Author's Address Author's Address
David Harrington David Harrington
HuaweiSymantec USA HuaweiSymantec USA
20245 Stevens Creek Blvd 20245 Stevens Creek Blvd
Cupertino, CA 95014 Cupertino, CA 95014
USA USA
Phone: +1 603 436 8634 Phone: +1 603 436 8634
Fax:
EMail: ietfdbh@comcast.net EMail: ietfdbh@comcast.net
URI:
 End of changes. 249 change blocks. 
587 lines changed or deleted 626 lines changed or added

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