August 1995 - Test - lists.nanog.org

Re: One alternative to CIDR... ASAP
by jnc＠ginger.lcs.mit.edu 14 Aug '95

14 Aug '95

From: Tim Bass <bass(a)linux.silkroad.com> Here is a very rough strawman idea just posted to the CIDRD-WG. ... Autonomous System Aggregation Protocol Without commenting on the technical details (I've always held that mapping from IPv4 addresses to something else is one way to provide routing that scales, as well as "portable" IPv4 "addresses"), let me just point out that this scheme requires a certain amount of protocol development and documentation, as well as implementation and deployment. As well all have seen, the Internet seems to have a hard time doing that in less than three years, flat out. Also, the CIDR RFC (RFC-1519, 1993, three years ago) explicitly says: the Internet ... is soon to face several serious scaling problems. These include: ... Growth of routing tables in Internet routers ... It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism to slow the growth of the routing table In other words, the growth of the routing tables was seen as a problem even then, and CIDR (and "supernetting") was the solution that was proposed, in a timely fashion, to that problem. RFC-1519 goes on to note: The proposed solution is to topologically allocate future IP address assignment ... this plan neither requires nor assumes that already assigned addresses will be reassigned ... routing technology will be capable of dealing with the current routing table size and with some reasonably small rate of growth. If this was an unacceptable solution, the time to say so, and make alternate plans, was back then. We've put a lot of code in place assuming that this was going to be the way we solved this problem, and it's very late in the game to say "oops, not the right approach". Noel

1 0

Re: One alternative to CIDR... ASAP
by Vince Fuller 13 Aug '95

13 Aug '95

People keep sending me e-mail asking for my ideas on alternatives to renumbering and CIDR. Here is a very rough strawman idea just posted to the CIDRD-WG. There are similar variations on this ASN routing paradigm that also could be considered: I'd suggest that those considering this proposal also peruse the archives of the IPAE mailing list, since IPAE (IP Address Encapsulation) was, at least in its earlies form, precisely this - a mechanism for encapsulating IP addresses in such a way as to create an inter-AS routing scheme using a separate, 32-bit address space. If memory serves, there have also been other earlier proposals for doing AS-to-AS routing using either a separate address space or using IP options - I believe the Big-Internet mailing list archives contains volumnous discussion of these techniques. Re-inventing a square wheel doesn't make it roll any better... --Vince

1 0

Re: routing meltdown
by Sean Doran 13 Aug '95

13 Aug '95

| Knowing Sean for who he is, I'm fairly sure that no RADB or RS will ever be | suitable to him. In particular... On the contrary; I believe Peter Lothberg's proposals for an RS scheme are quite reasonable. I think his criticisms of the current RADB and RS models are pretty well known, and valid. I would point out one more thing though, and that's that at the Stockholm IETF I had a genial chat with a number of folks from MERIT and the RA Team in general, and suggested several ways that the RADB could be made incrementally useful. I hope that some good comes out of that conversation. I'll use any tool that will make my job easier, and help our operation and the Internet scale better. At the moment, though, the RADB does the opposite, and the RS has no value whatsoever. Sean.

1 0

Re: routing meltdown
by Vadim Antonov 13 Aug '95

13 Aug '95

>What you want is something that isn't the Internet or even >a hop-by-hop destination-based connectionless packet network, >but rather something akin to X.25 or ATM. > Sean. ...which requires even more state kept in gateways, and therefore more CPU required to maintain that state. Film at 11. --vadim

3 2

One alternative to CIDR... ASAP
by Tim Bass 13 Aug '95

13 Aug '95

Friends: People keep sending me e-mail asking for my ideas on alternatives to renumbering and CIDR. Here is a very rough strawman idea just posted to the CIDRD-WG. There are similar variations on this ASN routing paradigm that also could be considered: VR, Tim PS: I'm off to the Azores in Portugal Monday for three weeks, so hopefully I can find net access to see how much of a flame-fest my mbox is enjoying..... ***************************************************************** STRAWMAN Autonomous System Aggregation Protocol (ASAP) --------------------------------------------- Too simple, by a simple minded person.... :-) 1) Modify IP code in routers to route with ASN numbers between AS; 2) Modify core routers to add ASN numbers to IP packets by; i.) Temporarily using TOS or similar field(s) in IP header; ii.) Add proper hooks in next version of IP; iii.) Some better idea. 3) Develop details of new routing algorithm to route, filter, load balance, multi-home using ASN tags; 4) Modify core routers to add ASN tags to IP packets that do not have ASN tags assigned by originating host (for backwards compatability with version of TCP/IP that cannot add their ASN numbers to IP headers (or a better idea); 5) Modify core routers to transfer routing from the ASAP protocol to the appropriate IGP if-and-only-if ASN of destination matches the current ASN; 6) Create simple UDP based algorithm (similar to DNS) that manages a distibuted database that maps IP addresses to ASN numbers. For example: When sending a packet, the kernal checks its cache for a map between the IP address and ASN number. If it existing is the cache (get a hit) it adds the ASN destination number to the IP header..... if not the router or host sends a UDP packet to a distributed database that maintains the mappings.. (these could be local, remote, but distributed and caching each other ... in a similar, but more efficient manner than DNS (after all how often do IP networks change their home ASN) (instead of ARP.... its ASNRP...... ;-) 7) Create another database of SUPERNETTED ASN numbers for IP service providers that aggregate current ASN numbers into some meaningful structure and provide distribued SUPER-ASN to SUPER-ASN routing. 8) More ideas to develop and refine.... Advantages: 1) IP address space allocation is simplifed and renumbering not necessary; 2) ASN routing reduces the size of the routing tables ; 3) SUPER-ASN routing further reduces the size of ASAP routing tables; 4) Routers can add ASN tags to IP packets until users migrate to new IP kernels; 5) More.... but I'm packing for a trip... Disadvantages: 1) Must create new ASAP protocol and SUPER-ASAP protocol; 2) Must create distributed ASN-NETWORK database; 3) IP code must be modified and upgraded; 4) Non-cached initial packets will route slower mapping destination ASN to destination IP address. 5) Also more disadvantages..... Just a start.... needs work.... but living in a plane is a real drain.. :-) Tim +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+

