|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Regarding global BGP community values
> > 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 configuration; (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 well. > 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
|