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

From: "Philip Christian" <[email-masked]>
Date: Mon, 10 Jun 2002 11:29:41 +0100

Looking at draft-ietf-isis-wg-tlv-codepoints-02.txt I notice that there is
not really any mechanism for private or proprietary use of a TLV.
 
Thus various companies (including my own) have just pcked one and used it
for their own purpose.  Eventually this will create an interop problem, but
what else is a company to do?
 
Is there a way that we could define that a certain TLV number is for private
/ proprietary / experimental purposes?
 
This would then stop people just picking one.
 
I am thinking that there would have to be some sort of entity identifier in
there so that when you see this TLV you know whether it is yours or not.
 
Maybe we could define that the first four bytes are an IP address for
example.  Any entity large enough to want to use a proprietary TLV would
have a public IP address to put in there, I would have thought. After the
first for bytes then the rest would be free.
 
Or maybe there is a better way to identify a particular company / entity
(like a MAC address)?  Maybe ISO 8348?
 
What do people think?
 
Philip

---

From: mike shand <[email-masked]>
Date: Mon, 10 Jun 2002 12:23:39 +0100

At 11:29 10/06/2002 +0100, Philip Christian wrote:
>for their own purpose.  Eventually this will create an interop problem, 
>but what else is a company to do?
>
>Is there a way that we could define that a certain TLV number is for 
>private / proprietary / experimental purposes?
>
>I am thinking that there would have to be some sort of entity identifier 
>in there so that when you see this TLV you know whether it is yours or not.
>

This has been suggested before, but never came to anything. I think if it 
WERE to be done then using something link the MAC OUI would probably work. 
What do you mean by ISO 8348? Do you mean ISO 6523? I hope not :-)

         Mike

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

---

From: "Philip Christian" <[email-masked]>
Date: Mon, 10 Jun 2002 13:43:18 +0100

I suppose that we could define different sub-TLVs, a sub-TLV if the
identifier is an IPv4 address, a different sub-TLV if it is a MAC address,
etc

Then folks could use whichever mechanism they prefer, as long as it is a
globally unique identifier.

Or is that too complex?

Philip

> -----Original Message-----
> From: mike shand [mailto:[email-masked]]
> Sent: Monday, June 10, 2002 12:24 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> 
>

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 12 Jun 2002 13:33:43 +0100

I have done an update, see below

Philip

> Sent: Tuesday, June 11, 2002 3:56 PM
> 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 
    
   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. 

                       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 
   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 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 
   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]. 
    
   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. 
    
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 
    
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: Jeff Parker <[email-masked]>
Date: Mon, 10 Jun 2002 10:46:19 -0400

> >Then folks could use whichever mechanism they prefer, as 
> >long as it is a  globally unique identifier.
> >
> >Or is that too complex?
 
Per Mike's suggestion, an OUI is globally unique and 
very short.  What's not to like?

- jeff parker

---

From: Jeff Learman <[email-masked]>
Date: Mon, 10 Jun 2002 11:14:03 -0400

IP address assignments are not permanent like OUI assignments are.
I realize the chance for collision is very low, though ;-)

At 10:06 AM 6/10/2002, Philip Christian wrote:

>A vendor code of 4 octets could be an IPv4 address. 
>Then no-one would have to assign them. The vendor just uses a global IPv4 address that he has. 
>
>Even the smallest vendor can buy a /32 IP address for this purpose. 
>
>That would work. 
>
>Philip 
>
>> From: Mike Truskowski [<mailto:[email-masked]>mailto:[email-masked]] 
>> Sent: Monday, June 10, 2002 2:42 PM 
>> To: [email-masked] 
>> Cc: Christian, Philip [HAL02:GI50:EXCH]; [email-masked] 
>> Why not just do the following? 
>> 
>> +-------------------------------------------------+ 
>> | Type   |  Length  |       Value                 | 
>> +-------------------------------------------------+ 
>> | TLV #  |  Length  |  vendor code  |   "value"   | 
>> +-------------------------------------------------+ 
>> 
>> Where the vendor code is a fixed 3-4 octets? 
>> 
>> I guess one could do this on their own... couldn't they? 
>> 
>> The major problem I see here is what Philip said he wanted to fix... 
>> 
>> If vendors are doing this already and this is trying to avoid 
>> interoperability 
>> problems... then it would seem reasonable that the carrier 
>> would go back and 
>> install new images or force the vendor to fix the embedded 
>> base..  but they 
>> won't do either.. thus leaving the problem to stumble over some day... 
>> 
>> Mike 
>> 
>> > At 13:43 10/06/2002 +0100, Philip Christian wrote: 
>> > 
>> > >identifier is an IPv4 address, a different sub-TLV if it 
>> is a MAC address, etc 
>> > > 
>> > Yes! That's how NSAP addresses got to be so awful :-) 
>> > 
>> >          Mike 
>> > 
>> > 
>> > 
>> > >Philip 
>> > > 
>> > > > From: mike shand 
>> [<<mailto:[email-masked]>mailto:[email-masked]>mailto:[email-masked]] 
>> > <http://spider.juniper.net/mailman/listinfo/isis-wg>http://spider.juniper.net/mailman/listinfo/isis-wg 
>> > 
>> 
>>