Internet Engineering Task Forceßßßßßßßßßßßßßßßßßßßßßßßßßßß P. Christian
INTERNET DRAFTßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßChristian Tena LTD
ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß ßßßDecember 2003
ß
ß
ßßßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use
ßßßßßßßßßßßßßßßßß<draft-ietf-isis-experimental-tlv-01.txt>
ß
Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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.  Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a
   "working draft" or "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 memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind.

   Distribution of this draft is unlimited.
ßßß
ßßß
1. 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.
ßßß
ßßß
2. 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 June 2004                           1

Internet Draft                                            December 2003
ßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use
ß
3. 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.
ßßß
ßß No single authority assigns TLV codes, [3] lists most known TLV
ßß codes at this time.ß Also no TLV code was ever defined for
   experimental use.
ßßß
ßß The extensible nature of IS-IS has made the use of TLVs in LSPs for
ßß non-standard purposes so useful that in the absence of a central
ßß authority for assigning TLV type numbers 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.
ßßß
ßß 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.
ßßß
ß
4. 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 IEEE
ßß assigned OUI as the first three bytes of the value of the TLV.

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


Christian                 Expires June 2004                           2

Internet Draft                                            December 2003
ßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use


                                            No. of Octets
             +---------------------------+
             |        CODE =250          |      1
             +---------------------------+
             |       LENGTH =n+3         |      1
             +---------------------------+
             |           OUI             |      3
             +---------------------------+
             |           DATA            |      n
             +---------------------------+

              Structure of the Experimental TLV

   The three octet OUI 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 three.

   For more information about OUIs 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 OUI 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 three 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 OUIs.ß
ßß Implementers are free to format the value field after their OUI into
ßß sub-TLVs so that the TLV may be used for multiple purposes, and would
   be well advised to do so.


5. 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 June 2004                           3

Internet Draft                                            December 2003
ßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use


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


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

ßßß
8. 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 June 2004                           4

Internet Draft                                            December 2003
ßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use


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

ßß
10. References
ßßß
ßß [1] 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.

   [2] RFC 1195, Use of OSI IS-IS for Routing in TCP/IP and Dual
       Environments, R Callon, December 1990
ßßß
ßß [3] RFC 3359, Reserved TLV Codepoints in ISIS
       Tony Przygienda, August 2002

   [4] IEEE OUI and Company_id Assignments
       http://standards.ieee.org/regauth/oui/index.shtml

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

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




ßßß







Christian                 Expires June 2004                           5

Internet Draft                                            December 2003
ßßßßßßßßßßßßßßßßßßßßßß TLV for Experimental Use


11. Author's Addresses
ßßß
ßß Philip Christian
ßß Christian Tena LTD
  ßßß
ßß Email: philip.christian@christiantena.co.uk














































Christian                 Expires June 2004                           6