On Thu, 2 Jan 2020 at 15:46, Robert Raszuk <rob...@raszuk.net> wrote:
>> Hence I'd always prefer transit nodes to use solely the MPLS stack for any >> clues on how to load-share. > > That may not be a good idea. > > Think about SR-MPLS and global labels with say 5 TE segment nodes (hops). As > MPLS header would be identical all flows travelling via such TE path would > get zero load balancing across ECMP paths even parallel L3 links. > > Even if you get fancy and stick there EL as described in > draft-ietf-mpls-spring-entropy-label-12 the limited ERLD in most platforms > will not even reach it in the middle of the network. Adam implied presence of entropy indeed, and of course this would then be design constraint in choosing the LSR. Most platforms seems ambiguous, Trio, FP4, Jericho, Pacific should be good to +dozen labels, which seems very much reasonable for SR+EL. No perfect answer, but certainly if you want to design network to never do payload heuristics, it's entirely possible and there is no significant CAPEX penalty to it. > Not to mention that P routes may be receiving both IP and MPLS traffic. But I > guess your point was that ".. if packets is mpls packet". And if you only balance on labels and include EL, then it doesn't matter what it carries. There is absolutely no way to be sure that MPLS payload heuristics is interpreting bytes correctly, it cannot know what it is carrying. The more verification you do (like IP packet length match) the rarer and harder to troubleshoot the problems are, the problems quickly become so esoteric you'll never even hear of them, because even customer can't believe it would be caused by the service provider's pseudowire. Like 'all hosts work, then we added ipsec, and one host stopped working' could very well be transit heuristics problem, but going from customer => noc => ops => dev => vendor would be unlikely. IMHO, if you MUST do payload heuristics, simple heuristic 4 == IPv4, 6 == IPv6, anything else is unknown is the correct heuristics. And then you must design your network to honor that assumption. -- ++ytti _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
