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

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

I am guessing that OUI means an IEEE assigned MAC address?

If so then it sounds okay to me.

I'll write it if you like.

Philip

> -----Original Message-----
> From: Tony Przygienda [mailto:[email-masked]]
> Sent: Monday, June 10, 2002 5:44 PM
> To: Christian, Philip [HAL02:GI50:EXCH]
> Cc: 'Mike Truskowski'; [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> 
> 
> Yes, the proposals have been made before and nohting has been written 
> down. I am
> for using the official OUI, this would be aligned with Frame 
> Relay, ATM 
> and so on.
> The /32 may fly but unfortunately IP address space is a 
> volatile thing 
> compared to
> OUIs. I assume any vendor building sophisticated networking gear with 
> ISIS on it
> will at a certain point have an OUI, I see little value in having a
> /32-address-based-cottage-industry-of-ISIS-extensions ...
> 
> So, this time any takers to write it down ?
> 
>     thanks
> 
>     -- tony
> 
> 
> 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
> >
> > > -----Original Message-----
> > > From: Mike Truskowski [ mailto:[email-masked] ]
> > > Sent: Monday, June 10, 2002 2:42 PM
> > > To: [email-masked]
> > > Cc: Christian, Philip [HAL02:GI50:EXCH]; 
> [email-masked]
> > > Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?
> > >
> > >
> > > 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:
> > > >
> > > > >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?
> > > >
> > > > Yes! That's how NSAP addresses got to be so awful :-)
> > > >
> > > >          Mike
> > > >
> > > >
> > > >
> > > > >Philip
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: mike shand
> > > [<mailto:[email-masked] >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?
> > > > > >
> > > > > >
> > > > > > At 11:29 10/06/2002 +0100, Philip Christian wrote:
> > > > > > >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
> > > > > > >
> > > > > >
> > > > > > 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: Jeff Learman <[email-masked]>
Date: Tue, 02 Jul 2002 11:17:43 -0400

>I am guessing that OUI means an IEEE assigned MAC address? 

It's the first three bytes of an IEEE assigned MAC address.
An OUI can be used for purposes other than assigning MAC addresses.

See http://standards.ieee.org/regauth/oui/index.shtml for more info.

Jeff

>> From: Tony Przygienda [<mailto:[email-masked]>mailto:[email-masked]] 
>> > > From: Mike Truskowski [ <mailto:[email-masked]>mailto:[email-masked] ] 
>> > > [<<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 
>> > > > 
>> > > 
>> > > 
>> > 
>> 
>> 
>>

---

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

And to answer my own question...

One can read what OUIs are from
http://standards.ieee.org/regauth/oui/index.shtml

still sounds okay to me

Philip

> From: Christian, Philip [HAL02:GI50:EXCH] 
> Sent: Monday, June 10, 2002 6:00 PM
> To: 'Tony Przygienda'
> Subject: RE: [Isis-wg] Proprietary / Private TLV numbers?
> 
>

---

From: Jeff Parker <[email-masked]>
Date: Wed, 3 Jul 2002 16:56:14 -0400

> I looked at your draft and looks ok. Actually, MAC addresses have a 
> 'local-valid-only' bit but I forgot whether it
> was in OUI or not or maybe that's the bit you found.

I think you are both thinking about the "global/local" bit,
which is the second bit on the wire, right after the 
unicast/mcast bit, which is the LSBit of the first byte.  

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Wed, 3 Jul 2002 16:57:08 -0400

> unicast/mcast bit, which is the LSBit of the first byte.  

...and therefore part of the OUI-space.  
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 3 Jul 2002 23:32:59 +0100

I haven't yet, no.  My boss (the wife) suddenly decided that I would be
taking a week off work.
I'm back now though and will have another go at it.

Philip

-----Original Message-----
From: Jeff Learman [mailto:[email-masked]]
Sent: Wednesday, July 03, 2002 10:45 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: [email-masked]
Subject: Re: [Isis-wg] Proprietary / Private TLV numbers?

Have you updated the text since the round of comments after your
post on 6/12?

Jeff

>small comment on draft, pls find a reference to OUI description and include
it. Many people don't know the
>concept

---

From: "Philip Christian" <[email-masked]>
Date: Wed, 3 Jul 2002 23:34:33 +0100

No reason in my mind.
I can add it if no one objects.

Philip

-----Original Message-----
From: Naiming Shen [mailto:[email-masked]]
Sent: Wednesday, July 03, 2002 11:10 PM
To: Christian, Philip [HAL02:GI50:EXCH]
Cc: 'Tony Przygienda'; [email-masked]; 'Mike Truskowski';
[email-masked]

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

---

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

At 06:10 PM 7/3/2002, Jeff Parker wrote:
>Thanks to Jeff L's link, I wandered over an grabbed the file.
>Most of the entries start with 00.  However, there are addresses
>with the second bit set.  Here are a few...

Well I'll be ...  Not to mention that some listed companies
sure look like ones that might need to assign MAC addresses.
IEEE's OUI request form doesn't ask you whether you'll use it for
MAC addresses or for the other umpteen things OUIs are used
for.  I wonder if these are special assignments.

Based on this info, I would suggest adding the following to the text.

  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.

Or something like that.  Alternatively, if some saintly company
is willing to donate an OUI, we could use that.  For example, a
company could donate that form of their OUI with the "multicast"
bit set.  (Note that none of the assignments has an odd first byte?
I think this means that IEEE is willing  to ignore the "local/global"
meaning, but isn't silly enough to play the same game with
"unicast/multicast"!)

Jeff

>- jeff parker
>
>02-07-01   (hex)                RACAL-DATACOM
>020701     (base 16)            RACAL-DATACOM
>                                LAN INTERNETWORKING DIVISION
>                                155 SWANSON ROAD
>                                BOXBOROUGH MA 01719
>
>02-1C-7C   (hex)                PERQ SYSTEMS CORPORATION
>021C7C     (base 16)            PERQ SYSTEMS CORPORATION
>                                2600 LIBERTY AVENUE
>                                P.O. BOX 2600
>                                PITTSBURGH PA 15230
>
>02-60-86   (hex)                LOGIC REPLACEMENT TECH. LTD.
>026086     (base 16)            LOGIC REPLACEMENT TECH. LTD.
>                                14 ARKWRIGHT ROAD
>                                READING BERKS RG2OLS
>                                UNITED KINGDOM
>
>02-60-8C   (hex)                3COM CORPORATION
>02608C     (base 16)            3COM CORPORATION
>                                2081 N. SHORLINE BLVD.
>                                MOUNTAIN VIEW CA 94043
>
>
>- jeff parker
>- axiowave networks
>- My most important job is to defend the homeland, to protect innocent
>Americans from the deaths of the killers.
>- G. W. Bush
>
>
>
>> Sent: Wednesday, July 03, 2002 5:35 PM
>> To: Tony Przygienda
>> Cc: Philip Christian; [email-masked]
>> There are only 4 million OUIs, not 16.  Two bits are reserved
>> for "globally vs. locally assigned" and "multicast vs. unicast".
>> 
>> Practically speaking, if you own an OUI, you own two values, one
>> with the multicast bit clear and one with it set.  HOWEVER, I wouldn't
>> put it past IEEE to sell a special kind of OUIs that are NOT valid for
>> use in making MAC addresses (because the local or mcast bit
>> is set) so it is probably risky to use an OUI with this bit set for
>> any other purpose.
>> 
>> Use of an OUI with the locally-administered bit set is probably
>> fine for use in a lab.  However, you might want to ask IEEE before
>> committing this to an RFC.
>> 
>> When defining OUI you might want to include this URL:
>> "http://standards.ieee.org".  It's easy to find OUI from there, and
>> I hope that this URL is stable enough to document.
>> 
>> Jeff
>> 
>> >>So I am just writing something at the moment based on OUIs.
>> >>
>> >>Two questions.
>> >>
>> >>1. What TLV number shall be assigned as the proprietary TLV?
>> >you like 250?
>> >
>> >>2. Does the "locally assigned" bit have any significance in 
>> an OUI as it does in a MAC address?
>> >>
>> >>IEEE assigned OUIs are no problem for vendors, but I am 
>> thinking that there is no harm in allowing an individual to 
>> use an OUI with "locally assigned" bit set (or something 
>> similar) if they do not have an IEEE assigned OUI.
>> >>
>> >>One scenario is maybe a college student doing a university 
>> project for example.  An absolute requirement for an IEEE 
>> assigned OUI would be a big deal for them, whilst maybe the 
>> loss of an absolute guarantee of uniqueness would not cause 
>> them a serious problem.  In any case they can put their own 
>> "key" somewhere in the TLV to statistically reduce the 
>> problem to next to nothing, for example.
>> >>
>> >>The draft could clearly state that this SHOULD NOT be used 
>> for commercial products intended for deployment in the 
>> Internet, if that helps.
>> >>
>> >>Put another way, it might just stop a student / lab guy 
>> from just picked your OUI at random and trampling on it, just 
>> because he thinks that it will never get out of the lab...
>> >I looked at your draft and looks ok. Actually, MAC addresses 
>> have a 'local-valid-only' bit but I forgot whether it
>> >small comment on draft, pls find a reference to OUI 
>> description and include it. Many people don't know the
>> >concept
>> >
>> >   thanks
>> >
>> >   -- tony
>> >
>> >
>> >

---

From: Jeff Parker <[email-masked]>
Date: Wed, 3 Jul 2002 18:55:49 -0400

I must have too much time on my hands.  

I noticed a few dozen with bit 1 set, but there is even one with bit 0 set!

11-00-AA   (hex)		PRIVATE
1100AA     (base 16)	

And the old DEC hands will remember these addresses - all with Philip's bit
set.  

- jeff parker	 

AA-00-00   (hex)		DIGITAL EQUIPMENT CORPORATION
AA0000     (base 16)		DIGITAL EQUIPMENT CORPORATION
				LKG 1-2/A19
				550 KING STREET
				LITTLETON MA 01460-1289

AA-00-01   (hex)		DIGITAL EQUIPMENT CORPORATION
AA0001     (base 16)		DIGITAL EQUIPMENT CORPORATION
				LKG 1-2/A19
				550 KING STREET
				LITTLETON MA 01460-1289

AA-00-02   (hex)		DIGITAL EQUIPMENT CORPORATION
AA0002     (base 16)		DIGITAL EQUIPMENT CORPORATION
				LKG 1-2/A19
				550 KING STREET
				LITTLETON MA 01460-1289

AA-00-03   (hex)		DIGITAL EQUIPMENT CORPORATION
AA0003     (base 16)		DIGITAL EQUIPMENT CORPORATION
				LKG 1-2/A19
				550 KING STREET
				LITTLETON MA 01460-1289

AA-00-04   (hex)		DIGITAL EQUIPMENT CORPORATION
AA0004     (base 16)		DIGITAL EQUIPMENT CORPORATION
				LKG 1-2/A19
				550 KING STREET
				LITTLETON MA 01460-1289
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://spider.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Parker <[email-masked]>
Date: Thu, 11 Jul 2002 10:25:27 -0400

Philip -
	Private mail.
	I think Ran's final point is actually quite helpful.  
I'd be happy to review a new version of this, or to suggest
one, if you drop me a line the next three hours.  (I'm headed
on vacation)

- jeff parker

> On Wednesday, June 12, 2002, at 08:33 , Philip Christian wrote:
> > 5. Security Considerations
> >  
> >    The proprietary TLV raises no new security issues for IS-IS. 
> 
> 	Excuse me, but I don't think so.  I think that it 
> raises new security
> 	issues because different vendors might use it in 
> different ways.  In
> 	a multi-vendor environment there could be unintended 
> consequences
> 	where A sends something with the new TLV that is syntactically
> 	valid with a different box B, but has unrelated semantics.
> 
> 	Even if I'm confused, it is customary to outline *why* 
> one thinks
> 	that no new security issues are raised, rather than making the
> 	assertion without supporting explanatory text.
> 
> >    Information placed in an IS-IS TLV cannot be considered secure,
> 
> 	You've not defined "secure".  For "secure" == "authentic",
> 	then the IS-IS MD5 authentication can provide some security.
> 	If by "secure" you mean that "confidentiality" is provided,
> 	then please talk in terms of "confidentiality" rather than
> 	the vague term "secure".
> 
> > and
> >    so if security is required then an implementation will need to
> >    encrypt the information using a suitable method.
> 
> 	This also seems wrong.  I'd suggest re-writing the whole section
> 	and in the re-write not using the word "secure" anyplace,
> 	instead using words like "integrity", "authentication", and/or
> 	"confidentiality" so that one's meaning is more crisp and clear.
>

---

From: Jeff Learman <[email-masked]>
Date: Thu, 11 Jul 2002 11:30:10 -0400

Philip, here is the previous email I was referring to.

>Date: Wed, 12 Jun 2002 12:27:38 -0400
>To: "Philip Christian" <[email-masked]>
>From: Jeff Learman <[email-masked]>
>Cc: [email-masked], "'Tony Przygienda'" <[email-masked]>, "'Mike Truskowski'" <[email-masked]>, "'mike shand'" <[email-masked]>
>
>
>Minor comments below.
>
>At 08:33 AM 6/12/2002, Philip Christian wrote:
>
>>I have done an update, see below 
>>
>>Philip 
>>
>>> From: mike shand [<mailto:[email-masked]>mailto:[email-masked]] 
>>> Sent: Tuesday, June 11, 2002 3:56 PM 
>>> Cc: 'Tony Przygienda'; [email-masked]; 'Mike Truskowski' 
>>> 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
>
>>   Information placed in an IS-IS TLV cannot be considered secure, and 
>>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: "Philip Christian" <[email-masked]>
Date: Thu, 11 Jul 2002 17:20:03 +0100

On the 4th of July I sent out an update.  I am coming to the conclusion that
no-one got it,  sigh....
On top of that for every comment I have to figure out whether it is a new
one, or whether it is an old one that the old list server is still shooting
at me.
Please can someone just kill the old server...

Anyway here is the one that I sent on the 4th.

Some of the comments that people have sent will be addressed, and others
won't.  It represents the state of play in my mind from seven days ago.

One thing that I changed was the security section, thought Jeff's new point
is helpful too.

My apologies if things are not addressed.  If so then it is due to my
confused state caused by old mails flying about.

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 

    
    
   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. 

1. Abstract 

    

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

   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. 

    
    
   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.

Christian                Expires January 2003                         2
                       TLV for Proprietary Use                July 2002

   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. 

   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. 

   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 

     
Christian                Expires January 2003                         3
                       TLV for Proprietary Use                July 2002

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

7. Acknowledgments 

8. Author's Addresses 
    
   Philip Christian 

Christian                Expires January 2003                         4

---

From: "Philip Christian" <[email-masked]>
Date: Fri, 12 Jul 2002 17:03:16 +0100

"But I really think a note along the lines of "be sensible" is all that is 
required.

         Mike"

I have no problems with that.

Thanks, Philip

---

From: Jeff Learman <[email-masked]>
Date: Fri, 12 Jul 2002 13:03:16 -0400

At 11:36 AM 7/12/2002, Philip Christian wrote:
>Excuse my ignorance on this, but is it normal practice (or even mandatory) for an IS to store the old LSP when a new one comes along?  Presumably it holds it till it times out?
>
>Therefore sending a big TLV is bad. 

Right.

>Sending a TLV frequently is bad. 

Not quite right.  CHANGING a TLV frequently is bad, because
you need to regen and flood your LSP each time you change it.
Of course, someone might say, "Well, I don't need to update
everyone each time I change the value, it's fine just to include
the current value whenever I generate my LSP for some other
reason."  This would be fine, and it means that we need to be
a little more specific about what not to do: your TLV should
not significantly affect the frequency with which your router
sends LSPs.  (Obviously, this argument applies to LSP TLVs, so
we gotta be careful about that ...)  But like Mike says, let's
keep it as simple as possible, and give a word to the wise.
Fools better not be messing with this stuff anyway ;-)

By the way, it wouldn't make much sense to send your TLV in some
LSPs and not in others.  I suppose someone could come up with an
excuse to do this, but I doubt I'd buy it.

Jeff

>Sending a big TLV frequently is bad^2 ? 
>
>Is that about right? 
>
>Thanks, Philip