[sdnog] using RIPE atlas to check which DNS root your resolver prefers.

[Nishal Goburdhan]

On 08 Jan 2015, at 09:52, tariq198487 <tariq198487 at hotmail.com> wrote:

> To be clear we only need to exclude E-root prefixes from the police which means:
> 1- No added BGP commuinty 
> 2- Allow operators customers to access E-root via SIXP

no, that's not correct...
what you need, is for the IXP to not influence your routing policy;  because an IXP is just meant to move your traffic, and not influence how you choose to send it, right?  

if you - as the end-user-ISP choose not to send particular prefixes to your end client (we were using ET as an example earlier) then that's -your- choice, as a network, and -you- should have ways to determine how to deal with that choice that -you- are making.  and, because it's -your- (the ISP) network, and you have a direct contractual relationship with your client, -you-, the ISP want to have control of this.  

here are some scenarios for you to think through: 
- what if a new service becomes available at SIXP;  you should simply want the IXP to send you this prefix, and -you- choose to make it available to your clients or not, based on the service that they have contracted to you for.  and you should be able to apply that policy yourself, and not have to contact the IXP/the other network/ santa-claus/... to do this.   (this is why BGP policy is so cool to play with, and why we try to teach use of BGP communities...)

- what are you selling to your client?  surely you are selling IP transit, which, if i remember, means access to all parts of the internet that you know about?  so here, you have a client -paying- you (transit is not a free service, right? :-)) for the privilege of you carrying their packets to as many networks and as far as you can.  do you now consider sudan to be part of the global internet?  so why are you excluding advertising sudanese network prefixes to your client?   better yet - why are you asking the IXP to do this for you? 

if, for some silly reason, the contractual relationship between you and the client was -not- to include sudanese network prefixes then you can easily filter these outbound to your client, right?   again, it's a relationship thing between you, the ISP, and -your- client, so you (should) control this.  

- if, for some reason, the contractual relationship to your client is -not- to include sudanese prefixes, i have to ask ... why would you do this ??    this is Not A Good Thing! (one of) the value(s) of an ISP is your ability to shorten the path to the internet for your clients.  because by offering these shorter (and hopefully faster) paths to the internet (in this case, the part of the internet that works in sudan), you increase the likelihood that your client will use your service, and not a competitor's (it should be obvious why this is good ;-)).  if you can accept that this (making the path to the 'net quicker and shorter) is a good thing, then, in the long term, you will build infrastructure to support this better.  that infrastructure will be in the form of additional peering (remember, you want to make your network faster, and the path to other networks "shorter") and this infrastructure building you'll undertake, is good for the internet because the 'net becomes more meshed, and more resilient.   (and also, faster...).   

- let's assume that you could leverage your geographic location, and build and sell access across your infrastructure to the landlocked countries around you.  would you still exclude your peering routes when you promise to connect these nations to the internet?   :-)

i could go on and on .. :-)   but i think you get my point...

otoh, if your organisational definition of "transit" excludes routes learned from your peers, then, to paraphrase a good friend of mine, i encourage all my competitors to run their networks like this...

--n.