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

From: Jeff Learman <[email-masked]>
Date: Thu, 11 Jul 2002 13:18:06 -0400

Philip,

Looks great.

I think we should consider adding one comment to this document.
It's controversial, but this opinion has been raised before and
maybe should be voiced.
 
  There is a danger to using ISIS as a generic transport mechanism for
  flooding information.   LSPs get big, LSDBs get big, CPU time goes up,
  etc.  For this reason, use of this mechanism in LSPs SHOULD be restricted
  to purposes that are important for routing, and an effort should be
  made to minimize the amount of information to be flooded.  Updates
  to information flooded this way SHOULD be less frequent than link
  state and adjacency changes, to avoid causing unnecessary runs of
  SPF.

This is putting it mildly.  Some folks have said, with good reason, that
use of this kind of feature should be strongly discouraged.
No doubt some word-smithing is in order.

Trivial edits below.

At 12:36 PM 7/11/2002, you wrote:

>Jeff, 
>
>I have just realised that your comments now are important as by the time you get back I will have submitted it onto the Internet Drafts server thing.  I intend to do this on the 15th or 16th.
>
>I hope that you can have a look before you go.  There is actually enough info in here to implement, and so I'm sure that people actually will.
>
>Thanks, 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>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. 
>    
>
>
>
>
>
>
>
>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 

semicolon instead of comma above.

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

PDUs (not DPUs)
operator's

That's all
Jeff

>   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>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 
>
>-----Original Message----- 
>From: Christian, Philip [HAL02:GI50:EXCH] 
>Sent: Thursday, July 11, 2002 5:23 PM 
>To: 'Jeff Parker'; 'Mike Truskowski' 
>Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? 
>
>Here is the security section of what I sent on the 4th. 
>
>If you can improve it then be my guest (I am sure that you can). 
>
>Philip 
>
>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. 
>
>-----Original Message----- 
>From: Jeff Parker [<mailto:[email-masked]>mailto:[email-masked]] 
>Sent: Thursday, July 11, 2002 5:17 PM 
>To: 'Mike Truskowski' 
>Cc: Christian, Philip [HAL02:GI50:EXCH] 
>Subject: RE: [Isis-wg] Proprietary / Private TLV numbers? 
>
>Mike - 
>        Yes, the only thing missing was a note from me saying "Ooops" to the 
>list.  
>
>        I am running out of time here, but I'm sure that the issue is in 
>good hands. 
>I'll be back in 10 days and will look forward to the current state of 
>revisions. 
>
>- jeff parker 
>
>> From: Mike Truskowski [<mailto:[email-masked]>mailto:[email-masked]] 
>> Sent: Thursday, July 11, 2002 12:12 PM 
>> To: [email-masked] 
>> Cc: [email-masked] 
>> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers? 
>> 
>> 
>> This message uses a character set that is not supported by 
>> the Internet Service.  To view the original message content,  
>> open the attached message. If the text doesn't display 
>> correctly, save the attachment to disk, and then open it 
>> using a viewer that can display the original character set. 
>
>If this was private it must have been copied to the whole list by 
>mistake... 
>
>Anyway, at first I didn't agree with his comments about the word 
>secure since the OUI is present in the TLV.. but by  the time 
>I got to the last sentence.. I seemed to agree with the thought 
>process. 
>
>Simply the word "secure" infers different things to different=20 
>people...   I actually agree in spirit with his last 2 points.  Maybe 
>we, Philip or Jeff, should rewrite the paragraph.   It's OK by me. 
>
>I wonder if it was left out to begin with would anyone have asked 
>to add it. 
>
>Mike>

---

From: mike shand <[email-masked]>
Date: Thu, 11 Jul 2002 19:18:26 +0100

>It's controversial, but this opinion has been raised before and

I strongly agree. There should be some warning against using this as a 
general purpose reliable multicast.

         Mike

>>I have just realised that your comments now are important as by the time 
>>you get back I will have submitted it onto the Internet Drafts server 
>>thing.  I intend to do this on the 15th or 16th.
>>
>>I hope that you can have a look before you go.  There is actually enough 
>>info in here to implement, and so I'm sure that people actually will.
>>
>>Thanks, Philip
>>
>>    [3] 
>> <http://standards.ieee.org/regauth/oui/index.html>http://standards.ieee.org/regauth/oui/index.html 
>>
>>
>>7. Acknowledgments
>>
>> > From: Mike Truskowski 
>> [<mailto:[email-masked]>mailto:[email-masked]]

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