You mean to support the engineering of individual class types in an E-LSP? An E-LSP by definition carries mulitple class types....
cheers
Dave
> -----Original Message-----
> From: Nabil Seddigh [mailto:nseddigh@tropicnetworks.com]
> Sent: Monday, July 08, 2002 12:29 PM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: te-wg@ops.ietf.org
> Subject: Re: Another question on draft-ietf-tewg-diff-te-proto-01.txt
>
>
>
> Dave,
>
> Mechanisms to support multiple class types on an E-LSP were proposed
> in this WG. Some providers and vendors expressed interest in
> such schemes. However, in Utah, the WG felt that standardizing
> multiple OA-ELSP would be premature until the basic DS-TE
> mechanisms are standardized and shown to be viably deployable.
>
> Updated versions of the related drafts can be found below:
>
> http://www.ietf.org/internet-drafts/draft-ganti-tewg-diffserv-
> multicos-elspreq-00.txt
> http://www.ietf.org/internet-drafts/draft-ganti-mpls-diffserv-
> elsp-02.txt
>
> Best,
> Nabil Seddigh
>
>
>
> > This implies a 1:1 relationship between TTs and LSPs, this wouldn't
> > necessarily be true for an E-LSP. Now the mechanisms don't
> currently exist
> > to support associating multiple class types/bandwidth
> constraints for an
> > E-LSP, but if traffic trunk is exclusively an L-LSP
> concept, couldn't we pin
> > this down a bit more explicitly..?
> >
> > thanks
> > Dave
>