On Thu, Nov 15, 2012 at 2:15 AM, Ben S. Butler <Ben.Butler@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. ^_^;