Network Working Group A. Farrel Internet Draft Old Dog Consulting Intended Status: Best Current Practice Created: July 27, 2009 Expires: January 27, 2010 Inclusion of Manageability Sections in PCE Working Group Drafts draft-ietf-pce-manageability-requirements-07.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. This document specifies the recommendation 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-ietf-pce-manageability-requirements-07.txt July 2009 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 manageability considerations are only understood once the protocols have been implemented and sometimes not until after they have been deployed. The resultant attempts to retrofit manageability mechanisms are not always easy or architecturally pleasant. Furthermore, it is possible that certain protocol designs make manageability particularly hard to achieve. Recognizing that manageability 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 manageability, this document defines recommendations for the inclusion of Manageability Considerations sections in all Internet- Drafts produced within the PCE Working Group. Meeting these recommendations 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, 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. [OPS-OAM] presents work in progress within the Operations Area to give general guidance for considering Operations and Management (OAM) of new protocols. The remainder of this document describes what subsections are needed within a Manageability Considerations section, and gives advice and guidance about what information should be contained in those subsections. Farrel [Page 2] draft-ietf-pce-manageability-requirements-07.txt July 2009 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 contents of a manageability considerations section can be clearly understood. 1.2. What is Manageability? In this context, "manageability" is used to refer to the interactions between a network operator (a human or an application) and the network components (hosts, routers, switches, applications, and protocols) performed to ensure the correct operation of the network. Manageability issues are often referred to under the collective acronym, FCAPS. This stands for: - Fault management - Configuration - Accounting - Performance - Security. Conventionally, Security is already covered in Internet-Drafts in its own Security Considerations section, and this document does not in any way diminish the need for that section. Indeed, as pointed out in Section 6, a full consideration of other aspects of manageability may increase the text that should be supplied in the Security Considerations section. The author of a Manageability Considerations section should certainly consider all aspects of FCAPS. He should reflect on how the manageability of a new protocol impacts the manageability and operation of the entire network. Specific optional subsections (see Section 2.3) should be added as necessary to describe features of FCAPS that are pertinent but which are not covered by the recommended subsections. More discussion of what manageability is and what may be included in a Manageability Considerations section can be found in [OPS-OAM]. As part of documenting the manageability considerations for a new protocol or for protocol extensions, the author should consider that one of the objectives of specifying protocols within the IETF is to ensure interoperability of implementations. This interoperability extends to the manageability function so that it is an ideal that there should be implementation independence between management applications and managed entities. This may be promoted by the use of standardized management protocols, and by the specification of Farrel [Page 3] draft-ietf-pce-manageability-requirements-07.txt July 2009 standard information models. Note that in some contexts reference is made to the term "management plane". This is used to describe the exchange of management messages through management protocols (often transported by IP and IP transport protocols) between management applications and the managed entities such as network nodes. The management plane may use distinct addressing schemes, virtual links or tunnels, or a physically separate management control network. The management plane should be seen as separate from, but possibly overlapping with, the control plane in which signaling and routing messages are exchanged, and the forwarding plane (sometimes called the data plane or user plane) in which user traffic is transported. 2. Presence and Placement of Manageability Considerations Sections 2.1. Null Manageability Considerations Sections In the event that there are no manageability requirements for the an Internet-Draft, the draft SHOULD still contain a Manageability Considerations section. The presences of this section indicates to the reader that due consideration has been given to manageability, 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 manageability requirements introduced by this document," and SHOULD briefly explain why that is the case with a summary of manageability 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 Manageability 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 Through Configuration and Policy - Information and Data Models, e.g. MIB modules - Liveness Detection and Monitoring - Verifying Correct Operation Farrel [Page 4] draft-ietf-pce-manageability-requirements-07.txt July 2009 - 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. That is, null subsections are allowed, and each should be formed following the advice in Section 2.1. 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. If a topic does not fit comfortably into any of the subsections listed, the authors should be relaxed about adding new subsections as necessary. In time, if an optional subsection is found to be common across many Internet-Drafts, it may be added to the list in Section 2.2 in a future revision of this document. 2.4. Placement of Manageability Considerations Sections The Manageability Considerations Section SHOULD be placed immediately before the Security Considerations section in any Internet-Draft. 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 subsections may be included, so additional information MAY also be included in these subsections. 3.1 Control of Function Through Configuration and Policy This subsection describes the functional elements that may be controlled through configuration and/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 subsection, but a reference to another section of the document is sufficient if there is a full description elsewhere. Other protocol elements are amenable to control through the Farrel [Page 5] draft-ietf-pce-manageability-requirements-07.txt July 2009 application of local or network-wide policy. It is not the intention that this subsection should give details of policy implementation since that is covered by more general policy framework specifications such as [RFC3060] and [RFC3460]. And specific frameworks for policy as applicable within protocol or functional architectures are also normally covered in separate documents, for example, [RFC5394]. However, this section SHOULD identify which protocol elements are potentially subject to policy, and should give guidance on the application of policy for successful operation of the protocol. Where this material is already described within the body of the document, this subsection SHOULD still identify the issues and reference the other sections of the document. 3.2 Information and Data Models This subsection 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 specifically for the protocol functions specified in the document. Where new or extended MIB modules are recommended, it is helpful if this section can give an overview of the items to be modeled by the MIB modules. This does not require an object-by-object description of all of the information that needs to be modeled, but could explain the high-level 'object groupings' (perhaps to the level of suggesting the MIB tables), and certainly should explain the major manageable entities. For example, a protocol specification might include separate roles for 'sender' and 'receiver,' and might be broken into a 'session' and individual 'transactions'; if so, this section could list these functionalities as separate manageable entities. [RFC3444] may be useful in determining what information to include in this section. The description in this section can be by reference where other documents already exist. It should be noted that the significance of MIB modules may be decreasing, but there is still a requirement to consider the managed objects necessary for successful operation of the protocol or protocol extensions. This means that due consideration should be given not only to what objects need to be managed, but also to what management model should be used. There are now several options including the MIB/SNMP model, and the Netconf model being developed by the NETMOD working group [YANG]. Farrel [Page 6] draft-ietf-pce-manageability-requirements-07.txt July 2009 3.3 Liveness Detection and Monitoring Liveness detection and monitoring apply 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 protocols. These mechanisms do not typically require additional management capabilities, but are essential features for the protocol to be useable and manageable. Therefore, this section SHOULD highlight the mechanisms in the new protocol or protocol extensions that are required in order to ensure liveness detection and monitoring within the protocol. Further, 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. This section SHOULD identify the management actions expected when the protocol detects a control plane fault. 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. This section SHOULD refer to other mechanisms that are assumed to provide monitoring of data plane liveness, and SHOULD identify requirements for new mechanisms as appropriate. This section SHOULD describe the need for liveness and detection monitoring, SHOULD highlight existing tools, SHOULD identify requirements and specifications for new tools (as appropriate for the level of the document being written), and SHOULD describe the coordination of tools with each other, with management applications, and with the base protocol being specified. 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. Farrel [Page 7] draft-ietf-pce-manageability-requirements-07.txt July 2009 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 on 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. There may be some overlap between this section and that describing liveness detection and monitoring since the same tools may be used in some cases. 3.5 Requirements on Other Protocols and Functional Components The text in this section SHOULD describe the requirements that the new protocol puts on other protocols and functional components, as well as requirements from other protocols that have been considered in designing 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. It is not appropriate to consider the interaction between the new protocol and all other protocols in this section, but it is important to identify the specific interactions that are assumed for the correct functioning of the new protocol or protocol extensions. 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 active, reachable addresses in use within a network might need to be considered in the light of the impact on the scalability of the IGPs operating within the network. A very important feature that SHOULD be addressed in this section is backward compatibility. If protocol extensions are being introduced, what impact will this have on a network that has an earlier version of the protocol deployed? Will it be necessary to upgrade all nodes in the network? Can the protocol versions operate side by side? Can the new version of the protocol be tunneled through the old version? Can existing services be migrated without causing a traffic hit or is a 'maintenance period' required to perform the upgrade? What are the configuration implications for the new and old protocol variants? Farrel [Page 8] draft-ietf-pce-manageability-requirements-07.txt July 2009 Where a new protocol is introduced, issues similar to backward compatibility may exist and SHOULD be described. How is migration from an old protocol to the new protocol achieved? Do existing protocols need to be interfaced to the new protocol? 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. This may be a catch-all section named 'Other Considerations', or may be one or more additional optional sections as described in Section 2.3. 4. IANA Considerations This document does not introduce any new codepoints or name spaces for registration with IANA. It makes no request to IANA for action. Internet-Drafts SHOULD NOT introduce new codepoints or name spaces or requests for IANA action within the Manageability Considerations section. 5. Manageability Considerations This document defines Manageability Considerations sections recommended 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. (This is an example of a null Manageability Considerations section.) 6. Security Considerations This document is a BCP 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 be covered in the Security Considerations Farrel [Page 9] draft-ietf-pce-manageability-requirements-07.txt July 2009 section. Note that fully designing a protocol before it is implemented (including designing the manageability aspects) is likely to result in a more robust protocol. That is a benefit to network security. Retrofitting manageability to a protocol can make the protocol more vulnerable to security attacks including through the new manageability facilities. Therefore, the use of this document is RECOMMENDED in order to help ensure the security of all protocols to which it is applied. 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 Romascanu, David Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, and Dimitri Papdimitriou for their comments. 8. Intellectual Property Considerations The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into Farrel [Page 10] draft-ietf-pce-manageability-requirements-07.txt July 2009 other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. 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 [RFC3060] B. Moore, et al., Policy Information Model Version1 Specification, RFC 3060, February 2001. [RFC3460] Moore, B. Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. [RFC3444] Pras, A., and Schoenwaelder, J., "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC5394] Bryskin, I., Papadimitriou, P. and Berger, L., "Policy- Enabled Path Computation Framework", RFC 5394, December 2008. [OPS-OAM] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols", draft-ietf-opsawg-operations- and-management", work in progress. [YANG] M. Bjorklund (Ed.), "YANG - A data modeling language for NETCONF", draft-ietf-netmod-yang, work in progress. Farrel [Page 11] draft-ietf-pce-manageability-requirements-07.txt July 2009 10. Author's Address Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Intellectual Property Statement The IETF Trust 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 any IETF 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. Copies of Intellectual Property 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 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrel [Page 12] draft-ietf-pce-manageability-requirements-07.txt July 2009 Appendix A - Example Manageability Considerations Sections Readers are referred to the following documents for example Manageability Considerations sections that received positive comments during IESG review: Farrel, A., Vasseur, J.P., and Ash., J., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. J.L. Le Roux, Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. Le Roux, J.L., Vasseur, J.P., Ikejiri, Y., and Zhang, R., "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. Le Roux, J.L. and Vasseur, J.P. "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Bradford R., Vasseur, J.P., and Farrel, A., "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Key-Based Mechanism", RFC 5520, April 2009. Oki, E., Le Roux, J.L., and Farrel, A. "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", draft-ietf-pce- inter-layer-frwk, work in progress. This list may be extended in future versions of this document. Farrel [Page 13]