Re: [GROW] draft-white-grow-overlapping-routes-00

[Robert Raszuk <[e-mail]>]

/* 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.