On Fri, 9 Sept 2022 at 09:31, Crist Clark <cjc+na...@pumpky.net> wrote:
> As I said in the original email, I realize router IDs just need to be > unique in > an AS. We could have done random ones with IPv4, but using a well chosen In some far future this will be true. We meet eBGP speakers across the world, and not everyone supports route refresh, _TODAY_, I suspect mostly because internally developed eBGP implementations and developers were not very familiar with how real life BGP works. RFC6286 is not supported by all common implementations, much less uncommon. And even for common implementations it requires a very new image (20.4 for Junos, many are even in 17.4 still). So while we can consider BGP router-id to be only locally significant when RFC6286 is implemented, in practice you want to be defensive in your router-id strategy, i.e. avoid at least scheme of 1,2,3,4,5,6... on thesis that will be common scheme and liable to increase support costs down the line due to collision probability being higher. While it might also add commercial advantage for transit providers, to have low router-id to win billable traffic. > And to get even a little more specific about our particular use case and > the > suggestion here to build the device location into the ID, we're > generally not I would strongly advise against any information-to-ID mapping schemes. This adds complexity and reduces flexibility and requires you to know the complete problem ahead of time, which is difficult, only have rules you absolutely must have. I am sure most people here have experience having too cutesy addressing schemes some time in their past, where forming an IP address had unnecessary rules in them, which just created complexity and cost in future. If you can add an arbitrary 32b ID to your database, this problem becomes very easy. If not, it's tricky. -- ++ytti
