Diff Serv TE

[Kireeti Kompella <kireeti@juniper.net>]

Hi,

There are at least four (!) proposals on the table.  (What's new? :-))

I have a couple of questions on the requirements doc.  My overall
comment is that it is rather biased towards the "current" DiffServ
TE doc (draft-ietf-mpls-diff-te-ext-01.txt) -- which is mostly okay,
if that is what Service Providers really want.

1) The notion of "class-type" was introduced solely as a means of
   managing scalability of the current scheme: introducing 8 more
   bandwidths for each *class* would not scale, hence do it only
   for *class-type*.  However, DiffServ itself has no notion of
   Class Type.  So, the following text:

|  [TEWG-FW] introduces the concept of Class-Types. The fundamental 
|  requirement for DS-TE is to be able to enforce different bandwidth 
|  constraints for different Class Types rather than a single one. 

   should be changed (in my opinion) to something like:

|  The fundamental requirement for DS-TE is to be able to enforce
|  different bandwidth constraints for each DiffServ class, rather
|  than a single one.  However, there is an overriding requirement
|  that DS-TE scale well, so if necessary, this requirement may need
|  to be enforced per Class-Type (see [TEWG]) rather than per class.

   Note that Jim's and my proposals don't need the notion of Class
   Types (although they are compatible with either notion).

2) In my opinion, the notion of preemption *across* Classes/Class
   Types should be discussed further.  Jim's and my proposals
   suggest that each class be given a definite priority, so one
   explicitly configures whether best effort trumps voice traffic
   or not, by assigning BE a higher or lower priority wrt voice.

3) The notion of "oversubscription" has been thoroughly ignored.
   Do Service Providers really want their best effort traffic and
   the voice traffic to be oversubscribed at the same level?
   Intuitively, I would think that one would want BE to be rather
   more oversubscribed (~300%) than voice (~10%) -- but what do I
   know, I'm just a vendor.

Kireeti.