RE: setup priority in draft-ietf-tewg-diff-te-proto-

[Dimitry Haskin <dhaskin@axiowave.com>]

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".
 
>          - 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.

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.

> 
> >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. 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