<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div>On Thu, Aug 12, 2021 at 1:22 PM William Herrin <<a href="mailto:bill@herrin.us">bill@herrin.us</a>> wrote:<br></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Aug 12, 2021 at 9:41 AM Hank Nussbacher <<a href="mailto:hank@interall.co.il" target="_blank">hank@interall.co.il</a>> wrote:<br>
> On 12/08/2021 17:59, William Herrin wrote:<br>
> > If you prune the routes from the Routing Information Base instead, for<br>
> > any widely accepted size (i.e. /24 or shorter netmask) you break the<br>
> > Internet.<br>
><br>
> How does this break the Internet?  I would think it would just result in<br>
> sub-optimal routing (provided there is a covering larger prefix) but<br>
> everything should continue to work.  Clue me in, please.<br>
<br>
A originates <a href="http://10.0.0.0/16" rel="noreferrer" target="_blank">10.0.0.0/16</a> to paid transit C<br>
B originates <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a> also to paid transit C<br>
C offers both routes to D. D discards <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a> from the RIB based<br>
on same-next-hop<br>
You peer with A and D. You receive only <a href="http://10.0.0.0/16" rel="noreferrer" target="_blank">10.0.0.0/16</a> since A doesn't<br>
originate <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a> and D has discarded it.<br>
You send packets for <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a> to A (the shortest path for<br>
<a href="http://10.0.0.0/16" rel="noreferrer" target="_blank">10.0.0.0/16</a>), stealing A's paid transit to C to get to B. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Unless A filters C-bound packets purportedly from <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a>. B<br>
doesn't currently transit for A so from B's perspective that's not an<br>
allowed path. In which case, your path to <a href="http://10.0.1.0/24" rel="noreferrer" target="_blank">10.0.1.0/24</a> is black holed.<br></blockquote><div><br></div><div>Bill, I beg to respectfully differ, knowing that I'm just a researcher and working `for real' like you guys, so pls take no offence. </div><div><br></div><div>I don't think A would be right to filter these packets to <a href="http://10.0.1.0/24">10.0.1.0/24</a>; A has announced <a href="http://10.0.0.0/16">10.0.0.0/16</a> so should route to that (entire) prefix, or A is misleading its peers. </div><div><br></div><div>If A doesn't, though, then B receives a packet from A to <a href="http://10.0.1.0/24">10.0.1.0/24</a>. Unless B is filtering based on the specific IP prefixes of A - which seems to me unlikely - then B has no way to know that this packet is from `you' rather than from A itself (or a customer of A). So B will carry this traffic, imho. </div><div><br></div><div>So A is just paying for the traffic since it announced the prefix. </div><div><br></div><div>Such situations, to best of my knowledge, actually happen on the Internet when a subprefix is filtered for different reasons. We observed it happens with ROV , in our ROV++ simulations, but I'll refrain </div><div>from attaching the URL again so not to be `plugging' that paper (and since I'm lazy to look it up hhh)</div><div><br></div><div>have great day and I'll be happy to learn if I'm wrong. Amir</div></div></div>