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

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

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

Actually, looking more into it I believe it just would not work (at least 
with many BC models including Russian Dolls model).
This is because a Headend cannot always compute accurately how much 
bandwidth would be available for all 64 possible <CT/preemption> 
combinations on a remote link simply by knowing the BCs and the advertised 
available bandwidth for the eight valid TE-classes.

Let's try illustrate with an example.

Assume :
         - Russian Doll models
         - 3 CTs are used
         - TE-class mapping is:
                 TE-class <-->   CT      preemption
                 0               0       0
                 1               1       1
                 2               2       0
                 rest            unused
         - Head end receives through IGP for a considered link:
                 available bw CT0/preemp0 = 20
                 available bw CT1/preemp1 = 20
                 available bw CT2/preemp0 = 20
                 BC0=100
                 BC1=70
                 BC2=50
         - Headend is required to setup a new tunnel for CT1 with setup 
preemption 0 with bandwidth 50 (ie a tunnel with setup  priority outside 
the class map).

My claim is that the Head-end just can NOT tell whether the new tunnel will 
fit on the considered link or not.

Case1:
======
the considered link currently has established:
         - 30 worth of CT2 with holding preemption 0
         - 0 worth of CT1 with holding preemption 1
         - 50 worth of CT0 with holding preemption 0
Pictorially , we have
I------------------------------------------------------I
I-------------------------------I                      I
I--------------I                I                      I
I    CT2       I    CT2+CT1     I      CT2+CT1+CT0     I
I 30CT2@pre0   I   0 CT1        I       50CT0 @ pre0   I
I--------------I                I                      I
I-------------------------------I                      I
I------------------------------------------------------I

I-BC2=50------>
I-----------------BC1=70-------->
I-----------------------------------------BC0=100------>

then the new LSP WOULD NOT fit because there is 30 worth of CT2 LSP at 
holding preemption 0 chewing up 30 of BC1=70 (remember BC1 is a constraint 
on sum of CT1 +CT2 LSPs).
yet we have the advertised values mentioned above:
available CT2/0 = MIN  [ (50 - 30) , (70-30), (100-50-30) ] = 20
available CT1/1 = MIN [(70-30 ), (100-50-30) ] = 20,
available CT0/0 = MIN [(100 - 50 - 30)] =20.
(Please see Appendix C of proto draft for details on the formulas for 
computing available bw)

Case2:
======
considered link currently has established:
         - 20 worth of CT2 holding preemption 0
         - 0 worth of CT1 holding preemption 1
         - 60 worth of CT0 holding preemption 0
Pictorially , we have
I------------------------------------------------------I
I-------------------------------I                      I
I--------------I                I                      I
I    CT2       I    CT2+CT1     I      CT2+CT1+CT0     I
I 20CT2@pre0   I   0 CT1        I       60CT0 @ pre0   I
I--------------I                I                      I
I-------------------------------I                      I
I------------------------------------------------------I

I-BC2=50------>
I-----------------BC1=70-------->
I-----------------------------------------BC0=100------>

then the new LSP WOULD FIT because there is only 20 worth of CT2 LSP at 
holding preemption 0 chewing up only 20 of BC1=70
yet we also have the same advertised values mentioned above:
available CT2/0 = MIN  [ (50 - 20) , (70-20), (100-60-20) ] = 20
available CT1/1 = MIN [(70-20 ), (100-60-20) ] = 20,
available CT0/0 = MIN [(100 - 60 - 20)] =20.

Do you agree it is not possible for the Head-end to know whether the new 
LSP would fit?
Do you agree we cannot generally allow setup priority to be set to other 
values than the ones allowed by TE-map (ie the ones for which there will be 
an adevrtised available bandwidth)?

Cheers

Francois

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

---

From: "Dimitry Haskin" <[email-masked]>
Date: Sun, 16 Jun 2002 18:58:33 -0400

Francois,

I agree with you conclusion even though your examples poorly illustrate
your point. In both your cases a new tunnel for CT1 would not fit since
in either case 80 of the total 100 bandwidth were reserved at priority 0
which can not be preempted by the setup priority 0 (or any other
priority) of the new tunnel. I believe you can make your case by
slightly modifying your example - for instance like followed:

                 0               0       1
                 1               1       2
                 2               2       0

Now that we agree that setup priority values should be restricted to
those allowed by TE-Class table so that a head end could be
unambiguously informed on what is available for new tunnels at each
possible CT/setup-priority combination, may I question if it necessary
to restrict HOLDING priorities in the same way? ;)

Dimitry

-----Original Message-----
From: Francois Le Faucheur [mailto:[email-masked]] 
Sent: Thursday, June 13, 2002 9:16 AM
To: Dimitry Haskin
Cc: 'Francois Le Faucheur'; [email-masked]
Subject: RE: setup priority in draft-ietf-tewg-diff-te-proto-

Dimitry,

> > Hmm. Interesting point. I think you're right that it could

Actually, looking more into it I believe it just would not work (at
least 
with many BC models including Russian Dolls model).
This is because a Headend cannot always compute accurately how much 
bandwidth would be available for all 64 possible <CT/preemption> 
combinations on a remote link simply by knowing the BCs and the
advertised 
available bandwidth for the eight valid TE-classes.

Assume :
         - Russian Doll models
         - 3 CTs are used
         - TE-class mapping is:

the class map).

My claim is that the Head-end just can NOT tell whether the new tunnel
will 
fit on the considered link or not.

Case1:
======

I-BC2=50------>

holding preemption 0 chewing up 30 of BC1=70 (remember BC1 is a
constraint 

Case2:
======

I-BC2=50------>

LSP would fit?

values than the ones allowed by TE-map (ie the ones for which there will
be 
an adevrtised available bandwidth)?

Cheers

Francois