Internet Engineering Task Force                            P. Christian
INTERNET DRAFT                                           Christian Tena
                                                            May 19 2005


                         TLV for Experimental Use
                 <draft-ietf-isis-experimental-tlv-05.txt>

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.

   This Internet-Draft will expire on November 19, 2005.


. Abstract

   This document defines a TLV that may be used by any individual,
   company or other organisation for experimental extensions to the
   IS-IS routing protocol, and defines the format of the TLV.


. Conventions used in this document

   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.







Christian               Expires November 2005                         1

Internet Draft                                                 May 2005
                       TLV for Experimental Use

. Introduction

   IS-IS as defined in [1] has always been an extensible routing
   protocol.  Extensions to IS-IS are encoded as a TLV.  Critically [1]
   has always defined that when an IS-IS router receives an LSP, that
   it SHALL process the parts of the LSP that it understands, and SHALL
   flood the entire LSP, including all TLVs whether they are understood
   or not, on to other routers in the network.

   Thus information that is encoded into a TLV and placed in an LSP by
   a router will be propagated to every other router in an IS-IS level-
   1 area or level-2 subdomain, even by implementations that were never
   designed with that particular TLV in mind.

   The basic function of an IS-IS TLV is identified by the first byte
   of the TLV (the code).  Thus there are only 256 possible TLV codes.
   Certain TLVs have been defined to include sub-TLVs so that a single
   TLV code can be used for multiple functions.

   During 2003 an agreement was reached between ISOC/IETF and ISO/IEC
   JTC1/SC6 on how enhancements to IS-IS would be developed and
   documented.  This agreement is documented in [7].  Before this
   agreement it was not clear which authorities could or could not
   assign TLV codes.  Also no TLV was defined for experimental
   purposes.  The extensible nature of IS-IS has made the use of TLVs
   for non-standard purposes so useful that vendors have occasionally
   simply chosen a number and hoped for the best.  The risk is that
   such a TLV code may then be chosen by another organization at a
   later time for a different function, thus creating an
   interoperability problem.  Also this accelerates the depletion of
   the 256 possible TLV codes.  [3] lists TLV codes that are known to
   have been used.

   This document specifies a TLV that may be used for experimental
   purposes, and a mechanism that insures that different
   implementations using this TLV can exist in the same network without
   creating interoperability problems.

   By using this new TLV, companies, individuals or institutions may
   use extensions to IS-IS without fear of interoperability problems
   with other organizations in the future, and the available pool of
   TLV codes will no longer be diminished by experimental use.


. TLV code for experimental use

   The code for this TLV SHALL be 250.

   TLVs that use 250 for the code field MUST include a valid IANA
   assigned SNMP Enterprise Code (EC) as the first four bytes of the
   value of the TLV.


Christian               Expires November 2005                         2

Internet Draft                                                 May 2005
                       TLV for Experimental Use


   The structure of the TLV is shown in the diagram below.

                                            No. of Octets
             +---------------------------+
             |        CODE =250          |      1
             +---------------------------+
             |       LENGTH =n+4         |      1
             +---------------------------+
             |   SNMP Enterprise Code    |      4
             +---------------------------+
             |           DATA            |      n
             +---------------------------+

              Structure of the Experimental TLV

   The four octet SNMP EC plus the data octets together constitute a
   normal IS-IS variable length value field.  The length field MUST be
   set to the number of octets of data plus four.

   For more information about SNMP ECs refer to [4].

   The Experimental TLV MAY be used in LSPs, IIHs and/or SNPs.

   On receipt of an LSP a router MAY ignore TLVs of type 250 that
   include an SNMP EC from a different organization, but MUST flood the
   LSP onwards as per [1].  IIHs and SNPs that contain TLVs of type 250
   MUST also be handled as per [1].

   After the first four bytes of the value field of the TLV subsequent
   bytes MAY be used freely for any purpose (within the limitations set
   out in this document) provided that the resultant TLV is conformant
   with [1].

   Many organizations will have access to only one or a few SNMP ECs.
   Implementers are free to format the value field after their SNMP EC
   into sub-TLVs so that the TLV may be used for multiple purposes, and
   would be well advised to do so.


. Using experimental information to modify SPF

   All routers in an IS-IS routed network need to calculate routes
   such that they all arrive at the same shortest path for a given
   destination.  If this does not happen then routing loops and
   blackholes are likely to occur.

   Therefore a router MUST NOT calculate a route differently due to
   information that it receives in an experimental TLV.  Shortest paths
   MUST continue to be calculated as per [1] and [2].



