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

Tarig Yassin tariq198487 at hotmail.com
Mon Jan 19 12:56:23 SAST 2015


>i think we're talking about many different things here, so let's be specific.  right now, the SIXP is adding +no-export, and +prepends >to prefixes advertised at the SIXP.  i contend that this is a bad thing;  i think i've explained why, in earlier messages to the list.  do >you think this is a good thing, and if so, can you explain why?  (this is an open question, and not just posed to tariq).   note:  we >have still to hear from the SIXP why this is in place, and/or the technical benefit that it brings, vs. allowing ISPs to manage their >own traffic control principles.

I am totally Agree with you, may be you miss-understood my point. I mean by Controlling is to 1- manage IXP devices 2-  monitor the traffic 3- Inform ISPs when the peering traffic leak out.


-- 
Tarig Yassin

> From: nishal at controlfreak.co.za
> Date: Sun, 11 Jan 2015 13:18:23 +0200
> To: sdnog at sdnog.sd
> CC: admin at sixp.sd; murtada.makki at visionvalley.net
> Subject: Re: [sdnog] using RIPE atlas to check which DNS root your resolver	prefers.
> 
> On 11 Jan 2015, at 11:57, Tarig Yassin <tariq198487 at hotmail.com> wrote:
> > 
> > >i could go on and on .. :-)   but i think you get my point...
> > 
> > no need, you made your point very clear, which the control should be for ISPs not IXP.
> 
> :-)
> 
>  
> > >otoh, if your organisational definition of "transit" excludes routes learned from your peers,
> > you know that peer is free of charge for ISPs but customers still paying as they need ISPs to carry thier traffic even within Sudan.
> 
> yes that's mostly the same the world over, btw.  here's a reference for you - in 2011, PCH conducted a survey of 142,000 peering agreement globally that showed that "that 99.5% of interconnection agreements are concluded without a written contract".   ie.  free peering.  
> read more here:  http://dx.doi.org/10.1787/5k918gpt130q-en	
> 
> but i think you missed the part about my post where i said that when you sell IP services to a customer, you sell them access to your network's reach.  that's made up of:
> * your network
> * your customers
> * your peers
> * your transit providers
> 
> don't confuse this with peering.  when you peer with another network, you send them just:  
> * your network
> * your customers
> 
> to your peers at the SIXP, you'd advertise just your network+customers. and*not* your other peers and transit.   but in your case, to your *customer* in ET, you *should* advertise what your network thinks is the whole internet;  ie. the whole bang lot, including what's in sudan...  right?    :-)
> 
>  
> > This is 1st time we are discussing the change of the setup since the SIXP has been founded, I think it will be better if we include Murtada (the one who technically build the SIXP) on the communication.
> 
> it's a free, open, and unmoderated mailing list  (and thanks for running this;  you know who you are!)
> i'd encourage all operators to join...
> 
>  
> > but let me think, it is not bad to have someone to monitor and control (does not include Community tagging) the Peering traffic, because right now ISPs are only focusing on Transit traffic.  
> 
> i think we're talking about many different things here, so let's be specific.  right now, the SIXP is adding +no-export, and +prepends to prefixes advertised at the SIXP.  i contend that this is a bad thing;  i think i've explained why, in earlier messages to the list.  do you think this is a good thing, and if so, can you explain why?  (this is an open question, and not just posed to tariq).   note:  we have still to hear from the SIXP why this is in place, and/or the technical benefit that it brings, vs. allowing ISPs to manage their own traffic control principles.
> 
> your comment about transit traffic is probably true;  you know more about the SD traffic patterns than i do, but, i can guarantee you, that while you believe that this is true, and while the operators still build and work from this premise, then it's going to take you a much, much longer period of time to get your "local" traffic to be more relevant.  and, i think we all agree that working to get your "local" traffic relevant;  having more content locally, and having faster, cheaper, more reliable, locally hosted-and-created content is in the best interests of your community, right?     
> 
> 
> > What I'm trying to say that if we move the control to ISPs I'm afraid that national peering will be ignored by ISPs then the project will die. 
> 
> can you explain why you think that?   i, for one, don't agree with you, and there are 142,000+ peering agreements worldwide that say otherwise...
> for full disclosure:  i also speak with some bias;  you might remember that i have my hands involved in the IXP in JNB an CPT, where "control" of the traffic is given complete to the ISPs and we don't seem to have this issue either...
> (the other part about control and monitoring relates to lawful intercept.  that's still very possible at layer-2, but since i'm not sure if that's what your talking about i won't write more on that here)
> 
> i'll re-write what i think is best for you (SIXP) here, very simply: 
> - immediately:  remove the unneeded (and harmful) prepend and no-export that the SIXP is tagging, after letting peers know you are doing this.   this whole thread, is about the damage that this hitherto unexplained policy is doing to your local internet community, even if you don't realise it...
> 
> medium term:  
> - investigate layer-2 options as an IXP, only because it would mean it's cheaper and easier to run this in the long-run.
> 
> neither of those seems like a lot of work to me, tbh, but ymmv! 
> 
> --n.
> _______________________________________________
> Sdnog mailing list
> Sdnog at sdnog.sd
> http://lists.sdnog.sd/mailman/listinfo/sdnog
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sdnog.sd/pipermail/sdnog/attachments/20150119/54139eb1/attachment.html>


More information about the sdnog mailing list