1 0

Re: $320 for a .com domain registration?
by Hank Nussbacher 13 Aug '95

13 Aug '95

On Sat, 12 Aug 1995 00:02:35 -0700 (PDT) you said: > >I just finished browsing http://www.britain.eu.net/naming-co/couk-form.html >which is the registration form for the .co.uk domain. They charge 300 >pounds for each domain registered, approximately $320 is US funds. > >Comments? > >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael(a)memra.com > Just for comparison, we in Israel charge $50USA one-time fee for a domain in the co.il, org.il, ac.il, etc. domain. Hank

1 0

$320 for a .com domain registration?
by Michael Dillon 12 Aug '95

12 Aug '95

I just finished browsing http://www.britain.eu.net/naming-co/couk-form.html which is the registration form for the .co.uk domain. They charge 300 pounds for each domain registered, approximately $320 is US funds. Comments? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael(a)memra.com

4 4

Re: routing meltdown
by Hank Nussbacher 12 Aug '95

12 Aug '95

On Fri, 11 Aug 1995 18:10:12 -0400 you said: > Sean. > >P.S.: I seem to have misplaced my copy of Radia Perlman's > _Bridges and Routers_. Does anyone have the ISBN handy? Try the Jan 1988 IEEE Network issue for many definitive articles on routers vs bridges. 2 articles by Radia as well as others on this list. Hank

1 0

Re: routing meltdown
by Barney Wolff 12 Aug '95

12 Aug '95

