[c-nsp] LDPv6 Census Check

[David Sinn]

> On Jun 12, 2020, at 8:26 AM, Saku Ytti <saku at ytti.fi> wrote:
> 
> On Fri, 12 Jun 2020 at 18:16, David Sinn <dsinn at dsinn.com> wrote:
> 
>> I'm not sure what implementation you are saying doesn't exist. The Broadcom XGS line is all on-die. The two largest cloud providers are using them in their transport network (to the best of my understanding). So I'm not sure if your saying that no one is using small boxes like I'm describing or what. And it doesn't have to be MPLS over IP. That is one option, but IPIP is another.
> 
> I'm saying implementation which has off-chip and supports putting some
> on-chip. So that you could have full table lookup for edge packets and
> and fast exact lookup for others. Of course we do have platforms which
> do have large LEM tables off-chip.

But why do you need full table lookup in the middle of the network? Why place that class of gear where it's not needed?

>> Again, feel free to look at only one small aspect and say that it is completely better in all cases. MPLS is not better in wide ECMP cases, full stop. SR doesn't help that when you actually look at the problems at massive scale as I have done. You continually are on the trade-off spectrum of irrationally deep label stacks or enumeration of all of the possible paths through the network and burn all of your next-hop re-writes. At least if you want high-radiux, single chip systems. So this is not sentimentally around a protocol, it's the practical reality when you look at the problems at scale using commodity components. So if you want to optimize for costs and power (which is operational costs), MPLS is not where it is at.
> 
> I'm not sure why this deep label stack keeps popping, if we need
> multiple levels of tunneling, we need it in IP too, and it's almost
> more expensive in IP. Cases I can think of in SR, you'll only loop top
> label or two, even if you might have 10 labels.
> For every apples to apples cases MPLS tunnels are superior to IP
> tunnels. If you want cheap very small FIB backbone, then all traffic
> will need to be IP tunneled to egress, and you get all the MPLS
> problems, and you get more overhead and larger keys (larger keys is
> not a big deal).

The label stack question is about the comparisons between the two extremes of SR that you can be in. You either label your packet just for it's ultimate destination or you apply the stack of the points you want to pass through.

In the former case you are, at the forwarding plane, equal to what you see with traditional MPLS today, with every node along the path needing to know how to reach the end-point. Yes, you have lowered label space from traditional MPLS, but that can be done with site-cast labels already. And, while the nodes don't have to actually swap labels, when you look at commodity implementations (across the last three generations since you want to do this with what is deployed, not wholesale replace the network) a null swap still ends up eating a unique egress next-hop entry. So from a hardware perspective, you haven't improved anything. Your ECMP group count is high.

In the extreme latter case, you have to, on ingress, place the full stack of every "site" you want to pass through. That has the benefits of "sites" only need labels for their directly connected sites, so you have optimized the implications on commodity hardware. However, you now have a label stack that can be quite tall. At least if you want to walk the long-way around the world, say due to failure. On top, that depth of label stack means devices in the middle can't look at the original payload to make ECMP decisions. So you can turn to entropy labels, but that sort of makes matters worse.

The practical reality is somewhere in the middle. At least you probably want some form of path engineering, so the first model really doesn't work or is at least equal to just doing traditional MPLS-TE. The closer you get to the latter, the higher your stack goes. So then you have to look at the hardware you want at the edge of your network and how many labels it can impose. If you want a all commodity network, that doesn't work.

So, yes, MPLS works fine if you want to buy big iron boxes. But that come at a cost. So the point about MPLS is always better is not accurate. Engineering is about trade-offs and there are trade-offs to be made when you optimize in a different direction and that points away from MPLS and back to IPIP

David

> Now if discussion is do we need tunnelling at all, the discussion is
> very different.
> 
> -- 
>  ++ytti