re: MPLS Gets the Management BluesTony 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.
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.
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.
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.
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.
re: MPLS Gets the Management BluesLet 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 these.
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 unicast). 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.
Kireeti.
PS: Geoff: only LERs need implement MPLS ping. It's only when MPLS traceroute is used that LSRs need to get involved.
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.
http://www.btplc.com/symposium...
Cheers,
Geoff