RE: Alternative to draft-ash-mpls-diffserv-te-class-types-00.txt ?

["Lai, Wai S (Waisum), ALSVC" <wlai@att.com>]

The name of a service is not the issue.
Consistency in the mapping of services across providers is the
point to be made.  If parameter P_i can take N_i values,
then we can have N_1 x N_2 x ... different combinations.
It is proposed to solve this problem by having a small,
well-defined, and standardized set of parametric values.
Thanks, Wai Sum.

-----Original Message-----
From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com]
Sent: Wednesday, November 21, 2001 10:01 AM
To: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
Subject: RE: Alternative to
draft-ash-mpls-diffserv-te-class-types-00.txt ?



 As I indicated in the previous e-mail, since the
 individual parameters are signaled independently
 [which are already standardized], there should not
 be a interoperability problem.

 I fail to understand, how does it matter in what 
 name the service provider market his service ?
 
 Thanks,
 sanjay

> -----Original Message-----
> From: Lai, Wai S (Waisum), ALSVC [mailto:wlai@att.com]
> Sent: Wednesday, November 21, 2001 8:26 AM
> To: te-wg@ops.ietf.org
> Subject: RE: Alternative to
> draft-ash-mpls-diffserv-te-class-types-00.txt ?
> 
> 
> As you mentioned previously,
> >           Service Provider-1's "Gold
> > 		Service" may be same as Service Provide-2's 
> > 		"Bronze Service
> it makes multi-provider interoperability more difficult to achieve.
> The intent of the draft is to propose a small, well-defined, set
> of class types so that we can have consistent mapping of services
> across provider network boundaries in the implementation of
> end-to-end QoS.
> Thanks, Wai Sum. 
> 
> -----Original Message-----
> From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com]
> Sent: Tuesday, November 20, 2001 7:12 PM
> To: Lai, Wai S (Waisum), ALSVC; te-wg@ops.ietf.org
> Subject: RE: Alternative to
> draft-ash-mpls-diffserv-te-class-types-00.txt ?
> 
> 
>  
>  Hi! Do you mean that with the existing MPLS-DS & MPLS-DS-TE
>  mechanisms, end-to-end QoS can not be implemented ?
> 
>  As indicated in the section 4 of the draft, all of the real
>  parameters that make up the "ClassType" are signaled 
>  individually (existing or new TLVs) anyway. Then how does it
>  matter, what we call them (Class-Type 0 or Class-Type 1) ??
> 
>  Infact, the draft itself indicates [last line of Abstract]
>  that its primary purpose is to further improve the
>  scalability through the introduction of ClassType. [Which is
>  is being address by different existing & upcoming DS-TE
>  drafts]. Therefore, I am not sure, what is being achieved
>  by the standardization of this new concept "Class-Type" ?
> 
>  Thanks,
>  sanjay
> 
> > -----Original Message-----
> > From: Lai, Wai S (Waisum), ALSVC [mailto:wlai@att.com]
> > Sent: Tuesday, November 20, 2001 4:49 PM
> > To: te-wg@ops.ietf.org
> > Subject: RE: Alternative to
> > draft-ash-mpls-diffserv-te-class-types-00.txt ?
> > 
> > 
> > For end-to-end connections that span multiple provider networks,
> > what are the alternatives (to standardization) for developing
> > consistent interoperable end-to-end QoS solutions?  For example,
> > would there be an equivalent of circuit-switched toll-quality
> > voice in VoIP?
> > Thanks, Wai Sum.
> > 
> > -----Original Message-----
> > From: Choudhury, Sanjaya [mailto:Sanjaya.Choudhury@marconi.com]
> > Sent: Tuesday, November 20, 2001 11:40 AM
> > To: te-wg@ops.ietf.org
> > Subject: Alternative to 
> > draft-ash-mpls-diffserv-te-class-types-00.txt ?
> > 
> > 	2. This draft attempts to standardize the different
> > 	user requirements into 6 Class Types, based on current
> > 	experience.
> > 		a. User's requirement may not fit into one of 
> > 		predefined 6 Class-Types
> > 
> > 		b. I am not sure whether, this information need
> > 		to be standardized. [Service Provider-1's "Gold
> > 		Service" may be same as Service Provide-2's 
> > 		"Bronze Service -and it does not matter!]
> > 
> > 
>