The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Mar> msg00277



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-meyer-soft-preemption-00.txt

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Mon, 17 Mar 2003 15:16:32 -0500
  • cc: "Adrian Farrel" <afarrel@movaz.com>, mrn@gblx.net, denver@gblx.net, jpv@cisco.com, "'mpls@uu.net'" <mpls@UU.NET>


In message <200303171821.NAA22711@bifocal.cisco.com>, George Swallow writes:
> > I support this concept, but I wonder why you do not use PathErr instead of 
> Resv.
> > Why not just define a new Errcode/value for the PathErr to indicate preempt
> ed
> > but still in place?
> > Transit nodes (including backwards compatibility) will forward the PathErr 
> but
> > not act on the LSP
> > The headend can treat the PathErr as you describe by performing
> > make-before-break.
> 
> There is one difference.  In 2205 the RESV is sent reliably
> (periodically refreshed) and the PathErr is one shot.  However if
> you're using 2961, this argument goes away.
> 
> ...George


In 2961, all it says about path-err is "PathErr and ResvErr messages
SHOULD be treated as implicit acknowledgments".  They are still one
shots.

If anything, if drops do occur, fast RESV propogation is more likely
with RFC2961 but path-err reliability is not improved.

Curtis