[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-farrel-pce-manageability-requirements) 00 01 02 03 04 05 06 07 08 09 10 11 RFC 6123

Network Working Group                                          A. Farrel
Internet Draft                                        Old Dog Consulting
Intended Status: Best Current Practice
Created: February 19, 2008
Expires: August 19, 2008


     Inclusion of Manageability Sections in PCE Working Group Drafts


           draft-ietf-pce-manageability-requirements-03.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 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-03.txt           February 2008

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-03.txt           February 2008

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-03.txt           February 2008

   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-03.txt           February 2008

   - 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-03.txt           February 2008

   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, [PCE-POLICY].

   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.

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

Farrel                                                          [Page 6]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

   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.

   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.


Farrel                                                          [Page 7]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

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?

   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.

Farrel                                                          [Page 8]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

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
   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.




Farrel                                                          [Page 9]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

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 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

   [RFC3060] B. Moore, et al., Policy Information Model Version1
             Specification, RFC 3060, February 2001.



Farrel                                                         [Page 10]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

   [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.

   [OPS-OAM] Harrington, D., "Guidelines for Considering Operations and
             Management of New Protocols", draft-harrington-operations-
             and-management", work in progress.

   [PCE-POLICY] Bryskin, I., Papadimitriou, P. and Berger, L., "Policy-
             Enabled Path Computation Framework", draft-ietf-pce-
             policy-enabled-path-comp, work in progress.

10. Author's Address

   Adrian Farrel
   Old Dog Consulting
   EMail: adrian@olddog.co.uk

11. Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.















Farrel                                                         [Page 11]

draft-ietf-pce-manageability-requirements-03.txt           February 2008

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)", draft-ietf-pce-pcep, work in
   progress.

   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 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/