The MPLS WG Archive

[Eric Gray <EGray@zaffire.com>]

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