[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on draft-kompella-tewg-bw-acct-00.txt
Kireeti and DS-TEers,
A few comments/thoughts:
1) Oversubscription
As Jim already clarified, other DS-TE approaches do support
oversubscription. They assume that tunnel bandwidth can effectively
directly be configured as "normalised bandwidth" ie an oversubscription
factor can be applied when selecting the "bandwidth" parameter of the
tunnel. Then nothing further has to be done to support oversubscription.
The one functional difference I can see between the two oversubscription
approaches is that your approach allows to have differnet oversubscription
ratios on different links (ie a given LSP may use 200Mb/s of normalised
bandwidth on a link and use 300Mb/s on another link). Some of us discussed
this a while back and we felt that while it may be a nice-to-have in some
cases , it was not a strong requirement which justified the extra
complexity of dealing with oversubcription ratios & normalised bandwidth on
every link configuration and in every advertisement.
Do you see a strong requirement for being able to fine-tune
oversubscription on a per-link basis for the same given LSP?
Anyone from Service Provider community could give us input on this?
Also, to size the bandwidth of a TE tunnel, I believe Service providers
often first collect traffic measurement and then massage this according to
their own black magic (ie look at peak or average or percentile or mixture,
compute those over different time windows,...). All this exercise can
pretty much be viewed as "how do I summarise all this information about
traffic into a single representative parameter -which is bandwidth- ?". So,
I look at all of this as already somehow trying to come up with a
"normalised bandwidth". Since "oversubscription" is one of the many black
magic parameters and part of the normalisation, it seems fairly natural to
factor it as part of this exercise of deciding the size of the tunnel in
the first place. No?
2) Migration from existing TE
It would be very useful if you could describe how you see migration from a
network running existing TE (with existing TE advertisement) into running
DS-TE as per your proposal.
Since you are proposing to deprecate the existing TE extensions, are you
assuming a flag day or are you assuming that a "new" implementations
support both extensions (and then what do I advertise in the old extensions)?
3) Bandwidth Constraints
As described in 2.2 of the Requirement draft, there are a combination of
requirements which lead us to define "Russian Dolls" bandwidth constraints
(ie constraint on CT2, then on CT2+CT1, then on CT2+CT1+CT0) rather than
simple bandwidth constraint per class/Class-Types..
If I take a typical 3 class (EF/Voice, AF/Data-Premium , BE/Best-Effort)
network, then I think it would be reasonable for QoS motivations to want to:
- limit EF traffic on its own (eg to 60%.)
- limit AF traffic DEPENDING on how much EF traffic is set-up: eg. limit
AF to 80% if there is no EF traffic , but obviously limit AF below if there
is some AF traffic (eg. limit EF+AF to 80%)
- limit Best Effort traffic DEPENDING on how much EF and AF is set-up: eg.
limit BE to 100% if there is no EF&AF, but limit BE below if there is EF
and AF traffic.
(the above discussion assume we're talking in "normalised" bandwidth).
No?
I could not see how one could achieve the above with your proposal. Do you
see a way to do this?
In other words, I think with your proposal I could limit normalised EF to
40% , normalise AF to 40% and normalised BE to 20%. But if there is no EF
currently, I cannot accept more AF than 40% which seems wasteful.
However, I think your proposal could be modified to achieve this without
changes in the advertisements, simply by changing the admission control
formulas to reflect the "Russian Doll" relationship of bandwidth constraints.
4)Multiple Computations on Head-End
I believe this is what Jim has already pointed out in one of his comments:
Not being able to predict bandwidth means a Head-End doing multiple
computations simply computes as accurately [ or as inaccurately '^) ] as
any other Head-End (when it could have computed more accurately).
5) Cross-Class Preemption
Just to avoid confusion I believe by "Cross-Class Preemption" you mean the
ability to have multiple classes/class-types use the same preemption level
(as opposed to "Preemption across Class-Types" as defined in 2.5.2 of DS-TE
Requirements).
I agree that there is currently no identified requirement for "Cross-Class
Preemption". As a matter of fact, it's not identified as a requirement in
the current DS-TE Requirements document.
Input from SP on this is welcome.
Just want to clarify that DS-TE proposal happens to support it naturally if
one wants to do it, but obviously it does not have to be used.
Cheers
Francois
PS: I'll be out of email from now on until the IETF, so I'll only be able
to resume discussions over there. Someone will probably have come up with a
fifth proposal by then.
_______________________
Francois Le Faucheur
Development Engineer, IOS Layer 3 Services
Cisco Systems
Office Phone: +33 4 97 23 26 19
Mobile : +33 6 89 108 159
Fax: +33 4 97 23 26 26
Email: flefauch@cisco.com
_________________________________________________________________
Cisco Systems Europe
Domaine Green Side
400, Avenue de Roumanille
Bātiment T3
06 410 BIOT
SOPHIA ANTIPOLIS
FRANCE
_________________________________________________________________