Subject: RE: [Isis-wg] Proprietary / Private TLV numbers?

From: "Philip Christian" <[email-masked]>
Date: Tue, 11 Jun 2002 15:38:38 +0100

First shot at a draft.  Comments?

Philip

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

                          TLV for Proprietary Use 
                     draft-ietf-isis-private-tlv-forlist.txt 
 
Status of this Memo 
 
   This document is an Internet Draft.  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". 
    
   To learn the current status of any Internet-Draft, please check the 
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow 
   Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 
   munnari.oz.au. 
    
   A revised version of this draft document will be submitted to the 
   RFC editor as a Proposed Standard for the Internet Community.  
   Discussion and suggestions for improvement are requested.  This 
   document will expire before December 2002. 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 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. 

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 a router that does not understand a TLV that 
   it receives in an LSP SHALL process the parts of the LSP that it 
  
                       TLV for Proprietary Use               June 2002 

   does understand, and SHALL flood the entire LSP, including all TLVs 
   whether they are understand 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. 
    
   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.  Also no TLV type number was ever 
   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. Also this accelerates the burning 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 using this TLV type number 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 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 XXX. 
    
   TLVs that use XXX for the type field MUST include a valid IEEE 
   assigned OUI as the first three bytes of the value of the TLV, 
   except for the concession stated below.  The rest of the value field 
   may then be used freely. 
    
   On receipt of an LSP a router MUST ignore TLVs of type XXX that 
   include an OUI from a different organization, but MUST flood the LSP 
   onwards as per [1]. 
    
   Organizations or individuals that do not have access to an IEEE 
   assigned OUI MAY use a locally assigned three byte value instead, 
   however in this case the second least significant bit of the first 
  
                       TLV for Proprietary Use               June 2002 

   byte MUST be set to one to indicate that it is non-IEEE assigned, 
   and implementations that use such a non-IEEE assigned OUI SHOULD NOT 
   be installed in the Internet.  A non-IEEE assigned OUI does not 
   guarantee uniqueness and may cause interoperability problems with 
   implementations from other organizations. 
    
   After the first three bytes of the value field of the TLV subsequent 
   bytes may be used freely for any purpose 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 it may be used for multiple purposes, and would be 
   well advised to do this from the outset.  Note that if subTLVs are 
   to be used then the very first implementation to exist will need to 
   recognize the subTLV structure, and ignore subTLVs that it does not 
   understand whilst searching for subTLVs that it does understand. 

5. Security Considerations 
 
   The proprietary TLV raises no new security issues for IS-IS.  
   Information placed in an IS-IS TLV cannot be considered secure, and 
   so if security is required then an implementation will need to 
   encrypt the information using a suitable method. 

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

---

From: Naiming Shen <[email-masked]>
Date: Wed, 03 Jul 2002 15:10:26 -0700

Philip,
	is there a reason this TLV meant only for LSP packet, not
for any isis pdus? i would think this optional TLV can be useful
for other type of isis packets.

thanks.

 ] 
 ] First shot at a draft.  Comments?
 ] 
 ] Philip

- Naiming
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Wed, 03 Jul 2002 18:53:22 -0400

Good point.  It should be for all IS-IS PDUs.

---

From: "Philip Christian" <[email-masked]>
Date: Fri, 12 Jul 2002 15:43:07 +0100

This is my first thought on the problem of abuse of LSPs.  As normal
I've probably written too much, but it will give you guys something
to chew on and improve.  Comments?

Philip

Appropriate use of proprietary TLVs.

   IS-IS is a highly scalable routing protocol.  Networks have been
   deployed containing many hundreds of ISs in a single level-1 area or 
   level-2 subdomain.

   One contributing factor to this scalability is that an IS needs to
   advertise its links and metrics only when it starts up, or when its
   local connectivity changes in some way.  In this way the amount of
   routing information traversing an IS-IS routed network is normally
   very low.  Unlike some other routing protocols, there is no periodic
   transmission of routing information, except for LSP timeout which is
   very infrequent.

   A downside of this is that every time one IS does advertise a new
   state of connectivity, every single IS in the network will need to
   recalculate all of its routes, although there are certain
   optimisations that reduce this load.

   An unfortunate consequence of an IS sending out new information in a
   proprietary TLV in an LSP is that it causes every other IS in the
   level-1 area or level-2 subdomain to recalculate all of its routes,
   whether an IS understands that particular TLV or not.  If many ISs
   in a large network were to frequently send out new LSPs then all of
   the ISs might spend most of their time recalculating routes, which
   would reduce scalability and stability considerably.

   Therefore an IS SHOULD NOT regularly transmit information in a
   proprietary TLV in an LSP.  Proprietary TLVs in LSPs SHOULD NOT be
   used except for the following (or similar) purposes:-

   1. For information about an IS that is constant or very rarely
      changed.

   2. For information that is related to topology, in which case the
      topology change would result in a new LSP anyway.  In this case
      the topology change SHOULD trigger the proprietary TLV to be
      updated at the same time as the normal LSP update.  This results
      in all of the other ISs in the network performing only one SPF run
      rather than two.

   Proprietary TLVs in LSPs MUST NOT be used as a generalised
   communication channel.

   Proprietary TLVs that are used in Hello and SNP PDUs are not flooded
   throughout a network, and do not result in route recalculations
   (unless they are part of a feature that enables or disables 
   adjacencies).  Therefore the proprietary TLV MAY be used more freely
   in Hello and SNP PDUs.

---

From: Naiming Shen <[email-masked]>
Date: Fri, 12 Jul 2002 07:59:54 -0700

] 
 ]    An unfortunate consequence of an IS sending out new information in a
 ]    proprietary TLV in an LSP is that it causes every other IS in the
 ]    level-1 area or level-2 subdomain to recalculate all of its routes,

that assumption is not true. an IS has some intelligence SHOULD NOT
recalculate when some irrelavant information changes. for example,
some TE bandwidth info change in LSPs WILL NOT cause a reasonable
implementation to rerun SPF.

 ]    whether an IS understands that particular TLV or not.  If many ISs
 ]    in a large network were to frequently send out new LSPs then all of
 ]    the ISs might spend most of their time recalculating routes, which
 ]    would reduce scalability and stability considerably.
 ] 
 ]    Therefore an IS SHOULD NOT regularly transmit information in a
 ]    proprietary TLV in an LSP.  Proprietary TLVs in LSPs SHOULD NOT be
 ]    used except for the following (or similar) purposes:-
 ] 

- Naiming

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Fri, 12 Jul 2002 11:05:58 -0400

>implementation to rerun SPF.

Would it be better to say "it could cause every other IS in the
subdomain ..."?

Jeff