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

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 28 May 2003 01:36:14 -0400

Hi Acee,

Though you can have vendor specific TLV encodings, the issue is there may be
a clash in the TLV or Sub-TLV values.

By using an SMI enterprise code or OUI to distinguish between various vendor
specific implementations, we have one value that can be used by vendors
instead of taking any TLV values, and we do not confuse information by
various vendors, which are used for different purposes.

Thanks,
Vishwas

-----Original Message-----
From: Acee Lindem [mailto:[email-masked]]
Sent: Wednesday, May 28, 2003 10:07 AM
To: [email-masked]
Subject: Re: Vendor attributes in TE LSAs - (Sent first reply
prematurely)

References:
<[email-masked]>
<[email-masked]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Udo,

Aside from any technical details, I don't agree with this draft
philosophically. In essence, it is a proposal to standardise on
a mechanism to be non-standard. More specifically, it removes
the OSPF WG, TE WG, and IETF in general from reviewing the vendor
specific TLVs. The contents, size, and refresh rate of these TLVs
are unknown.

By definition, there is no interoperability. The same set of problems
will undoubtedly be solved in multiple ways by different vendors using
different vendor specific TLV encodings.

Acee Lindem wrote:
> Udo,
>
> I don't support this enhancement since it essentially removes any
>
>
> Udo Neustadter wrote:
>
>> Hi all,
>>
>> I am working on a GMPLS implementation, and part of my problem is the
>> addition of company specific data to the TE LSAs. The Internet-Draft
>> http://www.ietf.org/internet-drafts/draft-udo-ospf-vendatt-00.txt
>> proposes an interoperable way to solve the following two issues:
>>   1. Companies that already applied with IANA for an SMI Network
>> management enterprise code do not need to re-apply for sub-TLV values
>> from the pool of numbers reserved for private use
>>   2. Allows private attributes/data to be embedded in the TE router LSA
>> (the one TE LSA that contains the router address TLV).
>>
>> I would like for the draft to be considered part of this working group.
>> This work is an extension to the work done in
>> http://www.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-09.txt
>> and
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensio
>> ns-09.txt.
>>
>> Thanks in advance for your support.
>>
>> Udo
>>
>
>
> --
> Acee
>

--
Acee

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2003 09:34:46 -0400

> various vendors, which are used for different purposes.

Hi Vishwas,

I understood the motivation. I think the SMI enterprise code is a better
choice than the OUI since it is administered by IANA. However, I'm against
the basic premise of allowing every vendor to roll their own TE LSAs and
carry them in OSPF. I believe doing so could impact 1) Interoperability (there
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.

Thanks,
Acee

--
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 28 May 2003 16:09:31 +0200

> 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 ;-)

    -- tony

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2003 10:22:56 -0400

> letting you know. Suit yourself ;-)

Maybe so - but at least this activity won't be sanctioned by the OSPF WG.

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

--
Acee

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 28 May 2003 18:14:35 +0200

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

> 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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 28 May 2003 14:06:46 -0400

> reality the output is the same

I'd be prefer an experimental range of TLVs that are
allocated from IANA for specific experimental purposes rather
than a single TLV giving carte blanche to advertise anything
in OSPF. I'm less cynical that the output will be the same. Hopefully,
if an experimental TE application is commerically viable it
will evolve into a standard.

--
Acee