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

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Tue, 20 Nov 2001 11:39:44 -0500

Hi! As far as I understand, this draft attempts to combine
multitude of user traffic requirements (DiffServ class, CAC,
preemption priorities...) into one logical construct by 
introducing (/building on) the concept of Class-Type. 

Personally, I feel the same goal can be achieved, without
introducing a new concept.

My primary concerns, with the proposed solutions are:
----------------------------------------------------
	1. The proposed solution builds on the concept
	of Class-Type, which is based on a _one of the_
	solutions to DS-TE.
		a. Personally, I think the concept of 
		Class-Type some how crept into the DS-TE-REQTS
		draft from one of the DS-TE solutions.

		b. From the recent posting, I sense that the
		new revision of DS-TE-REQTS will remove the 
		Class-Type as a requirement.
	
		c. The draft under discussion, itself indicates
		that there are better alternatives to solve the
		IGP scalability problem without introducing 
		Class-Type. [ex: Per-Class BW accounting /
		IGP-ALTERNATIVES/the upcoming 'unified' DS-TE
		approach(?)]

	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!]
		
Alternative:
------------
	Scalability:
	~~~~~~~~~~~
	The DS-TE scalability issue can be handled by the some
	of the existing DS-TE proposals (kompella,ash,boyel..)

	User friendly specification of traffic parameters:
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	One can always define a MIB table, inline with ATM's UPC
	contract tables. 

	In this approach, user can define a _named_ template, that 
	captures traffic characteristics like (as defined in the 
	draft):
		a. DiffServ/queueing priority Pubs
		b. QoS classes (?)
		c. MPLS/CAC priority classes
		d. restoration priority classes
		e. preemption priority classes
		... ... ...

	This allows the user to define his own "Class-Type", 
	from the individual parameters.

Thanks,
sanjay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 7:14 AM
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ash-mpls-diffserv-te-class-types-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: Proposed MPLS/DiffServ TE Class Types
> 	Author(s)	: J. Ash et al.
> 	Filename	: draft-ash-mpls-diffserv-te-class-types-00.txt
> 	Pages		: 
> 	Date		: 19-Nov-01
> 	
> Service Provider requirements for support of DiffServ aware 
> MPLS Traffic
> Engineering (MPLS-DS-TE) are presented in [MPLS-DS-TE-REQ].  
> This initiative includes the definition of MPLS-DiffServ-TE 
> class types (CTs), wherein CTs are defined as aggregations of 
> individual service classes.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te
> -class-types-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ash-mpls-diffserv-te-class-types-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-ash-mpls-diffserv-te-class-types-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Tue, 20 Nov 2001 16:48:51 -0500

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.

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Tue, 20 Nov 2001 19:11:39 -0500

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

> 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 ?
> 
> 
> Subject: Alternative to 
> draft-ash-mpls-diffserv-te-class-types-00.txt ?
>

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Wed, 21 Nov 2001 08:25:41 -0500

As you mentioned previously,
>           Service Provider-1's "Gold
> 		"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

 Thanks,
 sanjay

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Wed, 21 Nov 2001 10:00:36 -0500

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

> Sent: Wednesday, November 21, 2001 8:26 AM
> To: [email-masked]

---

From: "Naidu, Venkata" <[email-masked]>
Date: Wed, 21 Nov 2001 10:52:58 -0500

Balazs:

  Please see my comments inline...

-> I suppose the idea behind higher priority for control 
-> traffic is to assure proper link-state routing operation in 
-> sever overloads.

  Let me re-phrase my question. Can I send *some* control
  traffic on CT3/4/5 (which I think is appropriate).
  For example, some very low priority control traffic can be
  best matched to CT 5 (BE). The *requirement* to include
  all *control traffic* in CT 6 (High Priority, Low loss,
  with allowed preemption) is not appropriate.

  I think, the draft jeopardizing data traffic my making *all*
  control traffic to CT6.

--Venkata Naidu  

