>>> I don't think this is as simple as this ... Remember that when the >>> less specific (/24) goes away the AS4 must readvertise the more >>> specifics not to break routing. So therefor I do not think that any >>> simple policy would work. The choice/decision what to advertise and >>> what not must be done at best path run. >> >> Sure --but won't best path be run when the best path towards a >> specific destination falls out of the table? > > Best path today does not compare /16 and /24. In Pedro's proposal it does.
We could compare the less specific with the more specific, as you say. But it's important that the comparison be done on the inbound side, not the outbound side, if you want the option of reducing internal table size. > I think it works. The example is comparing all best path eligible > attributes of less and more specific during best path and if the less > specific would win suppress the more specific. > > I am only not sure if we really need to compare all. For example I am > not sure that like in your proposal it really matters if the more > specific was received over the same session as less specific (provided > that actually happens that often as you say :-) I don't think we say it has to come in on the same session, or even from the same entry point --only that the overlapping routes have to exist in the same table at some point for comparison. You could always do this at the outbound ASBR, but that's not the most efficient place to do it. The most efficient place is the inbound ASBR, I think. > That has been for years common recommendation of any RIR ... That's the > value of PA addresses. Multihomers were told to get PI which indeed does > not make the BGP table smaller. You said PI space first, not PA... With PA, if a provider is stupid enough to give the inbound traffic to one of their customers to a competing provider, then go ahead. I can't imagine doing that as a provider. If I'm providing the PA space, I want to be the primary entry point into the customer's network. Why bother with "prefer local routes to my customers over routes from peers," if I'm going to give out a set of longer prefixes that customer can advertise through another provider, drawing traffic from within my own network across a transit link into a peer to reach that same customer? But note: > "Advertisement of more specific prefixes should not be used unless > absolutely necessary and, where sensible, a covering aggregate > should also be advertised. A covering aggregate should also be advertised. In other words, if you're advertising the longer prefix, you _should_ advertise a shorter covering route --specifically what we're counting on in this draft. So it looks like the draft is already in line with what best common practice is. :-) > It never intended to. It reduces the local RIB/FIB size. I am not even > sure why you are comparing apple to oranges here :) I didn't bring it up. :-) :-) Russ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
