The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: re: MPLSOAM BOF meeting draft minutes

Ping:

> 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.

I have a major frustration with this thread that the subject of OAM keeps getting trivialized to one proposal vs. the other instead of focusing on the problem. MPLS OAM is a subject, there also happen to be some specific technical proposals that use a reserved label mechanism to protocol mux e2e OAM messages into an LSP. I'm not sure these proposals have exclusive ownership of the term MPLS OAM.

> 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....

This is a big assumption. Other semantics aside, it would not be significantly different than encoding ICMP in an explicit v4 label, that does not seem to require EVERY mpls device to look into the header. I think most students of OAM would PREFER a mechanism whereby intermediate LSRs COULD identify OAM flows, but as we all know, this does not exist.

> 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?).

Take a read of section 10 of the framework draft. For the record, backwards compatability was a desirable goal for the folks when thinking about this, and approaches that minimize network impact are clearly identified.

> 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.

Frankly I'm not entirely sure an LDP solution makes sense, but I can be convinced, I'll look forward to the draft. :-)

> 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.

Yes, in fact I may not necessarily agree with all aspects of GTTP, but I do like the feature of being able to discover hierarchical boundaries. OTOH, earlier in this post you decry needing to upgrade all nodes in the network while trumpeting solutions that require precisely that....

>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.

Some of the stuff you are proposing is only simple in the sense that some portion of it has engineering re-use. The actual transactions tend to be somewhat convoluted and processing intensive, e.g the insertion of the "suspect" state when ICMP replies stop and I don't know if the LSP or the return path has failed. Similarly if I can reduce performance data collection down to a query of the egress NE with a couple of P flow transactions, this scales a lot better than many SNMP transactions to interrogate two or more NEs on an LSP path and perform an off line comparison to produce an approximate performance evaluation.

> Yakov was right: let's ship the code to the network, use it, learn from it, and move on.
> Finally, I urge people not to be blind by the architecture and culture
> differences. Instead, let's think that's the best for the network.

What makes you think folks who don't agree with you have destructive motives or that incremental protocol modification is the only outcome of knowledge obtained? The only difference of note between all of us is that some are tackling the problem in a very constrained way and admitting there are shortcomings to the approach, and some of us are thinking a bit more greenfield. We also shouldn't be blind to the difference between "good" and "making do".....

rgds
Dave

---------------------------------
Sr. Advisor, Portfolio Integration and Architecture
dallan@nortelnetworks.com