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) > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/idr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
