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

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 11 Jun 2002 12:09:06 +0200

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

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

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: Tue, 11 Jun 2002 15:44:35 -0400

Francois,

See my comments inline.

> 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".
 
> different setup and holding priorities (to date at least), 

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.

> Constraint (instead of a dynamic IGP value) in case there is 

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.

Regards,
 Dimitry

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 11 Jun 2002 16:44:19 -0400

Oops, in my previous respond:

>I fail to see why CSPF or CAC is more complicated with the additional 
> restriction on the setup priority values.

should be:

>I fail to see why CSPF or CAC is more complicated withOUT the additional 
> restriction on the setup priority values.

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 11 Jun 2002 16:44:19 -0400

---

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

Dimitry,

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

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

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

>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

---

From: Dimitry Haskin <[email-masked]>
Date: Tue, 11 Jun 2002 15:44:35 -0400

Francois,

See my comments inline.

 

Regards,
 Dimitry

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 18 Jun 2002 11:58:32 +0200

Dimitry,

  16/06/2002 -0400, Dimitry Haskin wrote:
>Francois,
>
>I agree with you conclusion

great.

>even though your examples poorly illustrate
>your point.

agreed. I changed figures on the fly as I was making up the example and 
goofed up. But you got the jist of it.

>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:
>
>                  TE-class <-->   CT      preemption
>                  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? ;)

Interesting again.

At first thought, I think the basic aspects of the solution could be made 
to work without the restriction on the Holding Priority. However, some 
aspects could not be made to work, such as the local optimisation on 
Head-end for multiple path computation (which is a useful practical 
option). This is because of the same fundamental reason as why the Setup 
needs to be restricted: ie it would not always be possible for the Head-end 
to figure out the impact of arbitrary Holding priorities on the other 
Class-Types which uses this priority in their TE-Classes.

So again, I am in favor of keeping the restriction in for both priorities.

Francois

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