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

[Francois Le Faucheur <flefauch@cisco.com>]

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