The MPLS WG Archive

[Jean Philippe Vasseur <jvasseur@cisco.com>]

Hi Curtis,

At 14:28 18/02/2003 -0500, Curtis Villamizar wrote:

> In message
> <20030218001433.GS10825@gblx.net>, Matthew Meyer writes:
> > Folks,
> > 
> > There have been some off line conversations showing interest 
> > regarding this draft.  Would anyone be willing to comment
> on-
> > list?
> > 
> > Matthew
>
>
>
> As one of the offliners I'd like to say that this is much needed.
> Every ISP that we talk to regards preemption as a hole in the MPLS
> protocols that if utilized renders make-before-break and
> fast-reroute
> ineffective.  Soft preemption fixes that.
>
> I also support using the RRO as described in the draft.  It is
> the
> best way to accomplish soft preemption.  It is saying exactly what
> is
> happenning, namely that the LSP is still up but it is about to go
> down so do something top avoid having bits dropped.

Thanks for your feed-back

> The one thing I would add is some object or
> bit somewhere that
> indicates that the ingress is capable of understanding and acting 
> on
> the "Preemption pending" bit.  If the midpoint where the
> preemption
> occurs knows that the ingress is capable of dealing with the
> "Preemption pending" bit, it can do a soft preemption.  If
> not, then
> the midpoint might as well do a hard preemption, because the older
> ingress does not understand the "Preemption pending" bit and
> will
> ignore it.

Right, but see, we added the "soft preempted desired" that
solves this issue: 

4.1. SESSION-ATTRIBUTES Flags 
 
To explicitly signal the desire for a TE LSP to benefit from the soft
preemption mechanism (and so not to be 'hard' preempted), the following
new flag of the SESSION-ATTRIBUTE object (for both the C-Type 1 and 7)
is defined: 
               
Soft preempted desired:  0x40  

This allows to limit the overbooking ratio since the mid-point
preempting node will only soft preempt the TE LSP having this bit set.

This way, soft preempted TE LSPs will be limited to TE LSPs originated by
HE which are compliant with this draft and that do explicitly require
soft preemption.

> Non-broken midpoint LSRs already have to pass
> on changes to the "Local
> protection available" and "Local protection in use" bits
> back to the
> ingress.  Non-broken ingress LSRs already have to (or should) act
> upon
> changes to the "Local protection available" and "Local
> protection in
> use" bits.  Adding a "Preemption pending" bit to the
> same bitmask
> poses no additional scaling issues for existing non-broken routers.

Right

> There might be some partially broken
> implementations that currently
> don't look at "RRO IPv4/IPv6 Sub-Object Flags" and don't pass
> along
> changes to it or act on it but they have to be fixed to support
> existing fast-reroute related capabilities.

Correct.

Thanks.

JP.

> Curtis