Subject: [Isis-wg] Vendor proprietary LSP option codes

From: "Rijsman, Bruno (Bruno)" <[email-masked]>
Date: Wed, 22 Sep 1999 14:59:11 -0400

We are considering to use a proprietary LSP option for one of our
applications and we a considering which LSP option code we could use for
this application. We want to pick an option code which guarantueed not to
conflict with any existing or future option codes used in integrated IS-IS
and proprietary option codes of other vendors.

It seems to me that 
(a) there is currently no official way for allocating unique option codes
(b) option codes are a scarce resource (only 255 codes available)

To solve this, it would be a good idea to:
(a) allocate a single option code for "vendor proprietary options"
(b) to require that the first three bytes in such "vendor proprietary
options" must be an ethernet OUI allocated to that vendor
(c) to strongly recommend that "vendor proprietary options" be small in size
and do not change frequently (to avoid impact on "innocent" nodes).
(d) to require that "vendor proprietary options" which are not recognized
must be silently ignored but propagated anyway (actually, this is already
part of ISO 10589).

If such an option already exists, could someone point me to it. If it
doesn't exist yet, what would be the proper process for me to standardize
such an option?

PS - It might be relevant to know that for this particular application we
are using IS-IS in an OSI CLNP network (the OSI network is used for
management of SDH/SONET network elements).

Bruno Rijsman
Lucent Technologies - Optical Networking Group

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

---

From: Tony Li <[email-masked]>
Date: Thu, 23 Sep 1999 10:52:09 -0700

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.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 23 Sep 1999 11:17:17 -0700

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

I agree between those two alternatives but still find both inferior to
simply allocating TLV types to vendors, with the hope that they eventually
make the semantics public.

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 23 Sep 1999 11:31:22 -0700

|  However, I wouldn't
|  want to do things like standardizing the way to pass company's X
|  equipment serial numbers for 
|  inventory purposes ;-)

We are, of course, in violent agreement.  Hopefully no one would burden the
routing protocol with becoming their generic transport mechanism even with
a proprietary TLV type.

Tony

---

From: Jeff Learman <[email-masked]>
Date: Thu, 23 Sep 1999 17:28:10 -0400

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:
>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:     [email-masked]
  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
____________________________________________________________________