Roeland M.J. Meyer writes...
One idea I had that could reduce the number of prefixes would be to make
some limit on the number of prefixes per AS. This could be either a flat
limit on the number of prefixes, or a partitioned limit on the number of
prefixes per each size (same in each size). I like the latter because it
does discourage keeping multitudes of small network pieces (which is
probably why prefix filtering really got started in the first place).
Unfortunately, access lists are not smart enough to count prefixes per AS
to apply a limit, so some new code would have to be added to the BGP logic
in the routers to do this. I would suggest the default limit be set at
2 prefixes per prefix size /17 through /24, with a total limit of 5 prefixes
in this whole range, and no limit (for now) on prefixes of /16 or shorter.
It may be necessary to exclude certain network block ranges from these counts.
This would have one effect. ISP's would require any and all customers
who have their own space to run BGP and use their own AS, therefore
just sticking a variety of different labels on routes that were
previously under the ISP's announcements.
This point isn't even taking into account how absolutely real
it is for a medium size ISP to have 3 /17s or 3 /18s or 3 /19s
or 6 prefixes from /17 to /24.
Given that this would seriously impact the larger NSP's (how many /24's
do you think Sprint, MCI, and UUNet) announce for non-BGP customers,
how realistic do you view this proposal?
/* Beginning Rant */
Not to sound bitter, but the vast majority of the contributers
to this list have gone from using engineering practices for the
good of the net to using engineering practices to make it work,
given the goals and limitations of corporate policy. Any other
approach can't get the dollars behind it and compete with
the corporate direction of "well if other providers are willing
to limit their potential customer revenues by making this policy,
we can just buy RSP-4's and get the customers they lose".
Our ideas and suggestions need to be both good for the net, and
not vulnerable to someone out there flying in the face of it to
make a buck. Sprint's filtering policies are one of the few
filtering plans that was successfully imposed upon the net that
actually stuck (read, significantly impacted a majority of us in
dealing with inter-provider announcements). The only way they
did make it stick and not cost them large amounts of revenue
was to make exceptions for their own customers thereby removing
the "good of the net" result and making it "good for Sprint".
Cabal-like engineering mandates may be damn good for the routers,
but the dollars behind the routers are speaking much louder with
each passing day. It is not only naive, but irresponsible to count
on the technical "good of the network" arguments to continue to
dismiss without question or compromise, business concerns,
especially when such proposed and/or implimented methods cause
complaints of hardship from paying customers which assuredly
reach those who's chief concern is the satisfaction of the
/* End of Rant */
I suppose they'll be asking for my Techno-Socialist badge to
be turned in by morning.