[c-nsp] LDPv6 Census Check

[David Sinn]

> On Jun 11, 2020, at 2:02 PM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 11/Jun/20 17:32, David Sinn wrote:
> 
>> Respectfully, that is deployment dependent. In a traditional SP topology that focuses on large do everything boxes, where the topology is fairly point-to-point and you only have a small handful of nodes at a PoP, labels can be fast, cheap and easy. Given the lack of ECMP/WECMP, they remain fairly efficient within the hardware.
>> 
>> However if you move away from large multi-chip systems, which hide internal links which can only be debugged and monitored if you know the the obscure, often different ways in which they are partially exposed to the operator, and to a system of fixed form-factor, single chip systems, labels fall apart at scale with high ECMP.
> 
> I'm curious about this statement - have you hit practical ECMP issues
> with label switching at scale?

Yes. Path enumeration when you use mult-tier Clos topologies within a PoP causes you many, many problem.

> We have ECMP'ed label switch paths with multiple paths for a single FEC
> all over the place, and those work fine both on Cisco and Junos (of all
> sizes), both for IPv4 and IPv6 FEC's. Have done for years.

The protocols will work fine. And if you are still buying SP class chips, you're fine. But you are paying a lot for those chips in cost and power. If you look to move to the class of single-chip systems, which gives you lower costs and higher radix, you have to pay the trade-offs somewhere. MPLS at high-radix ECMP exposes this.

David

> Unless I misunderstand your concern.
> 
> Mark.