Subject: PLEASE IGNORE EARLIER MESSAGE Fwd: RE: setup priority in draft-ietf-tewg-diff-te-proto-

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 13 Jun 2002 11:47:56 +0200

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 <[email-masked]>
>From: Francois Le Faucheur <[email-masked]>
>Subject: RE: setup priority in draft-ietf-tewg-diff-te-proto-
>Cc: "'Francois Le Faucheur'" <[email-masked]>, Dimitry Haskin 
><[email-masked]>, [email-masked]
>
>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