The MPLS WG Archive

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

Hello Indra,

I think the real issue here is that one needs to know the user-label for the
LSP over which the OAM packet is received in order to be able to detect
connectivity defects (e.g. mis-merging) and to do performance monitoring.

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.

Regards,
Ben

Shahram Davari wrote:
> 
> Hi Indra,
> 
> I should also add that, after a PHP, the egress can not uniquely identify the LSP that the OAM packet belongs to. And that is why we have proposed to duplicate the user-label below the OAM label. If there was no PHP, there was no need to duplicate the user-label label.
> 
> Yours,
> -Shahram
> 
> > -----Original Message-----
> > From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
> > Sent: Thursday, February 15, 2001 4:58 AM
> > To: Indra.Widjaja@fnc.fujitsu.com; Ben.Mack-Crane@tellabs.com; Shahram
> > Davari
> > Cc: mpls@UU.NET
> > Subject: RE: PHP negotiation
> >
> >
> > Hi Indra,
> >
> > From a quick analysis I think you are right (Ben and Shahram
> > may wish to
> > confirm this).  However,  this is a fortuitous consequence
> > rather than a
> > planned one, ie a lack of protocol ID in the normal labelled
> > header forces
> > one to create a special bottom-of-stack OAM alert label, and
> > so increase the
> > label stack by + 1, thereby fortuitously negating the effect of PHP.
> > However, PHP must not be allowed on the OAM alert labelled header.
> >
> > Neil
> > > -----Original Message-----
> > > From: Indra Widjaja [mailto:Indra.Widjaja@fnc.fujitsu.com]
> > > Sent: 14 February 2001 21:28
> > > To: Ben Mack-Crane
> > > Cc: erosen@cisco.com; neil.2.harrison@bt.com; kireeti@juniper.net;
> > > mpls@UU.NET
> > > Subject: Re: PHP negotiation
> > >
> > >
> > > Hi Ben and Neil:
> > >
> > > If I may get back to the technical discussion on why PHP
> > > impacts OAM ...
> > >
> > > I still don't quite understand how PHP would specifically
> > > break the behavior
> > > of your OAM proposal.
> > >
> > > Behavior 1: OAM with PHP
> > > Penultimate node pops the top label and sends an OAM packet
> > > to the ultimate node.
> > > Upon receiving the packet, the ultimate node sees an OAM
> > > alert label and
> > > forwards the packet to the local OAM engine for further processing.
> > >
> > > Behavior 2: OAM without PHP
> > > Penultimate node forwards an OAM packet without popping the
> > top label.
> > > Upon receiving the packet, the ultimate node pops the top label.
> > > Since the next label indicates an OAM alert label, the packet
> > > is forwarded
> > > to the local OAM engine for further processing.
> > >
> > > So it looks like the OAM engine will see no difference in the
> > > two behaviors.
> > > On the other hand, it would be different if the recently
> > > popped label is saved.
> > > Appreciate your clarification.
> > >
> > > indra
> > >
> > >
> > > Ben Mack-Crane wrote:
> > >
> > > > Eric,
> > > >
> > > > I don't know if one could describe the OAM proposal we're
> > > working on as
> > > > a "connection-oriented ITU-like scheme," but I have often
> > > found functional
> > > > modeling of layered networks (defined by ITU) useful in
> > > understanding how
> > > > networks work (or fail to work) in various configurations.
> > > I have even
> > > > found it useful in understanding connectionless networks.
> > > >
> > > > It seems to me that during its evolution MPLS has developed
> > > two personas.
> > > > It has a connectionless persona, exemplified by features
> > > like independent
> > > > unsolicited label distribution and PHP.  It also has
> > > developed a connection-
> > > > oriented persona with features like LSP tunnels and VPN
> > > applications.
> > > >
> > > > For cases in which an LSP must have well-defined endpoints
> > > and there is
> > > > a need to be able to effectively detect MPLS layer defects
> > > (e.g. mis-merging)
> > > > some additional OAM features are needed.  These OAM
> > > features apply to the
> > > > MPLS (shim header) packet layer, not to sub-ip layers (for
> > > which similar
> > > > OAM features are already defined).
> > > >
> > > > Regards,
> > > > Ben Mack-Crane
> > > >
> > > > Eric Rosen wrote:
> > > > >
> > > > > Neil> I  guess  the discussion  above  gave enough
> > > pointers  as  to why  an
> > > > > Neil> unambiguous location of the trail termination
> > > function is important
> > > > >
> > > > > Well, I can say that it  didn't give me a clue.  Repeated
> > > unsupported claims
> > > > > that it is "vital" to follow ITU architectures just
> > > aren't very persuasive.
> > > > >
> > > > > Are  you expecting  to achieve  WG  consensus on  an OAM
> > > proposal?  If  the
> > > > > proposal is  an attempt to warp  an IP-based architecture
> > > into  some kind of
> > > > > connection-oriented ITU-like scheme,  my guess is that
> > > there  is very little
> > > > > chance of achieving consensus.
> > > > >
> > > > > Actually, I  wonder if the  OAM stuff falls  under the
> > > charter of  the CCAMP
> > > > > group rather than the MPLS group.
> > >
> >