<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 1:59 PM 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 Tue, Oct 11, 2022 at 1:15 PM Matthew Petach <<a href="mailto:mpetach@netflight.com" target="_blank">mpetach@netflight.com</a>> wrote:<br>
> Wouldn't that same argument mean that every ISP that isn't honoring<br>
> my /26 announcement, but is instead following the covering /24, or /20,<br>
> or whatever sized prefix is equally in the wrong?<br>
><br>
> What makes /24 boundaries magically "OK" to filter on,<br>
<br>
Hi Matthew,<br>
<br>
/24 is the consensus filtering level for Internet-wide routes and it<br>
has been for decades. It became the consensus as a holdover from<br>
"class C" and remains the consensus because too many people would have<br>
to cooperate to change it. Indeed, a little over a decade ago some<br>
folks tried to change it to /19 and then /20 for prefixes outside "the<br>
swamp" and, well, they failed. Likewise, more than a few folks<br>
announce /26's to their immediate transit providers and they simply<br>
don't move very deep into the system -- nobody has any expectation<br>
that they will.<br></blockquote><div><br></div><div>Yes, I know.  I was there when smd was pointing out the arbitrary lines </div><div>being drawn in the sand, and decided to draw his own line.  The first salvo </div><div>was fired in 1996, with a customer complaining their /24 wasn't being </div><div>accepted by everyone, leading to a *very* long chorus of people chiming </div><div>in with different thoughts on where the line could and should be drawn:</div><div><a href="https://archive.nanog.org/mailinglist/mailarchives/old_archive/1996-01/msg00306.html">https://archive.nanog.org/mailinglist/mailarchives/old_archive/1996-01/msg00306.html</a></div><div><br></div><div>My point is that it's not a feature of BGP, it's a purely human convention, </div><div>arrived at through the intersection of pain and laziness.  </div><div>There's nothing inherently "right" or "wrong" about where the line was </div><div>drawn, so for networks to decide that /24 is causing too much pain, </div><div>and moving the line to /23 is no more "right" or "wong" than drawing </div><div>the line at /24.  A network that *counts* on its non-connected sites </div><div>being reachable because they're over a mythical /24 limit is no more </div><div>right than a customer upset that their /25 announcements aren't being </div><div>listened to.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> To wrap up--I disagree with your assertion because it depends entirely<br>
> on a 'magic' /24 boundary that makes it OK to filter more specifics smaller<br>
> than it, but not OK to filter larger than that and depend instead on covering<br>
> prefixes, without actually being based on anything concrete in BGP or<br>
> published standards.<br>
<br>
Got any better reasons besides disliking the consensus?<br></blockquote><div><br></div><div>Absolutely.</div><div><br></div><div>Let BGP work as it's supposed to work.</div><div><br></div><div>If there's a covering prefix being announced, according to BGP, it's a valid pathway to reach </div><div>all the prefixes contained within it.  If that's not how your network is constructed, don't </div><div>send out your announcements that way.  Only announce prefixes for which you *do* have </div><div>actual reachability.   </div><div><br></div><div>Consensus isn't a guarantee.</div><div><br></div><div>"SHOULD" in an RFC is still just a recommendation, and not following  </div><div>it isn't an error.</div><div><br></div><div>If you're worried about memory in your routers, and you decide to move the </div><div>line from /24 to /23 or /22, that's not an error, that's not breaking BGP, that's</div><div>just moving an arbitrary line that was set by stressed and busy network </div><div>engineers nearly 3 decades ago.</div><div><br></div><div>If a network engineer feels the need to filter out longer prefixes to deal with </div><div>a memory shortage in their devices, that's their decision; my anecdote was </div><div>to point out you'll likely run into people who don't understand BGP very well, </div><div>and mistakenly think there's some magical guarantee that /24 or shorter </div><div>prefixes will always work, while longer prefixes won't.  And that's just not </div><div>at all true.  BGP simply looks for the longest match in the available table,</div><div>whatever that might be, and uses whatever the "most specific" match is, </div><div>no matter how long or short it might be.  Networks should always keep </div><div>that in mind when announcing prefixes; don't announce a prefix you aren't </div><div>prepared to handle the traffic for, no matter what traffic engineering tweaks </div><div>you might be attempting to steer traffic away.  You should always assume </div><div>that for whatever reason, if you announce a prefix, there's a good chance </div><div>that other networks will see that as the best match and make use of it.</div><div>If you don't want it used for traffic, don't announce it.</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div></div></div>