Page 1 / 5   >   >>
kireeti 12/5/2012 | 1:55:44 AM
re: MPLS Gets the Management Blues Let me jump in here, as an author on the MPLS
ping draft in the IETF.

I won't go into the myriad issues with Y.1711 (or
for that matter with MPLS ping), or the fights, um, vigorous debates that the MPLS WG had on the
subject of MPLS OAM.

Let me instead say that the IETF *is* very much
involved with MPLS OAM (and not by issuing
another MIB) -- hence the MPLS ping document.

In evaluating MPLS ping, the following have to be
kept in mind:
a) MPLS is not purely connection-oriented, nor is
it connectionless. See (B-D) below. So, one
cannot simply apply techniques borrowed from a
connection-oriented world.
b) There are many protocols for exchanging labels:
RSVP-TE, LDP, BGP, and (lest I offend) CR-LDP.
Any MPLS OAM technique should deal with all of

Also, the following aspects of the MPLS data
plane must be kept in mind (like it or not, and
many don't):
A) Any OAM mechanism MUST follow the same data
path as the LSP it is testing. The use of an
OAM label can make this very tricky.
B) MPLS LSPs can be multipoint-to-point (LSP
merging). These means that there needn't be
a single "ingress".
C) Worse yet, MPLS LSPs can have mutiple egresses
(no, not multicast, just multiple paths for
D) MPLS LSPs can follow multiple paths (ECMP)
E) As has been pointed out, LSPs predominantly
have PHP.

One might say that the above makes OAM very complex, and is a result of not developing OAM
along with the basic forwarding behaviour. That may be, but many of those features (merging,
ECMP, PHP) have proven very useful, and are
requirements now. So, water under the bridge.

MPLS ping is a mechanism that takes all of the
above into consideration. If MPLS ping is
"overly complex", it's because the MPLS data
plane is "overly complex", which is because SPs
deploying MPLS like it that way(*). Nonetheless,
MPLS ping has been implemented by many vendors,
and is interoperable. We'll see about deployment
over the next year.

(*) Yes, there are exceptions.

BFD is the IETF's answer to OAM over Ethernet.
But BFD is more: those who are concerned that
MPLS ping cannot deal with thousands of tunnels
should read the document describing how BFD and
MPLS ping can interact to scale MPLS OAM.

I should also mention MPLS traceroute (built on
the MPLS ping mechanism), which isolates faults,
discovers multiple paths in ECMP situations, and
diagnoses LSP failures. Ultimately, while Y.1711
may be just fine for connectivity tests, not having a tool for isolating faults will prove a serious deficiency.


PS: Geoff: only LERs need implement MPLS ping.
It's only when MPLS traceroute is used that
LSRs need to get involved.
Tony Li 12/5/2012 | 1:57:10 AM
re: MPLS Gets the Management Blues

Well, yes, if you're using static LSPs and then turn things off, then things are going to get wierd in a awful hurry. Is this a realistic scenario tho? Most everyone is going to use signalled LSPs.

BT could just decree that they will not use static LSPs and be done.

Tony Li 12/5/2012 | 1:57:11 AM
re: MPLS Gets the Management Blues

With PHP, the "egress LSR" doesn't actually have to be an LSR. After all, it's not actually seeing a label. Yes, that system will need to understand and forward the packet based on it's L2 or L3 data.

However, if you step back and look at the LSR that performs the PHP, you'll see that it does NOT need to perform a lookup function. It simply needs to know how to perform an L2 encapsulation, if any, and the exit interface.

truelight 12/5/2012 | 1:57:33 AM
re: MPLS Gets the Management Blues Geoff, Tony etc

Okay your good. However these posts are starting to read like IETF mailing lists....yawn. This is light reading not heavy reading.

A new concept of technical Message boards maybe be in the making.

From a service assurance and quality performance perspective MPLS like IP and Etherent and the products they reside in have always lageed in OAM consideration since in reality this comes form a Service provider not a vendor view point.

stephenpcooke 12/5/2012 | 1:57:42 AM
re: MPLS Gets the Management Blues Geoff wrote:

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

I remember several years ago when PacBell was deploying Nortel's TransportNode platform that we had to go through all our documentation and re-write it so that it could be understood by someone with a high-school education. When we asked why we were told that PacBell employed people with no more than high-school education to operate their networks, that the only engineers were in the NOC who would tell the techs which page of the NTP to turn to to perform the procedure.

As PacBell was a $200M customer at that point we re-wrote the documentation.
gbennett 12/5/2012 | 1:57:42 AM
re: MPLS Gets the Management Blues Hi Stephen,

The OAM discussion I've had, and the presentation I've seen from BT were in the context of 2547bis Layer 3 VPNs.

It's a very rapidly growing service for them.

gbennett 12/5/2012 | 1:57:43 AM
re: MPLS Gets the Management Blues Tony Li (post 36) said:

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.

Tony, I would certainly agree with you that religious arguments sych as this have been used as stalling tactics in the past. But in terms of MPS deployment, I'm pretty sure that battle is over in most carriers. It certainly is in BT. I've discussed this with the BT folks who made the original OAM contributions in the IETF and to me their motive seems to be to make sure MPLS is manageable by the time network deployments reach a scale when an unmanageable technology would just blow the business case away. It also strikes me that BT is taking a very open approach to the problems it sees, by holding these BT Symposia with its major vendors, and even bringing in competing PTTs from the rest of Europe.

There are two links off this page that give the powerpoint presentations shown at these Symposia.


gbennett 12/5/2012 | 1:57:44 AM
re: MPLS Gets the Management Blues
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?
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".

gbennett 12/5/2012 | 1:57:44 AM
re: MPLS Gets the Management Blues Hi 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.

stephenpcooke 12/5/2012 | 1:57:44 AM
re: MPLS Gets the Management Blues Tony writes:

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)?
Page 1 / 5   >   >>
Sign In