<<   <   Page 5 / 5
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.


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.

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.

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.

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.

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.
<<   <   Page 5 / 5
Sign In