re: MPLS Gets the Management BluesWhen talking about MPLS OAM, the first question which never seems to get answered is just what the problem is that we want to solve.
Different carriers use MPLS for different purposes within their own networks. "Most" vendors think (for some reason I've never understood) that their equipment, and their MPLS capability, is the only thing in the network, and that co-operative OAM is not required.
And then vendors read the specs and figure they need to do everything everywhere, rather than understanding how a network is actually built.
Not that I've been frustrated by the whole mess :)
MPLS is not Sonet. If you want basic statistics like tunnel up/down, that doesn't require MPLS OAM.
Yes it does. BT has publicly presented configurations where MPLS forwarding can "go away", and IP dignostics link PING will still tell you everything is fine.
In this case the worst case scenario occurs, which is that the customer becomes the OAM mechanism for the carrier.
This is the reason that MPLS PING has been developed. But PING is not a complete OAM protocol. IP networks have historically used PING as a link failure detection mechanism, but when you have thousands of tunnels in a single link, the approach doesn't scale well.
ATM OAM solved this problem by piggy-backing OAM flows into the cell stream. One example where cell tax works in your favour.
You ask a lot of questions Stephen! HereGÇÖs one right back at you. Why should the carriers be the ones to make the major functionality decisions? What about other IP equipment users like enterprises, small and medium size businesses, educational institutions, governments, research organizations, and non-profits?
Well in general carriers are the ones who need OAM. First they tend to have SLAs with their customers. And second they operate over long distances.
OK, a university might have an SLA with its customers, but it tends to have skilled IT personel within fairly short distances of those sites. Even if the university doesn't have a specific IT department on a remote campus, there'll be a few geeks who've been given the key to the comms cabinet, and a technician in the NOC can tell them which router to power-cycle.
Enterprise networks call the service provider if the WAN link isn't working. If the LAN isn't working, an IT guy goes to the wiring closet to see what's wrong. Even when Ethernet gets its OAM protocols, they'll only be for carrier Ethernet, not for LANs.
As far as alarms, you have the media (sonet or whatever) state and you have the tunnel state to key off of.
As long as you run MPLS over SONET then you can detect media failures very rapidly, but I think the MPLS community wants to be able to offer rapid protection that's independent of SONET.
Let's say your link is Ethernet LAN PHY over a dedicated wavelength. In other words a basic LAN extension.
How do you know if there's a link failure? In SONET you'll know after 17 microseconds because SONET sends a frame every 125 microseconds whether there's data to send or not. So if the light goes away for longer than 17 microseconds your alarm goes off.
Ethernet is asynchronous. If there's no data to send there's no light. But how does the system tell the difference between no light (link failure) and no data to send?
The answer seems to be "use a higher level keep alive protocol". That's what Y.1711 describes, but the period is 1 second by default (there is a fast keepalive also).
In IP it's what OSPF hellos do (if you miss 3 then you assume the link is down, but that takes 10 seconds).
In ATM you have SSCOP, but you can turn that off and use the underlying SONET alarm if you really whant fast rerouitng.
This is a non-trivial problem for asynchronous transmission systems.
re: MPLS Gets the Management BluesWasn't PHP just a hack that was bolted on to MPLS behaviour to cope with software-based edge routers that couldn't do 2 lookups per packet at wire speed?
No. It was a useful feature that allowed the packet to be egressed from a tunnel on a device that didn't understand the contents of the packet being tunneled or how to forward it on in its own specific protocol. It can provide tremendous flexability in terms of where the tunnel endpoint is placed.
As far as the rest of what you have written, people keep talking about "carriers" and "the majority". But what we are really talking about is forcing the architecture and ideas mostly coming from one specific carrier on the rest of the world. Its no good to talk of "carriers" when we all know where the work is coming out of and who is pushing at ITU.
re: MPLS Gets the Management BluesThe big service providers have very clear cut OAM requirements. They have been running networks for many years and they want to continue to run networks in the same way going forward. It doesn't matter what network technology is being used: the high-level OAM requirements are basically the same.
The customer doesn't care whether you are using a dedicated network or a shared network or a connection oriented network or connectionless network. The customer wants GUARANTEES. The OAM is designed so that a service provider can provide those guarantees and still make money.
So, all you "connection-less" geeks better wake up and make the connection (pun intended) between customer requirements and OAM!
I thought the "connection-less" vendors got enough spanking during 2001-2003. But it seems they still haven't made the connection.
I guess it is time for another round of spanking! Let's see... where did I keep my belt...
re: MPLS Gets the Management Blues>Yes it does. BT has publicly presented >configurations where MPLS forwarding can "go >away", and IP dignostics link PING will still >tell you everything is fine.
The problem with those particular examples is that they lead to solutions that involve turning MPLS into "IPLS". MPLS will reliably tell you what the state of the tunnel is and provide you with alarms. It can't currently provide an integrated fault detection system with IP and VPN routing on top of MPLS.
And if you want integrated MPLS/IP fault management, its not the same as saying MPLS needs OAM. Providing the kind of fault management people sometimes suggest breaks all of the layering between MPLS and IP. And producing solutions that actually work will require limiting MPLS in particular ways that not everyone sees as positive.
And by all means, certain carrier's solutions seem "easy", but its because they don't understand how other people are using MPLS and don't care. They are focused on their network design and their specific set of problems. Nobody else and the broader issues beyond their architecture don't seem to matter.
re: MPLS Gets the Management BluesSo, all you "connection-less" geeks better wake up and make the connection (pun intended) between customer requirements and OAM!
I'll treat that seriously about the same time I see ethernet deployments at certain carriers stop because of the inherent OAM problems in ethernet.
I'll treat it seriously when I see a carrier decline to offer 2547 VPN service because of the inherently flawed design and unmanageable characteristics of it.
And about the same time that the ATM bigots start using all those OAM features they demanded as necessary but never used.
re: MPLS Gets the Management Blues>>Well in general carriers are the ones who need OAM. First they tend to have SLAs with their customers. And second they operate over long distances.
I think your wrong to suggest MPLS OAM is only a carrier problem.
What about banks, securities Firms, or retail chains? Are you suggesting NASDAQ doesn't have SLAs for the 200+ securities firms they service? Is what's good for BT good for them?
Nevertheless, to me, this all sounds like a communication problem similar to a general practitioner telling a well-renown heart surgeon how to perform a quadruple by-pass.
re: MPLS Gets the Management BluesNevertheless, to me, this all sounds like a communication problem similar to a general practitioner telling a well-renown heart surgeon how to perform a quadruple by-pass.
No, it is more like a patient telling a heart surgeon that he has severe chest pains, and the heart surgeon giving the patient some aspirin.
Different carriers use MPLS for different purposes within their own networks. "Most" vendors think (for some reason I've never understood) that their equipment, and their MPLS capability, is the only thing in the network, and that co-operative OAM is not required.
And then vendors read the specs and figure they need to do everything everywhere, rather than understanding how a network is actually built.
Not that I've been frustrated by the whole mess :)