Re: NSP ... New Information
At 07:10 AM 6/9/97 -0700, Bill Manning wrote:
At 09:47 PM 6/8/97 PDT, Randy Bush wrote:
Folk are trying to keep core routers from falling over.
To repeat an earlier unanswered question, what and whose legacy hardware and software is causing the problem?
proteon, ibm, cisco, bay, 3com to name a few, and, to my limited understanding, every implementation of an IP stack. Of course if you are willing to slow down everything and commit to a global network that runs at no greater than 64Kb. (and get everyone else to do the same) then you might be able to get by with the next generation of hardware.
--bill
One of the newbies (Livingston) has BGP in alpha using < 8MB for a full view and a 486 processor without stress. While this won't make a core router, it seems to offer something to consider, even learn from. One of my projects 25 years ago was to reduce the time to calculate the square root on a Seymour Cray machine by a factor of 20 to avoid spending $8 million on a second machine. The revised square root code performed in about the same time scale as the machine's hardware divide function. The clue came from one of the national laboratories and was published in Nuclear Science Abstracts. It took about 6 weeks to do the code and 18 months for the solution to be politically accepted. The original vendor does not always produce sacrosanct stuff. We just went through the process of acquiring our first significant router; one of our main concerns was a router which would allow school districts, libraries and hospitals to benefit from Texas HB2128, which offers distance insensitive T1s and DS3s and was co-authored by our telecomm lobbyist, W. Scott McCollough in Austin. I was somewhat dismayed at the memory limitations of current stuff compared to what I was hearing about the memory requirements. Jonah has more memory on his texas.net usenet news server than you can put on many core routers. Is there anyone working on alternative implementations of software which could possibly solve some of the problems using extant hardware? Will IP multicast help with the usenet stuff? Do we want to continue seeing cams at universities display the local tower while the institution doesn't meet RFC2050 guidelines with respect to utilization of their Class B while the rural areas can't get /19s to support diversity and redundancy? Does Congress need to pass "must carry" legislation similar to the "any willing provider" medical legislation? IMHO, it would be better that some old dogmas and implementations die and be replaced with efficient, robust code and a rather less limiting view of the future. Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571
One of the newbies (Livingston) has BGP in alpha using < 8MB for a full view and a 486 processor without stress. While this won't make a core router, it seems to offer something to consider, even learn from.
And what the heck has this got to do with real routing on [inter-]national backbones? Please don't bother to answer.
One of my projects 25 years ago was to reduce the time to calculate the square root on a Seymour Cray machine by a factor of 20 to avoid spending $8 million on a second machine. The revised square root code performed in about the same time scale as the machine's hardware divide function. The clue came from one of the national laboratories and was published in Nuclear Science Abstracts. It took about 6 weeks to do the code and 18 months for the solution to be politically accepted. The original vendor does not always produce sacrosanct stuff.
We await your router product, but not while holding our breaths. This is the network *operator* list, not a science fiction club. Larry, your agenda is obvious and you are in a long line of folk playing this sad game. We all wish otherwise, but the fact of the matter is that it does not work. Sorry. Can we get back to work now? randy
At 08:44 AM 6/9/97 PDT, Randy Bush wrote:
This is the network *operator* list, not a science fiction club.
Larry, your agenda is obvious and you are in a long line of folk playing this sad game. We all wish otherwise, but the fact of the matter is that it does not work. Sorry.
Can we get back to work now?
For the record, my agenda is working to provide equal access to the Internet on a level playing field for rural north Texas, including the public, K12, libraries as well as hospitals. This is not science fiction, although it might make a good nightmare for some if pushed to scale. The "how to do without a /19" question remains unanswered. Once again, I ask you to point to extant URLs which you refer to that offer a solution offering diversity and redundancy other than a fully routable and portable /19. I thank you in advance for doing so and appreciate your time and that of others. Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571
The "how to do without a /19" question remains unanswered.
No. You just don't like the answer. Get space from upstream like every other small provider does until they have sufficient track record to warrant their own space. Been there. Done that. What I did not do was bother everybody else in the world with whining. randy
At 09:18 AM 6/9/97 PDT, Randy Bush wrote:
The "how to do without a /19" question remains unanswered.
No. You just don't like the answer. Get space from upstream like every other small provider does until they have sufficient track record to warrant their own space.
Been there. Done that. What I did not do was bother everybody else in the world with whining.
randy
Are you saying that a /19 wouldn't put less load on the _system_ than the current situation + another block? Our /23 and /21 are from UUNET, our primary provider. ACSI is secondary provider. Teach me (read: offer your constructive criticism). I'm willing to learn.
<Picture: DIGEX>
MAE-East Looking Glass Results
Query: bgp Addr: 205.229.106.0
BGP routing table entry for 205.229.106.0/23, version 4581638 Paths: (4 available, best #4) 6467 4963, (aggregated by 4963 206.222.100.182) 165.117.1.122 (metric 28416) from 165.117.1.35 (165.117.1.122) Origin IGP, metric 2000000000, localpref 100, valid, internal, atomic-aggregate Community: 2548:668 Originator : 165.117.1.122, Cluster list: 165.117.1.35, 165.117.1.17, 165.117.1.122 1800 1239 4200 6467 4963, (aggregated by 4963 206.222.100.182) 192.41.177.240 from 192.41.177.240 (198.67.131.49) Origin IGP, metric 6, valid, external, atomic-aggregate Community: 2548:668 1800 1239 4200 6467 4963, (aggregated by 4963 206.222.100.182), (received-only) 192.41.177.240 from 192.41.177.240 (198.67.131.49) Origin IGP, metric 6, valid, external, atomic-aggregate 6467 4963, (aggregated by 4963 206.222.100.182) 192.41.177.108 from 165.117.1.122 Origin IGP, localpref 100, weight 100, valid, internal, atomic-aggregate, best Community: 2548:668 Originator : 165.117.1.122, Cluster list: 165.117.1.122
<Picture: DIGEX> MAE-East Looking Glass Results
Query: bgp Addr: 206.65.112.0
BGP routing table entry for 206.65.112.0/21, version 4581941 Paths: (2 available, best #2) 6467 4963, (aggregated by 4963 206.222.100.182) 165.117.1.122 (metric 28416) from 165.117.1.35 (165.117.1.122) Origin IGP, metric 2000000000, localpref 100, valid, internal, atomic-aggregate Community: 2548:668 Originator : 165.117.1.122, Cluster list: 165.117.1.35, 165.117.1.17, 165.117.1.122 6467 4963, (aggregated by 4963 206.222.100.182) 192.41.177.108 from 165.117.1.122 Origin IGP, localpref 100, weight 100, valid, internal, atomic-aggregate, best Community: 2548:668 Originator : 165.117.1.122, Cluster list: 165.117.1.122
Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571
proteon, ibm, cisco, bay, 3com to name a few, and, to my limited understanding, every implementation of an IP stack. Of course if you are willing to slow down everything and commit to a global network that runs at no greater than 64Kb. (and get everyone else to do the same) then you might be able to get by with the next generation of hardware.
--bill
One of the newbies (Livingston) has BGP in alpha using < 8MB for a full view and a 486 processor without stress. While this won't make a core router, it seems to offer something to consider, even learn from.
Livingston has serious problems with its BGP code and has since it was first available (going on six months now) Your analogy breaks down pretty quick. Sort of like the doit yourselfer electrician tinkering with the hoover dam generators. Heck, its all just volts and amps and what works at my house will work at the colocation point for millions of users.... not.
The original vendor does not always produce sacrosanct stuff.
True enough. Feel free to enlighten the rest of us with your code. I expect that you might even be able to make a buck or two out of it.
We just went through the process of acquiring our first significant router; one of our main concerns was a router which would allow school districts, libraries and hospitals to benefit from Texas HB2128, which offers distance insensitive T1s and DS3s and was co-authored by our telecomm lobbyist, W. Scott McCollough in Austin.
Woopdedo. I spent 18 years in Texas fighting the same fight.
I was somewhat dismayed at the memory limitations of current stuff compared to what I was hearing about the memory requirements. Jonah has more memory on his texas.net usenet news server than you can put on many core routers.
True. Whats your point? Memory is not the answer.
Is there anyone working on alternative implementations of software which could possibly solve some of the problems using extant hardware?
Sure. See the latest from the new router startups and the next round from the old guard.
Will IP multicast help with the usenet stuff?
Tangental question.
Do we want to continue seeing cams at universities display the local tower while the institution doesn't meet RFC2050 guidelines with respect to utilization of their Class B while the rural areas can't get /19s to support diversity and redundancy?
If you got your address space pre-RFC2050, do its guidelines apply to you? I expect that once they come back for more space that RFC2050 will apply.
Does Congress need to pass "must carry" legislation similar to the "any willing provider" medical legislation? IMHO, it would be better that some old dogmas and implementations die and be replaced with efficient, robust code and a rather less limiting view of the future.
Sure. As soon as they pass the legislation mandating PI = 3.0 Oh, and we are still waiting on your "efficient, robust code". T'would be a shame to legislate away a working system w/o your replacement code in place.
bringing the real Internet to rural Texomaland
Until you kill it off with legal manouvers. -- --bill
At 08:44 AM 6/9/97 -0700, bmanning@ISI.EDU wrote:
Woopdedo. I spent 18 years in Texas fighting the same fight.
Until you kill it off with legal manouvers.
-- --bill
Do you REALLY consider: 1) fighting for equal access to PRIs for rural Texas and 2) fighting for email privacy by standing up to the Texas Attorney General and supporting the law of the land (ECPA) as "legal manouvers (sic)". Surely you jest? Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571
Do you REALLY consider:
1) fighting for equal access to PRIs for rural Texas and 2) fighting for email privacy by standing up to the Texas Attorney General and supporting the law of the land (ECPA)
as "legal manouvers (sic)".
Whether one considers them "legal manouvers (sic)" or not, we certainly don't consider them operational issues (as in the "O" in NANOG). Well I don't anyway. Alex Bligh Xara Networks
Alex.Bligh wrote:
Do you REALLY consider:
1) fighting for equal access to PRIs for rural Texas and 2) fighting for email privacy by standing up to the Texas Attorney General and supporting the law of the land (ECPA)
as "legal manouvers (sic)".
Whether one considers them "legal manouvers (sic)" or not, we certainly don't consider them operational issues (as in the "O" in NANOG). Well I don't anyway.
Alex Bligh Xara Networks
apparently the NANOG mailing list AUP hasn't been approved... something about legal issues... -- --/ Peter E. Giza || Technical Consultant || ADSmart Corporation fone 508.684.3609 || phax 508.684.3618 || page 800.632.1746 || http://www.adsmart.net /--
At 08:44 AM 6/9/97 -0700, bmanning@ISI.EDU wrote:
Will IP multicast help with the usenet stuff?
Tangental question.
Do we want to continue seeing cams at universities display the local tower while the institution doesn't meet RFC2050 guidelines with respect to utilization of their Class B while the rural areas can't get /19s to support diversity and redundancy?
If you got your address space pre-RFC2050, do its guidelines apply to you? I expect that once they come back for more space that RFC2050 will apply.
-- --bill
What is the current utilization rate of USC's block? Will they ever have to go back or meet current guidelines? Larry Vaden, founder and CEO help-desk 903-813-4500 Internet Texoma, Inc. <http://www.texoma.net> direct 903-870-0365 bringing the real Internet to rural Texomaland fax 903-868-8551 Member ISP/C, TISPA and USIPA pager 903-867-6571
Larry Vaden writes...
Does Congress need to pass "must carry" legislation similar to the "any willing provider" medical legislation? IMHO, it would be better that some old dogmas and implementations die and be replaced with efficient, robust code and a rather less limiting view of the future.
Consider the following problem. Suppose that IP space were not a problem. When IPv6 comes up all around, it certainly won't be then. You can have and waste all the IP space you could imagine, since we'll be numbering every atom in the known universe. And suppose we have ASNs a plenty. Would Sprint, Digex, and AGIS still be trying to cut out so many routes? Are any other ISPs doing this filtering? -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
At 12:27 AM 6/10/97 -0500, Phil Howard wrote:
Larry Vaden writes...
Are any other ISPs doing this filtering?
I know that Erol's was going to, and that Priori will likely, but for different reasons than you are used to. The primary reason that I have considered filtering is for protection against AS7007 type problems affecting my network. I.e. If you deaggregate the entire world and send it to me, I may be "not listening" to enough of it that I would be safe. Justin W. Newton Senior Network Architect Priori Networks http://www.priori.net ISP/C, Director at Large http://www.ispc.org
On Tue, Jun 10, 1997 at 01:18:05AM -0700, Justin W. Newton wrote:
I know that Erol's was going to, and that Priori will likely, but for different reasons than you are used to. The primary reason that I have considered filtering is for protection against AS7007 type problems affecting my network. I.e. If you deaggregate the entire world and send it to me, I may be "not listening" to enough of it that I would be safe.
Erols will be doing so. Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - ahp@hilander.com | Erols Internet Services, INC. | |Network Engineer | Springfield, VA. | +------------------------------------+--------------------------------------+
At 12:27 AM 06/10/97 -0500, Phil Howard wrote:
Suppose that IP space were not a problem. When IPv6 comes up all around, it certainly won't be then. You can have and waste all the IP space you could imagine, since we'll be numbering every atom in the known universe.
I continue to hear this used as a 'compelling reason' to urge IPv6 migration, when in reality it appears to be nothing more than people trying to do an 'end around' the address allocation policies by thinking that once v6 is deployed, the allocation policies will dissappear. Simply because one increases the available amount of address space does not in any way imply that allocation policies will change significantly. If they did, and the number of routes increased significantly, we would have much larger problems in the global routing system than we would with people whining about not being able to obtain large enough address allocations. - paul
Paul Ferguson writes...
At 12:27 AM 06/10/97 -0500, Phil Howard wrote:
Suppose that IP space were not a problem. When IPv6 comes up all around, it certainly won't be then. You can have and waste all the IP space you could imagine, since we'll be numbering every atom in the known universe.
I continue to hear this used as a 'compelling reason' to urge IPv6 migration, when in reality it appears to be nothing more than people trying to do an 'end around' the address allocation policies by thinking that once v6 is deployed, the allocation policies will dissappear.
I wasn't trying to compel IPv6 with this. Instead, I was trying to show that the problem is really not one of IP space.
Simply because one increases the available amount of address space does not in any way imply that allocation policies will change significantly. If they did, and the number of routes increased significantly, we would have much larger problems in the global routing system than we would with people whining about not being able to obtain large enough address allocations.
Right. But people see it as such a problem because the routing policies are IP space derived. When people are told they need a /19 to be routable, then they begin to go backwards on solving the IP space problem and resume wasting it (but hiding the waste to look like its used). When the need to justify space usage occurred, along with it came some ideas on actually how to do that. And I see that working. We were projected to run totally out of space by now, and since we have not, I assume it did work pretty well. But the real problem is routing policies that are encouraging people to go back to wasting space. By using the network size as the criteria for doing route filtering, the smaller guys get screwed and they see their solution as inflating their network. This practice needs to be stopped or a better solution needs to come out of it. Suppose TCP/IP had been designed from the beginning with 64-bits of flat address space divided 32/32. We would not have the space crunch at all AND there would be no space "handle" for routing policies to lean on to screw the little guys. Tell me what the big boys with small routers would do in this case today? Even the biggest router has no chance with a billion routes. Or would we have been forced to come up with a new and better replacement for BGP(4) by now that does dynamic intelligent aggregation or something? -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Well, um, er... it wasn't going to be this long but I got started, and then put some math in it (I'm sorry, I know math is hardly operational) and then some history. Hit "D" now if your brain is mush. E Phil Howard wrote...
Suppose TCP/IP had been designed from the beginning with 64-bits of flat address space divided 32/32. We would not have the space crunch at all
Actually I beg to differ. IP was designed to handle a variety of network sizes, and to automatically infer the size of the network from the number of contiguous set bits in the first octet. You can skip most of the next two paragraph but read the line in the ***'s... DECnet, to contrast, was originally designed for 4-bit addressing. "After all, Nobody could afford more than 16 machines." Eventually DEC realized the error of their ways and upgraded to 8-bit addressing. "After all, Nobody could afford more than 256 machines." But WANs were becoming popular, and SPAN (discussed elsewhere, precursor to NSI) wanted to do it, and HEPNET (discussed elsewhere) wanted to do it. This resulted in DECnet V4, 16 bits of address space broken 6/10 into "Areas" of "nodes." Worked great for small private networks, badly for larger networks. Large internetworks were impossible as only 64 "areas" could exist. *** This shortsighted design spec required workarounds ("hidden areas", "poor man's routing") which REQUIRED that the USER know and specify the ROUTE from END TO END. *** IP provided a solution where (suprise, surprise) routing was handled at L3 and was oblivious to the user. It isn't until now, when most users are "used to unreliable service" that traceroute has become a popular end-user tool. If users expected their cars to be as reliable as the cheap-ass $20/mo Internet Providers, there would be no warranty business for GM, but let me jump back off this soapbox, as I digress. Anyway, IP has the strong point that network sizing is (now) a dynamic entity, so that a network (set of contiguous address space) is sized to the needs of the organization. The whole set of networks is limited to N bits (32 now, 64 under IPv6), but the masking is not fixed. I don't take issue with "It's too bad IP wasn't designed 64..." but rather that "32/32" is the end-all. I think 2^32 network spaces SOUNDS enough now, but pre-allocates obscene parts of the address space for no reason. Well, ok, to conserve routing entries. However, when you consider that we now have ~45K routes, o(45K) is five orders of magnitude off from o(4E9). It behooves us not to "make it easier" on the router by limiting it to 4E9 entries since the problem is already "outside a known technological solution today." (Well, with L3 anyway.) Recall that in 1982 memory was not cheap. IBM had introduced the PC the year before with 256K, upgradable to 640K. Memory was about $500/k and addressing was 16 bits, minis to 32, Crays to 64. In the 80's the NSFNET NSS could originally only handle one ASN announcing a route, then eventually upgraded to 4... These were memory and processing limitations. A table of 2^32 8-octet entries (4GB) is something that BACK THEN was inconceivable for memory storage. Today we consider that it would be possible to size the table at 2^32 entries of destination, gateway, netlength(mask), flag? 8 octets 4x8 octets 1 octet 2^32 x 40 = 1.6E11 Bytes of table space. If you take the Cisco approach to store this in multiple ways so you can fast-cache access to the routes vs a sequential search, it appears to take 5x storage, or 8E11GB. Add the router code, and we're talking a box with a terrabyte of RAM. That's a tad more than today's boxes. Now contrast this with 64/? variable networks. 2^64 entries of 40 octets =~ 6E20 Bytes. The technological difference between today's high-availability processors and either of those two goals are so vast that "trying to save on space..." wins nothing until we know what our real goalpost is. If we hit IPv6 Implementation Year and Yer Average Router can only handle 2E10Bytes, someone's gonna say "29/35?". That would be the time to haggle bits ;) Well, back to sleep. E
AND there would be no space "handle" for routing policies to lean on to screw the little guys. Tell me what the big boys with small routers would do in this case today? Even the biggest router has no chance with a billion routes. Or would we have been forced to come up with a new and better replacement for BGP(4) by now that does dynamic intelligent aggregation or something?
-- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Since Ehud got on his soapbox, I thought I'd get on mine as well. When we use IP addresses, there are two distinct purposes they serve. The first is the unique identification (EID) of a machine. The second is the choice of the next hop for routing. If we could split the two parts into separate address spaces, then the current 32 bit address space would be plenty large for EIDs (if you went to 48 bits, then it would be hard to imagine it ever running out.) If the route side of the address space was structured into levels of hierarchy, then the total number of routes anyone would be required to carry would also be far smaller. Unfortunately, I have never seen an acceptable solution to discovering the route path for a random host. It's a real pain, with lookups, tests and redirects all over the place. If anyone has a solution to this that can scale for the next 20-30 years, many people will throw flowers at your feet. Until this happens, the number of bits only skews the balance. The tension between addressing and routability is inherent in the dual use and will continue to drive the allocation system and router design. Jerry
At 09:22 AM 06/10/97 -0500, Phil Howard wrote:
Right. But people see it as such a problem because the routing policies are IP space derived. When people are told they need a /19 to be routable, then they begin to go backwards on solving the IP space problem and resume wasting it (but hiding the waste to look like its used).
But this is somewhat of a misnomer. It is not an issue of being 'routable' v. 'non-routable', but rather, one of whether you can be aggregated into a larger prefix. This practice encourages aggregation -- it is commonly agreed that Aggregation is Good (tm). The routability issue comes into play when: o You are specifically referring to routes being propagated by a service provider who uses prefix-length filters, AND o You cannot be aggregated into a large enough advertised CIDR block to conform to these types of filters.
When the need to justify space usage occurred, along with it came some ideas on actually how to do that. And I see that working. We were projected to run totally out of space by now, and since we have not, I assume it did work pretty well.
BGP4, CIDR, or Die.
But the real problem is routing policies that are encouraging people to go back to wasting space. By using the network size as the criteria for doing route filtering, the smaller guys get screwed and they see their solution as inflating their network. This practice needs to be stopped or a better solution needs to come out of it.
One might suggest that some of the prefix length filter could be replaced by more aggressive dampening policies. - paul
DataXchange is not filtering by prefix, we do occasionally filter out someone who is ping bombing or something, or a cyberpromo site. My routers seem to be able to handle the full table. How many entries are removed by this prefix filtering anyway? Does anyone have a handle on that? Looking at the weekly automated report of the possible gains by aggregating, it apprears to me that a concerted effort by a dozen or so of the top names could reduce the number of table rows by a considerable amount. Best Regards, Robert Laughlin ---------------------------------------------------------------------------- DataXchange sales: 800-863-1550 http://www.dx.net Network Operations Center: 703-903-7412 -or- 888-903-7412 ---------------------------------------------------------------------------- On Tue, 10 Jun 1997, Phil Howard wrote:
Larry Vaden writes...
Does Congress need to pass "must carry" legislation similar to the "any willing provider" medical legislation? IMHO, it would be better that some old dogmas and implementations die and be replaced with efficient, robust code and a rather less limiting view of the future.
Consider the following problem.
Suppose that IP space were not a problem. When IPv6 comes up all around, it certainly won't be then. You can have and waste all the IP space you could imagine, since we'll be numbering every atom in the known universe.
And suppose we have ASNs a plenty.
Would Sprint, Digex, and AGIS still be trying to cut out so many routes?
Are any other ISPs doing this filtering?
-- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Robert Laughlin writes...
DataXchange is not filtering by prefix, we do occasionally filter out someone who is ping bombing or something, or a cyberpromo site. My routers seem to be able to handle the full table. How many entries are removed by this prefix filtering anyway? Does anyone have a handle on that? Looking at the weekly automated report of the possible gains by aggregating, it apprears to me that a concerted effort by a dozen or so of the top names could reduce the number of table rows by a considerable amount.
I'd like to see information that lists the number of routes by sizes and networks announced, detailing whether an announcement is covered by a larger aggregate or not. Is anyone compiling this kind of data? Can filtering be done on the basis of networks covered by aggregate announcements or would that be too complicated to code (I've never coded a router and never seen IOS source). BTW, I fully support filtering specific instances of abuse, leaving it up to the host of the abuser to show what they actually change to reduce their exposure to abusers before the filter would be dropped. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
participants (13)
-
Alec H. Peterson -
Alex.Bligh -
bmanning＠ISI.EDU -
Ehud Gavron -
Jerry Scharf -
Justin W. Newton -
Larry Vaden -
Paul Ferguson -
Peter Giza -
Phil Howard -
Randy Bush -
randy＠psg.com -
Robert Laughlin