Aaron, The code is very green; the platform originally was inherited from Nortel and as such they invested heavily in PBB-TE first and foremost. To give you an idea they're currently at version 6.16 and the MPLS code was introduced in 6.10 (from memory). They support just enough OSPFv2 or IS-IS to implement basic MPLS TE functionality but it does not interop with any other vendor well at all from my testing. They only support protected active/standby LSP groups withI maximum 2 paths per group. Paths inside a group cannot be computed automatically and /must/ have EROs specified. They do not support Fast Reroute PLR/MP in any way and their product manager said they have no plans to do so in the future. They do support "signalling" desired FRR protection on an LSP, however, in my lab testing this is a moot point as they don't interop with our Cisco core gear. They seem to add GMPLS TLVs in to their PATH msgs with nil values even when you aren't using GMPLS, which Cisco doesn't like. I was able to get their gear to interop with our Brocade routers, but it was world of hurt of problems in production as they don't do make before break on LSPs or anything useful like that. Even when running only their gear in isolation, we had numerous extremely large service impacting problems with their software - things that as a software and network engineer by trade I can only put down to extremely badly written code. For example we had an issue where when BFD would flap on links rapidly through our network, the MPLS cross connect table would get misprogrammed with a bad value and then from that point onwards all transit LSPs would fail to signal through the node. Even further to this, the biggest issue I had is that their software was not written with enough easy-to-access diagnostic/debugging capability to be able to allow the vendor to triage and get to the root cause of issues. Most major issues never got solved because the things the vendor required you to troubleshoot were outragously inconvenient or massively service affecting in nature. Example; there was no way to send debugging via the network (syslog etc). In quite a few cases I had to break out in to the linux CLI and run their debug streaming program on all our nodes and use netcat to transport it back to our servers to capture it. They implement LDP signalled PWE and VPLS but the cli has a lot of really annoying nuances like, you can't change the LSP on a pseudowire without detaching it from its virtual switch (no make-before-break functionality exists either). We stuck with it for a while, hoping it would get better but every release seemed to bring different bugs, and the old ones never seemed to get fully fixed and would resurface in the future. I suspect they were dealing with race conditions in their code and they just never could seem to reproduce the conditions that would cause them in their lab. I think our microwave network tested their code in ways they never had before when storms rolled through. This might all be different on their larger packet optical devices I don't know - this all applies to the SA-OS on 39XX/51XX platform. We now use the ASR920 platform and comparatively it's night and day in terms of feature set and stability. Only thing I'm missing is lack of tunnel byte counters for use by auto-bw, but Cisco say this is coming in Everest... Regards, Patrick Wed, Apr 19, 2017 at 03:06:42PM -0500, Aaron Gould wrote:
Oh, ok... hmmm
So what was the issue with Ciena and MPLS Patrick ?
-Aaron
-- Patrick Cole <z@wwwires.com> Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630