10G MetroE 1-2U Switch

Fri Apr 21 14:06:49 UTC 2017

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 at wwwires.com>
> Senior Network Specialist
> World Without Wires
> PO Box 869. Palm Beach, QLD, 4221
> Ph:  0410 626 630
> 

-- 
Patrick Cole <z at wwwires.com>
Senior Network Specialist
World Without Wires
PO Box 869. Palm Beach, QLD, 4221
Ph:  0410 626 630