Re: Vendor attributes in TE LSAs - (Sent first reply prematurely)

[Tony Przygienda <[e-mail]>]

Acee Lindem wrote:

> Tony Przygienda wrote:
>
>> Acee Lindem wrote:
>>
>>
>>>>
>>>
>>> isn't any) 2) Scalability (LSA contents, size, and refresh frequency
>>> are
>>> unknown) and 3) Deployment - Debugging a multi-vendor network with many
>>> different vendor specific LSAs will be difficult.
>>
>>
>>
>> ok, but then from experience, they will _just_ take the TLVs they need
>> without
>> letting you know. Suit yourself ;-)
>
>
> Maybe so - but at least this activity won't be sanctioned by the OSPF WG.

this is just a semantic or maybe semiotic split-of-hairs IMHO. OSPF-WG
or any
other WG-approval is not a consumer brand and does nothing for the vendor,
espeically if he's pursuiting a proprietary value-add-on in the protocol.

>
>
> Perhaps the IANA allocation of TLVs and Sub-TLVs needs to be at the front
> end of the process rather than the backend.

yes, but is easier for vendors to grab an 'experimental' OUI (which is a
no-time-involved
process) and once they figured
out what it does for them and care about interoperability, ask for an
'official' sub-TLV.
It will be a well-understood process by both vendors AND their
customers. Customers
will understand that an 'experimental' gives them no guarantee as to
itneroperability as
Ran very clearly formulated and has been put down in the
isis-experimental draft.
Otherwise they'll ask you for a sub-TLV or probaly not even that (since
it needs time, so
they
just grab any number that looks free)
and of course not tell you what it does. Difference against just
semantical IMHO
and in terms of
reality the output is the same

    thanks

    -- tony