Y'all: I finally got around to rereading this draft, so I could make some intelligent comments on it. But before I begin, let me make a comment on the process here...
There are three drafts I know of in this space. Two of them have expired, but I've recently received emails about reviving them. None of these drafts require changes to BGP's operation on the wire, however. It seems, to me, that there's no reason for GROW to actually prefer one solution over another. In fact, it seems like there's no reason not to publish all the "non-overlapping" ideas, and let vendors and operators choose which one they prefer to implement & deploy. I'll leave this point open for discussion, and move to my comments on this draft in particular. == The first thing to note is this draft specifically attacks FIB table size without modifying the routing table size. Since I'm not convinced that FIB size, as opposed to the on-the-wire table size, is a problem that needs to be addressed, I'm not certain about the overall utility of the mechanism outlined here. Is there any reason to suspect that forwarding table size is "the" problem in hand? == The core idea behind FIB suppression is to run BGP as normal, and in particular to not shrink the RIB, but rather to not load certain RIB entries into the FIB. This approach minimizes changes to routers, and in particular is simpler than more general routing architectures that try to shrink both RIB and FIB. Is this really a good idea? I will now have two different control plane tables, one ostensibly built from the other, which do not match. While this might not be a problem for the router, it would be a wee bit of a problem at 2am when I'm trying to troubleshoot some network traffic flow problem, or a routing problem. Ping and traceroute are no longer reliable indicators of forwarding table state through the network --not a good thing, IMHO. == On the increase in stretch... While I realize aggregation always causes increases in stretch, it seems like this draft would increase stretch precisely where other drafts are trying to reduce it by increasing the amount of information BGP sends. I suppose different situations might call for different design parameters, but I don't see how this draft would allow for shorter paths through multiple BGP advertisements in parallel with reduced state (both deployed at the same time). Maybe the authors would care to add a section discussing how these things would work together. == In other words, even if an ingress router is not an APR for a given sub-prefix, it MAY install that sub- prefix into its FIB. Packets in this case are tunneled directly from the ingress to the BGP NEXT_HOP. These extra routes are called "Popular Prefixes", and are typically installed for policy reasons I'm not certain how these "popular prefixes" will actually work in practice. Wouldn't it be a requirement that every router in AS have the same list? It might be worth addressing this situation in some way within the draft. == How would this interact with traffic engineering? Since this uses MPLS tunnels to get traffic around to aggregation points, wouldn't this at least overlap with other uses of MPLS in the same network? Again, it seems like it might be worth making some comments on this in the draft. == I find this draft introduces a lot of complexity for the amount of gain it provides. While the end result in theory might be a really high level of aggregation within the provider's network, the reality of increased stretch would probably mean most networks end up only gaining some lower amount of savings in real forwarding table size reductions --and I'm not certain the savings are where providers really need them. I suppose this might be a good fit for some L3VPN deployments, but there a provider might find the increased stretch causes his network to be much slower at the savings of a small number of control plane entries, and and the cost of increased TE complexity. So, overall, I'm not certain of the value for complexity tradeoff here. Russ -- <>< [email protected] [email protected] _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
