Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On (2014-06-10 12:39 -0500), Blake Hudson wrote: > Please correct me if I'm wrong, but if the BGP table contains ~500k > prefixes, which are then summarized into ~300k routes (RIB), and the FIB > contains only the "best path" entries from the RIB, wouldn't the FIB be at > or below 300k? There is nothing to summarize away from global BGP table, if you have number showing less, it's probably counter bug or misinterpretation. Global BGP table, single BGP feed, will take same amount of RIB and FIB. You can see your FIB use in 'show plat hard capa pfc': #show platform hardware capacity pfc Module FIB TCAM usage: TotalUsed %Used 2 72 bits (IPv4, MPLS, EoM) 884736 712819 81% 144 bits (IP mcast, IPv6) 8192019235 23% You're probably bit better off than I am :) -- ++ytti
RE: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
FIB is not the same as RIB... Perfectly happy 6509, many paths, only one full table in the FIB: BGP router identifier XXX , local AS number 11404 BGP table version is 40916063, main routing table version 40916063 494649 network entries using 71229456 bytes of memory 886903 path entries using 70952240 bytes of memory 29 multipath network entries and 58 multipath paths -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Tony Wicks Sent: Tuesday, June 10, 2014 6:45 PM To: 'nanog' Subject: RE: Getting pretty close to default IPv4 route maximum for 6500/7600 routers. My 2c: The obvious thing for me is if people are running a full ipv4 route table on a box only just capable of handling one single table of that size, then really now is the time to asses if you really need to hold that table or just drop to default +internal+peers. If you have multiple up streams and you are using the route tables to do your route selection then great, but that means you need at least 1M capability now, and really 2+ should be your target. In my experience people running a full table on a small capability box normally don't actually need to carry it, or they just need a bigger box.
RE: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
My 2c: The obvious thing for me is if people are running a full ipv4 route table on a box only just capable of handling one single table of that size, then really now is the time to asses if you really need to hold that table or just drop to default +internal+peers. If you have multiple up streams and you are using the route tables to do your route selection then great, but that means you need at least 1M capability now, and really 2+ should be your target. In my experience people running a full table on a small capability box normally don't actually need to carry it, or they just need a bigger box.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
as many people will be hitting the wall on all sorts of platforms, perhaps it's wiki time. or have i just missed it? randy
NANOG 62 and a new tool for presentation submissions
Today we began an upgrade to the site/tool located at pc.nanog.org, known as the pc tool, which is designed to allow the community to propose talks for the next NANOG. The new site has some of the latest fads in web 2.0 web design and buzzwords, for instance we've decided to use a programming language with silent "d" in the name. Don't worry, it's somewhere short of having tag clouds. We hope you like it. Or at least, we hope not too many of you despise it. Please hold of on any talk submissions for a few days while we migrate the data from the old tool to the new. The NANOG Program Committee will issue the NANOG61 call for presentations shortly, marking the availability of the new tool. Thanks, -e -- Eric Oosting Network Architect eoost...@netuf.net | 404-941-6678
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On Tue, Jun 10, 2014 at 11:36 AM, Blake Hudson wrote: > > joel jaeggli wrote the following on 6/10/2014 1:10 PM: > > On 6/10/14, 10:39 AM, Blake Hudson wrote: >> >>> Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: >>> Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson wrote: In this case, does the 512k limit of the 6500/7600 refer to the RIB > or the FIB? And does it even matter since the BGP prefix table can > automatically be reduced to ~300k routes? > Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for 1M IPv4 prefixes. You can find more information here: http://www.cisco.com/c/en/us/support/docs/switches/ catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html And yes, you’re right - no matter how many neighbors you have, the FIB will only contain best paths, so it will be closer to 500k entries in total rather than N times number of neighbours. Please correct me if I'm wrong, but if the BGP table contains ~500k >>> prefixes, which are then summarized into ~300k routes (RIB), >>> >> Unlikely, just because prefixes could be cidr aggregated doesn't mean >> they are. the more specifics exist for a reason, in the case of >> deaggrates with no covering anouncement, well not much you're doing with >> those. >> >> your rib should be the sum of all received routes that you did not filter. >> > On the couple Cisco platforms I have available with full tables, Cisco > summarizes BGP by default. Since this thread is talking about Cisco gear, I > think it's more topical than results from BIRD. > > One example from a non-transit AS: > ASR#sh ip route sum > IP routing table name is default (0x0) > > IP routing table maximum-paths is 32 > Route SourceNetworksSubnets Replicates OverheadMemory > (bytes) > connected 0 10 0 600 1800 > static 1 2 0 180 540 > application 0 0 0 0 0 > bgp x 164817 330796 0 2973678089210340 > External: 495613 Internal: 0 Local: 0 > internal 579920123680 > Total 170617 330808 0 29737560109336360 > > I'm not sure you're reading that correctly. 164817+330796 = 495613 That is, the BGP routing table size is the union of the "Networks" and the "Subnets"; it's not magically doing any summarization for you. Matt
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On Tuesday, June 10, 2014 08:07:35 PM Łukasz Bromirski wrote: > Because you need to do your own summarization or ask your > upstreams to do it for you. Until then, most of transit > accepts loosely prefixes in exact length but also longer > (i.e. /24 but also both /25s). A couple of major service providers today permit announcements of any length, provided they are registered in an IRR that they use to build filters. Of course, there are no guarantees that prefixes typically longer than general industry practice permits will see the light of day beyond their network. Mark. signature.asc Description: This is a digitally signed message part.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
joel jaeggli wrote the following on 6/10/2014 1:10 PM: On 6/10/14, 10:39 AM, Blake Hudson wrote: Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson wrote: In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for 1M IPv4 prefixes. You can find more information here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html And yes, you’re right - no matter how many neighbors you have, the FIB will only contain best paths, so it will be closer to 500k entries in total rather than N times number of neighbours. Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, which are then summarized into ~300k routes (RIB), Unlikely, just because prefixes could be cidr aggregated doesn't mean they are. the more specifics exist for a reason, in the case of deaggrates with no covering anouncement, well not much you're doing with those. your rib should be the sum of all received routes that you did not filter. On the couple Cisco platforms I have available with full tables, Cisco summarizes BGP by default. Since this thread is talking about Cisco gear, I think it's more topical than results from BIRD. One example from a non-transit AS: ASR#sh ip route sum IP routing table name is default (0x0) IP routing table maximum-paths is 32 Route SourceNetworksSubnets Replicates OverheadMemory (bytes) connected 0 10 0 600 1800 static 1 2 0 180 540 application 0 0 0 0 0 bgp x 164817 330796 0 2973678089210340 External: 495613 Internal: 0 Local: 0 internal 579920123680 Total 170617 330808 0 29737560109336360 and the FIB contains only the "best path" entries from the RIB, wouldn't the FIB be at or below 300k? a live example of rib size from a router with two transit providers. bird> show route count 979842 of 979842 routes for 490932 networks a live example of rib size from a router with one ibgp peer with addpath and three upstream transit providers bird> show route count 1471242 of 1471242 routes for 491977 networks The RIB counts and memory used by the RIB seem to be nearly identical between a Cisco router with 3 full BGP feeds and another with 1 BGP feed. The differences seem to lie in the memory used by BGP for prefix tracking. If your router has multiple routing tables, or your installing multiple routes for the same prefix in the RIB, then I can understand why your RIB will be larger. These are nice features, but certainly not a requirement for everyone. --Blake
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On 6/10/14, 10:39 AM, Blake Hudson wrote: > > Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: >> Hi Blake, >> >> On 10 Jun 2014, at 19:04, Blake Hudson wrote: >> >>> In this case, does the 512k limit of the 6500/7600 refer to the RIB >>> or the FIB? And does it even matter since the BGP prefix table can >>> automatically be reduced to ~300k routes? >> Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 >> Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for >> 1M IPv4 prefixes. >> >> You can find more information here: >> >> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html >> >> >> And yes, you’re right - no matter how many neighbors you have, the FIB >> will only contain best paths, so it will be closer to 500k entries in >> total rather than N times number of neighbours. >> > > Please correct me if I'm wrong, but if the BGP table contains ~500k > prefixes, which are then summarized into ~300k routes (RIB), Unlikely, just because prefixes could be cidr aggregated doesn't mean they are. the more specifics exist for a reason, in the case of deaggrates with no covering anouncement, well not much you're doing with those. your rib should be the sum of all received routes that you did not filter. > and the FIB > contains only the "best path" entries from the RIB, wouldn't the FIB be > at or below 300k? a live example of rib size from a router with two transit providers. bird> show route count 979842 of 979842 routes for 490932 networks a live example of rib size from a router with one ibgp peer with addpath and three upstream transit providers bird> show route count 1471242 of 1471242 routes for 491977 networks > > --Blake > signature.asc Description: OpenPGP digital signature
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On 10 Jun 2014, at 19:39, Blake Hudson wrote: >> And yes, you’re right - no matter how many neighbors you have, the FIB >> will only contain best paths, so it will be closer to 500k entries in >> total rather than N times number of neighbours. > Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, > which are then summarized into ~300k routes (RIB), and the FIB contains only > the "best path" entries from the RIB, wouldn't the FIB be at or below 300k? Because you need to do your own summarization or ask your upstreams to do it for you. Until then, most of transit accepts loosely prefixes in exact length but also longer (i.e. /24 but also both /25s). You’ll see more and more deaggregation with the rise of smaller entities fighting for chance to do some traffic engineering, so be prepared to constant rise of prefixes overall. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about." John von Neumann |http://lukasz.bromirski.net
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Hello, On 10.6.2014 19:04, Blake Hudson wrote: > I haven't seen anyone bring up this point yet, but I feel like I'm > missing something... > I receive a full BGP table from several providers. They send me ~490k > *prefixes* each. However, my router shows ~332k *subnets* in the routing > table. As I understand it, the BGP table contains duplicate information > (for example a supernet is announced as well as all subnets within that > supernet) or excess information (prefix is announced as two /17's > instead of a single /16) and can otherwise be summarized to save space > in the RIB. many people deaggregate their address space purposely, including large networks like Google, Akamai, Netflix etc. Full list for analysis like "who does that" is available at http://www.cidr-report.org/as2.0/aggr.html These days also some people split their allocated aggregatable space (PA) with different routing policies for each subnet, substituting old PI addresses (at least in RIPE region). Technically nothing blocks this and politically - it's up to each, what accepts. But some unreachable subnet means problems with customers... There's no summarization in hardware/software from RIB to FIB. From the vendor perspective, they would like to sell you new hardware with larger TCAMs/etc, of course... :-) With regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Łukasz Bromirski wrote the following on 6/10/2014 12:15 PM: Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson wrote: In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for 1M IPv4 prefixes. You can find more information here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html And yes, you’re right - no matter how many neighbors you have, the FIB will only contain best paths, so it will be closer to 500k entries in total rather than N times number of neighbours. Please correct me if I'm wrong, but if the BGP table contains ~500k prefixes, which are then summarized into ~300k routes (RIB), and the FIB contains only the "best path" entries from the RIB, wouldn't the FIB be at or below 300k? --Blake
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
On 6/10/14, 10:15 AM, Łukasz Bromirski wrote: > Hi Blake, > > On 10 Jun 2014, at 19:04, Blake Hudson wrote: > >> In this case, does the 512k limit of the 6500/7600 refer to the RIB or the >> FIB? And does it even matter since the BGP prefix table can automatically be >> reduced to ~300k routes? > > Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 > Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for > 1M IPv4 prefixes. > > You can find more information here: > > http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html > > And yes, you’re right - no matter how many neighbors you have, the FIB > will only contain best paths, so it will be closer to 500k entries in > total rather than N times number of neighbours. Until you add multi-as multipath and addpath and a couple VRFs and all of sudden FIB budget blows up. signature.asc Description: OpenPGP digital signature
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
Hi Blake, On 10 Jun 2014, at 19:04, Blake Hudson wrote: > In this case, does the 512k limit of the 6500/7600 refer to the RIB or the > FIB? And does it even matter since the BGP prefix table can automatically be > reduced to ~300k routes? Te 512k limit refers to FIB in the B/C (base) versions of 6500/7600 Supervisors and DFCs (for line cards). BXL/CXL versions have FIB for 1M IPv4 prefixes. You can find more information here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html And yes, you’re right - no matter how many neighbors you have, the FIB will only contain best paths, so it will be closer to 500k entries in total rather than N times number of neighbours. -- "There's no sense in being precise when | Łukasz Bromirski you don't know what you're talking | jid:lbromir...@jabber.org about." John von Neumann |http://lukasz.bromirski.net
Re: Getting pretty close to default IPv4 route maximum for 6500/7600 routers.
I haven't seen anyone bring up this point yet, but I feel like I'm missing something... I receive a full BGP table from several providers. They send me ~490k *prefixes* each. However, my router shows ~332k *subnets* in the routing table. As I understand it, the BGP table contains duplicate information (for example a supernet is announced as well as all subnets within that supernet) or excess information (prefix is announced as two /17's instead of a single /16) and can otherwise be summarized to save space in the RIB. It appears to me that the weekly CIDR report shows similar numbers: Recent Table History Date PrefixesCIDR Agg 30-05-14502889 283047 31-05-14502961 283069 01-06-14502836 283134 02-06-14502943 283080 03-06-14502793 283382 04-06-14503177 282897 05-06-14503436 283062 06-06-14503988 282999 In this case, does the 512k limit of the 6500/7600 refer to the RIB or the FIB? And does it even matter since the BGP prefix table can automatically be reduced to ~300k routes? Thanks, --Blake Drew Weaver wrote the following on 5/6/2014 10:39 AM: Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew
Re: question about bogon prefix
On Tue, Jun 10, 2014 at 12:57 AM, Robert Drake wrote: > > > My guess is one of two things. Maybe they renumbered out of the /20 but > left a VPN server up and haven't managed to migrate off it yet, but they > have asked to return the block.. or, they forgot to pay their bill to ARIN > and the block has been removed from whois but Qwest isn't as diligent > because they're still being paid. > This brings up a good point which came to mind recently. What process(es) do folks use for cases where an address block and/or ASN seems no longer have whois info associated (eg. where authorization to use may have been revoked)? Do the RIRs have a process for notifying the community or at least the upstream providers that something has changed? Thanks for insight from the community. Tony
End of IPv4 addresses in LAC region
It has been just announced in LAC network operator mailing lists that the LAC region just crossed the /10 boundary, triggering exhaustion policies that now only allow assignments of /22 IP address blocks, either for initial assignments or additional requests. Next in line, ARIN region. Is February 2015 still the most likely guess ? Rubens
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On (2014-06-10 10:28 +), Bjoern A. Zeeb wrote: > You mean it’s more likely people acquire/merge with other companies for IP > space then go through transfer? https://www.arin.net/knowledge/statistics/ I mean that demand for IPv4 addresses will continue to foreseeable future, if you are offering content, and there is difference between reach for IPv6 and IPv4+IPv6, you're going to want to acquire some IPv4 addresses to avoid giving your competition an unfair advantage. How will this reflect to price, you imply price of IPv4 address is going to decrease, I expect it's not reached peak yet, due to still having RIR availability which sets natural limit to price. -- ++ytti
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On 10 Jun 2014, at 10:10 , Saku Ytti wrote: > On (2014-06-10 09:41 +), Bjoern A. Zeeb wrote: > >> IPv4 addresses have little commercial value anymore and IPv6 is basically >> free. The only people who still haven’t realised don’t have enough money to >> spend on IPv4 to keep themselves alive for another decade. > > Wishing how markets should be and how markets are in this instance are > divergent. You mean it’s more likely people acquire/merge with other companies for IP space then go through transfer? https://www.arin.net/knowledge/statistics/ — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On (2014-06-10 09:41 +), Bjoern A. Zeeb wrote: > IPv4 addresses have little commercial value anymore and IPv6 is basically > free. The only people who still haven’t realised don’t have enough money to > spend on IPv4 to keep themselves alive for another decade. Wishing how markets should be and how markets are in this instance are divergent. -- ++ytti
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On 10 Jun 2014, at 05:48 , Andrew Jones wrote: > Even if the first numbers were correctly calculated, they don’t allow for > further deaggregation of already advertised prefixes, which shouldn't be > underestimated as the commercial value of each address increases... IPv4 addresses have little commercial value anymore and IPv6 is basically free. The only people who still haven’t realised don’t have enough money to spend on IPv4 to keep themselves alive for another decade. — Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
Ah. I had to ³no mls cef max ip² and ³no mls def max mpls² for it to share. They were previously adjusted separately. :) Thanks. On 6/10/14, 3:12 AM, "John van Oppen" wrote: >On the sup 720 they become unshared if you carve v4 away from the default >separately, that is why I carve the other two instead.
RE: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On the sup 720 they become unshared if you carve v4 away from the default separately, that is why I carve the other two instead.
Re: Getting pretty close to default IPv4 route maximum for 6500/7600routers.
On the RSP720-10GE at least, it seems that IPv4 and MPLS are not shared. Am I correct or am I missing something? FIB TCAM maximum routes : === Current :- --- IPv4- 768k MPLS- 64k IPv6 + IP Multicast - 96k (default) Randy On 6/9/14, 3:27 PM, "John van Oppen" wrote: >It is generally much better to do the following: > >mls cef maximum-routes ipv6 90 >mls cef maximum-routes ip-multicast 1 > >This will leave v4 and mpls in one big pool, puts v6 to something useful >for quite a while and steals all of the multicast space which is not >really used on most deployments. > > >This gives us the following (which is pretty great for IP backbone >purposes in dual stack): > >#show mls cef maximum-routes >FIB TCAM maximum routes : >=== >Current :- >--- > IPv4 + MPLS - 832k (default) > IPv6- 90k > IP multicast- 1k > > >John > > >-Original Message- >From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jon Lewis >Sent: Monday, June 09, 2014 12:10 PM >To: Pete Lumbis >Cc: nanog@nanog.org >Subject: Re: Getting pretty close to default IPv4 route maximum for >6500/7600routers. > >Why, in your example, do you bias the split so heavily toward IPv4 that >the router won't be able to handle a current full v6 table? I've been >using > >mls cef maximum-routes ip 768 > >which is probably still a little too liberal for IPv6 > >FIB TCAM maximum routes : >=== >Current :- >--- > IPv4- 768k > MPLS- 16k (default) > IPv6 + IP Multicast - 120k (default) > >given that a full v6 table is around 17k routes today. > >A more important question though is how many 6500/7600 routers will fully >survive the reload required to affect this change? I've lost a blade >(presumably to the bad memory issue) each time I've rebooted a 6500 to >apply this. > >On Mon, 9 Jun 2014, Pete Lumbis wrote: > >> The doc on how to adjust the 6500/7600 TCAM space was just published. >> >> http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-serie >> s-switches/117712-problemsolution-cat6500-00.html >> >> >> On Tue, May 6, 2014 at 3:48 PM, Pete Lumbis wrote: >> >>> There is currently a doc for the ASR9k. We're working on getting on >>> for >>> 6500 as well. >>> >>> >>> http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-agg >>> regation-services-routers/116999-problem-line-card-00.html >>> >>> >>> >>> >>> On Tue, May 6, 2014 at 1:34 PM, wrote: >>> I would like to see Cisco send something out... -Original Message- From: "Drew Weaver" Sent: ÿÿ5/ÿÿ6/ÿÿ2014 11:42 AM To: "'nanog@nanog.org'" Subject: Getting pretty close to default IPv4 route maximum for 6500/7600routers. Hi all, I am wondering if maybe we should make some kind of concerted effort to remind folks about the IPv4 routing table inching closer and closer to the 512K route mark. We are at about 94/95% right now of 512K. For most of us, the 512K route mark is arbitrary but for a lot of folks who may still be running 6500/7600 or other routers which are by default configured to crash and burn after 512K routes; it may be a valuable public service. Even if you don't have this scenario in your network today; chances are you connect to someone who connects to someone who connects to someone (etc...) that does. In case anyone wants to check on a 6500, you can run: show platform hardware capacity pfc and then look under L3 Forwarding Resources. Just something to think about before it becomes a story the community talks about for the next decade. -Drew >>> >> > >-- > Jon Lewis, MCP :) | I route > | therefore you are _ >http://www.lewis.org/~jlewis/pgp for PGP public key_
