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]