<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Part 5: Patterns and Use Cases on Designing Network Automation at Scale</title><link>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/</link><description>Recent content in Part 5: Patterns and Use Cases on Designing Network Automation at Scale</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Wed, 19 Aug 2026 14:10:38 +0200</lastBuildDate><atom:link href="https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/index.xml" rel="self" type="application/rss+xml"/><item><title>15 - Closed-Loop Automation</title><link>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/15-closed-loop-automation/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/15-closed-loop-automation/</guid><description>&lt;h1 id="15-closed-loop-automation">15. Closed-Loop Automation&lt;a class="anchor" href="#15-closed-loop-automation">#&lt;/a>&lt;/h1>
&lt;p>The content network had thirty points of presence scattered across the globe, and every one of them reached its users the same way: over the public internet, through a handful of ISPs. Usually three, sometimes four (plus a handful of local peerings). Some were global Tier 1 transit; some, in regions that offered nothing better, were regional local providers. Under normal operations, each point of presence spread its users across all of its ISPs at once, because it needed every one of them to carry the traffic it saw, and &lt;a href="https://designingnetworkautomation.com/glossary/#bgp" class="glossary-term" title="The standardized exterior gateway protocol used to exchange routing information between autonomous systems on the Internet.">Border Gateway Protocol (BGP)&lt;/a> decided which users rode which ISP, with the usual local-preference values and community tags.&lt;/p></description></item><item><title>16 - Self-Healing Networks</title><link>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/16-self-healing-networks/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/16-self-healing-networks/</guid><description>&lt;h1 id="16-self-healing-networks">16. Self-Healing Networks&lt;a class="anchor" href="#16-self-healing-networks">#&lt;/a>&lt;/h1>
&lt;p>At 09:40 on a weekday, one of the Amsterdam point of presence&amp;rsquo;s ISPs started to go bad. Not down, bad. Somewhere inside that ISP&amp;rsquo;s network, well past the peering point, something began degrading the flows that crossed it. At Amsterdam&amp;rsquo;s edge nothing looked wrong: the &lt;a href="https://designingnetworkautomation.com/glossary/#bgp" class="glossary-term" title="The standardized exterior gateway protocol used to exchange routing information between autonomous systems on the Internet.">Border Gateway Protocol (BGP)&lt;/a> session stayed up, no BFD session dropped, the interface counters showed no loss, the running configuration matched intent exactly, and the closed loop from &lt;a href="./15-closed-loop-automation.md">Chapter 15&lt;/a> reported no drift. By every signal the network owned, that ISP was healthy.&lt;/p></description></item><item><title>17 - Autonomous Networks</title><link>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/17-autonomous-networks/</link><pubDate>Sat, 18 Jul 2026 00:00:00 +0000</pubDate><guid>https://designingnetworkautomation.com/series/part5-patterns-and-use-cases/17-autonomous-networks/</guid><description>&lt;h1 id="17-autonomous-networks">17. Autonomous Networks&lt;a class="anchor" href="#17-autonomous-networks">#&lt;/a>&lt;/h1>
&lt;p>The traffic optimizer was supposed to save money. The network&amp;rsquo;s ISPs did not all cost the same; at many points of presence one provider was roughly 30% cheaper per bit than the others, and most nights the network ran well under capacity. So the team added an optimizer that re-planned, during the low-traffic window, how each point of presence spread its users across its ISPs, shifting more of them onto the cheaper providers wherever the paths were good enough. It worked. The monthly transit bill dropped, and for some weeks nothing went wrong.&lt;/p></description></item></channel></rss>