> Date: Fri, 11 Aug 95 21:41:35 -0700 > From: Paul A Vixie <paul(a)vix.com> > > N**2 BGP4 sessions are bad for likely values of N (100, maybe.) That won't > change just because we've got a 1GB-RAM DEC Alpha with a 300MHz processor > instead of a Cisco to do our route processing. N**2 BGP4 sessions is a bad > design no matter what you're implementing it with. In that sense, your idea > is not "viable" since it doesn't solve some of the real problems coming up. Is N**2 sessions on N hosts really so bad? Am I missing something here? Since only the hosts are aware of the sessions, I don't see N**2 as a problem. Is the rate of updates dependent on the number of peers, or on the rate of real changes in the real networks? Barney Wolff <barney(a)databus.com>

1 0

Re: routing meltdown
by Nicolas Williams 12 Aug '95

12 Aug '95

If the problem we're talking about is that the large number of paths that an exchange point router will soon be seeing is too large, and having a single route-server at each exchange is not politically acceptable, then here is a possible solution. One way to cut down the number of paths each XP router sees would be for every XP NSP/ISP/whatever to install a router _and_ a BGP4 "proxy" server. Meaning that each XP router would peer via IBGP with a large (64-128MB of RAM) computer, which in turn would peer, via EBGP, with all of that AS' peers' routers or router servers. This way each XP router so configured would have as many paths learned at the XP as it would have routes learned at the XP, which would be a substantial reduction from the number of paths most XP routers tend to carry nowadays; the computer next to the router would be the one to absorb the heavy load of handling so many neighbors, routes and paths, and these computers can be upgrade with more ease than can the routers. This approach has two major benefits: - The load on the XP routers would be lowered considerably by relieving the router of part of the path selection process as well as the need to have enough memory to carry hundreds of thousands of paths. The pressure on router vendors to beef up their products "path" capacity would be considerably reduced, thus lowering router costs in the long run. - NAP members would be freed from having to wait for their router vendor to implement better route filtering features. After all, each member would then have better control over the software used for the BGP4 server (there's gated, there could be new PD/free/shareware BGP4 router daemons, or even commercial ones if everyone tried this setup), able, perhaps, to hack their BGP4 daemon any which way they desire. A Pentium-class PC running some sort of Unix or Unix-like OS, or a Sun or DEC Alpha, or something like that, populated with 64MB of RAM or more would do for such a server; these, unlike Cisco routers, tend to be easily upgradable to larger amounts of RAM or faster CPUs too! If you think about it, freeing ourselves from our router vendors' BGP4 limitations would allow more experimenting with route dampening, and even a model that allows for some temporary entropy within the /18 model. For example, a BGP4 daemon could be developped that keeps track of each prefix's routing flap, thus allowing policies that filter unstable prefixes/paths, or that would temporarily allow in prefix announcements that are too long (this would allow a /18+Entropy model, which would help ASes deal with rare AS partitioning incidents and the like). The number and size of holes in large aggregates could also be controlled; a policy could specify that no more than 4 /24 holes in /18s be accepted for example. All of the above features would take some time before they are implemented, but it would probably be less than the time it would take router vendors (after all, many of us would have an interest in helping to develop these features). One other, less important, benefit of doing this would be that of saving router vendors the headache of having to add more and more CPU and RAM capacity to their routers. Why would this be good? Well, IPv6, if it ever is accepted by the Internet (and I bet it will be), will only requiere XP routers to carry a few hundred routes at most (IPv6 would be used with CIDR from the beginning), wasting, as a result, the large amounts of RAM and fast CPUs everyone will have put in their XP routers by the time IPv6 replaces IPv4; general purpose servers can easily be reused, and if anything, are far less expensive than large routers. NAPs could even segregate all BGP4 traffic off of the FDDI or ATM switches, since member's XP route servers could be configured to peer over a lower bandwidth, separate LAN. Would this exchange point configuration be acceptable? Nick PS: A Cisco 4500 with two high speed interface boards and one ether card, along with a Pentium-class, 128MB box in a small case with no monitor or keyboard and with one ethernet interface would be enough of a start up kit for most NAP newcomers and it would all fit in the limited rack space Sprint offers at its NAP. I'd love to see lower entry barriers.

7 14