The MPLS WG Archive

["Vishal Sharma" <v.sharma@ieee.org>]

Hi Adrian,

Thanks for the clarification. I think I misunderstood your
question during the MPLS WG meeting then.

(I think what you mentioned was that with TLVs it is possible
to either (a) define new 32-bit flags, as needed, or (b) define arbitrary
options and parameters that would be carried as TLVs, and you asked,
referring to the entire scheme, whether the WG thought we need
a way to support arbitrary TVLs. 

I misunderstood it to refer to just the second option for encoding 
attributes within the TLVs defined for carrying new attributes.)

I get your point now, and support the overall TLV approach proposed
in the document.

-Vishal

> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adrian
> Farrel
> Sent: Wednesday, November 26, 2003 4:50 AM
> To: Vishal Sharma
> Cc: MPLS wg
> Subject: Arbitrary TLVs in draft-farrel-mpls-rsvpte-attributes-00.txt 
> 
> 
> Hi Vishal,
> 
> > I support. There was one question raised by Adrian though that
> > was not answered at the WG meeting, so it might be useful
> > for us to consider on the list. It was "do we need a way to support
> > arbitrary TLVs?"
> >
> > I believe this is one of the two solutions proposed in the
> > draft, and it would be good to get WG opinion on that.
> 
> Actually, it is the only solution proposed in the draft. The 
> 'need' for TLVs is a minor
> corroborative reasons used to discard an alternative solution.
> 
> In the currently proposed solution, additional TLVs come for free.
> We *could* simplify the current solution (by the order of a type 
> and length field) and
> dispense with arbitrary TLVs.
> 
> The authors felt that not taking the opportunity to add TLVs 
> would be seen as a mistake in
> future years.
> The similar OSPF solution has TLVs I believe.
> 
> Would welcome more opinions.
> 
> Cheers,
> Adrian