One document matched: draft-farrel-pce-manageability-requirements-01.txt

Differences from draft-farrel-pce-manageability-requirements-00.txt

Network Working Group                                      Adrian Farrel
IETF Internet Draft                                   Old Dog Consulting
Proposed Status: Informational
Expires: April 2007                                         October 2006

           draft-farrel-pce-manageability-requirements-01.txt

   Requirements for Manageability Sections in PCE Working Group Drafts

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-01.txt          October 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-01.txt          October 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 MUST still contain a Manageablity
   Considerations section. The presences of this section indicates to
   the reader and to the reviewer that due consideration has been given
   to manageablity, and that there are no (or no new) requirements.

   In this case, the section MUST contain a simple statement such as
   "There are no new manageablity requirements introduced by this
   document," and must 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 reviewer
   that no additional manageability mechanisms are required, and it is
   often hard to prove that sometihng is not needed. A Null
   Manageability Considerations section MUST NOT consist only of the
   simple statement that there are no new manageability requirements.

2.2. Mandatory Subsections

   If the Manageablity Considerations section is not null, it MUST
   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 MUST 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.

2.4. Placement of Manageability Considerations Sections

   The Manageability Considerations Section SHOULD be placed immediately
   before the Security Considerations section.


Farrel, Andersson and Doria                                       Page 3

draft-farrel-pce-manageability-requirements-01.txt          October 2006

3. Guidance on the Content of Subsections

   This section gives guidance on the information to be included in each
   of the mandatory 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
   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.

Farrel                                                            Page 4

draft-farrel-pce-manageability-requirements-01.txt          October 2006

   Where the protocol is responsible for establishing data or user plane
   connectivity, liveness detection and monitoring usually need to be
   acchieved 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 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 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

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,
   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 mandatory subsections
   described above, but which is needed to understand the manageability
   situation SHOULD be covered in an additional section.




Farrel                                                            Page 5

draft-farrel-pce-manageability-requirements-01.txt          October 2006

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

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

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.

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


Farrel                                                            Page 6

draft-farrel-pce-manageability-requirements-01.txt          October 2006

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

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

10. Informative References

   [RFC3444] Pras, A., and  Schoenwaelder, J., "On the Difference
             between Information Models and Data Models", RFC 3444,
             January 2003.

11. Author's Address

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

12. Full Copyright Statement

   Copyright (C) The Internet Society (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 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 8