The MPLS WG Archive

[Jim Boyle <jboyle@pdnets.com>]

Yeah, maybe lean and clean is better here.

On Thu, 20 Feb 2003, Markus Jork wrote:

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