The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3C1E34DA.70608@juniper.net>, Ping Pan writes:
> 
> MPLS OAM is not a magic box. It is essentially using some fixed label(s) 
> at the data level, and reporting error conditions when data path is not 
> working right. At best, it is ONE of the tools that can detect and 
> diagnosis data plane problems. But what's the cost? It requires EVERY 
> mpls device to look into the header to figure out if it is an OAM frame 
> or not. (If it's label stacked, the device needs to look deep into the 
> frame to detect OAM....) Data forwarding performance will suffer big 
> time, the hardware complexity will go up (no more one simple label 
> swapping operation), and every MPLS device needs to be changed.... If 
> there is a new feature, more hardware changes may be required.... Thus, 
> other than some chip companies who are banking on this as a value-add 
> package in order to sell more chips, this solution makes no sense 
> wheresoever to the providers (spending more money to replace existing 
> hardware?).


Ping,

MPLS-OAM is not all that bad.

The OAM label has to go under the delivery label and gets acted on at
the egress after that label is POPed.  This is no different than
looking at the existing predefined labels such as the IPv4 Explicit
Null label, except that it is not yet "existing" in the forwarding
machinery.  The midpoints would never see the OAM label and have no
need to look under the top label.

Using either LSP Ping, or MPLS-OAM, probes can be injected at
midpoints (at ones that support this, obviously not OXCs), given the
information on where the midpoints are discovered by means such as
GTTP if not already known (for example, loose hops not replaced with
strict hops after the initial RRO or hierarchical hops).


> What should we do instead? LSP-ping is one of the solutions for RSVP-TE 
> only, since, at the time when I was working on it initially, the vast 
> majority of the MPLS network uses RSVP-TE. I can promise you that a 
> simple solution of LDP will be available very soon. Ron Bonica had 
> proposed ICMP traceroute for MPLS. Though rejected by IESG to advance as 
> a RFC, it has been widely deployed and inter-operate among all vendors. 
>   Ron's newest tool, gttp, will bring more features. The service 
> providers have been using Kriteei's MIB to measure the traffic stat of 
> the LSPs. I think more MIBs will be deployed to get more network 
> information. At the end, we will try to overcome every MPLS network 
> problem with simple, flexible and deployable tools. Yakov was right: 
> let's ship the code to the network, use it, learn from it, and move on.


Personally, I like LSP Ping more than MPLS-OAM, more of a minimalist
approach but extensible.  The objections seem to be over it being
RSVP-TE specific.

Whether we use an MPLS-OAM label or a IPv4 Explicit Null label with a
UDP packet under it makes little difference except to the implementor.
The main point of the implementors (maybe not stated clearly or
conspicuously enough) is that hardware already exists to process ICMP
at wire rate and does not exist to process MPLS-OAM at wire rate.

Given that observation, maybe we can take on the issue of making LSP
Ping less RSVP-TE specific by initially shimming in control protocol
and length bits (plural, obviously) before the RSVP-TE stuff, letting
the CRLDP guys provide the CRLDP specific bits, and providing a "I
don't speak that control protocol" error message.  The data probe and
response would still be delivered via ICMP and the control plane probe
and response could still be delivered via UDP (or TCP if the CRLDP
folks prefer).


> > This is not yet about OAM solutions, that is the *next* step.  First agree
> > on requirements.  Requirements presented at the BoF are not met -- many SPs
> > feel these need to be satisfied and the work go forward.
> >
> > Jerry Ash
> > AT&T Labs


WRT Jerry's final point, it will be hard for an OXC (impossible to do
so efficiently if you believe the optical better than electric
switching argument, which I think you do) to inject or extract probe
packets from the data stream.  The existing control tests can be
applied to GMPLS (GTTP and the control part of LSP ping).  The data
path continuity and diagnosis might be better handled with the LMP
capabilities already designed for this purpose.  Intermediate OXC
nodes on an LSP would have to respond with a "can't do that" error if
asked to inject LSP ping probes into an optical LSP.

Curtis