Maximilian (Max) Wilhelm is a Holistic (Network) Automation Evangelist, trying to bring software engineering methods to network automation, and helping to overcome the vendor lock-in.
Starting off with Linux and Open Source in the early 2000s, he developed a weakness for networking, IPv6 and routing which lead to him being an avid Open Source enthusiast ever since. As a result he is a co-founder, maintainer, and contributor of Bio-Routing and ifupdown-ng, and a regular speaker at Open Source and networking conferences. Max also takes part in the organization of the Free and Open Source Software Conference (FrOSCon) and founded the FrOSCon Network Track (https://myfirst.network). Furthermore he’s a Co-Host of the virtualNOG.net meetings (and would love to hear your ideas for further topics 😊).
He's currently working as a Network Automation Engineer at Cloudflare and does a little moonlighting as Senior Infrastructure Consultant. His second calling is acting as the lead architect behind the widely automated Freifunk Hochstift community network where he got his hands dirty with ifupdown2 as well as ifupdown-ng, VXLAN, Linux VRFs, BGP and OSPF, infrastructure automation with Salt Stack and is afraid of SDNs ever since.
In the residual spare time he likes playing piano and the organ and doing wood work to get away from IT.
Following some discussion at RIPE84Fredy Kuenzler and I put forward an Internet Draft to define a well-known advisory BGP community to denote prefixes are used for Anycast.
To quote from the abstract of the ID:
In theory routing decisions on the Internet and by extension within ISP networks should always use hot-potato routing to reach any given destination. In reality operators sometimes choose to not use the
hot-potato paths to forward traffic due to a variety of reasons, mostly motivated by traffic engineering considerations. For prefixes carrying anycast traffic in virtually all situations it is advisable to stick to the hot-potato principle. As operators mostly don't know which prefixes are carrying unicast or anycast traffic, they can't differentiate between them in their routing policies.
To allow operators to take well informed decisions on which prefixes are carrying anycast traffic this document proposes a well-known BGP community to denote this property.
You can find the lastest version of the draft at: https://datatracker.ietf.org/doc/draft-wilhelm-grow-anycast-community/
A lot of things have been added and improved since the last talk at DENOG10.
We want to take this opportunity to provide an update on what we have done on and what our agenda looks like.