[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Diff Serv TE
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.