The MPLS WG Archive

[Ina Minei <ina@juniper.net>]

	Please find comments inline below.

			Ina

On Tue, 18 Feb 2003, Curtis Villamizar wrote:

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

The HE LSR is the one requesting soft-preemption by setting the
flag in the session attribute object. A transit will only send
a Resv message with the RRO 'Preemption Pending' bit set if it
previously received a path message requesting soft-preemption, meaning
that the HE always knows how to handle 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.
>