[Nanog-futures] NANOG Emai list again...
Thank you for sending this out. It is time for another reminder. Best wishes and thank you for a job well done, Richard Golodner ___ Nanog-futures mailing list Nanog-futures@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: IPv6 Addressing Help
I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp. the swamp preceeded cidr and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. as we are very poor at predicting the future, there was no win to be had in classful. randy
Re: IPv6 Addressing Help
On 15/08/2009, at 4:34 PM, Randy Bush wrote: I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp. the swamp preceeded cidr and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. as we are very poor at predicting the future, there was no win to be had in classful. This is really this basis of my reply, so, I'll just say +1 Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible. -- Nathan Ward
Re: IPv6 Addressing Help
Hi, On Sat, 2009-08-15 at 00:38 -0400, William Herrin wrote: With IPv6 we have more than enough addresses to give a /56 to everybody who needs more than a /60 and a /48 to everybody who needs more than a /56. I don't think this is a good assumption to make. Just because the namespace keylength (where the IP address is the keyvalue) is 96 bits longer than with IPv4, one needs to keep in mind that there will be eventually a shortage of addresses, if only theoretical. A rapidly escalating assignment series like this would place a strong upper bound on the number of routes needed for any one entity regardless of how they grow. Allocating from pools reserved solely for specific prefix sizes should enable the compression of distant TE disaggregation. I think pooling a /32 or /48 or whatever the allocation is like you described is however a good idea. Many of our IPv6 customers however, only want one specific IP address (so they can IPv6-enable their website). We assign those customers /96 subnets, and that seems to be going pretty well. The nice benefit of that is that we can aggregate those as say, a single /64 in our core router without polluting the IGP routes on our border routers (and IPv6 route entries typically use about twice as much memory as IPv4 route entries, so that is important to keep in mind.) I wish the RFCs had something useful to say about how to handle those single IP addressing situations. So far the discussion there is /80 vs /96, but both of those subnets seem wasteful to me. One of our upstream providers hands our border router off a /125 (which is just weird), for these single-ip-needed situations. William -- William PitcockSystemInPlace - Simple Hosting Solutions 1-866-519-6149http://www.systeminplace.net/ Follow us on Twitter: http://www.twitter.com/systeminplace
Re: IPv6 Addressing Help
On Sat, Aug 15, 2009 at 2:34 AM, Randy Bushra...@psg.com wrote: I'm going to contradict you there. Classful addressing had a lot to recommend it. The basic problem we ran in to was that there weren't enough B's for everyone who needed more than a C and there weren't enough A's period. So we started handing out groups of disaggregate C's and that path led to the swamp. the swamp preceeded cidr Randy, Correct. Disaggregate classful blocks overwhelming the routers was part of the problem. CIDR was part of the solution. That's what I said. and, if you had a bit of simple arithmetic clue, you would realize that, unless you are prescient, you will always run out of some classes before others. Of course. That's what reserves are for: a resource you move into place after you discover where it's needed. Whether its a reserve force in a military action, the reserve slack in your unix disk partition or the emergency fund in your bank account, this is a long solved problem in human endeavor. On Sat, Aug 15, 2009 at 3:03 AM, Nathan Wardna...@daork.net wrote: Read about how sparse allocation/binary chop stuff works. You get the same amount of routes in your IGP table (or less) but it's much more flexible. Sparse allocation says that you maximize the potential expansion of an allocation by simply changing its netmask. That means your first two allocations go at 0% and 50% (allowing either to expand to half your space), your next two go at 25% and 75% (allowing any to expand to 1/4th of your space) and so on. Let's try some of Randy's simple arithmetic on sparse allocation. Start with: /32 Sparsely allocate 200 /56's Total remaining space: in excess of /33. In fact, you haven't consumed a single /48. Expandability by altering the netmask: to /40 Largest allocation still possible: only /40 See the problem? You've eaten 8 bits of capability long before you've consumed even half of your space. In fact, when you do consume close to half your space, the largest remaining block is a meager /47 and your expandability of all those /56's is only to /47. Software developers very rarely fragment a resource pool on purpose because of precisely this problem. On the other hand, consider an escalating pools (aka classful) scenario: /32 broken into four pools: /34 for the /60 pool /34 for the /56 pool /34 for the /48 and larger pool /34 for the reserve pool Assume that: 90% of allocations are /60 9.9% are /56 0.1% are /48 or larger 100,000 allocations into this strategy you haven't tapped the reserve pool and it's probably still possible for you to allocate a /35 from the /48+ pool. And the price for this structure is that a small number of the registrants will have more than 1 but less than 4 routes (one each of /60, /56 and /48+) as opposed to sparse allocation improves the probability that they'll have only 1 route. On the other hand, 100,000 allocations in to the fore-mentioned sparse allocation, while there's a higher probability of each user having only 1 route, the largest users will need many more than 1. You've used a total of /42, maybe a little more of your space but your largest remaining free space is only /48. So if you need to accomodate a /44 customer, you'll have to give him 16 discontiguous /48's. Sparse is a farce. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: TransAtlantic 40 Gig Waves
In November 24th 2008 Sunet together with Telia and Sprint reached 40Gb on one wavelength using TAT-14. The total length for the project was 9600 kilometers (the length of Sweden plus TAT-14). The Swedish article can be found here http://techworld.idg.se/2.2524/1.215856/sunet-forst-med-40-gigabit-per-sekund-under-atlanten
Re: Follow up to previous post regarding SAAVIS
Keith Medcalf wrote: ... Dont know what web 2.0 is but the new portal is a web based object management system complete with recommended changes and inconsistency lists. We just added prefix allocation check with backend information from PCH (prefix checker tool). Web 2.0 is marketroid drivel-speak for a method of continuing to ensure that Web Applications are uninspectable and unsecurable. It is based on doing partial document refreshes using code executing within the browser, usually in such a fashion that it modifies the document tree directly through foreign (ie, from the net) code execution in the context of the current user (or, because of the zillions of holes in those browsers supporting code execution, with the priviledges of the OS itself). It is highly insecure and cannot be secured by any products currently available. It is best to stay as far as possible from anything claiming that it is Web 2.0. Hallmarks of Web 2.0 are gratuitous javascript and java applications which cannot be disabled. Enabling any type of even minimal security on any web site that is Web 2.0 buzzword compliant results in the display of completely blank pages. Web 2.0 pages will indirect all hyperlinks and navigation through javascript. Not because it provides anything useful but rather in order to force people to enable dangerous crap in their browsers (javascript, java, Flash Virus, c) Their are people who do understand how to do these things right. It's called progressive enhancement. [0] [1] Which means you don't need any fancy stuff to be able to use it or read the content, but if you have support for it, it will add extra convenience-features like search suggestions. Also in certain ways things are starting to improve for example the HTML5 spec has a video-tag [2] that's the only kinda of useful thing Flash is used for these days. Their is SVG and Canvas- tag in the HTML5-spec as well, which means even less reason to use plugins. The Chrome browser uses seperate processes with less priviledges to render the pages and run scripts and plugins. I'm just saying it's not all bad. [0] http://en.wikipedia.org/wiki/Progressive_enhancement [1] http://www.alistapart.com/articles/understandingprogressiveenhancement/ [2] Some may say, but their are no codecs specified, but the same is true for images, etc. and I think images did pretty well [3] http://en.wikipedia.org/wiki/Google_Chrome#Security
ADMIN: List FAQ/Monthly Post.
This 100-line document contains 62% of what you need to know to avoid annoying 10,000 people in your email to the NANOG list. It also contains pointers to another 23%. Please take 5 minutes to read it before you post [again]. General Information === About NANOG:http://www.nanog.org/about/ NANOG News: http://www.nanog.org/ NANOG lists and AUP:http://www.nanog.org/mailinglist/ NANOG List FAQ: http://www.nanog.org/mailinglist/listfaqs/ To Subscribe or Unsubscribe from the list: http://mailman.nanog.org/mailman/listinfo/nanog To contact the list's admins: adm...@nanog.org Posting Policy == The NANOG list has over 10,000 subscribers so it is very easy for a thread to have scores of posts while being off-topic and only of interest to only a small proportion of subscribers. Please consider before each post if your email will be of interest to the majority of members or might alternatively be emailed directly the people of interest or posted to another forum. Please read the FAQ and AUP policy before posting for more details. Especially the following are discouraged: * Is a certain site down? Other Outages not affecting half the Internet. Please use http://downforeveryoneorjustme.com/ or a similar site. Please post to the Outages mailing list: http://wiki.outages.org * Spam Please use SPAM-L - http://spam-l.com/mailman/listinfo * Contacting People * http://puck.nether.net/netops/ * http://www.peeringdb.com * Please try other methods of contacting sites before you post to NANOG. Saying something like I tried calling 213-555- but no answer shows you _have_ tried alternative methods first. * Political Issues * Topics such as ICANN policy, Government Policy or Law changes that do not have short term Operational impact should be avoided. * Operation topics with more specific lists * DNS - http://lists.oarci.net/mailman/listinfo/dns-operations * Email - http://www.mailop.org/ * NANOG Mailing list policy Please use the nanog-futures list or contact adm...@nanog.org Please also avoid = * Sending posts to the list relevant to only one or two people on this list, such as tests or traceroutes in response to another post for comparison to those originally posted. * Jokes, Puns, amusing observations, spelling corrections. Other NANOG related lists = * NANOG-futures - for discussion of the evolution of NANOG, including organizational structure, policies and procedures, and agendas for NANOG meetings. Such topics aren't appropriate for the main NANOG mailing list. http://mailman.nanog.org/mailman/listinfo/nanog-futures * nanog-attendee - For discussion of venue-specific issues relevant to attendees of the current NANOG physical meeting. http://mailman.nanog.org/mailman/listinfo/nanog-attendee * nanog-announce - For announcements of NANOG meetings an other Important NANOG related announcements. Low traffic and all posts are also sent to main list. http://mailman.nanog.org/mailman/listinfo/nanog-announce Other Mailing Lists === Information about related lists: http://www.nanog.org/mailinglist/listfaqs/otherlists.php
