The MPLS WG Archive

[neil.2.harrison@bt.com]

Eric Gray wrote (snipped):

> 	There is always a brute force negotiation
> mechanism: the upstream LSR that does not support
> PHP can simply refuse to do so - perhaps sending
> an appropriate error message.  The procedure for
> this is spelled out in section 4.1.1.2 of RSVP-TE
> 
NH=> I can think of one other brute force mechanism........PHP is not
allowed.  This also addresses this architectural conundrum:
Q - when is a trail not a trail?
A -  when PHP is used.
I have yet to hear some killer reason why PHP is so useful that we must have
it (other than the expedient 2 label look-up issue), but I can certainly see
some problems with it, eg where to site OAM functions to detect defects and
take consequent actions (eg send FDI/BDI and client/server adapatation of
FDI between nested LSPs), fix end-point for restoration, where to set
avial/QoS registers, etc.  All these functions need to know where the trail
termination point is and hence where the appropriate functional processing
is located.  To have an unclear datum for the trail termination function is
architecturally not acceptable.

In the mpls-arch ID it says (in section 3.16) 'From an architectural
perspective, this [ie PHP] is perfectly appropriate.'  I fundamentally
disagree with this statement *from an architectural perspective*.  One
cannot have LSP OH being arbitrarily assigned for processing at different
points - irespective of whether one agrees that the assigned OH is
appropriate/sufficient.  And this is clearly demonstated by the following
passage from Yakov's textbook (p 133) on MPLS that explains (I assume) the
initial rationale for these special labels:

"The explicit null labels are used in cases where a label encapsulation is
needed but no valid label is required.  This might be done, for example, to
retain the Exp fields for QoS purposes on the last hop of an LSP, even
though no label is required by the last hop."

neil