Subject: Re: Vendor attributes in TE LSAs

From: "Manral, Vishwas" <[email-masked]>
Date: Tue, 27 May 2003 12:40:40 -0400

Hi Udo,

The draft looks pretty straight forward and simple.

A similar draft exists in IS-IS
http://www.ietf.org/internet-drafts/draft-ietf-isis-experimental-tlv-00.txt
, and instead of "SMI Network management enterprise code for the vendor or
organization" uses "a valid IEEE assigned OUI as the first three bytes of
the value of the TLV."

I do not know the tradeoffs but if possible we could use the same value too.
Maybe someone could point out the tradeoffs if any.

Besides I guess Section 5(if the same mechanism is used in TLV's) and
Section 6 of the ISIS draft wold be valid here too.

Thanks,
Vishwas

-----Original Message-----
From: Udo Neustadter [mailto:[email-masked]]
Sent: Tuesday, May 27, 2003 6:49 PM
To: [email-masked]
Subject: Vendor attributes in TE LSAs

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

---

From: Udo Neustadter <[email-masked]>
Date: Wed, 28 May 2003 10:24:31 -0400

Thank you Vishwas.
I read the isis-experimental-tlv draft you mention and sections 5 and 6
in that draft seem applicable. A new version of my draft will include
similar notes.

Udo

> From: Manral, Vishwas [mailto:[email-masked]] 
> Sent: Tuesday, May 27, 2003 12:41
> Subject: Re: Vendor attributes in TE LSAs
> 
> 
> Hi Udo,
> 
, and instead of "SMI Network management enterprise code for the vendor
or organization" uses "a valid IEEE assigned OUI as the first three
bytes of the value of the TLV."

I do not know the tradeoffs but if possible we could use the same value
too. Maybe someone could point out the tradeoffs if any.

Thanks,
Vishwas

-----Original Message-----
From: Udo Neustadter [mailto:[email-masked]]
Sent: Tuesday, May 27, 2003 6:49 PM
To: [email-masked]
Subject: Vendor attributes in TE LSAs

Hi all,

Udo

---

From: Udo Neustadter <[email-masked]>
Date: Wed, 28 May 2003 10:27:16 -0400

Hello Acee,

The method described in katz-yeung-ospf-traffic is quite clear that the
assignment for sub Types in the TE Link TLV in the range from 32773
through 65535 does not involve the OSPF WG, TE WG, nor the IETF. It is
merely a formality with IANA to get such a number on a first come first
serve basis. This number, however easy to get, is something that must be
managed "forever" by IANA and the vendors. My draft makes it easier for
both IANA and the Vendors.

The draft also specifies the addition of data to the Router Address TLV,
which is completely missing under today's set of documents. I feel very
strongly that it is important to allow for extensions in the TE router
LSA.

On another note, I think the real question that needs to be answered
here is the kind of data that goes into the VendAtt sub-TLV. I our case
for instance that is data we are not ready to make public and/or have a
roadmap that shows the evolution of the protocol for some years to come.
I don't think the community would support such an evolving standard.
Just the fact that katz-yeung-ospf-traffic reserves a range of sub-TLVs
for private use proves that there is a need to have private data in the
TE LSA.

Regards,
Udo

> From: Acee Lindem [mailto:[email-masked]] 
> Sent: Wednesday, May 28, 2003 00:37
> Subject: Re: Vendor attributes in TE LSAs - (Sent first reply 
> prematurely)
> 
> 
> References: 
> <[email-masked]
> s.com> <[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,
> >>
> >>   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
> --
> Acee

--
Acee