North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Communities
* [email protected] (Iljitsch van Beijnum) [Tue 16 Oct 2001, 12:11 CEST]: >>> I've been thinking about other information that could be conveyed in >>> communities. For instance, bandwidth, delay and packet loss. > On Tue, 16 Oct 2001, Niels Bakker wrote: >> And generate a route flap every time a link gets used more or less? >> That would be suboptimal to say the least (the word `countereffective' >> seems more applicable to me). > Using dynamic data for this is not going to work in BGP, so this would > have to be static information (hm, packet loss is not too static, > hopefully). Indeed. > Static system-derived or configured information would already help a lot. > You can then easily select the route with the highest potential bandwidth > or the lowest speed-of-light delay, without the need to know a lot about > the internals of a transit network. > > Introducing "metrics" like this like this is not contrary to BGP design > philosophy: the way in which an AS selects the best route is not defined > in the RFC and the length of the AS path is certainly not the best > possible criterion. Setting communities based on a prefix's entry point into an ASN is doable with today's technologies (slight understatement). What's needed besides a standard numbering scheme for those communities is a way in all routers to route packets not merely destination-based but also based on a community set by the customer advertising the prefix to its upstream provider. As already noted, currently communities are mostly used to control advertisements of one's announcements by upstream providers, and not for outbound routing, which Example: Customer A has a connection to upstream B and speaks BGP with B. B as two different paths to C: one cheap and slow, one fast and expensive. (This seems to be a business opportunity - devise lines that are both cheap and fast.) Now B can set communities on routes received from C based on where a certain prefix was received. If they overlap, however, only the best route out of the two will be passed on to customer A. If this obstacle is overcome, A still faces the problem of getting B to discern between packets meant for either exit point to C. B could reengineer its network to basically exist of two separate entities (a cheap one and an expensive one) and let customers like A to connect to both, or extend all its routers to have a pre-prefix source+destination routing table entry to decide where to send packets. This seems to need quite some engineering work. :-) Or A could buy B and do it themselves. On a side note, A's possibilities of influencing inbound routing decisions - given that B acts on communities set by A, like `Prepend own ASN a few times before sending over just this link' or `Don't announce to D at all' - are already technically possible. Frankly, if I were B I'm not sure I'd be all that happy with customers influencing my routing decision process. They hand me their packets (or not); that should be it. Regards, -- Niels.
|