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

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

Wai Sum:

  I didn't understand why control traffic is so different?
  Draft recommends, no preemption of LSPs and/or transport 
  links across CTs, except for control-traffic CT. (Why?)

 * I mentioned my concern about CT6 because, control traffic is
   also *some data* in IP sense. For good example, I can send 
   OSPF/RSVP Hellos in one particular CT and all other Control
   messages (updates etc) in other CTs. Don't you agree?

--Venkata Naidu

-> 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!]