Internet DRAFT - draft-farrel-problem-protocol-icrm

draft-farrel-problem-protocol-icrm




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]