<div dir="ltr"><div>I think it could definitely be helpful. Cambium's Bequant-based QoE handles MPLS parsing.</div><div>Like you said MPLS tends to be a holdup for a lot of people looking at Preseem.</div><div>And it would make shaping at sites possible.<br></div><div>You said it looks reasonably straightforward to implement within cpumap-pping/xdp-cpumap-tc?</div><div>If you'd need more time to dedicate to it to explore that more, let us know what a fair feature bounty would be for it. =) I can see it helping a lot of operators.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 26, 2022 at 1:33 PM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net">libreqos@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The main reason I was asking about MPLS is that it looks pretty easy to extract the data, and I've seen a bunch of people on the WISP Talk FB group complaining about having to de-encapsulate before they pass things through Preseem. Where I could see that being most useful is if you have a shaper at a tower (rather than just the one), and want to shape your backhaul directly. I'll keep it on the "things to play with" list. :-)</div><div><br></div><div>We ran MPLS/VPLS for a while; we were pretty surprised when our network sped up a lot when it was removed! (Routers got really good at routing, and it's often faster than parsing a label these days). It also made it easier for the other techs to diagnose faults, MPLS never seemed to "click" for them.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 26, 2022 at 2:15 PM Robert Chacón <<a href="mailto:robert.chacon@jackrabbitwireless.com" target="_blank">robert.chacon@jackrabbitwireless.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>We use MPLS (VPLS tunnels back to core) with L2 isolation and DHCP snooping everywhere.</div><div>It decapsulates at our core so we don't need MPLS parsing for LibreQoS in our case.<br></div><div>It works well and minimizes the number of RFC6598 CG-NAT clients behind public addresses.</div><div>I'd prefer simple routing, but with IPv4 exhaustion - that would lead to a lot of unused RFC6598 addresses (and hence high CG-NAT ratios).</div><div>Many clients on one CG-NAT address leads to a lot of problems with services like Amazon Prime.</div><div>I'm hopeful we can switch to VXLAN as Dan suggested. It could be a great alternative to VPLS/MPLS.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 26, 2022 at 10:49 AM dan via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">MPLS is great for those that have dedicated engineering staff or hire a consultant to help out.  It's a real PITA when the business is primarily techs and they have no idea how to solve an issue.   I've been pushing for vxlan/evpn or srv6 for a while as a way to simplify the model.  'wisp' focused gear just isn't there yet though.  high hopes for mikrotik's support for vxlan to get hardware acceleration.   </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 26, 2022 at 10:05 AM Herbert Wolverson via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Actually had a conversation with our primary upstream provider yesterday about IPv6 (and why</div><div>they won't provide it to us). One of their lead engineers, once plied with beer, said that every</div><div>time they've deployed it they get 99% of it working well and 1% of things mysteriously</div><div>stop working, or go wonky. That was similar to our experience a few years ago. It mostly</div><div>helped a lot, but chasing down the "hey, this advertises a v6 address and doesn't actually</div><div>support it" issues drove us crazy.</div><div><br></div><div>Right now, we don't have enough IPv4 addresses, but that's being rectified. We mostly</div><div>do CGNAT and 10.64 addresses in the meantime, with public IPs assigned where they</div><div>are needed (mostly through a tunnel setup to avoid subnetting waste). Tunnels are a pain,</div><div>but they work (once you chase down all of the MTU issues).</div><div><br></div><div>Which reminds me, I have "can we support MPLS?" on my crazy notes list. I know that</div><div>Preseem and similar don't try, but we're already reading deeply enough into the ethernet</div><div>header that saying "this is an MPLS label, advance 4 bytes", "this is a VPLS label, advance</div><div>X (I forget) bytes" looks do-able. [Note, I personally don't enjoy MPLS. It's handy when</div><div>you want to pretend to have a flat network on top of a large routed network - and some</div><div>WISP consultants absolutely swear by it - but my experience is that you are adding</div><div>complexity for the sake of it. Routing works remarkably well.]<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 25, 2022 at 10:30 PM Dave Taht via LibreQoS <<a href="mailto:libreqos@lists.bufferbloat.net" target="_blank">libreqos@lists.bufferbloat.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">in my continued rip-van-winkle, living in the third world (california)<br>
way, I am curious as to how y'all are managing your<br>
ipv4 address supply and if you are deploying ipv6 to any extent?<br>
<br>
In all this discussion of multi-gbit fiber, my own direct experience<br>
is that AT&T's fiber rollout had very flaky ipv6, and more and more<br>
services (like starlink) are appearing behind cgnats, which have their<br>
own capex and opex costs.<br>
<br>
I see a lot of rfc1918 being used as the operational overlay<br>
elsewhere, tons of tunnels, also.<br>
<br>
-- <br>
This song goes out to all the folk that thought Stadia would work:<br>
<a href="https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz" rel="noreferrer" target="_blank">https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz</a><br>
Dave Täht CEO, TekLibre, LLC<br>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr">Robert Chacón<br>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a><br></div></div>
</blockquote></div>
_______________________________________________<br>
LibreQoS mailing list<br>
<a href="mailto:LibreQoS@lists.bufferbloat.net" target="_blank">LibreQoS@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/libreqos" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/libreqos</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Robert Chacón<br>CEO | <a href="http://jackrabbitwireless.com" target="_blank">JackRabbit Wireless LLC</a><br></div></div>