Dimitry
-----Original Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Thursday, June 13, 2002 9:16 AM
To: Dimitry Haskin
Cc: 'Francois Le Faucheur'; te-wg@ops.ietf.org
Subject: RE: setup priority in draft-ietf-tewg-diff-te-proto-
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