draft-ietf-opsawg-operations-and-management-06.txt   draft-ietf-opsawg-operations-and-management-07.txt 
Network Working Group D. Harrington Network Working Group D. Harrington
Internet-Draft Huawei Technologies USA Internet-Draft Huawei Technologies USA
Intended status: BCP March 9, 2009 Intended status: BCP May 11, 2009
Expires: September 10, 2009 Expires: November 12, 2009
Guidelines for Considering Operations and Management of New Protocols Guidelines for Considering Operations and Management of New Protocols
and Protocol Extensions and Protocol Extensions
draft-ietf-opsawg-operations-and-management-06 draft-ietf-opsawg-operations-and-management-07
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on November 12, 2009.
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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 20 skipping to change at page 3, line 20
4. Documentation Guidelines . . . . . . . . . . . . . . . . . . . 25 4. Documentation Guidelines . . . . . . . . . . . . . . . . . . . 25
4.1. Recommended Discussions . . . . . . . . . . . . . . . . . 25 4.1. Recommended Discussions . . . . . . . . . . . . . . . . . 25
4.2. Null Manageability Considerations Sections . . . . . . . . 25 4.2. Null Manageability Considerations Sections . . . . . . . . 25
4.3. Placement of Operations and Manageability 4.3. Placement of Operations and Manageability
Considerations Sections . . . . . . . . . . . . . . . . . 26 Considerations Sections . . . . . . . . . . . . . . . . . 26
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
8. Informative References . . . . . . . . . . . . . . . . . . . . 27 8. Informative References . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Operations and Management Review Checklist . . . . . 30 Appendix A. Operations and Management Review Checklist . . . . . 30
A.1. Operational Considerations . . . . . . . . . . . . . . . . 31 A.1. Operational Considerations . . . . . . . . . . . . . . . . 30
A.2. Management Considerations . . . . . . . . . . . . . . . . 33 A.2. Management Considerations . . . . . . . . . . . . . . . . 32
A.3. Documentation . . . . . . . . . . . . . . . . . . . . . . 34 A.3. Documentation . . . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Often when new protocols or protocol extensions are developed, not Often when new protocols or protocol extensions are developed, not
enough consideration is given to how the protocol will be deployed, enough consideration is given to how the protocol will be deployed,
operated and managed. Retrofitting operations and management operated and managed. Retrofitting operations and management
mechanisms is often hard and architecturally unpleasant, and certain mechanisms is often hard and architecturally unpleasant, and certain
protocol design choices may make deployment, operations, and protocol design choices may make deployment, operations, and
management particularly hard. Since the ease of operations and management particularly hard. Since the ease of operations and
skipping to change at page 7, line 9 skipping to change at page 7, line 9
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 doing network management. standard protocols for doing network management.
1.5. Available Management Technologies 1.5. Available Management Technologies
The IETF has a number of standard management technologies available. The IETF has a number of standard management technologies available.
These include SNMP, SYSLOG, RADIUS, DIAMETER, NETCONF, IPFIX, and These include SNMP, SYSLOG, RADIUS, DIAMETER, NETCONF, IPFIX, and
others. These protocol standards, pointers to the documents that others.
define them, and standard information and data models for specific
functionality, are described in "Survey of IETF Network Management
Standards" [I-D.ietf-opsawg-survey-management]
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 document is a set of guidelines
skipping to change at page 8, line 13 skipping to change at page 8, line 10
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.
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, most places turned flap damping loss of reachability. As a result, many networks turned flap damping
off. Some Regional Internet Registries issued an official off.
recommendation for turning it off.
2.1. Operations Model 2.1. Operations Model
Protocol designers can analyze the operational environment and mode Protocol designers can analyze the operational environment and mode
of work in which the new protocol or extension will work. Such an of work in which the new protocol or extension will work. Such an
exercise 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 the operational model related to the but could help in visualizing the operational model related to the
applicability of the protocol in the Internet environments where it applicability of the protocol in the Internet environments where it
will be deployed. will be deployed.
skipping to change at page 10, line 32 skipping to change at page 10, line 30
For example, the design of Resource ReSerVation Protocol (RSVP) For example, the design of 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, to add its own address to the message
to enable automatically tunneling through non-RSVP routers. But in to enable automatically tunneling through non-RSVP routers. But in
reality routers cannot look at an otherwise normal IP packet, and reality routers cannot look at an otherwise normal IP packet, and
potentially take it off the fast path! The initial designers potentially take it off the fast path! The initial designers
overlooked that a new "deep packet inspection" requirement was being overlooked that a new "deep packet inspection" requirement was being
put on the functional components of a router. The "router alert" put on the functional components of a router. The "router alert"
option was finally developed to solve this problem for RSVP and other option was finally developed to solve this problem for RSVP and other
protocols that require the router to take some packets off the fast protocols that require the router to take some packets off the fast
forwarding path. forwarding path. Router alert has its own 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 at the cost don't pay attention, we might get very good accuracy, but could send
of using all the available bandwidth. 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 components that are added to the network as result of the changes in
the operational model, such as servers performing auto-configuration the operational model, such as servers performing auto-configuration
operations. operations.
The protocol designer should consider also the impact on The protocol designer should consider also the impact on
skipping to change at page 14, line 27 skipping to change at page 14, line 25
and others and others
and and
NETCONF Configuration Protocol [RFC4741] NETCONF Configuration Protocol [RFC4741]
IP Flow Information Export (IPFIX) Protocol [RFC5101]) for usage IP Flow Information Export (IPFIX) Protocol [RFC5101]) for usage
accounting accounting
The syslog Protocol [I-D.ietf-syslog-protocol] for logging The syslog Protocol [RFC5424] for logging
and others and others
Interoperability needs to be considered on the syntactic level and Interoperability needs to be considered on the syntactic level and
the semantic level. While it can be irritating and time-consuming, the semantic level. While it can be irritating and time-consuming,
application designers including operators who write their own scripts application designers including operators who write their own scripts
can make their processing conditional to accommodate syntactic can make their processing conditional to accommodate syntactic
differences across vendors or models or releases of product. differences across vendors or models or releases of product.
Semantic differences are much harder to deal with on the manager side Semantic differences are much harder to deal with on the manager side
skipping to change at page 25, line 5 skipping to change at page 25, line 5
Protocol designers should consider how to provide a secure transport, Protocol designers should consider how to provide a secure transport,
authentication, identity, and access control which integrates well authentication, identity, and access control which integrates well
with existing key and credential management infrastructure. 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 Standard SNMP notifications or SYSLOG messages [RFC5424] might
[I-D.ietf-syslog-protocol] might already exist, or can be defined, to already exist, or can be defined, to alert operators to the
alert operators to the conditions identified in the security conditions identified in the security considerations for the new
considerations for the new protocol. For example, you can log all protocol. For example, you can log all the commands entered by the
the commands entered by the operator using syslog (giving you some operator using syslog (giving you some degree of audit trail), or you
degree of audit trail), or you can see who has logged on/off using can see who has logged on/off using SSH from where, failed SSH logins
SSH from where, failed SSH logins can be logged using syslog, etc. 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,
skipping to change at page 27, line 41 skipping to change at page 27, line 41
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
Adrian Farrell, David Kessens, Dan Romascanu, Ron Bonica, Bert Adrian Farrell, David Kessens, Dan Romascanu, Ron Bonica, Bert
Wijnen, Lixia Zhang, Ralf Wolter, Benoit Claise, Brian Carpenter, Wijnen, Lixia Zhang, Ralf Wolter, Benoit Claise, Brian Carpenter,
Harald Alvestrand, Juergen Schoenwaelder, and Pekka Savola. Harald Alvestrand, Juergen Schoenwaelder, and Pekka Savola.
8. Informative References 8. Informative References
[I-D.ietf-opsawg-survey-management] Harrington, D., "Survey of IETF
Network Management Standards", d
raft-ietf-opsawg-survey-
management-00 (work in
progress), March 2009.
[I-D.ietf-syslog-protocol] Gerhards, R., "The syslog
Protocol",
draft-ietf-syslog-protocol-23
(work in progress),
September 2007.
[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 [RFC1052] Cerf, V., "IAB recommendations for
for the development of Internet the development of Internet network
network management standards", management standards", RFC 1052,
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.
[RFC2119] Bradner, S., "Key words for use [RFC2119] Bradner, S., "Key words for use in
in RFCs to Indicate Requirement RFCs to Indicate Requirement Levels",
Levels", BCP 14, RFC 2119, BCP 14, RFC 2119, March 1997.
March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, [RFC2205] Braden, B., Zhang, L., Berson, S.,
S., Herzog, S., and S. Jamin, Herzog, S., and S. Jamin, "Resource
"Resource ReSerVation Protocol ReSerVation Protocol (RSVP) --
(RSVP) -- Version 1 Functional Version 1 Functional Specification",
Specification", RFC 2205, RFC 2205, September 1997.
September 1997.
[RFC2439] Villamizar, C., Chandra, R., and [RFC2439] Villamizar, C., Chandra, R., and R.
R. Govindan, "BGP Route Flap Govindan, "BGP Route Flap Damping",
Damping", RFC 2439, RFC 2439, November 1998.
November 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, [RFC2578] McCloghrie, K., Ed., Perkins, D.,
D., Ed., and J. Schoenwaelder, Ed., and J. Schoenwaelder, Ed.,
Ed., "Structure of Management "Structure of Management Information
Information Version 2 (SMIv2)", Version 2 (SMIv2)", STD 58, RFC 2578,
STD 58, RFC 2578, April 1999. April 1999.
[RFC2975] Aboba, B., Arkko, J., and D. [RFC2975] Aboba, B., Arkko, J., and D.
Harrington, "Introduction to Harrington, "Introduction to
Accounting Management", Accounting Management", RFC 2975,
RFC 2975, October 2000. October 2000.
[RFC3060] Moore, B., Ellesson, E., [RFC3060] Moore, B., Ellesson, E., Strassner,
Strassner, J., and A. J., and A. Westerinen, "Policy Core
Westerinen, "Policy Core
Information Model -- Version 1 Information Model -- Version 1
Specification", RFC 3060, Specification", RFC 3060,
February 2001. February 2001.
[RFC3084] Chan, K., Seligson, J., Durham, [RFC3084] Chan, K., Seligson, J., Durham, D.,
D., Gai, S., McCloghrie, K., Gai, S., McCloghrie, K., Herzog, S.,
Herzog, S., Reichmeyer, F., Reichmeyer, F., Yavatkar, R., and A.
Yavatkar, R., and A. Smith, Smith, "COPS Usage for Policy
"COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084,
Provisioning (COPS-PR)", March 2001.
RFC 3084, March 2001.
[RFC3139] Sanchez, L., McCloghrie, K., and [RFC3139] Sanchez, L., McCloghrie, K., and J.
J. Saperia, "Requirements for Saperia, "Requirements for
Configuration Management of IP- Configuration Management of IP-based
based Networks", RFC 3139, Networks", RFC 3139, June 2001.
June 2001.
[RFC3198] Westerinen, A., Schnizlein, J., [RFC3198] Westerinen, A., Schnizlein, J.,
Strassner, J., Scherling, M., Strassner, J., Scherling, M., Quinn,
Quinn, B., Herzog, S., Huynh, B., Herzog, S., Huynh, A., Carlson,
A., Carlson, M., Perry, J., and M., Perry, J., and S. Waldbusser,
S. Waldbusser, "Terminology for "Terminology for Policy-Based
Policy-Based Management", Management", RFC 3198, November 2001.
RFC 3198, November 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, [RFC3290] Bernet, Y., Blake, S., Grossman, D.,
D., and A. Smith, "An Informal and A. Smith, "An Informal Management
Management Model for Diffserv Model for Diffserv Routers",
Routers", RFC 3290, May 2002. RFC 3290, May 2002.
[RFC3410] Case, J., Mundy, R., Partain, [RFC3410] Case, J., Mundy, R., Partain, D., and
D., and B. Stewart, B. Stewart, "Introduction and
"Introduction and Applicability Applicability Statements for
Statements for Internet-Standard Internet-Standard Management
Management Framework", RFC 3410, Framework", RFC 3410, December 2002.
December 2002.
[RFC3444] Pras, A. and J. Schoenwaelder, [RFC3444] Pras, A. and J. Schoenwaelder, "On
"On the Difference between the Difference between Information
Information Models and Data Models and Data Models", RFC 3444,
Models", RFC 3444, January 2003. January 2003.
[RFC3460] Moore, B., "Policy Core [RFC3460] Moore, B., "Policy Core Information
Information Model (PCIM) Model (PCIM) Extensions", RFC 3460,
Extensions", RFC 3460,
January 2003. January 2003.
[RFC3535] Schoenwaelder, J., "Overview of [RFC3535] Schoenwaelder, J., "Overview of the
the 2002 IAB Network Management 2002 IAB Network Management
Workshop", RFC 3535, May 2003. Workshop", RFC 3535, May 2003.
[RFC3585] Jason, J., Rafalow, L., and E. [RFC3585] Jason, J., Rafalow, L., and E.
Vyncke, "IPsec Configuration Vyncke, "IPsec Configuration Policy
Policy Information Model", Information Model", RFC 3585,
RFC 3585, August 2003. August 2003.
[RFC3644] Snir, Y., Ramberg, Y., [RFC3644] Snir, Y., Ramberg, Y., Strassner, J.,
Strassner, J., Cohen, R., and B. Cohen, R., and B. Moore, "Policy
Moore, "Policy Quality of Quality of Service (QoS) Information
Service (QoS) Information
Model", RFC 3644, November 2003. Model", RFC 3644, November 2003.
[RFC3670] Moore, B., Durham, D., [RFC3670] Moore, B., Durham, D., Strassner, J.,
Strassner, J., Westerinen, A., Westerinen, A., and W. Weiss,
and W. Weiss, "Information Model "Information Model for Describing
for Describing Network Device Network Device QoS Datapath
QoS Datapath Mechanisms", Mechanisms", RFC 3670, January 2004.
RFC 3670, January 2004.
[RFC3805] Bergman, R., Lewis, H., and I. [RFC3805] Bergman, R., Lewis, H., and I.
McDonald, "Printer MIB v2", McDonald, "Printer MIB v2", RFC 3805,
RFC 3805, June 2004. June 2004.
[RFC4741] Enns, R., "NETCONF Configuration [RFC4741] Enns, R., "NETCONF Configuration
Protocol", RFC 4741, Protocol", RFC 4741, December 2006.
December 2006.
[RFC5101] Claise, B., "Specification of [RFC5101] Claise, B., "Specification of the IP
the IP Flow Information Export Flow Information Export (IPFIX)
(IPFIX) Protocol for the Protocol for the Exchange of IP
Exchange of IP Traffic Flow Traffic Flow Information", RFC 5101,
Information", RFC 5101,
January 2008. January 2008.
[RFC5321] Klensin, J., "Simple Mail [RFC5321] Klensin, J., "Simple Mail Transfer
Transfer Protocol", RFC 5321, Protocol", RFC 5321, October 2008.
October 2008.
[W3C.REC-xmlschema-0-20010502] Fallside, D., "XML Schema Part [RFC5424] Gerhards, R., "The Syslog Protocol",
0: Primer", World Wide Web RFC 5424, March 2009.
Consortium FirstEdition REC-
xmlschema-0-20010502, May 2001, [W3C.REC-xmlschema-0-20010502] Fallside, D., "XML Schema Part 0:
<http://www.w3.org/TR/2001/ Primer", World Wide Web Consortium
FirstEdition REC-xmlschema-0-
20010502, May 2001, <http://
www.w3.org/TR/2001/
REC-xmlschema-0-20010502>. REC-xmlschema-0-20010502>.
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
 End of changes. 35 change blocks. 
134 lines changed or deleted 108 lines changed or added

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