The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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