The MPLS WG Archive

["Matthew R. Meyer" <mmeyer@gblx.net>]

Thus spake Jim Boyle (jboyle@pdnets.com):

 |
 |First, great draft - I like this concept.

Thanks for your comments Jim.

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

All very interesting ideas. 

We could add as well:
  o) Your LSP should be rerouted away from this SRLG (administrative/CLI)
     (just a flag)

I don't see a problem with adding some more flags to convey 
administrative events though I do have healthy fear of 
proto-bloat.  I welcome more comments on this subject.

 |You can somewhat do some of these by changing metrics and waiting, but
 |just was wondering if something more general might be useful.

I think there are cases like zero-BW LSPs that still need to be 
handled where flooding a new zeroed IGP TLVs wouldn't help. 

 |Also, with Diffserv TE, not sure that one can assume that a preemption
 |necessarily "implies exhausted bandwidth at the affected priority
 |level *and greater*" (section 5), but local implementations can do
 |as they please I suppose.

Yes, I guess we need to be more specific there. This document assumed
independent Diffserv & TE deployments as opposed to Diffserv-TE.

Thanks,
Matthew