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

From: Jeff Learman <[email-masked]>
Date: Wed, 12 Jun 2002 12:27:38 -0400

Minor comments below.

At 08:33 AM 6/12/2002, Philip Christian wrote:

>I have done an update, see below 
>
>Philip 
>
>> -----Original Message----- 
>> From: mike shand [<mailto:[email-masked]>mailto:[email-masked]] 
>> Sent: Tuesday, June 11, 2002 3:56 PM 
>> To: Christian, Philip [HAL02:GI50:EXCH] 
>> Cc: 'Tony Przygienda'; [email-masked]; 'Mike Truskowski' 
>> Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? 
>> 
>> 
>> At 15:38 11/06/2002 +0100, Philip Christian wrote: 
>> >On receipt of an LSP a router MUST ignore TLVs of type XXX that 
>> >    include an OUI from a different organization, 
>> 
>> MUST is a bit strong here. SHOULD or MAY, perhaps. If you 
>> know how to parse 
>> company X's subTLVs you should be allowed to do so. 
>> 
>> I'm not sure we want to get into mentioning non-standard OUIs 
>> with G or L 
>> bits set. 
>> 
>>          Mike 
>> 
>> 
>
>Internet Engineering Task Force                            P. Christian 
>INTERNET DRAFT                                          Nortel Networks 
>                                                              June 2002 
>  
>  
>                          TLV for Proprietary Use 
>                     draft-ietf-isis-private-tlv-forlist2.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>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>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. 
>    
>
>
>
>
>  
>                       TLV for Proprietary Use               June 2002  
>  
>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 an IS-IS router SHALL flood entire LSPs that 
>   it receives on to other IS-IS routers in the network, whether or not 
>   it understands the TLVs that are included in the LSP.  Also IS-IS 
>   LSPs are structured such that a router can find TLVs that it 
>   understands, whilst ignoring ones that it does not. 
>    
>   Thus information that is encoded into a TLV and placed into 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 

use semicolon instead of comma above

>   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 

"depletion" rather than "burning".

>   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 XXX. 
>    
>   TLVs that use XXX for the type field MUST include a valid IEEE 
>   assigned OUI as the first three bytes of the value field of the TLV.  
>   For more information about OUIs see [3]. 
>    
>
>  
>                       TLV for Proprietary Use               June 2002  
>  
>   On receipt of an LSP a router MAY ignore TLVs of type XXX that 
>   include an OUI from a different organization, however the router 

"unrecognized OUI" rather than "different organization".  And I think
"MAY" should be "MUST", but I won't quibble.

>   MUST flood the LSP onwards as per [1]. 
>  
>   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]. 

I would say "The format of the remainder of the TLV would be defined
by the identified organization, and MUST be 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 sub-TLVs are 
>   to be used then the very first implementation to exist 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. 

This is one way.  Another way would be to use EUI48 or EUI64 numbers
as type codes, especially for large organizations to allow hierarchical
assignment of type codes.  EUI numbers start with the OUI, and the
remainder is allocated by the organization owning the OUI.  Admittedly,
this doesn't allow as optimized use of a switch statement as sub-TLVs
would.

Regards,
Jeff

>    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 
>    
>   [3] <http://standards.ieee.org/regauth/oui/index.html>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]

---

From: mike shand <[email-masked]>
Date: Thu, 13 Jun 2002 09:52:29 +0100

>"MAY" should be "MUST", but I won't quibble.

Yes, that's much better. Must ignore if you don't recognize.

         Mike

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