nanog mailing list archives

Re: Standard for BGP community lists


From: Joe Provo <nanog-post () rsuc gweep net>
Date: Tue, 20 Jul 2010 23:05:22 -0400

On Tue, Jul 20, 2010 at 09:34:40AM -0600, Danny McPherson wrote:

On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote:

On (2010-07-19 23:45 -0500), Brad Fleming wrote:

Hey,

9999:9999 for local rtbh
9999:8888 for local + remote rtbh

I didn't have much reason for selecting 9999 other than it was easy
to identify visually. And obviously, I have safe-guards to not leak
those communities into other networks.

I would recommend against using other public ASNs for internal signalling,
ASN part should be considered property of given ASN. AS9999 might want to
use 9999 to signal particular source where route was learned and your
customer might want to do TE with it. Now you must delete them on ingress
and rob your customers of this possibility.

IMO, any reasonable routing policy would reset all BGP communities on 
ingress (and MEDs for that matter), whether from a customer or peer, 
as transiting stuff that has varying semantic interpretations, unknown 
propagation scope, or relying on others to act on non-mandatory 
not-well-known communities that may not even be propagated in some 
BGP configurations as a matter of default behavior, is a simple recipe 
for nondeterministic behavior, more senseless path attribute tuples in 
the global routing system, resulting in less efficient BGP update packing, 
and may even result in security issues. 

We're still seeing buffer overflows, so people obviously fail to 
generalize about sanitizing input.  One would think the need is 
more obvious for signalling protocols, but expecting people to 
DTRT often results in disappointment.

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE


Current thread: