The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

Pankaj,

    The section says that the steps are considered for admission
when processing a Path message.  I believe there has been much
discussion in the past as to when resources are hard committed
and there are scenarios in which efficiency is better served using
one approach (during Path processing) and other scenarios where
efficiency is better served using the other approach (during Resv
processing).

    I am not sure there is a right answer but I believe some vendors
have made a choice and others have left the choice to the user.  I
think you need to at least consider pending setup requests for a
higher priority LSP when you process subsequent Path messages
for admission purposes - even if you do not actually commit the
LSP resources in Path processing.  Otherwise, you are setting up
the dissappointment scenario about which you are concerned.  I
also think that you should not preempt an existing LSP until you
are ready to commit resources for the preempting LSP.

    So, what you might consider doing is marking unused capacity
and lower priority (in use) capacity as 'reserved for admission
purposes' at either the setup or the holding priority of the preempting
LSP - if, that is, you do not actually commit these resources right
away in Path processing.

    So, in case it seems a little fuzzy, my answer would be to preempt
at the same time you would commit new resources.  This is consistent
with a business model in which you only stop serving one customer
when a higher paying customer starts paying the bill.

    Hope this helps...

--
Eric Gray

You wrote:

> Eric,
>
> Thanks for your response. Yes, I was referring to text in 4.7.3 and you are
> right about my typo. Actually, I was seeking answer to the "when" part,
> meaning when should preemption be done ? during PATH or RESV message
> processing. Do you have any ideas/comments on that ? (please see my original
> message)
>
> Thanks,
>
> -Pankaj
>
> -----Original Message-----
> From: Eric Gray [mailto:eric.gray@sandburst.com]
> Sent: Wednesday, May 30, 2001 10:34 AM
> To: Parmar, Pankaj N
> Cc: 'mpls@UU.NET'
> Subject: Re: preemption in RSVP-TE
>
> Pankaj,
>
>     Assuming you are referring to text in section 4.7.3 ("Procedures
> applying to both C-Types") of draft-ietf-mpls-rsvp-lsp-tunnel-08,
> at least part of the confusion stems from a typo in your quote.  The
> correct word is 'unused' (as in 'unused bandwidth').  In other words,
> no preemption is needed where there is already sufficient 'unused'
> bandwidth.
>
>     Admittedly, a part of the confusion may be caused by a somewhat
> arbitrary distinction between 'available' and 'unused'.  It helps to
> read 'requested bandwidth is available' as 'requested bandwidth is
> within the capacity of links which are usable for this session'.
>
> --
> Eric Gray
>
> You wrote:
>
> > I have a doubt regarding preemption, as explained in the draft,
> specifically
> > the following statement:
> >
> > "if the requested bandwidth is less than the used bandwidth then the
> > processing is complete. If the requested bandwidth is available, but is in
> > use by lower priority sessions, then lower priority sessions (beginning
> with
> > lower priority) MAY be pre-empted to free the necessary bandwidth."
> >
> > It is not clear when the session gets preempted. It seems preemption could
> > to be done during PATH message processing, but then there is a issue here.
> > If a lower priority session gets preempted at a given LSR, and gets
> > forwarded downstream, it is possible that another downstream LSR may
> reject
> > the PATH message and send a PATH_ERR upstream. The issue is, a lower
> > priority session got preempted for no reason. On the other hand, if
> > preemption is done during a RESV message, we are more certain that we
> really
> > want to preempt a lower priority session.
> >
> > Experts, please comment.
> >
> > Thanks,
> >
> > -Pankaj