The MPLS WG Archive

[Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>]

Manohar,

You're right, of course.  I was trying to follow the thread of the
discussion and failed to notice that it had circled around, in a sense.

If the egress LSR supports OAM (i.e., the ability to pop a label header,
recognise the OAM header, and do OAM processing) then it would not need
(or want) to request PHP -- so the question is moot from that perspective.

Regards,
Ben


Manohar Ellanti wrote:
> 
> ----- Original Message -----
> From: "Ben Mack-Crane" <Ben.Mack-Crane@tellabs.com>
> .
> >
> > If the user label is popped before reaching the LSP termination point, the
> > OAM processor at the termination point has no way of knowing on which LSP
> > a connectivity verification packet was received.  If the trace ID is
> wrong,
> > it is impossible to determine which LSP has the mismerging defect.
> >
> > Similarly, for performance monitoring the egress must count packets
> received
> > on a particular LSP to compare that number with the count in an OAM
> performance
> > packet.  If the user-label is PHP'ed, the egress router cannot count
> packets for
> > that LSP.
> >
> >
> PHP is signaled by the ultimate/egress node to the penultimate node. If OAM
> requires that per LSP work is to be done at the egress node and so one needs
> the top label to demultiplex at the egress node, why should one think of
> enabling PHP? Isn't  this egress initiated PHP negotiation. If the egress
> itself doesn't want penultimate node to pop the top level, then why in the
> first place initiate the PHP negotiation? May be I missed some discussion.
> But it looks very trivial to me that not using PHP feature is a simple way
> of out this.
> 
> -Manohar