<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 11, 2022 at 7:41 AM William Herrin <<a href="mailto:bill@herrin.us">bill@herrin.us</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">On Mon, Oct 10, 2022 at 3:37 PM Matthew Petach <<a href="mailto:mpetach@netflight.com" target="_blank">mpetach@netflight.com</a>> wrote:<br>
> They became even more huffy, insisting that we were breaking the internet by not<br>
> following the correct routing for the more-specific /24s which were no longer present<br>
> in our tables. No amount of trying to explain to them that they should not advertise<br>
> an aggregate route if no connectivity to the more specific constituents existed seemed<br>
> to get the point across. In their eyes, advertising the /24s meant that everyone should<br>
> follow the more specific route to the final destination directly.<br>
<br>
Hi Matthew,<br>
<br>
They were correct. If the /24 was reaching your network, traffic<br>
should not have been following the /20. In your version, they would<br>
have to disaggregate the /20 into 16 /24s just because you didn't want<br>
to honor most-specific path routing. That's not what anybody wants.<br>
Least of all you.<br></blockquote><div><br></div><div>I disagree.</div><div><br></div><div>To illustrate why, let's take your case a step further, shall we?</div><div><br></div><div>Wouldn't that same argument mean that every ISP that isn't honoring </div><div>my /26 announcement, but is instead following the covering /24, or /20, </div><div>or whatever sized prefix is equally in the wrong? And what about Fred's </div><div>/27 announcement? Gosh, and now Cindy wants to announce a dozen </div><div>/30's--is it everyone else's error for not listening to those announcements?</div><div><br></div><div>What makes /24 boundaries magically "OK" to filter on, such that if </div><div>you announce something smaller than a /24 that gets filtered, and </div><div>traffic goes to the covering aggregate, everyone says "well, that's </div><div>just how the Internet works, and of course traffic would be expected</div><div>to flow towards the covering announcement", but if I set the boundary </div><div>at a different, but still arbitrarily-sized point, like /23, suddenly the </div><div>announcing party is right, and I'm wrong?</div><div><br></div><div>If the stance is "it doesn't matter if there's a covering prefix, that </div><div>announcement doesn't mean you can reach all the prefixes </div><div>contained within it, you *must* listen to all the smaller announcements </div><div>in order to have reachability", then A) you're redefining how BGP works </div><div>in a fundamental way, and B) we should all buy stock in router memory </div><div>manufacturers, because they're going to be the next oil companies.</div><div><br></div><div>BGP 101 says that if I announce a covering prefix, I'm making a statement </div><div>into the BGP routing table that says "you can reach everything contained </div><div>within this covering route via me", and that's how the forwarding tables </div><div>treat it; any time there's nothing more specific in the table, even due to </div><div>a brief transient change on the Internet, traffic for those prefixes will be</div><div>forwarded to the router announcing the covering prefix announcement. </div><div><br></div><div>If I announce 0/1 into the DFZ and drop any traffic destined for it on the </div><div>floor, I'm not going to get much sympathy by saying "well, it's your fault,</div><div>you should have been listening to all the more specifics and not trusting </div><div>the covering route to actually have reachability to the prefixes contained </div><div>within it." (though that does make me think that if you're a content-heavy </div><div>shop looking to balance your traffic flows, it might be a interesting way </div><div>to make the point in a very real way to everyone on the Internet...)</div><div><br></div><div>To wrap up--I disagree with your assertion because it depends entirely </div><div>on a 'magic' /24 boundary that makes it OK to filter more specifics smaller </div><div>than it, but not OK to filter larger than that and depend instead on covering </div><div>prefixes, without actually being based on anything concrete in BGP or </div><div>published standards.</div><div><br></div><div>"But that's how we've always done it" is not the same as "but that's how </div><div>the protocol works." ^_^;</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regards, </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bill Herrin</blockquote><div><br></div><div>Thank you for the discussion!</div><div><br></div><div>Matt</div><div> </div></div></div>