Sorry, slight correction to the below - GMPLS Sub-TLVs inside the TE LSAs were being advertised with nil values instead of being removed completely. One additional thing that really irked me is that their TE code is that they set all TE metrics to 0 for every interface/link and no way to use the IGP metric or set it, so if you have two links of equal distance in terms of hops, there was no way to steer a CSPF computed LSP to prefer one without using EROs to do it. They also have no concept of attribute flags or link colors. Ultimately, their TE implementation was very basic. They openly admitted their focus was on GMPLS and not MPLS-TE. For us, GMPLS has no real use case in our network. Patrick Fri, Apr 21, 2017 at 11:45:06PM +1000, Patrick Cole wrote:
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
-- Patrick Cole <z@wwwires.com> Senior Network Specialist World Without Wires PO Box 869. Palm Beach, QLD, 4221 Ph: 0410 626 630