/* subject fixed */
Hi Russ,
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.
Ok here I completely disagree. Let me try to explain why ...
The tools to solve RIB and FIB scaling do not require to prevent BGP
from limiting it's table size.
The tools which may help with Internet BGP table grow are much more
efficient outbound from any AS not inbound. The reason is that there are
many inbound points which may receive overlapping prefixes.
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.
As above I think we clearly disagree on that point ;)
You said PI space first,
Sorry yes I meant PA in the first place as well.
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.
It will not ! Because wise provider do not suppress anything on inbound
within his network he carries his more specific prefixes just fine. It
is just outbound to his upstream he advertises his single PA space. 4
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.
And you still are .. of course provided that customer will not convince
some other ISP with sufficient $$$ to advertise part of your PA space.
That's why RIRs were recognizing this as an important enough issue that
such multimedia customer were getting Provider Independent address. Of
course if we finally converge on how to do multihoming with PA addresses
it would be much better.
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. :-)
You looked at the exception not the rule :)
r.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
