What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

Thu Nov 15 20:44:40 UTC 2012

On Thu, Nov 15, 2012 at 2:15 AM, Ben S. Butler
<Ben.Butler at c2internet.net> wrote:
> Hi,
...
> <snip>
...
> What we need is a way to filter that says throw this prefix away if I can see it inside of another prefix.  Ie discard this /48 if it is part of a /32 (or bigger) that I also have in my RIB and then insert the /32 into FIB and discard the /48".

Would you want this logic to still apply if you have ::/0 in your table
anywhere?  It really is the ultimate "covering" route for everything
else, and for some set of sites that advertise non-aggregated /48s,
their thought process may wander into the territory of "it doesn't
matter so much if you don't see the more specifics, you'll just
follow your default route to your upstream provider, and it'll reach
me that way."

It seems that this particular problem space only occurs for networks
that want to implement strict filters to limit their routing table size,
but also want to run completely default-free.  It sounds a little bit
like such people may be trying to shift the cost burden around in
an odd fashion.

"I don't want to listen to your more specifics; I worry about my
routing table resources, and whether or not I can keep up with
the rest of the internet.  But I also want to look like I'm one of
the big default-free providers, which means I'm creating reachability
problems to your network through my own choices.  Won't you
help me solve my self-created problem by altering how you
build and configure your network?"

I have no issues with people filtering out more specific prefixes
to limit the size of their view of the routing table; I do it for
routers I administer that don't have adequate resources to
take a full view.  But I also ensure that those devices have
a covering default route towards something that *does* know
how to get closer to the destination.

[more snippage...]

> So I guess the logic becomes....
>
> /48 Routes tagged with an island community permit as long as there is not a less specific covering route in the RIB.
>
> /48 Routes tagged with a TE community can be permitted or denied as chosen by the recipient end AS but should be carried in the DFZ by transit providers.

If you're having reachability problems to /48s that you're filtering
out, you must be trying to play in the DFZ; otherwise, your default
route would cover you, and this would be a non-issue.  And if you're
playing in the DFZ, by your own rule here, you should be carrying
those routes rather than filtering them out.

> /48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid.
>
> Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 maximum announced prefix size - rather than carried in the same block as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum.
>
> If we do that, it keeps the existing problem the size it is currently and solves it for future assignments, allows the island networks to work, prevents people cheating by trying to sneak a TE route in as an island route when there is covering /32 route, dumps off the rubbish from spurious announcements and hijacking, while allowing PI end user /48s to continue to work...  I think that would address the problem.
>

I think your use of the term "cheating" here is misapplied.

You've stated that the more specifics *must* be accepted
by the DFZ providers, so that downstreams can make their
own decisions as to whether to accept and use them or not.
You're implying that your network is default free, and thus
by not accepting the more specific prefixes, you would see
reachabiliity issues:

> It is not my place to judge your business, nor is it anyone elses to expect the rest of us to accept TE routes without a coverall and expect to be reachable.

Contrary to that line, you've stated you _do_ expect that
DFZ providers should accept those TE routes with or
without a coverall, in order to provide reachability.  I don't
think it's reasonable for you to expect to have it both ways.
It really sounds like you want every other DFZ provider to
have to carry the longer prefixes *except you*--and I don't think
you'll see much support from the rest of the community
for a proposal like that.

And if you *do* carry ::/0 in your network from an upstream,
this is all a moot point; filter away to whatever level your
heart desires, you won't be creating a reachability problem;
at worst, you'll create some inefficient routing, but the
packets will still flow.

> </snip>
>
> Thoughts...?
>
> Ben

tl;dr -- "this is what those HE sessions are for."

Matt
probably way off in the weeds in left field at this point...I should
never try to reply to messages during the day; so many distractions,
I never remember what it was I was trying to say back when I started
the sentence.  ^_^;