The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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.

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.

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.

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.

Curtis