re: MPLS Gets the Management BluesCisco, Tellabs, Rad, Lucent, Alcatel, Nortel etc all have opened displayed a public display of arrogance towards carriers in the IETF when addressing OAM. They do not represent thier companies well rather they try and justify why they are the best to each other. Most have little network experience in the real product development or deployment - technocrats.
IMHO the should all be fired and replaced by other employees ;-)
re: MPLS Gets the Management BluesUm. I defer to those who know the hardware better, but to the best of my knowledge the phy's are sending idles when there's no data, and (if you look at the various phy datasheets) they have LOS handling. So in fact link failure can be handled very quickly in ethernet networks between the two nodes that own the link. Gets a little dicier with paths, though Fast Reroute does pretty well these days (sub 50ms by a host of vendors). Some experimental work has been done to do OSPF convergence, triggered by link down indications (not just Hellos) in deep subsecond times for reasonable sized areas.
Granted other stuff can go wrong.
Tell you what, look here in this laser port and tell me what you see... :-)
-->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?
re: MPLS Gets the Management Blues>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?
Only original 10mbps ethernet (on copper cable) sent nothing during quiet times. (and they created link-test pulses to handle that) Everything from fast ethernet to 10gigE constantly sends idle code words to keep receivers (and descramblers/decoders depending on the technology) synchronised. So link loss detection happens very quickly. (and in fiber, there's always a level of some light - the binary decoding is based on the variations in light levels, not on or off)
But you're right through a switch there is no inherent path level keepalive as there is in sonet. To that end, one can use OSPF/ISIS hellos, or MPLS RSVP refreshes, or LDP hellos, or even BFD. Many of those can be miplemented faster than 1 second timers on most vendors routers. In theory BFD could be done in milliseconds. (anything that is put in hardware could be - if you put LDP hellos in the hardware, then it could be fast too)
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.
I'm not sure I get this (and I admit this may be my fault :-)
You're saying that PHP is useful for a given egress LSR that may not understand the protocol that's encapsulated by the MPLS header?
So how does removing that header before the packet reaches the egress LSR help?
Surely with a "naked" packet hitting the egress LSR, this LSR is now even more obliged to understand the protocol.
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.
But how does MPLS tell you what the state of the tunnel is? And if there is some kind of hello, how long does it take an LSR to figure out a given tunnel has gone down?
I know I mentioned BT in my example, but that's because they're the ones making public presentations about this stuff. I've spoken privately to at least a dozen service providers who have expressed a similar concern (to greater or lesser extents).
As you correctly point out, SPs don't stop Ethernet or 2547bis deployments because there's no OAM. But I think there's an expectation that by the time these deployments get to a serious scale, OAM should be in place.
I go back to my original concern, and very much a personal opinion. If the IETF wanted MPLS to be taken seriously as a carrier technology, then the OAM protocols should have been in the foundation RFCs.
If the in-crowd at the IETF hadn't shouted down the carrier concerns about this 2 years ago then we might have got at least the basic tools into the foundation documents. And those concerns were not just expressed by BT.
re: MPLS Gets the Management Blues You're saying that PHP is useful for a given egress LSR that may not understand the protocol that's encapsulated by the MPLS header? -------------
PHP is useful when traffic is to be delivered to a node without an encapsulating label. Consider the case of an LSP that is used to provide an L2 VPN. The LSR may not understand the protocol that is being carried in the VPN and can simply pop and forward without performing any type of lookup.
As another poster mentioned, it's also extremely convenient for implementors who don't want to double the number of cycles per packet that their system has to support.
re: MPLS Gets the Management BluesBut how does MPLS tell you what the state of the tunnel is? And if there is some kind of hello, how long does it take an LSR to figure out a given tunnel has gone down? ---------------
Geoff, the LSR that is adjacent to the failure propagates the information via signalling. The hello is only necessary when the underlying media (e.g., Ethernet with a switch in the middle) does not give the LSR an accurate picture of the path.
----------------- I know I mentioned BT in my example, but that's because they're the ones making public presentations about this stuff. I've spoken privately to at least a dozen service providers who have expressed a similar concern (to greater or lesser extents). ------------------
And how many of those carriers have expressed truly pragmatic and rational concerns? OAM is another tool for the circuit folks to delay and confuse the propagation of packet switching. The carriers AND the vendors are well motivated to provide a practical solution to the true operation and maintenance of the network. Real concerns will be taken seriously. Politically motivated rationales will be identified for what they are.
-------------- As you correctly point out, SPs don't stop Ethernet or 2547bis deployments because there's no OAM. But I think there's an expectation that by the time these deployments get to a serious scale, OAM should be in place. ---------------
Ok, so let's understand this: OAM is vitally important and needs to impose overhead everywhere because we insist on deploying Ethernet switches to cut costs.
re: MPLS Gets the Management Blues GB: But how does MPLS tell you what the state of the tunnel is? And if there is some kind of hello, how long does it take an LSR to figure out a given tunnel has gone down? --------------- TL: Geoff, the LSR that is adjacent to the failure propagates the information via signalling. The hello is only necessary when the underlying media (e.g., Ethernet with a switch in the middle) does not give the LSR an accurate picture of the path.
Tony, I think the example used by BT was that forwarding can be turned off by mistake for a given LSP by an engineer performing some other maintenance operation. Of course it depends how that tunnel was set up as to whether an alarm would be generated by the signalling protocol. If it's static, then no alarms are generated, regardless of which physical layer is being used. With no automated, end to end fault detection on the LSP it's now the customer who becoms the OAM mechanism. Worse still is that (until LSP-PING was created) the NOC could not use any remote mechanism to locate the point at which forwarding stops. Regular IP PING passes through the Control Plane, and (since there is no link failure in this example) will report that the customer's IP address is reachable.
Isn't this one of the big issues that Y.1711 CV addresses? I know the reaction of at least one vendor to this example was "well, they shouldn't employ such stupid engineers". It reminds me of the old saying "It's hard to make something foolproof, because fools are so ingeneous".
re: MPLS Gets the Management BluesHi Tony, On your PHP comment. I guess I'm just not seeing this. I must have been away from the hands-on side of things for too long :-)
In UHP operation, the outermost label stays on until the ultimate router. This router pops the label, and then has to perform a forwarding lookup on the next valid field. This field could be an IP address (regular forwarding), a Layer 2 MAC address or equivalent header (L2 VPN), or another label.
In PHP operation, the outermost label is popped by the penultimate LSR. So when the packet arrives at the egress LSR the packet is already "naked". In other words, the egress LSR only has the remaining outmost field to use to make a forwarding decision.
So in this case, surely the egress LSR in PHP operation has to understand the semantics of the filed "underneath" the label that was popped by the penultimate hop.
Is PHP one of the religious topics in MPLS? I ask because experts from several vendors have assured me that it's very much an optional procedure, and was only used to help out under-powered edge LSRs. The downside is that PHP operation makes OAM harder, of course.
As you correctly point out, SPs don't stop Ethernet or 2547bis deployments because there's no OAM. But I think there's an expectation that by the time these deployments get to a serious scale, OAM should be in place. ---------------
Ok, so let's understand this: OAM is vitally important and needs to impose overhead everywhere because we insist on deploying Ethernet switches to cut costs.
This is simply pushing the problem around.
Might the requirement for OAM have to do with them wanting to deploy VoIP and the expected levels of service and restoral time for voice are MUCH higher than for data in general? They may have deployed a bunch of Ethernet stuff, but what business unit of BT deployed it (ie: was it BTWholesale, the telecom supplier, or was it BTBroadband, the ISP)?
IMHO the should all be fired and replaced by other employees ;-)