Subject: some ideas on TLV type ...

From: Antoni Przygienda <[email-masked]>
Date: Wed, 25 Nov 1998 00:03:36 -0500

After reading Henk's & Naiming's draft something crossed my mind. We
have a pretty restricted TLV type space 
and it could make sense to start to think how to structure it further,
especially since we can start to collide
with new things that OSI could introduce (that can be of course solved
with proper communication but it takes
time). One possible solution would be to grab a reserved TLV type for 
optional IP extensions like the proposed ID or SNP checksums & structure
it further within, e.g.

	+-------------------+
	| IP extensions type| 1 byte
	+-------------------+
	| length	    | 1 byte
	+-------------------+ 
	| subtype 	    | 2 bytes
	|		    |
	+-------------------+

Additionally, it could make sense to have something to allow proprietary
things being put without 
standardizing them out by using OUI of 
the organization, it would be a well-known type and within it would be
structured based on the OUI. 

I think that's kind of somehow related to some of the issues that Tony
brought up witht the MPLS extensions
write-down.

Do I make sense ?  I know it wouldn't be a popular move now that the
drafts start to come in but the pain would 
be mild now compared to the one we'd take if we'd be forced to do it
later. 

		thansk 

		-- tony

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Nov 1998 00:37:50 -0800 (PST)

Tony,

I think that move might be more warranted when the TLV type space is
somewhat more depleted.  Currently we're using only a handful of the 256
possible types.  This would seem to be MUCH more of an issue if we were
looking at 50-80% utilization.  You'll note that we need only allocate one
additional type value as an 'escape', and that gives us 256 or 65535 more
values.

Regards,
Tony

---

From: Mike Shand <[email-masked]>
Date: Wed, 25 Nov 1998 08:52:35 +0000

Yes, I suggested something like this to a few folks a while ago. I'm not
sure whether it makes any sense for 'standardized' options. Hopefully we
can keep some kind of control between the IANA and OSI code point spaces,
and as Tony Li says wee are not (yet) running out. However the vendor
specific option seems like a useful thing. Not so much so that vendors can
do really way out things, but so that experimental features can be put in
without ANY fear of it causing a problem with other implementations.
Of course the classic example of this is that DEC uses option 42 (for
obvious Hitch-hiker reasons)  for the 'PhaseIV Information' option. We just
kind of hoped that nobody would ever re-use it, but of course it isn't
written down in any standard.

It occurs to me that we might end up with an option space structured rather
like the NSAP address space if we are not careful :-) :-(

	Mike

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Nov 1998 01:02:52 -0800 (PST)

|  Of course the classic example of this is that DEC uses option 42 (for
|  obvious Hitch-hiker reasons)  for the 'PhaseIV Information' option. We just
|  kind of hoped that nobody would ever re-use it, but of course it isn't
|  written down in any standard.

Yup, that was discovered and holds honored placement in both Cisco's and
Juniper's implementations.  ;-)

|  It occurs to me that we might end up with an option space structured rather
|  like the NSAP address space if we are not careful :-) :-(

I'd like to think we can do a good bit better than that...  ;-)

Tony

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 25 Nov 1998 11:07:11 -0500

> Juniper's implementations.  ;-)

And of course a few more have been used that hopefully people take the
pain to document ... 

> I'd like to think we can do a good bit better than that...  ;-)

I buy Tony's argument here about the codepoints although without
excitement, by the time we're 75%
full, I'm sure there will be lots of things that absolutely must have
their own codepoint
and then the usual "my hashing function wasn't all that perfect"-blues
will start. Should we 
however come up with some kind of rough guideline which subrange we'll
use ? Arbitrarily grabbing
things from anywhere smells like a real anarchy. I'd suggest to just
continue after the already 
existing IP extension TLVs.

2nd, is anyone willing to write the OUI one down ? It's pretty straight
forward. 

		thank you

		--- tony