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 


 





 
      

_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to