[Isis-wg] Vendor proprietary LSP option codes

[Jeff Learman]

I agree with Tony P.

There needs to be a safe way of allocating TLV codes, whether for
vender-proprietary purposes or prototypes for new functions that
might be standardized.  Migration from a vendor-specific code to
a standard code is the problem of the vendor.

There is no authority stepping forward to manage the 8-bit TLV
code space for IS-IS.  Clearly, ISO methods are far too slow.
The IETF has the advantages that it is quick-acting and is
a respected authority.  A TLV code should be selected for
"OUI-identified options", and simply state that the option
is defined by the authority specified by the OUI.

The 8-bit code space is rather limited, so if there was a good
allocation method, any company with a possible interest might feel
compelled to get one ASAP.  The 8-bit code space should be reserved
for standard options, with a grandfather clause for current practice
(provided there is public disclosure of such TLV codes, to avoid
future collisions).

Regards,
Jeff

At 11:03 AM 9/23/99 -0700, Tony Przygienda wrote:
>Tony Li wrote:
>
>> Bruno,
>>
>> Are you looking for a TLV type or a sub-TLV type to the proposed
>> extended IS/IP reachability TLV?
>>
>> If it's the former, then you are correct, there is no 'clean' way of
>> getting a number out of ISO today because so little work is going on in
>> ISO.  I suppose that you could take a proposal to them, or you could
>> circulate a proposal within the IETF.
>>
>> For the latter, we can help you out.  You might note that Cisco has several
>> reserved codes.
>>
>> IMHO, creating a single TLV type or sub-TLV type for 'vendor proprietary
>> options' is probably a poor choice as it has some future difficulties.  If
>> you ever do make your extension public (and you DO want to make it public
>> eventually...) and it gets a 'normal' TLV type, then you have to make a
>> migration to the new TLV.  If you don't use a 'normal' TLV, then all sorts
>> of interesting extensions end up in the 'vendor proprietary' bucket and we
>> have a soup that serves no one well.  Our goal has to be to create an open
>> protocol, not foster incompatible extensions.
>
>Disagree here,
>
>in my opinion, the migration is the issue specific to a specific vendor
only if he chooses
>to make the extensions public. OUI is the best way to get people a sandbox in
>which they can try things. It's indefinitely better than having people
"just using
>some TLV codes" due to the lack of a reserved one and collide in the field.
>
>--
>        thanks
>
>        --- tony
>
>
>
>
>
____________________________________________________________________

  Jeff Learman                           Internet:     jjl@one.com
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________