-> Balazs
-> 
-> 
-> "Naidu, Venkata" wrote:
-> > 
-> > 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?
->

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Wed, 21 Nov 2001 16:33:42 -0500

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:[email-masked]]
Sent: Wednesday, November 21, 2001 10:01 AM
To: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: RE: Alternative to

 
 Thanks,
 sanjay

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Wed, 21 Nov 2001 16:35:59 -0500

There are different types of control traffic for various purposes.
Control traffic that are critical to network health (such as for
routing and network management) must be able to get through under
all network conditions to keep the network up.
If, as you described below, a control packet can be treated as
"data" not directly related to overall network health, then
certainly it can be embedded in other class types.
Thanks, Wai Sum.

-----Original Message-----
From: Naidu, Venkata [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 10:53 AM
To: 'Balazs Szviatovszki'
Cc: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: RE: Alternative to

Balazs:

--Venkata Naidu  

-> Balazs
-> 
->

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Wed, 21 Nov 2001 16:53:44 -0500

Under normal conditions, a network should be properly dimensioned so that
preemption is not needed while ensuring that service objectives are met.
Preemption used under overload often leads to network instability.  Hence,
preemption is not a remedy for lack of network capacity, or lack of proper
capacity planning and provisioning in the network dimensioning process.
Thanks, Wai Sum.

-----Original Message-----
From: Balazs Szviatovszki [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 10:36 AM
To: Naidu, Venkata
Cc: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: Re: Alternative to

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

"Naidu, Venkata" wrote:
> 
> 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?

---

From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Date: Wed, 21 Nov 2001 19:05:21 -0500

Sanjay,

Some comments below.

Thanks,
Jerry Ash

> Class-Type as a requirement.

Not so, CT remains in the upcoming DS-TE-REQTS draft.

> of the existing DS-TE proposals (kompella,ash,boyel..)

This is a different scalability issue than addressed in the current draft.
E.g.,
http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-alternativ
e-02.txt and
http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-contro
l-01.txt address concerns about scalability of IGPs and extensions of LSAs
to communicate per-CT available bandwidth, etc. In particular, the former
('te-alternative') draft proposes 'no further IGP extensions' to support
CTs, and illustrates one possible technical solution which avoids further
extensions to the IGP.  Some progress is being made now toward that 'no
further extensions' objective.

The scalability issue discussed in the current draft
http://search.ietf.org/internet-drafts/draft-ash-mpls-diffserv-te-class-type
s-00.txt (e.g., see Section 3) is to reduce the dimensionality/complexity of
possible CTs across 4 levels of priority (DiffServ PHBs, admission-control
priority, restoration priority, preemption priority).  The intent is to
reduce a possibly very large number of independent CTs to 6, by combining
the 4 priority-dimensions into a smaller number (6) of CT combinations.  We
feel that this approach is more scalable than allowing a very large number
of CT combinations.

Another motivation for defining consistent CTs (also pointed out by Wai Sum)
is for consistent mapping of services across SP network boundaries to
achieve end-to-end QoS.  This objective is not new, but has already been
addressed in other standards fora for similar reasons (see the references in
the I-D for more information).  Services such as emergency services, for
example, (as discussed in
http://search.ietf.org/internet-drafts/draft-folts-ieps-white-paper-00.txt,
http://search.ietf.org/internet-drafts/draft-baker-ieps-requirements-00.txt,
and http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt)
need to cross multiple SP networks with consistency and interoperability on
priority treatment, etc.

---

From: [email-masked]
Date: Thu, 22 Nov 2001 09:41:49 +0100

Waisum,

That's an interesting statement. Do you mean that preemption should only be allowed for protection traffic preempting primary traffic of sufficiently low priority?

Sven.

"Lai, Wai S (Waisum), ALSVC" <[email-masked]> on 21/11/2001 22:53:44

  To:          [email-masked]                             
                                                              
  cc:          (bcc: Sven VAN DEN BOSCH/BE/ALCATEL)           

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

-----Original Message-----
From: Balazs Szviatovszki [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 10:36 AM
To: Naidu, Venkata
Cc: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: Re: Alternative to

Balazs

---

From: "Choudhury, Sanjaya" <[email-masked]>
Date: Mon, 26 Nov 2001 16:15:44 -0500

Hi! Some of my thoughts are inline in the forwarded e-mail.

 Thanks,
 sanjay

> From: Ash, Gerald R (Jerry), ALCTA [mailto:[email-masked]]
> Sent: Wednesday, November 21, 2001 7:05 PM
> To: 'Choudhury, Sanjaya'
> Cc: Ash, Gerald R (Jerry), ALCTA; [email-masked]

 	The draft just got announced today & I haven't got a
	chance to read it as yet. Personally, I still believe
  	there exists alternatives to the ClassType based 
  	DS-TE solution --but that is probably a discussion 
  	on a separate thread.
e-02.txt and
>further extensions' objective.

	Let us assume that such a DS-TE alternative exists
	to handle the IGP scalability problem, for the rest
	of the discussion.

>feel that this approach is more scalable than allowing a very large number
	
	The draft assumes that if one supports 4 DS classes 
	and 4 preemption priorities, one has to define 4 x 4 = 16
	"Class Types". But one does not have to. Just signal
	the DS class & preemption priority (as separate TLVs).

>and
http://search.ietf.org/internet-drafts/draft-schulzrinne-sip-911-01.txt)
>need to cross multiple SP networks with consistency and interoperability on

	If a LSP with DS class = EF, Setup Priority = 2 & Holding
	Priority = 2, is signaled, all the LSRs (in SP1 or SP2)
	are expected to treat the LSP in a similar way! I still 
	don't see a interoperability problem.

	If the main goal of the proposed draft, is to define a set
	of well-defined LSP characteristics, may be it should publish
	a set of recommended parameters [well known SLAs ?], without
	tying the solution to a particular DS-TE solution (Class Type).

---

From: "Lai, Wai S (Waisum), ALSVC" <[email-masked]>
Date: Mon, 26 Nov 2001 17:20:35 -0500

Sven,
   Our proposal is not to use preemption for user traffic as described
below, assuming proper network dimensioning.
   In the case of recovery under failure, whether an operator chooses to use
preemption or not is dependent on backup dimensioning, the severity of the
failure, and service objective.  For example, an operator may provision
sufficient reserve capacity to ensure that all restorable LSPs can be
recovered under any single failure event.  Such spare capacity can be shared
as described in the TEWG Design Team's "Network Hierarchy and Multilayer
Survivability."
Thanks, Wai Sum.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, 22 November 2001 3:42 AM
To: Lai, Wai S (Waisum), ALSVC
Cc: [email-masked]
Subject: RE: Alternative to
draft-ash-mpls-diffserv-te-class-types-00.txt ?

Waisum,

That's an interesting statement. Do you mean that preemption should only be
allowed for protection traffic preempting primary traffic of sufficiently
low priority?

Sven.

                                                              
  To:          [email-masked]                             

                                                              

-----Original Message-----
From: Balazs Szviatovszki [mailto:[email-masked]]
Sent: Wednesday, November 21, 2001 10:36 AM
To: Naidu, Venkata
Cc: Lai, Wai S (Waisum), ALSVC; [email-masked]
Subject: Re: Alternative to

Balazs

---

From: "Ash, Gerald R (Jerry), ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 18:43:59 -0500

Sanjay,

See responses below.

Thanks,
Jerry

>the DS class & preemption priority (as separate TLVs).
	
It is more than a matter of signaling the CT parameters.  CT defines a
bandwidth allocation concept, in which services are assigned to the
different CTs and links have bandwidth allocated by CT.  Available CT
bandwidth is (probably) going to be signaled/flooded for each link (e.g.,
with LSA extensions).  I don't think one could do dynamic mapping of
services to CTs, in which there are (to use your example) 16 possibilities
but we only use a few at random (say 3 or 4).  I don't know how the
bandwidth allocation would work for such a scheme.

>don't see a interoperability problem.

Same problem as above, don't know how you do a dynamic mapping of services
to CTs and keep the bandwidth allocation coherent, especially across SP
boundaries.