The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	JP,

> >"In order to reduce this over-provisioning exposure,
> >a preempting LSR MAY limit the number of soft
> >                  ^^^^
> >preempt-able TE LSPs to the subset of TE LSP that have explicitly
> >requested soft preemption via signaling, setting their Soft Preemption
> >desired bit in the SESSION-ATTRIBUTE of their RSVP Path messages."
> >
> >This is a MUST, not a MAY requirement. If the head end did
> >not request soft preemption for an LSP, it can well be the case that
> >he doesn't even know what soft preemption is, or it may not provide
> >the soft preemption behavior. if the preempting LSR will give soft
> >preemption in this case, a lot of over-booking will occur (since we
> >will end up relying on a timer to preempt these lsps), and this is
> >exactly what we are trying to avoid.
>
> Well no ... the idea is that the case of some head-end not supporting soft
> preemption is sorted out by means of a timer. Here, the "Soft preemption
> desired" bit allows the operator for performing some Hard-preemption on
> some TE LSPs even if soft preemption is supported by the head-end. Suppose
> the case of a head-end having several sets of TE LSPs. For some of them,
> hard preemption (resulting in traffic loss until the TE LSP gets rerouted)
> is acceptable whereas for others Soft preemption is desired. If it turns
> out that the over-booking ratio is not too high (could be configured on
> each mid-point or dynamically adjusted based on various links
> characteristics, ....), the mid-point may decide to not limit the
> soft-preemption to the LSPs having set the "soft preemption desired" bit.
>
	I think I see you point now. Let me rephrase it, to double
check my understanding. The idea is to do hard preemption
anyway, if the over-booking resulting from it is not terrible. In the best
case, we get nice behavior for everyone, in the worst case (head-end
doesn't support soft preemption) then the timer will take care of it.
Right?
	In that case, maybe the section can be clarified a little. As it
stands now, it seems that the cause-effect logic is reveresed, at least
for someone like me who thinks that the default behaviour is to only do
soft preemption when requested.

>
> >*** 6) A nice application for this draft is in the context of
> >diffserv-te. Some bw models (e.g. Russian Dolls) rely on preemption to
> >allow sharing of bw between classes (cts), but at the same time to
> >ensure that bw is available for certain classes when the need arises.
> >For example when only 4 cts are supported, in the absence of ct3 lsps,
> >ct0 lsps may take up the entire bw. To ensure that ct3 lsps always
> >have bw available, one gives them better priority. Thus, when a
> >reservation
> >for a ct3 lsp comes in, it can preempt a reservation for a ct0 lsp. If
> >one uses soft preemption, this is a very neat model: the assumption is
> >that it takes a bit for a newly established ct3 lsp to attract traffic to
> >it, and in this time the preempted ct0 lsp can reroute.
>
> Not sure to see your point here ?
>
	Something to add to the motivation section, if you so choose. I
think soft preemption is particularly useful when establishing new LSPs in
a diffserv-te model where RDM is implemented. If you  have a system where
a service is only enabled after the lsp is established, this means a bit
of delay in setting up the service, but no traffic loss. Which is really
really neat.

			Ina