Network Working Group Adrian Farrel
Internet Draft Old Dog Consulting
Category: Informational June 2003
Expiration Date: November 2003
Observations on Proposing Protocol Enhancements that Address
Stated Requirements but also go Further by Meeting more General Needs
draft-farrel-problem-protocol-icrm-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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
Procedures in place and currently being developed within the IETF
encourage the development and agreement of clear requirements before
the new protocols or protocol extensions are accepted as work items.
This does not preclude nor prohibit individuals from engaging in such
protocol work outside of the IETF, but it acknowledges that
acceptance of the work may be subject to proving the requirements
through a requirements document or through deployment and usage
experience. That work within the IETF on a requirements document may
change the underlying assumptions made by protocol developers and
thereby render their work obsolete or risible is a risk taken by all
who spend their time enhancing the set of available protocols without
first agreeing the requirements.
At the same time, some problem statements or requirement documents
are very narrowly scoped to address a very specific need. There is a
risk that the development of a solution to such a precise problem may
be non-extensible and may make the protocol unusable in a wider
context.
This document examines the need to avoid tying new protocol
developments too tightly to the problem statement or requirement
documents. It uses an example from the ITU ASON requirements for
signaling protocols within optical networks to illustrate how
adhering to the requirements statement too zealously may
unnecessarily restrict the applicability of the protocol in a wider
context.
A. Farrel [Page 1]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
1. Introduction
The Problem Working Group has been set up to accept and analyze
problem statements related to the work of the IETF to determine
whether they can be addressed through existing protocols and
mechanisms or whether they should be the subject of new work. If
new work is required, the Problem Working Group designates one or
more Working Groups to develop a requirements document, and when this
is reasonably mature, work can start on extending existing protocols
or developing new protocols to satisfy the requirements.
At the same time, individual Working Groups have put in place or are
developing procedures to regulate the process by which new protocols
and protocol extensions are developed. For example, the "MPLS and
GMPLS Change Process" [GMPLS] within the MPLS Working Group and the
Common Control And Measurement Protocols (ccamp) Working Group
describes the process through which individuals, working groups and
external standards bodies can influence the development of MPLS and
GMPLS standards. With respect to standardization, the process
detailed in [FMPLS] means that (G)MPLS extensions and changes can be
done through the IETF only, the body that created the (G)MPLS
technology. The IETF will not publish a (G)MPLS technology extension
RFC outside of the processes described in [GMPLS].
Neither of these processes precludes nor prohibits individuals from
engaging in protocol development work outside of the IETF, but they
acknowledge that acceptance of the work may be subject to proving the
requirements through a requirements document or through deployment
and usage experience. That work within the IETF on a requirements
document may change the underlying assumptions made by protocol
developers and thereby render their work obsolete or risible is a
risk taken by all who spend their time enhancing the set of available
protocols without first agreeing the requirements.
1.1 Requirement Documents
Some requirement documents are very narrowly scoped to address a very
specific need. There is a risk that the development of a solution to
such a precise problem may be non-extensible and may make the
protocol unusable in a wider context.
Clearly, a well-written requirements document will include a section
on extensibility. Nevertheless, the writer of a requirements document
cannot be expected to be psychic, and premonitions about future needs
within the Internet cannot be a mandatory criterion for authorship of
requirement documents.
The review process of both problem statements and requirement
documents may be expected to generate some observations about the
need to widen the scope of the problem since the reviewers have
been selected both on grounds of experience and also a track record
of ability. Further, since all Internet Drafts are open for review by
the entire Internet community, it may be hoped that a broad exposure
of similar or related issues will be achieved.
A. Farrel [Page 2]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
Nevertheless there is a need to avoid tying new protocol developments
too tightly to the problem statement or requirement documents. It
will often be the case that an IETF participant working on the
development of a new protocol will see a way to make the protocol
more flexible and extensible without perceiving a direct requirement
for such a feature. A good example of this might be the addition of
sub-TLV support to the Extended IP Reachability TLV in IS-IS [ISISTE]
when no immediate use of this construct was envisioned.
Further, it will sometimes be the case that the designer of a new
protocol perceives a need that is similar but slightly different
from those set out in the requirements document. If they are to be
strictly limited to the scope of the requirements document, this new
function must be discarded and not included in the protocol.
Of course, a simple solution might be to revisit the old problem
statement or generate a new one, to update the requirements document
and to continue with the protocol development to encompass all of the
issues that have now been identified. In practice this may be too
slow and might either block the development of the protocol to meet
the original requirements, or might lead the protocol to go down a
wrong developmental branch in the absence of the wider requirements
document.
1.2 Recommendations
This document does not aim to make any specific recommendations, but
simply to raise the issue and provide an example. It might be assumed
that a principle of "reasonableness" would be applied in all cases
under the guidance of Working Group chairs, Area Directors and the
IESG. As we all know, the IETF is made up only of reasonable people
with no personal issues and certainly no-one carries any corporate
allegiances.
1.3 Proof by Example
The remainder of this document aims to illustrate the points made in
the introduction by way of an example from the ccamp Working Group
and its attempts to address the ITU ASON requirements for signaling
protocols within optical networks.
1.4 Terminology
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 RFC 2119 [RFC2119].
This document uses the example of meeting the requirements of the ITU
ASON Architecture through GMPLS signaling to illustrate the points
made in the introductory section. Terms are introduced below, but
readers may need to familiarize with the informative references
before proceeding. See, in particular, [RFC3473], [ITU8080],
[ITU7713] and [ASON-REQ]
A. Farrel [Page 3]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
2. Background to the ASON Requirements
The ITU has developed a series of architectural requirements for the
control and management of Automatically Switched Optical Networks
(ASON). These are documented in [ITU8080].
The requirements contain many individual functions some of which were
already met by existing GMPLS procedures [RFC3473] and some of which
needed additional protocol development.
The intention of the process was that the ITU would liaise with the
IETF to present the requirements and the IETF would develop the
necessary protocols and protocol extensions to meet the needs that
the ITU had identified.
Owing to some confusion with the liaison process and an
understandable keenness within the ITU to see solutions to their
issues the actual process included the development of protocol
solutions within the ITU. The IETF is only now starting to examine
the requirements placed upon the protocols by the ASON architecture
and to consider whether the ITU's proposals meet the needs or whether
new protocols or protocol extensions must be developed.
3. Call and Connection Separation
One of the architectural requirements of [ITU8080] is the separation
of calls and connections.
Within the scope of ASON, a call is defined as an association between
endpoints that supports an instance of a service, and a connection is
defined as a concatenation of link connections and sub-network
connections that allows the transport of user information between the
ingress and egress points of a sub-network.
[ITU8080] specifically requires that it should be possible to set up
and maintain calls independent of connections. That is, it should be
possible to set up a call independent of any connections and then, at
a later time, to add connections to the call. This is called "Call/
Connection Separation".
[ITU8080] makes no stipulations concerning how that requirement
should be met.
4. Proposed Solutions
4.1 ITU-Driven Solution
[RFC3474] documents protocol number assignments made by IANA in
support of protocol extensions developed by the ITU to meet the
specific needs for call and connection separation as documented in
[ITU8080]. The associated protocol extensions and procedures are
briefly mentioned in [RFC3474] and are more fully described in
[ITU7713]
The solutions have been carefully designed to adequately meet the
needs expressed in [ITU8080].
A. Farrel [Page 4]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
4.2 A wider Solution
A recent Internet Draft [ASON-REQ] sets out the requirements
expressed in [ITU8080] in terms familiar to IETF participants. There
is no new material in this draft, but it does partition the problems
and express them in terminology familiar to those who regularly
follow the developments within the ccamp Working Group.
A second Internet Draft [ASON-SIG] aims to highlight solutions to
the requirements expressed in [ASON-REQ]. In many cases, these
solutions are simply references to the base GMPLS document [RFC3473],
and in other cases the references are to other Internet Drafts
currently being developed (for example [CRANK]).
In the case of call and connection separation, however, the only
existing material was [RFC3474] and [ITU7713]. The authors of
[ASON-SIG] felt that the previous solution did not satisfy the
framework for developing protocol extensions to MPLS and GMPLS
[GMPLS], nor did they feel that the previous solution addressed
additional requirements for call and connection separation. In
consequence, [ASON-SIG] contains extended protocols and procedures
that address call and connection separation needs that are above and
beyond those expressed in [ASON-REQ] yet which still fully meet the
requirements of [ASON-REQ].
During the early review of [ASON-SIG] this mismatch of requirements
led to an email exchange that may have been similar to the following:
Author : Call id collision is a useful feature consistent with the
GMPLS developments, and we hope the ietf community will
have the same opinion.
Reviewer : It's not clear why the collision case would arise - if
both ends of a call try to establish simultaneously,
wouldn't the source address be different, so that the call
ID ends up being different as well?
Author : Call ID is distinct from (or may be kept distinct from) a
sense of caller and called.
Reviewer : There is no requirement from the ITU for the call id to be
the same in both directions.
Author : Agreed that this may be beyond the ITU requirements, but
this draft needs to cover ITU *and* anything else the
authors think is a related requirement. It would be wrong
to leave out an associated function or possibly block its
future addition. In fact, we should add anything that the
authors think is appropriate or nice, such as the recipe
for homemade strawberry ice cream.
A. Farrel [Page 5]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
5. Additional Applicability Considerations
This section provides a discussion on the applicability of Strawberry
Ice Cream to the debate of the appropriate signaling protocol and
protocol extensions to support the requirements outlined in
[ASON-REQ] with respect to supporting the architecture and
architectural requirements of ASON in a GMPLS network.
5.1 Encoding and Procedures
The following recipe is fairly safe and requires relatively little
culinary ability.
5.1.1 Encoding
1 lb Strawberries
6 oz Sugar
5 floz Water
10 floz Double Cream
half Lemon
5.1.2 Procedures
Set aside a few of the strawberries and coarsely chop them, or leave
them whole if they are small. Mash the remainder of the fruit through
a sieve.
Dissolve the sugar in the water in a pan over a medium heat.
Bring to the boil and then boil. Implementations MUST boil the syrup
solution for three (3) minutes. Implementations MUST NOT boil the
syrup solution for more than three minutes.
Stir the syrup into the fruit pulp and add the juice of the lemon.
Whip the cream until it has begun to thicken. The cream MUST NOT be
too thick. measuring thickness of cream is outside the scope of this
document.
Fold the cream into the fruit mixture (which should have cooled by
now) and then add the chopped fruit.
Place the mixture in a box in the freezer for about three hours.
Remove, empty into a bowl and mash thoroughly. Return to freezer
until set.
Place in refrigerator for one hour before serving.
5.2 Alternative Encoding and Procedures
It has been brought to the author's attention, principally by his
wife and daughter, that cream is a by-product of the dairy industry
in which animals are detained against their will and deprived of
social interactions with their young after a certain age. In
addition, they are encouraged to lactate beyond normal quantities and
timescales.
A. Farrel [Page 6]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
The author (and, no doubt, the IETF) takes no position as to the
veracity of these opinions nor the conclusions drawn based upon them.
Nevertheless, an alternative encoding and procedure are given below
for the benefit of vegans.
Note that this is neither ice cream by content nor by method, but it
is pretty good anyway.
5.2.1 Encoding
1 lb Strawberries
1/2 cup Soya milk
5 tbs Sunflower oil
half Lemon
2 tbs Maple syrup
5.2.2 Procedures
Mash fruit coarsely with a fork. Place in a bowl and freeze for at
least four hours.
Place all ingredients (including the frozen fruit) in a blender and
mix until mixed.
If the resulting mixture is too sloppy an implementation MAY return
it to the freezer for half an hour before serving.
5.3 Survivability
Under some circumstances the lifetime of an ice cream may be limited
by events out of the scope of this document. For example, a
visitation of small boys may have a devastating impact on the
longevity of ice cream produced according to this document.
Alternatively node failures may reduce the product to an unappetizing
slurry.
Under normal circumstances with a well-functioning freezer, the ice
cream can be expected to last for only a limited amount of time. It
is RECOMMENDED that implementations run a timer with a default value
of 1814400000 milliseconds.
Implementations MUST NOT use mixing bowls or storage devices
constructed of soft plastics that easily harbor flavors or which have
previously been used to store crushed garlic.
5.4 Applicability
There is no direct applicability to the debate on the implementation
of ASON requirements in a GMPLS network except as follows:
- An IETF document that addresses the ITU ASON requirements may also
include additional information that is specific to the needs or
perceived needs of the IETF community.
- The time spent waiting for the mixture to freeze can be spent
writing Internet drafts.
A. Farrel [Page 7]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
- A bowl of homemade ice cream may just convince your opponent to
come around to your opinion. Failing that, a sharp clonk on the
head with a frozen block of ice cream beats all rational arguments.
- The information contained in this document may be of wider
applicability and interest than the material contained in the main
body of this document and so its presence may encourage both the
examination and review of this document, and may facilitate rapid
implementation and deployment.
5.5 A Note on Sweetness
The following considerations are optional procedures.
5.5.1 Your Personal Taste
Some people like things sweeter than others. Vary the amount of
sweetness according to your preferences.
5.5.2 Ripe Fruit and Hydroponics
The sweetness of the fruit should be taken into consideration. In
some circumstances significantly less sweetener is needed, such as
when the fruit is well-ripened or sun-ripened.
Note, however, that fruit grown in glasshouses and fed and watered
through techniques sometimes known as hydroponics may not have as
much flavor or sweetness.
5.5.3 Sources of Sweetness
Sources of sweetness vary. The author prefers cane sugar to beet
sugar but is reliably informed that no-one can tell the difference.
Lapsed vegans may prefer to use honey over maple syrup.
You are NOT RECOMMENDED to use artificial sweeteners or high fructose
corn syrup in these procedures. You MAY choose to do so at your own
risk.
5.5.5 Solubility
The sweetener used, especially in the procedures described in 5.1.2,
MUST be sufficiently soluble as to dissolve within a reasonable
period of time.
5.5.6 Additional Parameters
Some implementers (including the author) regard a small pinch of salt
as an essential additional ingredient, but be aware that many people
will scream and wave their hands in the air shrieking "You put SALT
in the ice cream?"
Dog hair may be considered to adversely affect the efficacy of the
procedures described in this document. Implementations SHOULD take
reasonable precautions to avoid the inclusion of dog hair within the
encoding of their ice cream. It should be noted that such dog hair
A. Farrel [Page 8]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
does not noticeably modify the flavor of the resulting ice cream, but
participants MAY return their portions using a PathErr or Notify
message carrying the Error Code 'Admission Control failure' (0x01)
and the Error Value defined as 16 bits 'ssur cccc cccc cccc' where
ss = 00 Low order 12 bits contain a globally-defined sub-code
u = 0 Message is not informational, but removes state
r = 0 Reserved
The low 12 bits are set to
4 (TBD IANA) eyes bigger than stomach
Alternatively, the participating node may use the Error Code 'Routing
Problem' (0x18) and Error Value 'Unsupported Encoding' (0x0e).
5.6 Pronunciation Concerns
If the parameters necessary for the encoding are to be acquired
within the United States of America, implementers from without that
republic are advised that water may be pronounced "wadder" and that
attempts to purchase "wor-tah" will be met by blank stares or
derision.
6. Security Considerations
The procedures within this document are extremely applicable to
security. Supplying an adversary with fresh and well-made ice cream
is a sure way to eliminate hostility.
The procedures within this document are an extreme security
vulnerability. Upon learning that fresh and well-made ice cream is
available all sorts of attempts to break your domestic security may
be made.
Implementers are advised that some people may be allergic to the
histamines in strawberries and that others plain don't like the
fruit. Others suffer from a belief that fat makes you fat and that
that is a bad thing.
The author notes that at the time of writing no evidence has been
supplied to suggest that milk made from genetically modified soy
is unsafe. On the other hand, no evidence has been supplied to
suggest that milk made from genetically modified soy is safe. This
subject is deferred for further study.
The IETF takes no position and makes no warranty as to the safety or
health merits of the procedures described in this document.
Individuals or companies are invited to register their opinions and
concerns with the IETF Chairman who will give them precisely the
attention that they deserve.
7. IANA Considerations
IANA is free to consider this document in any light whatsoever.
Should IANA assign any numbers to any protocols objects mentioned in
this document, the author would be stunned.
A. Farrel [Page 9]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
8. Acknowledgements
I should like to thank Deborah Brunghard for recklessly encouraging
me with this project. Also my dog, Bracken, for licking out the bowl.
9. References
9.1 Normative References
[RFC-2026] S.Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BEETON] Mrs. Beeton, "Every-Day Cookery and Housekeeping Book",
pub. Ward, Lock and Co., revised edition.
9.2 Informational References
[ASON-REQ] D. Papadimitriou et al., "Requirements for Generalized
MPLS (GMPLS) Usage and Extensions for Automatically
Switched Optical Network (ASON)", draft-papadimitriou-
ccamp-gmpls-ason-reqts-00.txt, April 2003, work in
progress.
[ASON-SIG] J. Drake et al., "Generalized MPLS (GMPLS) RSVP-TE
Signalling in support of Automatically Switched Optical
Network (ASON)", draft-dimitri-ccamp-gmpls-rsvp-te-ason-
00.txt, April 2003, work in progress.
[GMPLS] L. Andersson (editor), "MPLS and GMPLS Change Process",
draft-andersson-mpls-g-chng-proc-00.txt, February 2003,
work in progress.
[CRANK] A. Farrel (editor), "Crankback Routing Extensions for MPLS
Signaling", draft-iwata-mpls-crankback-05.txt, March 2003,
work in progress.
[RFC3473] L. Berger (editor), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
January 2003.
[RFC3474] Z. Lin, D. Pendarakis, "Documentation of IANA assignments
for Generalized MultiProtocol Label Switching (GMPLS)
Resource Reservation Protocol - Traffic Engineering (RSVP-
TE) Usage and Extensions for Automatically Switched
Optical Network (ASON)", RFC 3474, March 2003.
[ISISTE] T. Li, H. Smit, "IS-IS extensions for Traffic
Engineering", August 2001, work in progress.
[ITU8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)", November
2001 (and Revision, January 2003).
A. Farrel [Page 10]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
[ITU7713] ITU-T Rec. G.7713/Y.1304, "Distributed Call and Connection
Management", November 2001.
10. Author's Details
Adrian Farrel
Old Dog Consulting
care of
Ty Du
Ffordd yr Abaty
Llangollen
Sir Dinbych
Cymru
email: adrian@olddog.co.uk
11. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
A. Farrel [Page 11]
Internet Draft draft-farrel-problem-protocol-icrm-00.txt June 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
A. Farrel [Page 12]