Internet DRAFT - draft-farrel-rtg-manageability-requirements
draft-farrel-rtg-manageability-requirements
Network Working Group Adrian Farrel
IETF Internet Draft Old Dog Consulting
Proposed Status: Informational
Expires: April 2006 Loa Andersson
Acreo AB
Avri Doria
ETRI
October 2005
draft-farrel-rtg-manageability-requirements-01.txt
Requirements for Manageability Sections in Routing Area 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 Routing Area
Internet-Drafts to include an "Manageability Considerations" section,
and gives guidance on what that section should contain.
Farrel, Andersson and Doria Page 1
draft-farrel-rtg-manageability-requirements-01.txt October 2005
1. Introduction
When new protocols or protocol extensions are developed within the
Routing Area, 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 Routing Area. 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 Routing Area of the IETF and
applies only to Internet-Drafts developed within the Routing Area.
Expanding the scope to cover all protocols developed within the IETF
is an issue for the IESG.
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.
An appendix contains two example Manageablity Considerations
sections: one from an informational architecture document that was
developed to include a Manageability Considerations section, and one
that has been written for an existing protocol specification RFC that
did not orriginally have such a section.
Farrel, Andersson and Doria Page 2
draft-farrel-rtg-manageability-requirements-01.txt October 2005
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
protocol specified in 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.
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-rtg-manageability-requirements-01.txt October 2005
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 is intended to describe 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.
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, Andersson and Doria Page 4
draft-farrel-rtg-manageability-requirements-01.txt October 2005
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, Andersson and Doria Page 5
draft-farrel-rtg-manageability-requirements-01.txt October 2005
4. Manageability Considerations
This document defines the Manageability Considerations sections for
inclusion in all Routing Area 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.
Routing Area 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 Routing Area
Internet-Draft. New security consideration introduced by the
Manageability Considerations section should also be covered in the
Security Considerations section.
7. Acknowledgements
The authors would like to extend their warmest thanks to Alex Zinin
for inviting them to write this document.
Peka Savola provided valuable feedback on an early version of this
document.
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, Andersson and Doria Page 6
draft-farrel-rtg-manageability-requirements-01.txt October 2005
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.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
10. Informational References
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP: 26, RFC 2434,
October 1998.
[RFC3552] Rescorla E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP: 72, RFC 3552,
July 2003.
11. Authors' Addresses
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Loa Andersson
Acreo AB
Email: Loa.Andersson@acreo.se
Avri Doria
ETRI
Email: avri@acm.org
Farrel, Andersson and Doria Page 7
draft-farrel-rtg-manageability-requirements-01.txt October 2005
12. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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, Andersson and Doria Page 8
draft-farrel-rtg-manageability-requirements-01.txt October 2005
Appendix A. Example Manageabilty Considerations Sections
A.1 Informational / Architecture Document
This section contains a copy of the Manageability Considerations
section included in the Path Computation Element (PCE) Architecture
document published as draft-ietf-pce-architecture [to be updated with
RFC number when known].
x. Manageability Considerations
The PCE architecture introduces several elements that are subject to
manageability. The PCE itself must be managed as must its
communications with PCCs and other PCEs. The mechanism by which PCEs
and PCCs discover each other are also subject to manageability.
Many of the issues of manageability are already covered in other
sections of this document.
x.1 Control of Function and Policy
It must be possible to enable and disable the PCE function at a PCE,
and this will lead to the PCE accepting, rejecting, or simply not
receiving requests from PCCs. Graceful shutdown of the PCE function
should also be considered so that in controlled circumstances (such
as software upgrade) a PCE does not just 'disappear' but warns its
PCCs and gracefully handles any queued computation requests (perhaps
by completing them, forwarding them to another PCE, or rejecting
them).
Similarly it must be possible to control the application of Policy at
the PCE through configuration. This control may include the
restriction of certain functions or algorithms, the configuration of
access rights and priorities for PCCs, and the relationships with
other PCEs both inside and outside the domain.
x.2 Information and Data Models
It is expected that the operations of PCEs and PCCs will be modeled
and controlled through appropriate MIB modules. The tables in the new
MIB modules will need to reflect the relationships between entities
and to control and report on configurable options.
Statistics gathering will form an important part of the operation of
PCEs. The operator must be able to determine the historical
interactions of a PCC with its PCEs, the performance that it has
seen, and success rate of its requests. Similarly, it is important
for an operator to be able to inspect a PCE and determine its load
and whether an individual PCC is responsible for a disproportionate
Farrel, Andersson and Doria Page 9
draft-farrel-rtg-manageability-requirements-01.txt October 2005
amount of the load. It will also be important to be able to record
and inspect statistics about the communications between the PCC and
PCE, including issues such as malformed messages, unauthorized
messages and messages discarded owing to congestion. In this respect
there is clearly an overlap between manageability and security.
Statistics for the PCE architecture can be made available through
appropriate tables in the new MIB modules.
The new MIB modules should also be used to provide notifications
(formerly known as traps) when key thresholds are crossed or when
important events occur. Great care must be exercised to ensure that
the network is not flooded with SNMP notifications. Thus it might be
inappropriate to issue a notification every time that a PCE receives
a request to compute a path. In any case, full control must be
provided through the MIB modules to allow notifications to be
disabled.
x.3 Liveness Detection and Monitoring
Section 6.5 [of the PCE architecture document] discusses the
importance of a PCC being able to detect the liveness of a PCE.
PCE-PCC communications techniques must enable a PCC to determine the
liveness of a PCE both before it sends a request and in the period
between sending a request and receiving a response.
It is less important for a PCE to know about the liveness of PCCs,
and within the simple request/response model, this is only helpful:
- to gain a predictive view of the likely loading of a PCE in the
future
- to allow a PCE to abandon processing of a received request.
x.4 Verifying Correct Operation
Correct operation for the PCE architecture can be classified as
determining the correct point-to-point connectivity between PCCs and
PCEs, and assessing the validity of the computed paths. The former is
a security issue that may be enhanced by authentication and monitored
through event logging and records as described in Section x.1. It may
also be a routing issue to ensure that PCC-PCE connectivity is
possible.
Verifying computed paths is more complex. The information to perform
this function can, however, be made available to the operator through
MIB tables provided full records are kept of the constraints passed
on the request, the path computed and provided on the response, and
Farrel, Andersson and Doria Page 10
draft-farrel-rtg-manageability-requirements-01.txt October 2005
any additional information supplied by the PCE such as the constraint
relaxation policies applied.
x.5 Requirements on Other Protocols and Functional Components
At the architectural stage it is impossible to make definitive
statements about the impact on other protocols and functional
components since the solutions work has not been completed. However,
it is possible to make some observations.
- Dependence on underlying transport protocols
PCE-PCC communications may choose to utilize underlying protocols
to provide transport mechanisms. In this case some of the
manageability considerations described in the previous sections may
be devolved to those protocols.
- Re-use of existing protocols for discovery
Without prejudicing the requirements and solutions work for PCE
discovery (see Section 6.4 [of the PCE Architecture document) it is
possible that use will be made of existing protocols to facilitate
this function. In this case some of the manageability
considerations described in the previous sections may be devolved
to those protocols.
- Impact on LSRs and TE LSP signaling
The primary example of a PCC identified in this architecture is an
MPLS or GMPLS LSR. Consideration must therefore be given to the
manageability of the LSRs and the additional manageability
constraints applicable to the TE LSP signaling protocols.
As well as allowing the PCC management described in the previous
sections, an LSR must be configurable to determine whether it will
use a remote PCE at all - the options being to use hop-by-hop
routing or to supply the PCE function itself. It is likely to be
important to be able to distinguish within an LSR whether the route
used for a TE LSP was supplied in a signaling message from another
LSR, by an operator, or by a PCE, and in the case where it was
supplied in a signaling message whether it was enhanced or expanded
by a PCE.
x.6 Impact on Network Operation
This architecture may have two impacts on the operation of a network.
It increases TE LSP setup times while requests are sent to and
processed by a remote PCE, and it may cause congestion within the
network if a significant number of computation requests are issued in
Farrel, Andersson and Doria Page 11
draft-farrel-rtg-manageability-requirements-01.txt October 2005
a small period of time. These issues are most severe in busy networks
and after network failures, although the effect may be mitigated if
the protection paths are precomputed or if the path computation load
is distributed among a set of PCEs.
Issues of potential congestion during recovery from failures may be
mitigated through the use of pre-established protection schemes such
as fast reroute.
It is important that network congestion be managed proactively
because it may be impossible to manage it reactively once the network
is congested. It should be possible for an operator to rate limit the
requests that a PCC sends to a PCE, and a PCE should be able to
report impending congestion (according to a configured threshold)
both to the operator and to its PCCs.
x.7 Other Considerations
No other management considerations arise.
A.2 Protocol Definition Document
This section provides an example Manageability Considerations
section that might have been included in RFCxxxx had this document
been in force at the time that the RFC was initially drafted.
There is no implied criticism of the authors of RFCxxxx or of the
yyyy working group that produced it. The RFC has been chosen simply
because it is familiar to the authors.
y. Manageability Considerations
y.1. Control of Function and Policy
y.2 Information and Data Models
y.3 Liveness Detection and Monitoring
y.4 Verifying Correct Operation
y.5 Requirements on Other Protocols and Functional Components
y.6 Impact on Network Operation
Farrel, Andersson and Doria Page 12
