I think the argument is not about route filtering - it is the implementation
method.
Genuity uses ip extended access-lists.
Everyone else uses prefix-lists.
To a purist, the former is more granular, but performs poorly because it is
a linked list implementation. The later, while less granular, performs
faster by using a trie. It also allows insertion without list rebuilding.
Does this matter much? I'm sure there are some that have tested convergence
between the two technologies, so I'd welcome comments out of curiosity.
They are somewhat anal with their lists as well. If you have a /19, but you
want to deaggregate for inbound BGP TE, you will need to send them EVERY
route you will send. That can be 64 subnets. For a /16, it is waaayyy
worse. Then again, it allows them to know exactly how many prefixes MAY be
announced from their customers, which I suppose has its merits.
Hmm. From a coding point of view you are certainly correct. From a
troubleshooting POV, prefix lists are superior, because it is much easier to
tell, at a glance, what the ACL is supposed to do, particularly for less
experienced engineers. This is a significant advantage. However, it can be a
big project to convert a large, installed base of extended ACLs to
prefix-list ACLs, so that might be why Genu has held off. Even with a script
or other tool, there is still a chance for some customer downtime.
As far as requring exact ACLs, rather than allowing "greater than or equal
to" type ACLs - there are a couple good reasons for this. One is, to ensure
maximum route aggregation by your customers, and potentially prevent serious
deaggregations. This may also help with troubleshooting.
Of course, it's less convenient for customers, and requires more interaction
and changing of ACLs, which can cause downtime. I suspect the best practice,
at this point, is autogeneration of ACLs using IRR database entries, and
tools like RTConfig or their homegrown equivalent.
You have hit the nail on the head. I don't argue with route filtering, just the
hoops that I had to go through with Genuity as compared to my other providers.
At the time, the fastest line available in my location was T1 and I was having
to load balance between providers and lines by advertising small pieces out
different lines.
I think the argument is not about route filtering - it is the
implementation method.
Genuity uses ip extended access-lists.
Everyone else uses prefix-lists.
To a purist, the former is more granular, but performs poorly
because it is a linked list implementation. The later, while
less granular, performs faster by using a trie.
IOS 12.0S (and derivatives) are popular with ISPs (at least those
who use Ciscos), and support 'access-list compiled', making
access-lists likely to be around the same speed as prefix lists;
they just take up RAM (one access list I use takes 10Mb of RAM
once compiled).
extended access lists still permit flexibility, ie, the /16
permitted only:
access-list 111 permit ip host 192.168.0.0 host 255.255.0.0
becomes to permit all /16 thru /24 under that:
access-list 111 permit ip 192.168.0.0 0.0.255.0 255.255.0.0 0.0.255.0
(might look less clear than a prefix list when you start wanting to
let them permit say /19 thru /22, but then, router configs come from
automated systems now, right? :-))