Christian               Expires November 2005                         3

Internet Draft                                                 May 2005
                       TLV for Experimental Use


. Correct use of Experimental TLV in LSPs

   Some implementations recalculate SPF each time that they receive a
   new LSP.  In the least case an implementation needs to decide
   whether a new LSP is significant or not.  If one router constantly
   transmits LSPs into the network then others may not perform well.

   Additionally LSPs are flooded to every router in a level-1 area or
   level-2 subdomain, and are therefore not a particularly efficient
   way of carrying a piece of information simply from router A to
   router B.

   Consequently the experimental TLV SHOULD NOT be used within LSPs as
   any kind of general transport mechanism, and the experimental TLV
   SHOULD NOT cause frequent transmission of LSPs into the network.

   In general it would be preferable to transmit information in an
   experimental TLV at such time as an LSP would be normally be
   transmitted anyway, if this is possible.

   These particular restrictions do not apply to use of the
   experimental TLV in IIHs and SNPs.


. Authentication of PDUs

   If HMAC authentication of IS-IS PDUs that contain an experimental
   TLV is used then the experimental TLV MUST be included in the HMAC
   calculation.


. Documenting an Experimental TLV

   Without an understanding of what an experimental TLV has been used
   for an operator is not able to make an informed decision as to
   whether or not to deploy it in their network.

   Implementors SHOULD document the use of an Experimental TLV in an
   experimental status RFC.  Experimental RFCs MAY be submitted
   directly to the RFC editor and do not necessarily need to discussed
   by the workgroup.  Details may be found in section 4.2.3 of RFC
   2026 [6].

   If such documentation is not available then an operator SHOULD
   consider the interoperability and security of an implementation
   to be unknown.






Christian               Expires November 2005                         4

Internet Draft                                                 May 2005
                       TLV for Experimental Use


. Security Considerations

   The contents of IS-IS PDUs are not protected by encryption,
   so the contents of TLVs in LSPs are visible throughout the
   routing area or domain, while the contents of Hello Packets,
   CSNPs, and PSNPs are visible to observers on the link they
   are sent to.  The addition of MD5 authentication, as described
   in [5] can increase the integrity of TLVs, while encryption could
   increase their confidentiality.

   The general extensibility of the TLV mechanism has always allowed
   the addition of new information, and the possibility of conflicting
   interpretations of such information by different implementations.
   This proposal does not introduce a new quality of information; it
   simply allows an increase in the quantity of such additions.  As
   such, it represents no new security issues for IS-IS.


. IANA Considerations

   [] currently lists TLV 250 as refering to an IETF draft.  At such
   time that this document becomes an RFC then the entry for TLV 250 in
   [3] will need to refer to the RFC number of this document.


. References

11.1 Normative References

   [] ISO, "Intermediate system to Intermediate system routeing
       information exchange protocol for use in conjunction with the
       Protocol for providing the Connectionless-mode Network Service
       (ISO 8473)", ISO/IEC 10589:1992.

   [] RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual
       Environments, R Callon, December 1990

   [] IS-IS TLV Codepoints per [RFC3563]
       IANA, http://www.iana.org/assignments/isis-tlv-codepoints

   [] Private Enterprise Numbers
       IANA, http://www.iana.org/assignments/enterprise-numbers

11.2 Informational References

   [] RFC 3567, Intermediate System to Intermediate System (IS-IS)
       Cryptographic Authentication
       Tony Li, RJ Atkinson, July 2003




Christian               Expires November 2005                         5

Internet Draft                                                 May 2005
                       TLV for Experimental Use


   [] RFC 2026, The Internet Standards Process -- Revision 3
       Scott O. Bradner, October 1996

   [] RFC 3563, Cooperative Agreement Between the ISOC/IETF and
       ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6)
       on IS-IS Routing Protocol Development, A. Zinin, July 2003


. Author's Addresses

   Philip Christian
   Christian Tena
   Ruislip
   Middlesex
   UK

   Email: philip.christian@christiantena.co.uk


. Intellectual Property Rights Statement

   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.

   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.

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


Christian               Expires November 2005                         6

Internet Draft                                                 May 2005
                       TLV for Experimental Use


. Disclaimer

   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.










































Christian               Expires November 2005                         7