<div dir="ltr">Agree with Mike on looking at communities first. Depending on the provider, that could be a very nice tool, or completely worthless. <br><div><br></div><div>For your planned idea on smaller "regional" nodes, you could do something like :"default || ( customer && specific cities/states/regions/countries )" , d</div><div><br></div><div>I would definitely make sure you consider what your fallback options are in case of partitions as Bill mentioned in another reply. The less routes you have to start with the harder it gets though.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 5, 2020 at 9:19 AM Mike Hammett <<a href="mailto:nanog@ics-il.net">nanog@ics-il.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><div style="font-family:arial,helvetica,sans-serif;font-size:10pt;color:rgb(0,0,0)">Maybe instead of transit + 1, you use communities to just allow all customer prefixes, regardless of how deep they are. Obviously that community would need to be supported by that provider.<div><br></div><div><br></div><div>I've been wondering a similar thing for how to take advantage of the 150k - 250k hardware routes the CRS317 now has in v7 beta. That many routes should cover the peering tables for most operators, maybe even transit's customers.<br><br><div><span name="x"></span><br><br>-----<br>Mike Hammett<br>Intelligent Computing Solutions<br><a href="http://www.ics-il.com" target="_blank">http://www.ics-il.com</a><br><br>Midwest-IX<br><a href="http://www.midwest-ix.com" target="_blank">http://www.midwest-ix.com</a><span name="x"></span><br></div><br><hr id="gmail-m_434575936564534361zwchr"><div style="color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt"><b>From: </b>"James Breeden" <<a href="mailto:James@arenalgroup.co" target="_blank">James@arenalgroup.co</a>><br><b>To: </b><a href="mailto:nanog@nanog.org" target="_blank">nanog@nanog.org</a><br><b>Sent: </b>Thursday, June 4, 2020 10:00:51 PM<br><b>Subject: </b>Partial vs Full tables<br><br>





<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I have been doing a lot of research recently on operating networks with partial tables and a default to the rest of the world. Seems like an easy enough approach for regional networks where you have maybe only 1 upstream transit and some peering. </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I come to NANOG to get feedback from others who may be doing this. We have 3 upstream transit providers and PNI and public peers in 2 locations. It'd obviously be easy to transition to doing partial routes for just the peers, etc, but I'm not sure where to
 draw the line on the transit providers. I've thought of straight preferencing one over another. I've thought of using BGP filtering and community magic to basically allow Transit AS + 1 additional AS (Transit direct customer) as specific routes, with summarization
 to default for the rest. I'm sure there are other thoughts that I haven't had about this as well....</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
And before I get asked why not just run full tables, I'm looking at regional approaches to being able to use smaller, less powerful routers (or even layer3 switches) to run some areas of the network where we can benefit from summarization and full tables are
 really overkill. </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div>
<div id="gmail-m_434575936564534361Signature">
<div id="gmail-m_434575936564534361divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-serif">
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<b>James W. Breeden</b></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<i><span style="font-size:10pt">Managing Partner</span></i></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<i> </i></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<b><img width="158" height="96" id="gmail-m_434575936564534361x_Picture_x0020_1" alt="logo_transparent_background" style="width: 1.6458in; height: 1in;"></b></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<b><span style="font-size:10pt;color:rgb(192,0,0)">Arenal Group:</span></b><span style="font-size:10pt;color:rgb(192,0,0)"> Arenal Consulting Group | Acilis Telecom | Pines Media</span></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<span style="font-size:10pt;color:rgb(127,127,127)">PO Box 1063 | Smithville, TX 78957</span></p>
<p style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif;color:rgb(33,33,33)">
<span style="font-size:10pt">Email: <a href="mailto:james@arenalgroup.co" target="_blank"><span style="color:windowtext">james@arenalgroup.co</span></a> | office 512.360.0000 |
<a href="http://www.arenalgroup.co/" target="_blank"><span style="color:windowtext">www.arenalgroup.co</span></a></span></p>
</div>
</div>
</div>


</div><br></div></div></div></blockquote></div>