The MPLS WG Archive

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

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