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

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 21 Nov 2001 09:56:41 -0500

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:[email-masked]]
-> Sent: Tuesday, November 20, 2001 7:12 PM
-> To: Lai, Wai S (Waisum), ALSVC; [email-masked]
-> 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:[email-masked]]
-> > Sent: Tuesday, November 20, 2001 4:49 PM
-> > To: [email-masked]
-> > 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:[email-masked]]
-> > Sent: Tuesday, November 20, 2001 11:40 AM
-> > To: [email-masked]
-> > 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!]

---

From: Balazs Szviatovszki <[email-masked]>
Date: Wed, 21 Nov 2001 16:35:53 +0100

I suppose the idea behind higher priority for control traffic is to assure proper link-state routing operation in sever overloads. Check out this draft:

<draft-ash-ospf-isis-congestion-control-01.txt>  
"Proposed Mechanisms for Congestion Control/Failure Recovery in OSPF & ISIS Networks"

Still, I would not dare to say that there should not be preemption among other non-control traffic types. Recall, the draft of Jim, proposed that it should be configurable which class-type could preempt which one <draft-boyle-tewg-ds-nop-00.txt> : 

            class voice use priority 2
	    class data use priority 4
	    [mpls preempt <yes|limited|map|no>]
----------> [preempt map voice over data]
	    [class mute <list>]

Previous idea was that higher priority can preempt any lower priority. I think this is the concept actually coded in many MPLS implementations. 

Balazs