> On Jun 12, 2020, at 8:26 AM, Saku Ytti <[email protected]> wrote:
>
> On Fri, 12 Jun 2020 at 18:16, David Sinn <[email protected]> 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
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
