[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PLEASE IGNORE EARLIER MESSAGE Fwd: RE: setup priority in draft-ietf-tewg-diff-te-proto-
Please ignore the message below which was sent inadvertently right in
middle of writing it.
sorry
Francois
>Date: Thu, 13 Jun 2002 11:39:17 +0200
>To: Dimitry Haskin <dhaskin@axiowave.com>
>From: Francois Le Faucheur <flefauch@cisco.com>
>Subject: RE: setup priority in draft-ietf-tewg-diff-te-proto-
>Cc: "'Francois Le Faucheur'" <flefauch@cisco.com>, Dimitry Haskin
><dhaskin@axiowave.com>, te-wg@ops.ietf.org
>
>Dimitry,
>
>At 15:44 11/06/2002 -0400, Dimitry Haskin wrote:
>>Francois,
>>
>>See my comments inline.
>>
>> >
>> > Dimitry,
>> >
>> > At 16:58 22/04/2002 -0400, Dimitry Haskin wrote:
>> > >Francois,
>> > >
>> > >As fairly minor comment, there is seemingly no reason to
>> > restrict the setup
>> > >priority values in the same way the holding priorities value
>> > are restricted
>> > >(i.e. to form configured TE Class). What you try to achieve will work
>> > >without such a restriction.
>> >
>> > Hmm. Interesting point. I think you're right that it could
>> > work without the
>> > restriction.
>> >
>> > My first reaction, though, is that we should keep the
>> > restriction in, because:
>> > - Removing it would make configuration somewhat
>> > confusing to users
>> > (ie user can configure setup to any value and holding only to
>> > a subset;
>> > user would inevitably wonder why it is so and will be
>> > frustrated not to be
>> > able to use any value for holding)
>>
>>On a humorous note, this parallels the following logic: "even if we have
>>abundance of bread we have to ration it so there were no or less frustration
>>with milk rationing that we have to impose".
>
>analogies are good because, like proverbs, if you dig hard enough, you can
>always found one which supports whatever position you have 8^)
>
>My analogy would be :
>"you're walking up the hill with your two little kids so they can ski it
>down. You are carrying their two pairs of pole. Should you be carrying two
>pairs of skis or the eight pairs of skis that you just happen to have
>available in your car?"
>
>>
>> > - In practise, it appears that SPs have little
>> > practical use for
>> > different setup and holding priorities (to date at least),
>> > and end up using
>> > the same value for both.
>>
>>I don't see the point of this argument unless you are proposing to deprecate
>>the setup priority. FWIW, the setup priority is still there and it can be
>>useful to signal different setup and holding priority values.
>
>This would not deprecate it. You could still use differnet setup and hold
>priority. It woudl just limit you to the same subset for both.
>
>>Consider a simple example where there is three CTs, say 1, 2, and 3, with
>>respective holding priorities 1, 2, and 3. A user wants to have the
>>following case by case options when setting LSPs in CT 1: a) no preemption,
>>b) allow preemption of LSPs from CT 3 only, c) allow preemption from both CT
>>2 and 3. As one can see, if the restriction on the setup priority is not
>>removed, at least 5 TE classes need to be configured to handle this not so
>>far fetched example. If the restriction is removed, 3 TE classes would
>>suffice. It is not difficult to come up with an example, where one may run
>>out of 8 TE classes unless restriction is removed.
>>
>>As you can see, contrarily to the supposition below, the restriction only
>>may make configuration more complex rather than simpler.
>
>This really depends on the details of the CLI for configuration of
>TE-class/Tunnel. I was more talking about the functional differnce: ie
>having a different subset of possible values for the two preemption priorities.
>
>> >
>> > >Such a restriction on the setup priority value
>> > >only adds more error checking and failure cases.
>> >
>> > but removing the restriction would make Constraint BAsed
>> > Routing and CAC
>> > more complicated. They would have to be able to handle a
>> > setup priority for
>> > which they have no current "available bandwidth" information in the
>> > topology database, and in that case they would have to consider the
>> > "available bandwidth" of next higher priority or the
>> > advertised Bandwidth
>> > Constraint (instead of a dynamic IGP value) in case there is
>> > no higher
>> > priority in that CT.
>>
>>I lost... I fail to understand what you try to say. As I understand it, the
>>setup priority allows, if necessary, to take resources from existing LSPs at
>>*lower* (numerically higher) holding priority. Bandwidth at the setup
>>priority level cannot be considered for preemption any way. I fail to see
>>why CSPF or CAC is more complicated with the additional restriction on the
>>setup priority values.
>
>With existing TE (and with DSTE with the restriction) when you need to
>compute a path for a given setup preemption, you immediately have
>available a figure which tells you the available bandwidth for THAT
>preemption (IGP advertises exactly that).
>
>With DSTE without the restriction, you will have to figure out available
>bandwidth for other preemptions (ie preemptions for which IGP has not
>advertised anything ). The rule will be :
> - if there is an advertised available bandwidth with higher
> preemption, use this. eg. IGP has advertised Availbe Bw for preemption 1
> and 3. To compute a path for a LSP with setup priority of 2, use the
> available bandwidth for preemption 1.
> - if there is no advertised available bandwidth with higher
> preemption, use the
>
>>If anything, it is more complicated due to an
>>additional value checking.
>>
>> >
>> >
>> > So to me it seems that keeping the restriction would :
>> > - keep configuration simpler for the end user
>> > - keep implementation easier
>> > - not lose anything really useful in practise
>> >
>> > What do you think?
>> >
>> > Thanks
>> >
>> > Francois
>> >
>>Regards,
>> Dimitry