The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Please find a list of comments below, look for *** for the
beginning of each comment.

				Ina

*** 1)  section 1 - terminology

As Arthi pointed out, the soft preemption desired flag definition
needs to be corrected.

Also:

"Preemption Pending flag - This flag is set on an IPv4 or IPv6 RSVP Resv
RRO sub-object to signal to the TE LSP ingress LER that the TE LSP is
about to be preempted and must be re-signaled (in a non disruptive
fashion, with make before break) along another path. The flag can be
                                                              ^^^ may
set for Path RRO as well.
>>>add If present in the Path RRO, it is used to alert downstream
LSRs that the LSP was soft preempted upstream.


*** 2) section 5
    Missing discussion of how to avoid a soft preempted LSP from
hanging around forever (e.g. because the head end couldn't reroute
it). I can see the discussion on the timer in the interop
section. However, the timer is needed even if the head end is running
the same sw version as the preempting node.

*** 3) section 6

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

*** 4) section 7 - interoperability
" When this timer expires,
the soft preempted TE LSP will be torn down and the preempting
node SHOULD send a Path Error."

>>>>change_to the soft preempted TE LSP SHOULD be hard preempted.

The exact mechanisms of hard preemption are described elsewhere, so
to make this as generic as possible, the exact messages shouldn't be
stated here.

"an implementation MAY choose to Hard preempt TE LSP for
                   ^^^^^^^^^^^ MUST - see comments for section 6
which the Soft preemption desired bit has not been set. "

*** 5) As described in this draft, the assumption is that hard
preemption is the default behavior, and soft preemption is signaled by
the head end. As such, it should be made clear that soft preemption
behavior should only be given to lsps that have requested it.

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