|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Why does Sprint have address filters again?
> > Roeland M.J. Meyer writes... > > > At 02:16 AM 6/1/98 -0700, Patrick W. Gilmore wrote: > 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 stockholders. /* End of Rant */ I suppose they'll be asking for my Techno-Socialist badge to be turned in by morning. --------------------------------------------------------------------------- ** Andrew W. Smith ** [email protected] ** Chief Network Engineer ** ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** ** "Opportunities multiply as they are seized" - Sun Tzu ** ---------------------------------------------------------------------------
|