The MPLS WG Archive

[Dimitri.Papadimitriou@alcatel.be]

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.

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
> 
> ======================================================================
> George Swallow          Cisco Systems                   (978) 936-1398
>                         250 Apollo Drive
>                         Chelmsford, Ma 01824

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