Network Working Group Adrian Farrel IETF Internet Draft Old Dog Consulting Proposed Status: Best Current Practice Expires: June 2007 December 2006 Requirements for Manageability Sections in PCE Working Group Drafts draft-farrel-pce-manageability-requirements-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract It has often been the case that manageability considerations have been retrofitted to protocols. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the requirement for all new Internet-Drafts in the PCE Working Group to include a "Manageability Considerations" section, and gives guidance on what that section should contain. Farrel Page 1 draft-farrel-pce-manageability-requirements-02.txt December 2006 1. Introduction When new protocols or protocol extensions are developed, it is often the case that not enough consideration is given to the manageability of the protocols or to the way in which they will be operated in the network. The result is that manageablity considerations are only understood once the protocols have been implemented and sometimes not until after they have been deployed. The resultant attempts to retrofit manageablity mechanisms are not always easy or architecturally pleasant. Further, it is possible that certain protocol designs make manageablity particularly hard to achieve. Recognising that manageablity is fundamental to the utility and success of protocols designed within the IETF, and that simply defining a MIB module does not necessarily provide adequate manageablity, this document defines requirements for the inclusion of Manageablity Considerations sections in all Internet-Drafts produced within the PCE Working Group. Meeting these requirements will ensure that proper consideration is given to the support of manageability at all stages of the protocol development process from Requirements and Architecture, through Specification and Applicability. It is clear that the presence of such a section in an Internet-Draft does not guarantee that the protocol will be well-designed or manageable. However, mandating the inclusion of this section will ensure that the authors have the opportunity to consider the issues and by reading the material in this document they will gain some guidance. This document is developed within the PCE Working Group. It is hoped that other working groups in the Routing Area and in other Areas will benefit from the experiences generated in the PCE Working Group and will consider adopting similar requirements. Expanding the scope to cover all protocols developed within the IETF is an issue for the IESG and for IETF consensus. The remainder of this document describes what subsections are needed within a Manageablity Considerations section, and gives advice and guidance about what information should be contained in those subsections. 1.1. Requirements Notation This document is not a protocol specification. Nevertheless, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] in order that the requirements can be clearly understood. Farrel Page 2 draft-farrel-pce-manageability-requirements-02.txt December 2006 2. Presence and Placement of Manageablity Considerations Sections 2.1. Null Manageablity Considerations Sections In the event that there are no manageablity requirements for the an Internet-Draft, the draft SHOULD still contain a Manageablity Considerations section. The presences of this section indicates to the reader that due consideration has been given to manageablity, and that there are no (or no new) requirements. In this case, the section SHOULD contain a simple statement such as "There are no new manageablity requirements introduced by this document," and SHOULD briefly explain why that is the case with a summary of manageablity mechanisms that already exist. Note that a Null Manageability Considerations section may take some effort to compose. It is important to demonstrate to the reader that no additional manageability mechanisms are required, and it is often hard to prove that something is not needed. A Null Manageability Considerations section SHOULD NOT consist only of the simple statement that there are no new manageability requirements. If an Internet-Draft genuinely has no manageability impact, it should be possible to construct a simple Null Manageability Considerations section that explains why this is the case. 2.2. Recommended Subsections If the Manageablity Considerations section is not null, it SHOULD contain at least the following subsections. Guidance on the content of these subsections can be found in section 3 of this document. - Control of Function and Policy - Information and Data Models, e.g. MIB module - Liveness Detection and Monitoring - Verifying Correct Operation - Requirements on Other Protocols and Functional Components - Impact on Network Operation In the event that one or more of these subsections is not relevant, it SHOULD still be present, and SHOULD contain a simple statement explaining why the subsection is not relevant. 2.3. Optional Subsections The list of subsections above is not intended to be prescriptively limiting. Other subsections can and SHOULD be added according to the requirements of each individual Internet-Draft. Farrel Page 3 draft-farrel-pce-manageability-requirements-02.txt December 2006 2.4. Placement of Manageability Considerations Sections The Manageability Considerations Section SHOULD be placed immediately before the Security Considerations section. 3. Guidance on the Content of Subsections This section gives guidance on the information to be included in each of the recommended subsections listed above. Note that just as other sub-sections may be included, so additional information MAY also be included in these subsections. 3.1 Control of Function and Policy This sub-section describes the configurable items that exist for the control of function or policy. For example, many protocol specifications include timers that are used as part of operation of the protocol. These timers often have default values suggested in the protocol specification and do not need to be configurable. But it is often the case that the protocol requires that the timers can be configured by the operator to ensure specific behavior by the implementation. Even if all configurable items have been described within the body of the document, they SHOULD be identified in this sub-section, but a reference to another section of the document is sufficient if there is a full description elsewhere. 3.2 Information and Data Models This sub-section SHOULD describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specificially for the protocol functions specified in the document. [RFC3444] may be useful in determining what information to include in this section. The description can be by reference where other documents already exist. 3.3 Liveness Detection and Monitoring Liveness detection and monitoring applies both to the control plane and the data plane. Mechanisms for detecting faults in the control plane or for monitoring its liveness are usually built into the control plane protocols or inherited from underlying data plane or forwarding plane Farrel Page 4 draft-farrel-pce-manageability-requirements-02.txt December 2006 protocols. These mechanisms do not typically require additional management capabilities. However, when a control plane fault is detected, there is often a requirement to coordinate recovery action through management applications or at least to record the fact in an event log. Where the protocol is responsible for establishing data or user plane connectivity, liveness detection and monitoring usually need to be achieved through other mechanisms. In some cases, these mechanisms already exist within other protocols responsible for maintaining lower layer connectivity, but it will often be the case that new procedures are required so that failures in the data path can be detected and reported rapidly allowing remedial action to be taken. 3.4 Verifying Correct Operation An important function that Operations and Management (OAM) can provide is a toolset for verifying the correct operation of a protocol. This may be achieved to some extent through access to information and data models that report the status of the protocol and the state installed on network devices. But it may also be valuable to provide techniques for testing the effect that the protocol has had on the network by sending data through the network and observing its behavior. Thus, this section SHOULD include details of how the correct operation of the protocols described by the Internet-Draft can be tested, and in as far as the Internet-Draft impacts the operation of the network, this section SHOULD include a discussion about how the correct end-to-end operation of the network can be tested, and how the correct data or forwarding plane function of each network element can be verified. 3.5 Requirements on Other Protocols and Functional Components Here the text SHOULD describe the requirements that the new protocol puts on other protocols and functional components, as well as requirements from other protocols that has been considered in desinging the new protocol. This is pertinent to manageability because those other protocols may already be deployed and operational, and because those other protocols also need to be managed. 3.6 Impact on Network Operation The introduction of a new protocol or extensions to an existing protocol may have an impact on the operation of existing networks. This section SHOULD outline such impacts (which may be positive) including scaling concerns and interactions with other protocols. For example, a new protocol that doubles the number of acitve, Farrel Page 5 draft-farrel-pce-manageability-requirements-02.txt December 2006 reachable addresses in use within a network might need to be considered in the light of the impact on the scalability of the IGPs operating within the network. 3.7 Other Considerations Anything that is not covered in one of the recommended subsections described above, but which is needed to understand the manageability situation SHOULD be covered in an additional section. 4. IANA Considerations This document does not introduce any new codepoints or name spaces for registration with IANA. Internet-Drafts SHOULD NOT introduce new codepoints or name spaces for IANA registration within the Manageability Considerations section. 5. Manageability Considerations This document defines the Manageability Considerations sections for inclusion in all PCE Working Group Internet-Drafts. As such, the whole document is relevant to manageability. Note that the impact of the application of this document to Internet- Drafts produced within the PCE working group should be that PCE protocols and associated protocols are designed and extended with manageability in mind. This should result in more robust and more easily deployed protocols. However, since this document does not describe any specific protocol, protocol extensions, or protocol usage, no manageability considerations need to be discussed here. 6. Security Considerations This document is informational and describes the format and content of future Internet-Drafts. As such it introduces no new security concerns. However, there is a clear overlap between security, operations and management. The manageability aspects of security SHOULD be covered within the mandatory Security Considerations of each Internet-Draft. New security considerations introduced by the Manageability Considerations section MUST also be covered in the Security Considerations section. Farrel Page 6 draft-farrel-pce-manageability-requirements-02.txt December 2006 7. Acknowledgements This document is based on earlier work exploring the need for Manageability Considerations sections in all Internet-Drafts produced within the Routing Area of the IETF. That document was produced by Avri Doria and Loa Andersson working with the current author. Their input was both sensible and constructive. Peka Savola provided valuable feedback on an early versions of the original document. Thanks to Bert Wijnen, Dan Romascanum, David Harrington, Lou Berger, and Spender Dawkins for their comments. 8. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [RFC3444] Pras, A., and Schoenwaelder, J., "On the Difference between Information Models and Data Models", RFC 3444, January 2003. Farrel Page 7 draft-farrel-pce-manageability-requirements-02.txt December 2006 10. Author's Address Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk 11. Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A - Example Manageability Considerations Sections This section is to be completed. It will contain references to published RFCs that provide good or noteworthy examples of Manageability Considerations sections, and may include some comentary on why these examples are good or bad. Farrel Page 8