Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On 3/15/10 2:42 AM, Tony Li wrote: Interestingly, I'm not sure that this is worth fixing. Most BGP implementations store a copy of all of the best paths that they've received from neighbors. They then compute the 'best path' amongst this set and advertise it appropriately. Truly fixing this problem would require that an implementation retain state on a per-neighbor basis about which attributes were advertised (and in some cases, what changes to what attributes were performed). Further, the implementation would still have to effectively compute the update because output policy could have a substantial impact on the result. Thus, the question really becomes whether transmitting the update and receiving it is more expensive than additional filtering in the sender. Given that bandwidth is 'free', the tradeoff is now between the sender with additional state and processing, or the processing in the receiver. Note that the receivers task is to parse the update, realize that there is, in fact, no change, and not do anything. Indeed, you're trading systemic state for implementation optimizations, in lots of places where issues such as this are amplified. 40% duplicates in a system today ma not be a problem, however, if prefix, origin, and path validation techniques are employed down the road in a secure routing protocol built on the current model, and every one of those updates have to be processed, I suspect at some point senders will be a bit more conservative in what they send. -danny ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Indeed, you're trading systemic state for implementation optimizations, in lots of places where issues such as this are amplified. 40% duplicates in a system today ma not be a problem, however, if prefix, origin, and path validation techniques are employed down the road in a secure routing protocol built on the current model, and every one of those updates have to be processed, I suspect at some point senders will be a bit more conservative in what they send. No necessarily - the receivers can cache validation outcomes with reasoinbly efficient results. See http://www.potaroo.net/papers/phd/pam-2007/bgpcache.pdf for a study of this approach. One can also point out that an update that is a duplicate of what's already been accepted is irrelevant. Regardless of whether it has been validated or not. ;-) Tony P.s. Ok, small exception in the case where you're in the middle of transitioning from a non-validated world and you have accepted a non-validated path and just received a validated path. ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On 20/03/2010, at 8:40 AM, Tony Li wrote: Indeed, you're trading systemic state for implementation optimizations, in lots of places where issues such as this are amplified. 40% duplicates in a system today ma not be a problem, however, if prefix, origin, and path validation techniques are employed down the road in a secure routing protocol built on the current model, and every one of those updates have to be processed, I suspect at some point senders will be a bit more conservative in what they send. No necessarily - the receivers can cache validation outcomes with reasoinbly efficient results. See http://www.potaroo.net/papers/phd/pam-2007/bgpcache.pdf for a study of this approach. One can also point out that an update that is a duplicate of what's already been accepted is irrelevant. Regardless of whether it has been validated or not. I'm not sure I understand this Tony. What is in my mind when I read this is a counter case when a BGP speaker sees from a peer: advertise withdrawal advertise a dup of the previous advertisement withdrawal advertise a dup etc i.e. in this case the dups are not irrelevant, and in this case caching of previous validation outcomes would be beneficial. Geoff ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
top posting: it's my fault for not stating clearly -- Since Amund's msg said that - Surprisingly, as much as 40% of churn consists of duplicate announcements, which are unnecessary for correct protocol operation. I was merely offering one explanation for the cause of the observed duplicates. The least to say is that this is not RRG's job (hence the presentation was to GROW), even if worth fixing. Lixia On Mar 15, 2010, at 1:42 AM, Tony Li wrote: [Off topic warning...] we did a measurement study to understand the causes of such excessive duplicate announcements, the results are reported in the following paper: Investigating Occurrence of Duplicate Updates in BGP Announcements http://www.cs.ucla.edu/~jpark/dupbgp.pdf to be presented at PAM conference next month Interestingly, I'm not sure that this is worth fixing. Most BGP implementations store a copy of all of the best paths that they've received from neighbors. They then compute the 'best path' amongst this set and advertise it appropriately. Truly fixing this problem would require that an implementation retain state on a per-neighbor basis about which attributes were advertised (and in some cases, what changes to what attributes were performed). Further, the implementation would still have to effectively compute the update because output policy could have a substantial impact on the result. Thus, the question really becomes whether transmitting the update and receiving it is more expensive than additional filtering in the sender. Given that bandwidth is 'free', the tradeoff is now between the sender with additional state and processing, or the processing in the receiver. Note that the receivers task is to parse the update, realize that there is, in fact, no change, and not do anything. Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Toni, you are raising an interesting issue. However, if the sending routers do not check whether an update is duplicate, and if the receiving routers do not check whether an update is duplicate, don't we create a positive feedback loop? I mean, if a router X sends a duplicate update to N other peers, then each of those other routers can also generate duplicate updates sent to their own peers, creating a multiplicative effect. Of course there are several factors that would act to limit the dissemination of such updates, such as policy, but in principle the positive feedback is still there, right? Tony Li wrote: [Off topic warning...] we did a measurement study to understand the causes of such excessive duplicate announcements, the results are reported in the following paper: Investigating Occurrence of Duplicate Updates in BGP Announcements http://www.cs.ucla.edu/~jpark/dupbgp.pdf to be presented at PAM conference next month Interestingly, I'm not sure that this is worth fixing. Most BGP implementations store a copy of all of the best paths that they've received from neighbors. They then compute the 'best path' amongst this set and advertise it appropriately. Truly fixing this problem would require that an implementation retain state on a per-neighbor basis about which attributes were advertised (and in some cases, what changes to what attributes were performed). Further, the implementation would still have to effectively compute the update because output policy could have a substantial impact on the result. Thus, the question really becomes whether transmitting the update and receiving it is more expensive than additional filtering in the sender. Given that bandwidth is 'free', the tradeoff is now between the sender with additional state and processing, or the processing in the receiver. Note that the receivers task is to parse the update, realize that there is, in fact, no change, and not do anything. Tony -- Constantine -- Constantine Dovrolis | 3346 KACB | 404-385-4205 Associate Professor | Networking and Telecommunications Group College of Computing | Georgia Institute of Technology dovro...@cc.gatech.edu http://www.cc.gatech.edu/~dovrolis/ ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Hi Paul, Well, let's look at the flip-side for a moment. Imagine if there were /no/ growth in prefixes. Is that good? I think the answer clearly is no. No growth in prefixes implies no growth in the internet, implies no growth in revenue for those who make money from activities associated with attaching to the net. Actually, no growth in prefixes does not imply that there is no growth in the Internet. You can still add customers within existing prefix allocations and improve your addressing efficiency. Also, since you can grow the net very efficiently with even a tiny amount of prefix additions, it would seem like much, much, much slower growth would be acceptable to meet your reasonable request that the Internet keep growing. Let the data do the arguing. At the moment it's looking like BGP maybe is coping with growth just fine. I.e. we can not yet safely conclude there is an urgent scaling problem with internet routing (despite path-vector being known now to have some inefficient behaviours even when working as intended). First, no one is claiming that there is an imminent and urgent problem. What I feel that we've shown is that we have a long term systemic problem. Given that truly dealing with this issue does appear to require major amounts of time to deploy, it only seems reasonable to start dealing with it long before it becomes an urgent problem. Where's the data suggesting routing is or is going to run into problems? Not /fears/ that it will, but actual data. Please see my RAWS presentation. It shows that prefix growth exceeds the speedup that we can expect in DRAM. This in turn implies that BGP will take longer to converge at a given node when that node has to process the full table. Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mar 14, 2010, at 1:33 PM, Amund Kvalbein wrote: Folks, In this context, I think you might be interested in a measurement study that will be presented at INFOCOM this coming week. The focus of the study is BGP scalability with respect to churn rates. We have analyzed six years of Routeviews BGP update traces from four monitors in different tier-1 networks. Some of the main findings are that - BGP churn varies widely on many time scales, and cannot be understood through black-box statistical analysis. - The most severe churn experienced by these monitors are caused by mis-configurations and events that are local to the monitored AS. - Surprisingly, as much as 40% of churn consists of duplicate announcements, which are unnecessary for correct protocol operation. This figure has been pretty constant over our measurement period. we did a measurement study to understand the causes of such excessive duplicate announcements, the results are reported in the following paper: Investigating Occurrence of Duplicate Updates in BGP Announcements http://www.cs.ucla.edu/~jpark/dupbgp.pdf to be presented at PAM conference next month An earlier presentation can be found at http://www.cs.ucla.edu/~jpark/grow-5.pdf - After filtering out duplicates, local effects and anomalies caused by a few specific events, we find that there is an increasing trend in baseline churn over the past six years, but that this growth is quite modest, and much slower than the growth in the DFZ RIB size. The paper can be found at http://simula.no/research/nd/publications/Simula.nd.435 Comments are always welcome. Regards, Amund ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mar 14, 2010, at 10:17 PM, Paul Jakma wrote: On Mon, 15 Mar 2010, Robin Whittle wrote: I thought that you were arguing against the existence of the routing scaling problem, because in your first message in this thread, you wrote: However, it does not seem justified to say the current routing architecture has a scaling problem. Since I have difficulty understanding what you describe as your scribblings in a manner you agree with, If a person disagrees that a hypothesis has been proven, it does not of itself follow that the person believes the hypothesis has been disproven. You seem to exclude Insufficient evidence at this time to draw a conclusion from the set of valid views people may hold on a topic (as does the straw poll that led to me post). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Necessity hath no law. -- Oliver Cromwell it is interesting to watch this series of exchange between Paul and Robin:) One position states that we face serious routing scalability problem today. another position states that insufficient evidence exists today to support the above. If I take on a 3rd position: this debate seems a supporting evidence for what we discussed at Hiroshima meeting (see my presentation on behalf of the evolution solution team, http://www.cs.ucla.edu/~lixia/aggregation.pdf , slide 4), - Internet is big and diverse - routing scalability problem is not universal - Internet has no boss - no universal buy‐in, no flag day/year/decade Thus we need solutions that can be deployed by individual parties who need it, and can provide clearly identifiable returns (slide 5) Lixia ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Paul raises a critical point that IMO gets insufficient attention here... On Mar 15, 2010, at 3:35 AM, Tony Li wrote: Hi Paul, Well, let's look at the flip-side for a moment. Imagine if there were /no/ growth in prefixes. Is that good? I think the answer clearly is no. No growth in prefixes implies no growth in the internet, implies no growth in revenue for those who make money from activities associated with attaching to the net. Actually, no growth in prefixes does not imply that there is no growth in the Internet. You can still add customers within existing prefix allocations and improve your addressing efficiency. Point of clarification: *Existing* (aka incumbent) providers may be able to add additional customers under *existing* prefixes. It's not possible to assume anything beyond that without assuming facts not in evidence -- e.g., a widely adopted new architecture, and/or a widely adopted new addressing format (IPv6), and/or a widely adopted mechanism for redistributing IPv4 address space that is already allocated. The implication is that while this possibility may exist (for some), its existence doesn't matter (in general). Also, since you can grow the net very efficiently with even a tiny amount of prefix additions, it would seem like much, much, much slower growth would be acceptable to meet your reasonable request that the Internet keep growing. It seems that the problem of super-linear growth in demands on the routing system is one of (if not THE) most central issues motivating this exercise. And yet the ambiguous nature of this characterization is apparent even in draft-narten-radir-problem-statement-05.txt. Assuming that super-linear growth is driven by some combination of factors like (a) new routing service providers, plus (b) incremental address provisioning (i.e., post-CIDR IPv4 scarcity management), plus (c) new sites, plus (d) multihoming, plus (e) supplemental traffic engineering, ...any new architecture that solves this routing *inflation* problem, but in the process suppresses (a), or leaves (a) to be sorted out through exogenous mechanisms is quite likely to create the opposite problem. IMO, any network architecture that is inherently vulnerable to that other risk of routing system *deflation* -- i.e., the arbitrary rationing/structural exclusion of future aspiring routing service providers -- is unlikely to be widely adopted, and should be considered harmful, fatal. In short, that first factor -- new entrants into the routing services sector -- constitutes an upward-sloping growth line that *must* be sustained, no matter how effective or ineffective the new architecture is in eliminating the super-linear scalability problems caused by the other factors. Let the data do the arguing. At the moment it's looking like BGP maybe is coping with growth just fine. I.e. we can not yet safely conclude there is an urgent scaling problem with internet routing (despite path-vector being known now to have some inefficient behaviours even when working as intended). First, no one is claiming that there is an imminent and urgent problem. What I feel that we've shown is that we have a long term systemic problem. Given that truly dealing with this issue does appear to require major amounts of time to deploy, it only seems reasonable to start dealing with it long before it becomes an urgent problem. I would argue that the exhaustion of unallocated IPv4 represents a very imminent an urgent problem, for the same reason outlined above. Given current architecture and the current state of IPv6 deployment, (a) shares fate with the availability of unallocated IPv4. No doubt if (when) the existing mechanisms for sustaining (a) no longer work, other forces will come into play in response to the unmet demand (e.g., markets, regulation, piracy, etc.). But as a result, the base rate of new entry (a) will no longer be strongly influenced by technical scalability considerations -- and the collateral effects of those external forces could have additional, unpredictable effects on the deployability or other scalability benefits (ala b~e) of the new architecture. Where's the data suggesting routing is or is going to run into problems? Not /fears/ that it will, but actual data. Please see my RAWS presentation. It shows that prefix growth exceeds the speedup that we can expect in DRAM. This in turn implies that BGP will take longer to converge at a given node when that node has to process the full table. Tony I agree that premature obsolescence/abandonment and/or collapse is a real problem, but I think we should recognize that routing system inflation is just one (of at least two) paths that lead in that general direction. TV ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Sun, 14 Mar 2010, Tony Li wrote: Actually, no growth in prefixes does not imply that there is no growth in the Internet. You can still add customers within existing prefix allocations and improve your addressing efficiency. Hehe, My implicit assumption is that there's no significant change in allocation densities. :) Stuff like that generally seems to be an administive issue, so it's maybe unlikely it can be affected through routing changes. First, no one is claiming that there is an imminent and urgent problem. What I feel that we've shown is that we have a long term systemic problem. Given that truly dealing with this issue does appear to require major amounts of time to deploy, it only seems reasonable to start dealing with it long before it becomes an urgent problem. Please see my RAWS presentation. It shows that prefix growth exceeds the speedup that we can expect in DRAM. I remember reading that. This in turn implies that BGP will take longer to converge at a given node when that node has to process the full table. That's the thing though, the most recent data doesn't seem to show any evidence of things like that. If per-node convergence was taking significantly longer (in the scaling badly relative to prefix growth sense), then Sigma(per-prefix per-node convergence) should be similarly increasing by at least the same amount and BGP observers ought to be able to see that, and so the data should show it. Yet it doesn't seem to, right? Further, even if the growth issues only affected a certain subset of prefixes, surely there'd be side-band issues. I.e. processing problems with certain prefixes should adversely affect the processing of other prefixes being processed around the same time. I'm sorry for being such an arse with my scepticism, and I'll understand if people reply to me as if I'm half-wit, but if scaling is a problem surely it should be apparent in some data somewhere over the last decade+ that people have been worrying about it? Where's the smoking gun graph, based on real data, that shows the scaling problem? I'm somewhat willing to take your word as authoritative, but ideally we'd have graphs :). I stress again that, despite taking this contrarian view of the scaling problem, I still think the work here is very important! I just think this question must have a big impact on which classes of solutions are and are not viable. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: We don't understand the software, and sometimes we don't understand the hardware, but we can *___see* the blinking lights! ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mar 15, 2010, at 1:13 PM, Paul Jakma wrote: On Sun, 14 Mar 2010, Tony Li wrote: Actually, no growth in prefixes does not imply that there is no growth in the Internet. You can still add customers within existing prefix allocations and improve your addressing efficiency. Hehe, My implicit assumption is that there's no significant change in allocation densities. :) Stuff like that generally seems to be an administive issue, so it's maybe unlikely it can be affected through routing changes. First, no one is claiming that there is an imminent and urgent problem. What I feel that we've shown is that we have a long term systemic problem. Given that truly dealing with this issue does appear to require major amounts of time to deploy, it only seems reasonable to start dealing with it long before it becomes an urgent problem. Please see my RAWS presentation. It shows that prefix growth exceeds the speedup that we can expect in DRAM. I remember reading that. This in turn implies that BGP will take longer to converge at a given node when that node has to process the full table. That's the thing though, the most recent data doesn't seem to show any evidence of things like that. If per-node convergence was taking significantly longer (in the scaling badly relative to prefix growth sense), then Sigma(per-prefix per-node convergence) should be similarly increasing by at least the same amount and BGP observers ought to be able to see that, and so the data should show it. Yet it doesn't seem to, right? Do you have a write-up of this ? Regards Marshall Further, even if the growth issues only affected a certain subset of prefixes, surely there'd be side-band issues. I.e. processing problems with certain prefixes should adversely affect the processing of other prefixes being processed around the same time. I'm sorry for being such an arse with my scepticism, and I'll understand if people reply to me as if I'm half-wit, but if scaling is a problem surely it should be apparent in some data somewhere over the last decade+ that people have been worrying about it? Where's the smoking gun graph, based on real data, that shows the scaling problem? I'm somewhat willing to take your word as authoritative, but ideally we'd have graphs :). I stress again that, despite taking this contrarian view of the scaling problem, I still think the work here is very important! I just think this question must have a big impact on which classes of solutions are and are not viable. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: We don't understand the software, and sometimes we don't understand the hardware, but we can *___see* the blinking lights! ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mon, 15 Mar 2010, Paul Jakma wrote: Hehe, My implicit assumption is that there's no significant change in allocation densities. :) Oops, here I mean allocation density on a per-prefix basis. (IPv6 obviously completely changes HD on an proportion-of-address space basis - but shouldnt as much on a per-prefix basis). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: There's no time like the pleasant. ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mon, 15 Mar 2010, Marshall Eubanks wrote: Do you have a write-up of this ? See Geoff Huston's BGP in 2009 presentation: http://www.potaroo.net/presentations/2010-03-04-bgp2009.pdf Also see the Simula report referred to in this thread, which does not disagree with Geoff Huston's data and findings. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: You'll never be the man your mother was! ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Hi Constantine, Toni, you are raising an interesting issue. However, if the sending routers do not check whether an update is duplicate, and if the receiving routers do not check whether an update is duplicate, don't we create a positive feedback loop? Yes, but I think it was obvious that the receivers DO check. If no one checked, then any update would propagate throughout the net. Yes, that would be VERY, VERY bad. Lixia's paper pretty clearly stated that they were only seeing duplicates go one hop. Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mon, Mar 15, 2010 at 6:04 PM, Tony Li tony...@tony.li wrote: employer hat off Any operator who would like to stand up and embarrass their favorite router vendor by showing a graph of router boot convergence times is welcome to do so. ;-) /employer hat off eh, I don't have a hat nor a graph, but at a former employer we put a great deal of stress on 2 vendors to bring cold-boot times under 15minutes (cold-boot - normalized/converged full table). As I understand things today at that employer, this time has been slowly increaseing again :( it makes sense, based on the prior conversation. Another point to keep in mind is that in the overall table let's say there is a 1% churn per time period (per second for grins). That the pathway from route-processor (or whatever the part that digests inbound bgp messages is called on your fav platform) to forwarding-bits (asics + tcam again whatever it is in your fav device) can only handle 10,000 changes in that same time period. If the table grows to beyond where 1% == 10k prefixes I don't think you can expect, under normal conditions, convergence to ever happen. Part of the RRG discussion gets back to 'can we sustain the current model where every butterfly flutter is felt by all devices', this is what the above is about. I don't think you'll be able to measure this in the live network until you reach these limitations. I'm CERTAIN Cisco/Juniper both have a graph that shows where their platforms start not-converging under bgp update-load. It's trivial to extend that to a constant X% of the table churning. Now, keep in mind that Geoff's numbers are for 'full internet routes' (DFZ routes perhaps even), not 'provider bgp table' which invariably will include internal deaggregates + other address families. -chris ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Folks, In this context, I think you might be interested in a measurement study that will be presented at INFOCOM this coming week. The focus of the study is BGP scalability with respect to churn rates. We have analyzed six years of Routeviews BGP update traces from four monitors in different tier-1 networks. Some of the main findings are that - BGP churn varies widely on many time scales, and cannot be understood through black-box statistical analysis. - The most severe churn experienced by these monitors are caused by mis-configurations and events that are local to the monitored AS. - Surprisingly, as much as 40% of churn consists of duplicate announcements, which are unnecessary for correct protocol operation. This figure has been pretty constant over our measurement period. - After filtering out duplicates, local effects and anomalies caused by a few specific events, we find that there is an increasing trend in baseline churn over the past six years, but that this growth is quite modest, and much slower than the growth in the DFZ RIB size. The paper can be found at http://simula.no/research/nd/publications/Simula.nd.435 Comments are always welcome. Regards, Amund Amund Kvalbein, Post Doc Simula Research Laboratory http://simula.no/people/amundk On 14. mars 2010 18:30, Paul Jakma wrote: On Sat, 13 Mar 2010, Robin Whittle wrote: Geoff's research is: In the Re: [rrg] draft-narten-radir-problem-statement-05.txt thread http://www.ietf.org/mail-archive/web/rrg/current/msg06152.html and in BGP in 2009: http://www.potaroo.net/presentations/2010-02-01-bgp2009.pdf Those are the ones. I'd read that email too, but had forgotten of its existence in replying to this thread - thanks for highlighting it. It's possible that the current architecture of the internet is holding back growth that should otherwise be there. Yes. If we concentrate only on non-mobile networks, there are two broad aspects of the routing scaling problem: 1 - The unreasonable, arguably unscalable, burden placed on the DFZ routers individually, and on the DFZ control plane in general, by the set of end-user networks which currently get portability, multihoming and inbound TE by the only means available: getting their own space and advertising it as PI prefixes in the DFZ. Well, why is it unreasonable exactly? If the system works and is scalable, what's the problem? It's only unreasonable if there's a /good/ way to keep those prefixes out of the DFZ (i.e. good in the sense that it's at least as good as what we have today). If such a way exists, then that's great - we should definitely research ways to improve routing, of course. However, it does not seem justified to say the current routing architecture has a scaling problem. So it would not be justified, at thhis time (AFAICT), to excuse inefficiencies added by proposed changes on the basis that there's a pressing problem with the current architecture. 2 - The much larger number of end-user networks which could use 2 or more ISPs and which want or need portability, multihoming or inbound TE but don't have it because they are unable to get the space and advertise it. (Perhaps a subset of these could do it, but don't because they known how unscalable it is.) The growth in BGP advertised PI prefixes is the simplest measure of the first aspect - which is like the tip of the iceberg. The less visible part is point 2, like the main body of the iceberg. Well, the internet is going to grow. That's hardly a surprise. What's the problem with the internet growing? Geoff's results seem to show that the growth is well within the scaling abilities of the 'net. So even if Moore's Law keeps up in some acceptable manner with the pace of growth in the number of PI prefixes in the DFZ, this doesn't help with point 2 or with mobility. Sure, but: a) If the scope of the problem suddenly is those very small networks which want portability/multi-homing but aren't big enough to get an AS and PI, then: - it's a much, much smaller problem in terms of affected parties than internet routing doesn't scale - it's not clear even that such networks exist to any meaningful extent (OK, I'm geeky enough that I'd love portability and multihoming for my home network), i.e. if this is the problem being solved then that changes the economic incentives of roll-out. b) If the problem is that fewer networks today can get PI, then we should be able to see a change in the mode of prefix growth in the historical data. However, TTBOMLK, we don't see this in the data. Basically, if there's a problem then where is the evidence of it, now that we seem to have initial evidence to suggest otherwise? Sorry I haven't had time to revisit our discussions in early February. I have a backlog of RRG messages to read and respond to - mainly discussion following from my critiques of several architectures - and I need to give priority to paying work. No worries, that was just speculation on my
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mon, 15 Mar 2010, Robin Whittle wrote: Also, as just mentioned by Amund Kvalbein: BGP churn evolution: A perspective from the core http://simula.no/research/nd/publications/Simula.nd.435/simula_pdf_file Yes, saw the post of that. Its conclusion does not disagree with Geoff's results, indeed it seems to concur somewhat. (Geoff goes further and made the neat observation about possible correlation with path-length, I think). DFZ. Cumulatively, these prefixes add up to the single biggest identifiable problem at the heart of the routing scaling problem. Well, let's look at the flip-side for a moment. Imagine if there were /no/ growth in prefixes. Is that good? I think the answer clearly is no. No growth in prefixes implies no growth in the internet, implies no growth in revenue for those who make money from activities associated with attaching to the net. I.e. given much of the planet does not have internet access, and hence assuming the internet is at least a few decades away from any natural slow-down in growth due to saturation (I havn't plugged Brian Carpenters 10M prefix figure into Geoff's growth formula, but it feels like we've got at least a decade to go): growth in prefixes == good growth in prefixes == healthy internet So to some extent, (I would say a greater degree) growth in prefixes is desirable, at this time. This is what we have been doing since the RAWS workshop in 2006, and some folks have been researching this since before RAWS. Well, yes. I know. I've been discussing scalable and/or IPv6 multihoming with people on lists on/off for approaching a decade, perhaps a little more (i'd have to go check my mail archives). Whoah . . . You are arguing against the positions of pretty much everyone who is involved in the RRG. Please see 17.2.x of: Yes. I know. I used to not doubt much there was a scaling problem myself (that's what everyone thought and why should i disagree?). It's hard to maintain that view though when data starts coming in that seems to suggest otherwise. If we're to be scientific about this, we have to take heed of data. You have asserted there is no routing scaling problem, Did I? Could you go perhaps go back to my message where I said how I wished to vote. I think you'll find you've misunderstood me. but you haven't argued why this is the case - such as by arguing in detail against the arguments presented in the five above documents. Why do I need to argue the case? Let the data do the arguing. At the moment it's looking like BGP maybe is coping with growth just fine. I.e. we can not yet safely conclude there is an urgent scaling problem with internet routing (despite path-vector being known now to have some inefficient behaviours even when working as intended). Where's the data suggesting routing is or is going to run into problems? Not /fears/ that it will, but actual data. The mapping for TTBOMLK was not in my cache. Google resolved my query in a fraction of a second: I didn't invent TTBOMLK on the fly and so it's certainly more googleable than some acronyms, yes. ;) To The Best Of My Knowledge The L is Limited. fwiw ;) OK - in the context of the work which has been done so far, I suggest that your assertion that there is no routing scaling problem is just speculation too! I suspect you've misunderstood my scribblings. regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Chinese saying: He who speak with forked tongue, not need chopsticks. ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Hi Paul, You wrote: You have asserted there is no routing scaling problem, Did I? Could you go perhaps go back to my message where I said how I wished to vote. I think you'll find you've misunderstood me. I have not mentioned anything about voting - there is no voting in the RRG, and I understand no attempt will be made to seek or reach consensus on the final recommendation. (msg06220) I thought that you were arguing against the existence of the routing scaling problem, because in your first message in this thread, you wrote: However, it does not seem justified to say the current routing architecture has a scaling problem. Since I have difficulty understanding what you describe as your scribblings in a manner you agree with, I will not pursue this discussion further except to note that: 1 - I was not complaining about TTBOMLK. 2 - I disagree with your Let the data do the arguing. - people can argue, data can't. 3 - Our arguments must concern our reasonable fears about the future, since we have no data about the future. - Robin ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Mon, 15 Mar 2010, Robin Whittle wrote: I thought that you were arguing against the existence of the routing scaling problem, because in your first message in this thread, you wrote: However, it does not seem justified to say the current routing architecture has a scaling problem. Since I have difficulty understanding what you describe as your scribblings in a manner you agree with, If a person disagrees that a hypothesis has been proven, it does not of itself follow that the person believes the hypothesis has been disproven. You seem to exclude Insufficient evidence at this time to draw a conclusion from the set of valid views people may hold on a topic (as does the straw poll that led to me post). regards, -- Paul Jakma p...@jakma.org Key ID: 64A2FF6A Fortune: Necessity hath no law. -- Oliver Cromwell ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Hi Chris, Thanks for your reply, in which you wrote: 1 - The unreasonable, arguably unscalable, burden placed on the DFZ routers individually, and on the DFZ control plane in general, by the set of end-user networks which currently get portability, multihoming and inbound TE by the only means available: getting their own space and advertising it as PI prefixes in the DFZ. it's not just their own space, it's PA space as well, leaked around the provider, or through the provider. OK - for brevity I usually write just PI prefixes, but I understand some end-user networks get a prefix as PA space from one ISP and then have another ISP advertise it for multihoming service restoration. 2 - The much larger number of end-user networks which could use 2 or more ISPs and which want or need portability, multihoming or inbound TE but don't have it because they are unable to get the space and advertise it. (Perhaps a subset of these could do it, but don't because they known how unscalable it is.) I reckon most folks don't do it because they haven't hit a reason that they see to actually do it. A reason strong enough to get a bunch of address space from an RIR, with whatever initial and ongoing expenses that involves, plus having their ISPs advertise it. If there were a scalable, simple method for most anything to be 'multihomed' I suspect you'd see a whole lot more multihoming going on (or mobility, or simple device/network agility) Yes - including multihoming a small business network which uses relatively inexpensive connections, such as DSL, fibre, HFC cable or WiMAX. Such networks would generally never have the resources or expertise to get address space, or the type of Internet connectivity which ISPs are ready to use with prefixes they advertise in the DFZ. I think most networks on these DSL etc. services don't need portability or multihoming, but I think we should aim for a scalable routing solution which is light-weight enough that those who do what these benefits should be able to get it, without too much expense, administrative stuff or expertise. I think my Ivip system could do this: http://tools.ietf.org/html/draft-whittle-ivip-arch http://tools.ietf.org/html/draft-whittle-ivip-drtm and that LISP could too, if it adopted a mapping system like DRTM and if it involved address arrangements along the lines I plan for Ivip. Dino recently mentioned (msg06229): No, no renumbering required. Plus we want people to use their existing PI or PA prefixes as EID-prefixes when they convert to LISP. I can't imagine how it could be scalable or desirable for end-user networks to use their PA prefixes as EIDs. Each EID prefix needs to be covered by a coarse prefix which is advertised by multiple PTRs in the DFZ. (For Ivip, each micronet is within a MAB which is advertised in the DFZ by multiple DITRs). These coarse prefixes (MABs) need to cover the EID prefixes (micronets) of many end-user networks, otherwise there is insufficient scaling benefit. There's no way I can imagine sufficient routing scalability improvements being achieved by converting an isolated PA prefix into an EID, since each such EID prefix, or set of them for one end-user network, would need its own coarse prefix in the DFZ. Then there is mobility - which has a prominent place in the RRG Charter's description of the routing scaling problem. Broadly speaking, mobility is a whole other iceberg, so far completely submerged. providers see this in their own networks, but today the technology doesn't work/exist (no need to debate which) to have this work reliably and simply across provider boundaries, so it seems 'submerged'. I am keen to get some critiques / discussion of the TTR Mobility architecture, which will provide globally mobile global unicast addresses for mobile nodes, for IPv4 and IPv6, no matter what sort of address the MN has, including behind NAT: http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf So even if Moore's Law keeps up in some acceptable manner with the pace of growth in the number of PI prefixes in the DFZ, this doesn't help with point 2 or with mobility. Tony's and VInce's work seems to say that moores law: 1) isn't going to cut it, 2) doesn't apply anyway... we should just drop this from the idea bench. I agree. We can't keep relying on semiconductors becoming more powerful. - Robin ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
Hi Paul, I am replying to your message Re: [rrg] 2 Possible Consensus Items http://www.ietf.org/mail-archive/web/rrg/current/msg06277.html in this earlier thread: http://www.ietf.org/mail-archive/web/rrg/current/msg06163.html since you were discussing Geoff Huston's research and the question of the current interdomain routing system and its routers scaling. Geoff's research is: In the Re: [rrg] draft-narten-radir-problem-statement-05.txt thread http://www.ietf.org/mail-archive/web/rrg/current/msg06152.html and in BGP in 2009: http://www.potaroo.net/presentations/2010-02-01-bgp2009.pdf You wrote, in part: It's possible that the current architecture of the internet is holding back growth that should otherwise be there. Yes. If we concentrate only on non-mobile networks, there are two broad aspects of the routing scaling problem: 1 - The unreasonable, arguably unscalable, burden placed on the DFZ routers individually, and on the DFZ control plane in general, by the set of end-user networks which currently get portability, multihoming and inbound TE by the only means available: getting their own space and advertising it as PI prefixes in the DFZ. 2 - The much larger number of end-user networks which could use 2 or more ISPs and which want or need portability, multihoming or inbound TE but don't have it because they are unable to get the space and advertise it. (Perhaps a subset of these could do it, but don't because they known how unscalable it is.) The growth in BGP advertised PI prefixes is the simplest measure of the first aspect - which is like the tip of the iceberg. The less visible part is point 2, like the main body of the iceberg. Then there is mobility - which has a prominent place in the RRG Charter's description of the routing scaling problem. Broadly speaking, mobility is a whole other iceberg, so far completely submerged. So even if Moore's Law keeps up in some acceptable manner with the pace of growth in the number of PI prefixes in the DFZ, this doesn't help with point 2 or with mobility. Sorry I haven't had time to revisit our discussions in early February. I have a backlog of RRG messages to read and respond to - mainly discussion following from my critiques of several architectures - and I need to give priority to paying work. - Robin ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
On Fri, Mar 12, 2010 at 10:29 PM, Robin Whittle r...@firstpr.com.au wrote: 1 - The unreasonable, arguably unscalable, burden placed on the DFZ routers individually, and on the DFZ control plane in general, by the set of end-user networks which currently get portability, multihoming and inbound TE by the only means available: getting their own space and advertising it as PI prefixes in the DFZ. it's not just their own space, it's PA space as well, leaked around the provider, or through the provider. 2 - The much larger number of end-user networks which could use 2 or more ISPs and which want or need portability, multihoming or inbound TE but don't have it because they are unable to get the space and advertise it. (Perhaps a subset of these could do it, but don't because they known how unscalable it is.) I reckon most folks don't do it because they haven't hit a reason that they see to actually do it. If there were a scalable, simple method for most anything to be 'multihomed' I suspect you'd see a whole lot more multihoming going on (or mobility, or simple device/network agility) Then there is mobility - which has a prominent place in the RRG Charter's description of the routing scaling problem. Broadly speaking, mobility is a whole other iceberg, so far completely submerged. providers see this in their own networks, but today the technology doesn't work/exist (no need to debate which) to have this work reliably and simply across provider boundaries, so it seems 'submerged'. So even if Moore's Law keeps up in some acceptable manner with the pace of growth in the number of PI prefixes in the DFZ, this doesn't help with point 2 or with mobility. Tony's and VInce's work seems to say that moores law: 1) isn't going to cut it, 2) doesn't apply anyway... we should just drop this from the idea bench. -chris ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
