Internet Engineering Task Force (IETF) A. Farrel Request for Comments: 6123 Old Dog Consulting Category: Historic February 2011 ISSN: 2070-1721 Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts
AbstractIt 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. The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group. Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6123.
Copyright Notice Copyright (c) 2011 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents 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 Simplified BSD License.
This document was developed within the PCE Working Group and was used to help guide the authors and editors within the working group to produce Manageability Considerations sections in the Internet-Drafts and RFCs produced by the working group. [RFC5706] presents general guidance from the IETF's Operations Area for considering Operations and Management of new protocols and protocol extensions. It has been adopted by the PCE Working Group to provide guidance to editors and authors within the working group, so this document is no longer required. However, the working group considers that it will be useful to archive this document as Historic for future reference. RFC2119] in order that the contents of a Manageability Considerations section can be clearly understood. X.700], which stands for the following: - Fault management - Configuration - Accounting - Performance - Security Conventionally, Security is already covered an Internet-Draft 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. The author 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 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 [RFC5706]. As part of documenting the manageability considerations for a new protocol or for protocol extensions, authors 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 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 by 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. Appendix A.
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. 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 - 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.
RFC3060] and [RFC3460]. Additionally, 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.
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 it 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 (Simple Network Management Protocol) model and the Network Configuration Protocol (NETCONF) model, being developed by the NETCONF Data Modeling Language (NETMOD) Working Group [YANG].
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.
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. Section 2.3.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [X.700] CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI) for CCITT applications.
RFC 4655, August 2006. Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key- Based Mechanism", RFC 5520, April 2009. Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE- Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009.