On Fri, 24 Aug 2018 at 13:15, Andy Davidson <[email protected]> wrote: > > Hi, > > On 17/08/2018, 12:21, James Bensley <[email protected]> wrote: > > For example - AS51551, I want to peer with them so I want their AS-SET > > so that I can accept their routes, and all downstream customer routes. > > There’s a couple of subtleties missing from existing replies to the comments > in the thread you started, so I hope it’s ok to make some comments now. > > Firstly, the Internet thanks you for your secure approach to routing > configuration by filtering based on their IRR data. For configuring prefix > filtering of your peers, in order to limit the effect of routing leaks on end > user enjoyment and security. You are a knight of the peering realm and my > horse is forever at your disposal. > > Secondly, the AS-SET is something that the peer should communicate to you, > rather than something that you should ‘detect’. It is possible that one peer > may wish to indicate that they wish to send you different prefixes to what > they send to someone else. For example they may send their global customer > routes to knights of the peering realm like you, so you should use > AS-65534:GLOBAL, whereas gutterick serfs should expect the regional or local > prefixes and therefore a different filter. Or perhaps there is a > product/partner relationship that means they want to signal deaggregates or > additional transited networks to you which they do not want to send to other > peers. The point I am trying to make is that your peering partner should > indicate the as-macro that they wish you to filter against in your BGP setup. > That said, it’s reasonable to expect that if you are not negotiating > anything special to a peer’s usual behaviour you should get the peer’s usual > as-macro, but again they should explicitly communicate that rather than have > you detect it. The usual place to explicitly communicate your peering > preferences as a peering network is peeringdb and Job has made this point > already in this thread. > > Lastly, remember RPKI, especially if you want to build filters containing > prefixes being originated by networks in regions where there is poor IRR > adoption but more wide RPKI adoption. > > > Best wishes, > Andy
Thanks for the response Andy, its appreciated. Re; RPKI - I'm on the case ;) Cheers, James.
