The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

curtis,

thanks for the clarification, and trying to summarize
the discussion (which was "how soft the preemption is"
at the end) it seems we're focusing on the second case
were consolidated feedback is expected, there might be
thus some words to ponder within the actual version of
the document (which tends to imply that timing is a
critical issue) such as "This indicates to the HE of 
this LSP that it must be re-routed *as soon as possible* 
using a make before break." and "The preempting node MUST 
*immediately* send a Resv message with the 'Preemption 
pending' RRO flag set for each soft preempted TE LSP."

you have mentioned "The RRO with "Preemption pending" 
set can be sent in both the PATH and RESV to insure this."
would you clarify what do you mean in the former one?
i don't see this in the current i-d version (i see only
Resv RRO mentioned w/o further details)

note also that i am not sure on how far we can go in
soft-preemption of soft-preempted lsp, when you say: 
"allows further soft-preemptions to act on already 
soft-preempted LSPs." wouldn't we then propagate the
problems? imho it might be wise (and i think this is 
what the current doc says in section 6) to limit it 
*by default* to external events - 

thanks,
- dimitri.

Curtis Villamizar wrote:
> 
> In message <3E89335B.E1691D6E@alcatel.be>, Dimitri.Papadimitriou@alcatel.be wri
> tes:
> > hi, to address the following comment exchange:
> >
> > -----
> >
> > > > > The preference for the RRO flag is that like the protect-inuse,
> > > > > the ingress knows which hops it does not have resources on.
> > > > > Consider the path A-B-C-...Z. If hops D-E and G-H have preempted,
> > > > > but all of the hops are near 100% utilized, the ingress knows it
> > > > > can share bandwidth with its prior LSP on all hops for which the
> > > > > RRO flag bit is not set. Its harder to do that with a collection
> > > > > of path-err messages.
> >
> > > > That's perfectly correct and one of the reasons why we ended up
> > > > with this scheme. Otherwise, the HE would have had to wait for some
> > > > unknown period of time (to make sure it has received all the PERR
> > > > from the set of preempting nodes) before triggering a new CSPF on
> > > > the modified topology
> >
> > > OK. But I don't see how using Resv lets you know when all of the
> > > premption is complete. Since in your example preemption of D-E is
> > > likely to happen first it will trigger a Resv reporting just one
> > > hop as preempted. Later there will be another Resv that indicates
> > > D-E and G-H as preempted. Sometime later there might be another
> > > Resv indicating further preemption down near Z. The only advantage
> > > seems to be that the Resv gives you a list of preemptions that have
> > > happened (saving the HE from having to maintain that list itself).
> > > It does not remove the "unknown period of time" issue.
> >
> > -----
> >
> > we may consider two modes, a fast one using PathErr messages (or
> > even Notify messages) to the sender (optimizing the time performance),
> > and a trace mode using the RRO but with a prior notification to
> > the receiver so that the complete trace is available through the
> > RRO at the sender side before making a decision (optimizing the
> > resource performance), i have got the impression that the current
> > solution tries to optimize both at the same time but as mentioned
> > by adrian it doesn't seem to be feasible
> >
> > thanks,
> > - dimitri.
> 
> Dimitri,
> 
> The vast majority of traffic is IP and of that some 95% or more is
> TCP.  In the last major ISP traffic sampling I've seen (available
> through CAIDA - look around) there was enough relatively high speed
> and long duration TCP flows to make traffic easily compressible by
> 30-40% and possibly by 50% with very low loss.  If this were to occur,
> customers with high speed access would notice a degredation in
> performance of bulk transfers, but would otherwise be nearly
> imperceptible.  If the degredation were for a brief period, customers
> with high speed access that were not making explicit measurements
> would not notice either (or barely notice).
> 
> This means that soft preemption can be provide many seconds or even
> 10s of seconds of "grace period" before hard preemption.  The
> performance loss for "less preferred" IP traffic over temporarily
> overloaded links for seconds or a few 10s of seconds would be
> imperceptible unless doing bulk transfer and measuring the throughput.
> Rerouting by multiple ingress need not be rushed to the point that
> poor layout results (ie: the ingress reroutes can be paced such that
> feedback from the midpoints is effective).
> 
> The reroute can also be configured to go "as fast as possible" if that
> is what the ISP would prefer.
> 
> If a large number of LSPs is soft preempted, and preemption occurs at
> multiple hops, then the RRO method consolidates the feedback and most
> important, allows further soft-preemptions to act on already
> soft-preempted LSPs.  The RRO with "Preemption pending" set can be
> sent in both the PATH and RESV to insure this.
> 
> The case where a large number of LSPs is soft preempted is likely to
> be caused by a failure at some other link that causes higher
> preference LSPs to be rerouted.  If these use either FRR or standby
> LSPs, then the primary LSP need not be rerouted "as fast as possible"
> and the effective result will be a pacing of LSP setups and therefore
> of soft-preemptions.  Knowing which lower preference LSPs are already
> soft-preempted is more important than fast notification of the
> ingress.
> 
> Curtis
> 
> > George Swallow wrote:
> > >
> > > In San Francisco the workgroup showed support for making
> > >
> > >   MPLS Traffic Engineering Soft preemption
> > >     draft-meyer-mpls-soft-preemption-00.txt
> > >
> > > an MPLS WG Document.  This message is to solicit any further comments
> > > prior to making a final determination.
> > >
> > > Please reply by 4/7 24:00 GMT.
> > >
> > > ...George

-- 
Papadimitriou Dimitri 
E-mail : dimitri.papadimitriou@alcatel.be 
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491