The MPLS WG Archive

[ananth.nagarajan@mail.sprint.com]

Ping,

[deleted]
> 
> 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.... 

I don't think your understanding about MPLS OAM requirements is 
accurate. First of all MPLS OAM is not ONE tool - rather it is a suite 
of functionalities - Ping and Traceroute are probably two of the 
various functionalities that OAM is composed of. Also, I think the 
potential impact on hardware has been rather overemphasized. Of course, 
if you choose to implement all the functionalites of OAM for all of 
your traffic types all the time, you get a whole lot of complexity.  
That is not the idea of OAM - the idea is to give the operator a  set 
of mechanisms that he needs to operate the network in the best possible 
way in order to ensure customer SLAs, although only a subset of those 
mechanisms may be used at any given time.  Therefore, there needs to be 
a standardization effort for this "suite", rather than just one or two 
specific functions of OAM.




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

Unfortunately, there is a periodic need to replace/evolve existing 
infrastructure.  Not all deployments of MPLS are for originally-IP 
networks, some deployments are to evolve an existing ATM infrastructure 
to IP.  For this, it is necessary to take into account the service 
needs of existing ATM customers, and it may be necessary, therefore, to 
have a more extensive OAM set.

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

I don't think the intention of the proposed WG is to ignore all this 
work.

> 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.
> 
> Hope you will understand.
> 

Sadly, it doesn't look as if you understand either.  I guess it comes 
from a difference of opinion on what is "best for the network".

Ananth