The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

This is exactly what I said before. I believe that there is one implementation
out there that does exactly what you wrote below and it is not ours.

Bora


Eric Gray wrote:

> Folks,
>
>         Discussion on this topic has convinced me
> that there is a flaw in the MPLS specifications
> - though I do not think it should be fixed in
> the encaps draft.
>
>         It seems that some people have concluded
> that the intention behind defining the explicit
> NULL labels was to allow them to be used by an
> implementation that does not support PHP.  It
> is - in retrospect - easy to see why this might
> concluded since it is difficult otherwise to be
> able to explain why the explicit NULL labels
> were defined at all.  Without some implied use
> for these labels, their value is implementation
> specific and the need to specify them nil.
>
>         This is a problem, however, because other
> people have assumed that the implementation that
> is not able to support PHP will refuse implicit
> NULL labels.  Making this assumption is useful
> to those implementations that rely on PHP because
> a reasonable work-around for having an upstream
> peer that does not support PHP is to allocate a
> label from a special set (similar to the explicit
> NULL labels) - but with the added value of being
> able to assign specific labels from this set that
> help in the forwarding process as well.  As an
> example, there may be different sets of special
> labels corresponding to each possible output
> port.  If the upstream LSR simply takes the
> implicit NULL label signaled and turns it into
> a corresponding explicit NULL label in an NHLFE,
> then the downstream LSR does not get an explicit
> notification of the fact that the upstream LSR
> will not be doing PHP.
>
>         This ambiguity should be cleared up.  One
> possible place to do this would be in the MPLS
> architecture draft.
>
> --
> Eric Gray