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. Needing to enumerate every possible path within the network or having to have a super-deep label stack removes all of the perceived benefits of cheap and simple. The arguments about IP lookups being slow is one best left to the 1990's when it was true. Fixed pipeline systems have proven this to be false. And if the argument is coming down to the lookup delay between the two and your talking about the WAN, speed of light is dominate so the ns differences are in the noise, baring the monetary exchanges. Your follow on statement about more ports and smaller silicon is in abstract somewhat correct but is practice not. Across the silicon manufactures no one in the open market is making a purely MPLS capable chip. With the cost of chips today, you must have multiple customers for the silicon, or, if you are using wholly internally, have enough volume to justify the $100M's that it costs to make. So everyone is optimizing around re-use and maximal customer overlap for execution. So they all do MPLS and IP and SR and IPIP and ... making the argument moot. But please to not take this as saying SRv6 is great. The community got v6 wrong in a number of areas and SR is not helping that. v4 as a transport vs. MPLS is a useful conversation to be had, again depending on deployment and philosophy around large vs. small network nodes. David > On Jun 10, 2020, at 9:51 PM, Saku Ytti <[email protected]> wrote: > > On Thu, 11 Jun 2020 at 00:48, Mark Tinka <[email protected]> wrote: > >> On 10/Jun/20 21:36, Phil Bedard wrote: >>> In its simplest form without TE paths, there isn't much to SRv6. You use a >>> v6 address as an endpoint and a portion of the address to specify a >>> specific VPN service. You completely eliminate the label distribution >>> protocol. >> >> A BGPv6-free core is a decent use-case for us. > > 100% Eliminating label forwarding in core is not an asset, it is a > liability. Label forwarding is fast, cheap and simple[0]. You can do > it with on-chip memory in constant time. IP lookups are slow, > expensive and complex[0]. SRv6 marketing is false, bordering dishonest > marketing of an unclean abomination of a protocol. Every HW designer > has sighed in relief when I've said I don't care about it, because > it's also very HW unfriendly, like IPv6 generally. Unfortunately SRv6 > is somewhat easy to market with the whole 'it's simple, just IP' > spiel. > > [0] None of this is hard to measure, it is a known fact. And all of it > matters, you can measure lower jitter for MPLS than IP, you can better > carry DDoS traffic when using MPLS compared to IP and you can have > more ports in front-plate for the same money, by spending external > memory SERDES for WAN ports. > > > > -- > ++ytti > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
