[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

intra-AS messaging for route leak prevention

On Mon, Jun 06, 2016 at 05:54:18PM +0200, Job Snijders wrote:
> On Mon, Jun 06, 2016 at 11:41:52AM +0000, Sriram, Kotikalapudi (Fed) wrote:
> > I am a co-author on a route-leak detection/mitigation/prevention draft 
> > in the IDR WG in the IETF:
> > https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-03  
> > 
> > Question: Are there other means of conveying this information 
> > in common use today (i.e. for prevention of route leaks)?  
> For instance AT&T and NTT agreed (through email) that there should be no
> intermediate networks between 2914 & 7018, therefore NTT blocks
> announcements that match as-path-regexp '_7018_' on any and all eBGP
> sessions, except the direct sessions with 7018. NTT calls this concept
> "peerlocking".
> I'll cover this approach at the upcoming NANOG meeting in Chicago:
> https://www.nanog.org/meetings/abstract?id=2860
Dropping unexpected AS vectors was frequently used in the 1990s 
by folks, especially in the context of seeking to ensure traffic 
intended for direct/private interconnections stayed on them. I 
know some folks would also just filter "big networks" (to avoid 
that marketing term) from other peers to sidestep the impact of 

It doesn't fit for all peers/networks (eg content which will 
seek alternate paths around congestion), but if you can fold 
it into your automation it is helpful.



        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG