Pierre Francois wrote: > Eduardo, > > John G. Scudder wrote: > > Eduardo, > > > Remember that the input to the aggregation step is the Local RIB. Prefixes > to be aggregated need to share the same next hop (not in the BGP NEXT_HOP > sense necessarily, but in the actual what-you-put-in-the-forwarding plane > sense). The AS_PATH is irrelevant to the aggregation step. This is because > the aggregation is never exposed outside the local router. Indeed, modulo > the "creating additional routable space" issues introduced by "Type 4" of > the draft it should be impossible for an outside observer to even tell if > FIB aggregation is in use or not. > > The whole thing is orthogonal to what goes on in the control plane. > > > As for the evaluation methodology, Lixia or one of her co-authors will have > to address that. > > > As far as I understood, they considered the first AS number on each path is > its "nexthop" attribute, because they don't have the actual nexthops in > the data. > > > That's why they had to validate this approach by showing that a given > router, usually uses the same nexthop for almost all the prefixes that it > reaches through a given neighboring AS. >
Exactly. We have 9 tables that have the next-hop information, and most prefixes of these tables satisfy this assumption. > > This might come from the fact that it always has the same IGP tie-break > winner when comparing multiple nexthops of the same neighboring AS. And > most of the time when comparing paths from the same neighboring AS you > reach that BGP DP rule. > Yes, that's what we thought too. > > However you can find designs were having multiple nexthops at same IGP > distance from a given PE holds true for almost every (PE,neighboring AS). > The plot on such networks could have been much less favorable for the > validation of the approach I guess. > If the tie-breaking rule is prefix-agnostic, i.e., always end up with the same router regardless of the prefix, then the result should be the same. But if it picks different routers for different prefixes, then the result will be different. Another thing is that a router usually has a small number of neighbors (i.e., possible next hops), e.g. a few tens? But since we use the neighbor AS in our evaluation, a router can have a few hundreds or even a couple of thousands neighbors, which will make the aggregation worse in our evaluation. That's why we're looking for routing tables from operational routers to help further evaluate the schemes. Thanks, --- beichuan > > Regards, > > Pierre. > > --John > > On Nov 11, 2009, at 2:26 PM, Eduardo Ascenço Reis wrote: > > > Hi, > > Regarding FIB Aggregation draft (draft-zhang-fibaggregation-02.txt), > prefixes that would be aggregated share the same NEXT_HOP and AS_PATH > attributes. > > Is that correct? > > From Lixia presentation I got that the evaluation methodology > extracted NEXT_HOP from AS_PATH information (Route Views Archive > Base). > > Thanks, > > -- > > Eduardo Ascenço Reis > > > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
