<div><div dir="ltr"></div></div><div><div dir="ltr">On Fri, Jun 12, 2020 at 10:22 PM David Sinn <<a href="mailto:dsinn@dsinn.com" target="_blank">dsinn@dsinn.com</a>> wrote:<br></div></div><div><div class="gmail_quote"></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div>Except that is actually the problem if you look at it in hardware. And to be very specific, I'm talking about commodity hardware, not flexible pipelines like you find in the MX and a number of the ASR's. I'm also talking about the more recent approach of using Clos in PoP's instead of "big iron" or chassis based systems. </div></div></blockquote><div><br></div></div><div><div><div>TE gives you the most powerful traffic engineering tool kit available. Naturally it has a bit more weight than just a single screwdriver. It can you build nearly any kind of multipath transport while that Clos thing is just one architecture hunting for the cheapest implementation of IP/LDP-style ECMP.<br></div></div></div><div><div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div><div>On those boxes, it's actually better to not do shared labels, as this pushes the ECMP decision to the ingress node. That does mean you have to enumerate every possible path (or some approximate) through the network, however the action on the commodity gear is greatly reduced. It's a pure label swap, so you don't run into any egress next-hop problems. You definitely do on the ingress nodes. Very, very badly actually.</div></div></blockquote></div></div><div><br></div></div><div><div>Actually shared links are not a swap but just a pop similar to SR. But indeed this would shift your ECMP issue just to the headend. So for your ECMP scaling there would still be an option left to use an implementation which offers you a merge-point with a single label to all upstreams for a certain equal-cost multipath downstream. This does exist, so would certainly fix your ECMP scaling problem. But advanced control-plane code is certainly not cheap so in the end, like it was already said before, if a simple and cheap platform can solve all your needs then it might be the better one. Let‘s see what problems we need to solve in five years again.</div></div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div></div><div>What I'm getting at is that IP allows re-write sharing in that what needs to change on two IP frames taking the same paths but ultimately reaching different destinations are re-written (e.g. DMAC, egress-port) identically. And, at least with IPIP, you are able to look at the inner-frame for ECMP calculations. Depending on your MPLS design, that may not be the case. If you have too deep of a label stack (3-5 depending on ASIC), you can't look at the payload and you end up with polarization.</div></blockquote><div><br></div></div><div><div>Not really as you are still forced to rewrite on imposition for the simplest form of tunneling, and for TE as often as you need to go against your SPT as well, it‘s just happening on IP (and IP rewrites are more expensive than MPLS rewrites / forwarding operations).<br></div>
</div>