North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Regarding global BGP community values

  • From: Alex P. Rudnev
  • Date: Tue Oct 12 08:01:25 1999

> One problem is potential significant growth in routing and forwarding
> tables sizes, which was one of the primary drivers for aggregation
> techniques in the first place.  If this is a problem, the provider can
> always opt to not accept the more specifics from the peer.
The growth itself do not cause the problems, but in conjunction with the
poor router implementation (which cause 60,000 routes to use 30 MB of the
RAM - that means 500 bytes for every prefix -:) and numerous memory leaks
in the router implementation cause the problem. If we look around, we'll
see existing computers (including embedded ones) have not CPU and memory
problems, and all problems we see with the routers are mainly caused by
the bad implemented text.

On the other hand, you are right if you speak about the stability or
loop-less routing - extra specifics cause a lot of instability.

But it's slightly out of this issue. 

Talking about the global transitive communities, we should mention one
existing problem. Communities are used now for boths internal and global
control (I make my peering announces as 2118:11, I mark those announces
which should not be advertised to the other peers, as 2118:12, for
example, TELIA use communities widely, and so on). On the other hand, we
have not any mechanism how to filter communities out when we advertise
prefixes - in case of CISCO, I can -
- don't send communities at all
- set new communities instead of existing
- add new communities to the existing

This is the chance to see the growing number of useless communities if we
introduce the set of transitive ones.

And this make some mechanism of _community filtering_ very desirable.
Note, this days we see the turn from the AS-based routing to the
community-based and MED-based, because:
(1) AS-es themself do not provide any protection against the mistakes -
they are not used in the routing; this cause prefix-based filtering very
desirable (at least at the downstream links);
(2) AS list growth quickly, and (even if we build access lists by the RIPE
or RA-DB or <ANY>...-DB data base) we can't maintain such big pieces of
(3) AS-base control restricts the main principle of the effective routing
control - _analyze everything careful, but ONCE; then add your labels and
use this labels_. The communities are one type of such _labels_.

And, if we are facing to the some future BGP-5 protocol, and remembering
about the compatibility, the new terms _local community, global community,
transitive communities_ (replace _community_ to any other world, if you
want) became very desirable. Note - we just have _PRIVATE-AS_ and some
ways to filter them out; now it's time to have PRIVATE_COMMUNITIES as

> The other problem I can think of at the moment, which is likley more
> of a concern for most folks, is wrt providers leaking more specifics,
> either via BGP customers, or directly.  This could be a concern
Note - it's often when we leak such specifics _on purpose_. For example,
see 144.206/16 - we should leak some specifics from this block to make
routing _correct_ (some branchs have commercial-quality access, some
branches have not). 

On the other hand, the more you restrict allowed (in the Internet)
prefixes, the less effectively you does use address space. This is the
stick with the two ends. I believe we should see more and more /20, /21
and even /24 prefixes in the network in the next few years - because the
CPU and memory could be increased easily, but the address space can not.

Alex (Roudnev).

> because perceived "clue" of a peer, as well as simple errors in
> configurations, etc...  This can be addressed to some extent by
> providing drafts that discuss these issues.
> Then, there are the problems those accepting MEDs have regarding a
> networks ability to associate intelligent values with MEDs, or provide
> a *only* reasonable number of prefixes (versus "more specifics"
> expanding to thousands of /24s and longer).  Of course, a large piece
> of this would be reliant upon a decent IP allocation plan that at
> worst provides router-based aggregates for more specifics, and
> preferrably PoP-based.  This is difficult, of course, with all the
> older networks, acquisitions, etc...
> Anyways, if a set of transitive communities were defined to provide a
> safety net that could catch the more specifcs, or some other mechanism
> were created to provide the same capabilities, I'd be interested.
> I believe AboveNet and a few others actually have experience with
> accepting more specifics, and since I missed the BOF in Montreal (and
> no information is available on the web server as of yet?), I'd be
> interested in hearing what folks oinions are regarding this.
> -danny