Subject: [Isis-wg] draft-ietf-isis-private-tlv

From: "Philip Christian" <[email-masked]>
Date: Thu, 4 Jul 2002 22:27:59 +0100

Here is my latest attempt at proprietary TLV.
Sorry if I have missed anyones ideas/comments, my inbox is a mess.
I cannot submit it as an Internet Draft until the 15th.

Philip

Internet Engineering Task Force                           P. Christian,
INTERNET DRAFT                                          Nortel Networks
                                                              July 2002

                          TLV for Proprietary Use 
                     draft-ietf-isis-private-tlv-forlist3.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 for vendor specific or 
   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 January 2003                         1
                       TLV for Proprietary Use                July 2002
 
3. Introduction 
    
   TLVs are extensions to IS-IS packets (PDUs).  When added to IS-IS
   LSPs they are flooded throughout an IS-IS level-1 area or level-2
   subdomain, and when added to IS-IS Hello PDUs they are are present
   only on a specific interface of an IS-IS router.

   The structure of IS-IS TLVs is defined in ISO 10589 [1].
    
   The basic function of an IS-IS TLV is identified by the first byte 
   of the TLV.  Thus there are only 256 possible basic types of TLV.  
   Certain types of TLV have been defined to include sub-TLVs so that a
   single TLV type can be used for multiple functions. 
    
   No single authority assigns TLV type numbers, [2] lists all known 
   TLV type numbers at this time.  No TLV type number has ever been 
   defined for private, proprietary or experimental use. 
    
   The extensible nature of IS-IS has made the use of TLVs in LSPs for 
   proprietary 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 type number may then be chosen by another organization at
   a later time for a different function, thus creating an 
   interoperability problem.  Such use also accelerates the consumption
   of the 256 possible TLV type numbers. 
    
   This document specifies a TLV type number that may be used for 
   proprietary, private or experimental purposes, and a mechanism that 
   insures that implementations from different sources can use the TLV 
   for different purposes 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 type numbers will no longer be diminished by proprietary use. 
    
4. TLV type number for proprietary use 
    
   The type field for this TLV SHALL be 250. 
    
   TLVs that use 250 for the type field MUST include a valid IEEE 
   assigned OUI as the first three bytes of the value field of the TLV.

   OUIs are three byte unique numbers that may be purchased from the 
   IEEE and which are used for several purposes.  Typically the first
   three bytes of a MAC address are an OUI for example.  By buying an
   an OUI a vendor has effectively bought a block of sixteen million
   MAC addresses, and so most vendors already have an OUI that may 
   also be used for proprietary TLVs as per this document.

   For more information about OUIs see [3]. 

Christian                Expires January 2003                         2
                       TLV for Proprietary Use                July 2002

   The OUI MUST NOT have the 7th bit of the first byte set in vendor
   implementations.  This bit is ordinarily reserved in the OUI portion
   of MAC addresses to mean "locally administered", and is reserved for
   locally administered (experimental) values in this TLV, e.g., for
   academic purposes.
  
   The TLV of type 250 may be used in IS-IS LSP, IIH, ISH or SNP PDUs.

   On receipt of an IS-IS PDU a router MUST ignore TLVs of type 250 
   that include an OUI that is not recognised, however the router MUST 
   flood LSPs onwards as per [1] even if they include unrecognised
   proprietary TLVs. 
 
   After the first three bytes of the value field subsequent bytes may 
   be used freely for any purpose provided that the resultant TLV is 
   conformant with [1]. 
    
   Organisations will have access only to a finite number of OUIs. The 
   IEEE reserves the right to not assign more OUIs to organisations 
   that already have them.  For more information see [3].  Therefore
   implementors would be well advised to think about defining a 
   format whereby one OUI can be used for multiple types of 
   proprietary TLV.

   Implementers are free to format the value field after their OUI into
   sub-TLVs so that it may be used for multiple purposes, and would be 
   well advised to do this from the outset.  Note that if sub-TLVs are 
   to be used then the very first and all subsequent implementations
   that use that OUI will need to recognize the sub-TLV structure, and
   ignore sub-TLVs that it does not understand whilst searching for
   sub-TLVs that it does understand. 
    
5. Security Considerations 
 
   The proprietary TLV raises no new security issues for IS-IS.  

   IS-IS DPUs will normally be limited to an operators routing domain,
   and so information placed in a proprietary TLV will not normally be
   visible outside of an operator's network.

   However IS-IS PDUs are not encrypted, and so if a link over which
   an adjacency is maintained is not secure, then any information 
   contained in an IS-IS PDU, including a proprietary TLV is not
   secure either.
    
6. 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] draft-ietf-isis-wg-tlv-codepoints-02.txt, Reserved TLV 
   Codepoints in ISIS, Tony Przygienda, November 2001 
     
Christian                Expires January 2003                         3
                       TLV for Proprietary Use                July 2002

   [3] http://standards.ieee.org/regauth/oui/index.html

7. Acknowledgments 
    
   The author takes no credit for this work as the concept was 
   discussed in the IS-IS Working Group before the author even became 
   an active participant.  Suggestions for acknowledgement gladly 
   received. 
    
8. Author's Addresses 
    
   Philip Christian 
   Nortel Networks Harlow Laboratories 
   London Road, Harlow, 
   Essex, CM17 9NA UK 
    
   Email: [email-masked] 

Christian                Expires January 2003                         4