Hello, > > > All of the recent proposals and rrg discussion seem to focus on > > re-empowering aggregation by attempting to pinpoint the reasons for > > deaggregation and dealing with them. A lot of reasons have been brought > > up, such as PI usage, ingress TE, avoiding renumbering, etc. Yet, it is > > unclear how much each 'cause' contributes to overall deaggregation. > > Does it matter? As long as the solution handles all (or most) of them, that > should be all that's needed. Are there significant causes of expansion that > aren't handled by separation of location and identity? If so, I think we need > to hear about them ASAP. >
Here's why it might matter. Some proposals address some, but not all of the alleged causes of expansion. Imagine if we knew how much each cause contributed to expansion, and realized that one or some of those causes didn't really contribute much to expansion at all. Proposals that didn't address these 'problems' wouldn't be subject to such a criticism anymore. On the flipside, if one of these causes was the found to be the main contributor of expansion, we certainly would make solving this problem a MUST. > > > I wonder if it would be preferred to have a solution that allows > > networks to shield themselves from routing table bloat, regardless of > > the causes behind long-prefix announcements - a cause-agnostic solution. > > A terminology nit here: when you say "routing table" do you really mean the > routing table (strictly defined), or the RIB, or the FIB (since many > implementations now include all three as separate databases). > I mean the RIB and FIB. > I ask because to the extent that a solution downsizes one of these (e.g. the > FIB reduction work), but not the others, it may not help with the overall > growth of 'routing tables' (in the generic sense), since I think a lot of the > concern is that the stability and robustness of the routing overall (i.e. the > global distributed computation) is negatively impacted by 'routing table > growth'. > > Not that I'm against things like FIB reduction - I welcome its deployment, in > parallel with other things; it's sort of a 'the more the merrier' situation. > I agree that a solution that does not reduce both RIB and FIB should not be considered complete. > > why do you consider VA a short-term solution? ... VA allows networks to > > scale down their tables to any arbitrary size by re-enabling > > aggregation within the network. > > I wouldn't even consider it a short term solution to the larger problem, > because it's only local - it doesn't really have any impact on the global > distributed computations which currentlt produce end-end paths, and it's > that larger, overall situation which I thought (perhaps mistakenly) was > a major focus. > If all local parties that suffer from a scalability problem are given a solution, isn't this a global fix? A patch for a program needn't go to everyone, but just those users that ever use the program. I also don't CLEARLY understand what you mean by "larger, overall situation" and what additional ground that covers. Can you spell that out a bit more? Dan Jen > Again, though, I don't see any problem with deploying it in parallel - as > long as it's realized what its limitations are. > > Noel _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
