The MPLS WG Archive

[Markus Jork <mjork@avici.com>]

>  |In message <Pine.LNX.4.44.0302191431560.3611-100000@fido.nc.rr.com>, Jim Boyle 
>  |writes:
>  |> 
>  |> First, great draft - I like this concept.
>  |> 
>  |> While a flag might be just the right thing for this particular
>  |> application, I wonder if it might be good to try to broaden 
>  |> soft preemption technique to include other polite preemptions.
>  |> 
>  |> These might include the following indicators
>  |> 
>  |> o) your LSP is being prempted on the indicated link (draft covers)
>  |> o) your LSP should be rerouted, this node is shutting down
>  |> o) your LSP should be rerouted, this link is being taken out of
>  |>    service
>  |> o) your LSP should be rerouted away from this node (administrative/CLI)
>  |> o) your LSP should be rerouted away from this link (administrative/CLI)
>  |> 
>  |> You can somewhat do some of these by changing metrics and waiting, but
>  |> just was wondering if something more general might be useful.
>  |
>  |Why couldn't you just use the same bit and allow soft preemption on
>  |link shut, reload, 
> 
> Or OL bit set...
> 
>  |CLI administrative without encoding the reason?
>  |Since these are all CLI initiated, it wouldn't hurt to delay.
>  |Alternately, the soft preempt on anything using a specific resource
>  |could be done.
>  |Link bundle lost a member might also qualify as a reason for soft
>  |preemption for implementations of link bundling that can transparently
>  |more flows to other members of the bundle.
>  
> I think there is value in conveying to the head-end the population 
> category of the soft preemption (Single LSP|Link|Bundle Member|SRLG|
> Node). Doing so provides prompt, more accurate info for the head-end
> to use when trying to quickly find the new valid path for the first 
> of (say) 30 arriving soft preemptions. 
> 
>     .---,A     .---,B
>     |   |---1--|   |----- 
>     |   |---2--|   |-----
>     `---'      `---'
>      HE        Maint
> 
> fe. Imagine we cause all LSPs transiting a node B to be soft preempted 
> in prep for maintenance. HE A's LSPs all transited a certain circuit (1)
> to the maintenance node B, however there is a parallel circuit as well(2).
> Without the "node" flag, we might amend the HE TE-DB zeroing (1)s 
> reservable BW (the circuit for which we were just soft preempted)
> when we should have zeroed out (2) as well. The result could be our
> soft preemption make before break sets up (or tries to) through the 
> maintenance node despite being recently soft preempted off it..
> 
> Technically a HE need only receive the first LSP population oriented 
> flag (Node|SRLG|etc) soft preemption to discover 1) what subset of 
> locally originating LSPs need to be rerouted and 2) what links/nodes/
> members need to be avoided. There is still a need for one-at-a-time
> straight soft preemption of course. 
> 

I like the original soft preemption idea in the draft as it stands now.
But I have my doubts about the extensions discussed in this e-mail thread.
When planning an admin link or node shutdown, it is probably a better
idea to indicate that via the IGP (through a metric change or announcing
the available bandwidth as 0).
If you do it via RSVP signaling as discussed here, the HE routers
getting the notification now have two pieces of information: the TE-DB
tells them the link/node is still available and a good choice for
a path while RSVP tells them don't go there. So now they've got to
trust what RSVP tells them (for how long???) and reroute.
Other nodes in the network that didn't route any lsp through the
node that goes down now see that there's plenty of bandwidth
through it. They weren't notified by RSVP it's going down. So they
might "optimize" their lsp's and use that node now.
This seems like a somewhat messy situation.

To avoid problems you would have to give indication of link/node
shutdown via RSVP and the IGP at approximately the same time.
But why do that when you can get the job done via IGP alone and
without extra protocol extensions?

In the "higher priority lsp preempts lower priority lsp" scenario
of the draft, soft preemption via RSVP works better because you
will get link bandwidth usage updates via the IGP relatively quickly
at the same time.

Markus