Subject: Diff Serv TE

From: Kireeti Kompella <[email-masked]>
Date: Wed, 18 Jul 2001 08:09:05 -0700 (PDT)

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.

---

From: Jim Boyle <[email-masked]>
Date: Thu, 19 Jul 2001 15:59:42 -0400

> Hi,

Greetings.

>    or not, by assigning BE a higher or lower priority wrt voice.

actually, mine suggest that classes be given "different" values.  An LSP 
setup into priority 0 may actually have no impact on the advertised 
bandwidth at another priority.  In yours, one can assume remotely, that 
an LSP at p=0 will take bandwidth at p=7.  One never would have to 
assume that, as it falls out in the observed and predicted IGP 
announcements.  So a more likely implementation would not "search" for 
bandwidth in this manner.

>    more oversubscribed (~300%) than voice (~10%)

Maybe because that can be addressed with current approaches.  The 
methods are less explicit, but they provide more flexibility.  For 
instance, the oversubscription of a link might be based on the link 
speed (e.g. oversubscribe fast links more) and that would be encoded 
into the maximum reservable bandwidth (and thus unreserved per 
priority).  Likewise, the bw requested per LSP can be manipulated.  One 
might understand best efforts by 33% (above), or voice (90%) of observed 
utilization on the LSP.  Or the ratio might be a function of bandwidth.

Along the lines of predicting IGP LSAs, I have a two questions for you.

In your draft, you mention a node A which is doing CAC on a link (L?). 
Remote from this is node Z which is setting up multiple LSPs over L and 
is keeping its own internal view of what is likely available by priority 
on L so as to determine whether or not it should try to setup another 
LSP on L (or use other links or fail, etc...).  There is also the 
recommendation that nodes like A holdoff on advertisements for BW 
related issues by multiple seconds, even minutes.   How does Z what 
impact on link L some other node, say X is having?

Also, in the requirements draft, I believe there was a scenario where a 
network administrator might wish to divy up percentages of the network 
to classes and have those percentages remain as traffic loads the 
network.  Is this possible with your approach?

cheers,

Jim