> From: Dan Jen <[email protected]>
> 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.
> 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 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.
> 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.
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
