Re: [sidr] [Idr] operator inputs -- route leak solution

It seems a reasonable approach as long as it's kept as simple as described here.

Regards,
Neil.

> On 21 Mar 2017, at 18:00, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrote:
> 
> Inviting comments especially from GROW WG folk (network operators). 
> Please look at this and address the question posed at the end. Thank you.
> 
> The most common form of route leak occurs when multi-homed 
> customer AS-C receives a route from its transit provider AS-A
> and leaks it to another transit provider AS-B.  
> [RFC 7908  https://tools.ietf.org/html/rfc7908  ]
> 
> Customer AS-C is often the single point of failure.
> AS-A and AS-B may be doing intra-AS community tagging etc. 
> perfectly well to prevent route leaks, but AS-C does not and ends up leaking.
> The leaked route propagates via AS-B to the rest of Internet 
> due to prefer customer route policy.
> (Example: Google/Hathway/Airtel leak -
> https://bgpmon.net/what-caused-the-google-service-interruption/   
> see many more examples in RFC 7908 )
> 
> A solution component for this has long been discussed in 
> SIDR/GROW/IDR and well documented in IDR (see Section 4) 
> ( https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06  ). 
> The solution involves AS-A setting a field (in an optional transitive attribute)
> in BGP update to indicate that 
> (1) it is sending the route to a customer AS (or lateral peer), and 
> (2) the route SHOULD be considered a leak if subsequently received
> from a customer or a lateral peer.
> This is one component of the overall solution.
> It has been presented and discussed and I believe accepted
> in SIDR/IDR/GROW over the last few years (at least since 2014).
> 
> Question: 
>> From an operator point of view,
> are you willing to place a piece of relationship info (as stated above)
> in the BGP update for the significant gain of a route leak solution
> that works well to detect/stop route leaks that do happen,
> and prevents single point of failures in incremental/partial
> deployment scenarios?
> 
> Sriram 
> 
> P.S. There is already immense BGP-derived public data out there on AS peering relations:
> 
> http://as-rank.caida.org/?mode0=as-info&mode1=as-table&as=3356&data-selected-id=39 
> 
> http://bgp.he.net/AS7018#_graph4
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr