From owner-Big-Internet@munnari.oz.au Sun Dec 1 03:15:25 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA04210; Sun, 1 Dec 1991 03:15:36 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA04185; Sun, 1 Dec 1991 03:15:25 +1100 (from jch@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA07345; Sat, 30 Nov 91 11:15:03 EST Message-Id: <9111301615.AA07345@mitchell.cit.cornell.edu> To: Big-Internet@munnari.oz.au Subject: alpha gated with Class E mods available Reply-To: gated@comet.cit.cornell.edu Organization: Information Technologies/Network Resources; Cornell University, Ithaca, NY X-Mailer: MH [version 6.7] MH-E [version 3.7+] Date: Sat, 30 Nov 91 11:15:02 -0500 From: Jeffrey C Honig An alpha version of gated with untested Class E modifications is now available, contact me for information on obtaining it. Jeff From owner-Big-Internet@munnari.oz.au Mon Dec 2 17:43:22 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA17536; Mon, 2 Dec 1991 17:43:35 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA17529; Mon, 2 Dec 1991 17:43:22 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA24445; Mon, 2 Dec 91 01:43:10 EST Date: Mon, 2 Dec 91 01:43:10 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112020643.AA24445@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au.iwg@rice.edu, dennis@mrbill.canet.ca Subject: Re: Class E and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU I think that Dennis has hit the nail exactly on the head. Without a concrete idea of where we are going in the long run, it's hard to know whether we are going in the right direction in the smaller steps. Now, I know that this may seem a little agressive/procrastinatory, in that it sounds like we have to solve the world's problems before we can take a single step. I must confess that I'm usually in favor of taking small steps myself, and using a repetitive approximation method, so why have I switched religions in this case? I've started to think that this method does not work where you have a large, installed system which you have to keep running. Taking one small step at a time forward from where we were, to solve a short range problem, is what has got us where we are now. Sometimes this approach runs you into a corner. Having said these very general (and thus semi-useless) words, let me give some quick thoughts on what is happening, and what my general plan was, and why I was doing this class E thing. (Let me interject here that I don't claim to posess the whole Truth in this matter. There is also this group call the Road Warriors which has been started to think about some of this. Enough disclaimers.) I unfortunately don't think the goal that a lot of you seem to be heading towards, the ability to use arbitrary masks to divide up the existing 32 bit space as we see fit, is really a long-term solution to the problems caused by the growth of the Internet. There just isn't enough room in 32 bits (particularly with wastage caused by incomplete usage of allocated spaces) to give us the kind of structure we're going to need to handle the kind of growth we are seeing. Even 5 levels (which would only give us 6 bits per level) would not be a lot better than the 3 (or more, if you use variable width subnetting) we have now. My long-term plan (of which the Nimrod architecture was a part, and I don't have space, nor you the patience to read it, to lay this out) was to define a completely new (basically blank sheet) routing and addressing architecture, which could do (hopefully :^) anything and grow to mindboggling sizes, tie it in to the existing IP through use of the 32 bit field as a (basically flat) host identifier, and then pivot around that to a new IP with longer identifiers, resource allocation, etc, etc, etc. The problem then becomes how to patch the existing thing to keep running until that (or something with similar capabilities) becomes available. I had pushed (along with others) pretty hard to get BGP out the door and required in Router Reqmts to remove the limits on number of globally visible routing destinations *in the protocol* at the EGP level. (EGP itself is clearly already failing). My 'wetted-finger' feeling was that, given the BGP and OSPF/your- favourite-IGP class of protocol technology, contemporary CPU, memory and bandwidth costs would allow us to get up to about 30K-50K routing destinations before the system keeled over. (E.g. If you assume 50 bytes per destination, 30K destinations takes 1.5MByte to store; not a lot of money, even at todays memory costs, let alone 2 years from now, which is when we'll have that number.) I know that in reality this is a very complicated question that depends on the rate of change in the topology, etc, but that was my gut instinct, assuming "reasonable" $$$$ could be squirted in the general direction of resource limitations to handle them. The thing you have to look at is "where is the protocol/architecture going to fall over"? Questions about individual boxes are up to the vendor and the service provider to deal with. If the protocols can do it reasonably, given a competent implementation, then that's as far as the IETF's writ runs. What ought to interest us is where the next bottleneck in the protocol/architecture is. Now, maybe my guess about how far BGP et al will take us is way off, but that's what I personally was going on. I'd love to hear opinions. As to why Class E was being done, 30K is a lot more than the number of class B network numbers. (This is especially true since only a fraction of the number allocated seem to wind up connected to the Internet.) Clearly, if the BGP estimate is right, there is a bottleneck *before* BGP keels over. Class E was a move to handle this problem. Is it the most elegant? No; the masks thing is clearly better. However, it is fairly easy to implement (various major router vendors I polled seemed to think it would take about a day or so of engineering effort to implement), and does not require any seriously incompatible changes to any existing protocol; i.e. no new packet formats in BGP, EGP (which is still with us, sad to say) etc. Also, it is targeted toward solving a single, specific problem; running out of class B's. Remember, full masks will still bring us the problems I pointed out: i) making sure they aren't used to make the problem worse, ii) the problem of coordination among various independant groups in allocation (which exists now, which is why more people don't share network numbers) and iii) the need for major renumbering to get the maximal benefit. Finally, I thought, it had the benefit of being easy to get agreement on (so we could get it in the pipe for deployment). Remember, *nothing* gets reasonably fully deployed in much less than 2 years. How long has BGP been around without being fully available and deployed? Now, none of this is to say that the bet to go ahead with E was right. Maybe they are a horrible idea and should be junked. However, we need to decide here, guys. Remember, even going ahead with E's does not mean we can't *also* do masks. But, if you want E's to be available as a potential part of a solution "toolkit" 2 years from now, we need to push the go button on them fairly soon now. Noel From owner-Big-Internet@munnari.oz.au Tue Dec 3 04:00:20 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA00935; Tue, 3 Dec 1991 04:00:31 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA00929; Tue, 3 Dec 1991 04:00:20 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA26321; Mon, 2 Dec 91 12:00:13 EST Date: Mon, 2 Dec 91 12:00:13 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112021700.AA26321@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, vcerf@nri.reston.va.us Subject: Re: Class E and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU What does your intuition tell you about the % bandwidth consumed by maintaining updates on 30-50K destinations? cpu utilization? I know these are not easy numbers to come by, but they are another pair of resources one wants to consider when evaluating the efficacy of different routing strategies for achieving large-scale operation. Vint, the bandwidth used will depend on the protocol and topology, unfortunately (as well as rate of change, as Yakov pointed out). Interestingly enough, these measures of resource usage were exactly the things that the Road Warriors decided they needed to know about the various protocols! DV class algorithms need to send new table entries for all routes which are affected by a topology change (even with SRI type optimizations to make sure this only happens once); depending on exactly what breaks, a single change may affect a lot of routes. Since the external feed into our LS IGP's is currently from a DV algorithm (BGP), and the bulk of the data carried by the IGP will be external, the small, bounded line utilization of LS algorithms in response to topology changes won't help us in the LS IGP's. There are two possible lines of attack to reduce the bandwidth (in addition to the obvious one of reducing the number of destinations through supernet masks). One is to damp the number of cases which require retransmission of routing tables. For instance, BGP routes need not be updated if the metrics changes as long as the AS path remains the same; no loops can result. Similarly, external information fed into an IGP (but not sent on from the other side of the AS) need not be updated on a change (even a path change) as long as the destination remains reachable. Both result in non-optimal routing, but the traffic does get there. (I think it's a fundmantal constant of the universe that practical routing in large networks is non-optimal!) Another is to change to an EGP which uses LS, and bound the amount of data to be transmitted after a topology change to a small amount. We have one on the way, IDPR (albeit with a lot of other crazy stuff like flow setup). I've had a model for a while that IDPR might be used as a gap-filler if BGP blows out. (IDPR also tracks AS's, not network numbers, providing another level of heirarchy.) LS also has the advantage that you can delay routing table calculation, reducing computing cost. However, I don't see computing cost as being as big a problem as bandwidth or memory; it's not insignificant, just not likely to be the bottleneck. I am persuaded that installing class E would be a good idea - especially if we forebear from using it with the intent of moving to the longer term solution instead. Class E becomes a safety valve if we cannot deploy the larger scale solution fast enough. Given the likely timeline to design, test, and deploy any really large scale solution, which seems to me to likely be 4-5 years (unless we Manhattan Project it), we will almost certainly need a number of patches in the interim. Noel From owner-Big-Internet@munnari.oz.au Wed Dec 4 13:57:45 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA25220; Wed, 4 Dec 1991 13:57:58 +1100 (from owner-Big-Internet) Return-Path: Received: from ALLSPICE.LCS.MIT.EDU by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA25210; Wed, 4 Dec 1991 13:57:45 +1100 (from jnc@ALLSPICE.LCS.MIT.EDU) Received: by PTT.LCS.MIT.EDU id AA04650; Tue, 3 Dec 91 21:57:28 EST Date: Tue, 3 Dec 91 21:57:28 EST From: jnc@ALLSPICE.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9112040257.AA04650@PTT.LCS.MIT.EDU> To: big-internet@munnari.oz.au, vcerf@nri.reston.va.us Subject: Re: Class E and EGP Cc: jnc@ALLSPICE.LCS.MIT.EDU Vint, after being made thoughtful by your question about my intuition and 50K destination, I've been doing some research with major router vendors, etc, to check to see if my 'wet thumb' about the lifetime of BGP and the current address architecture is accurate. I'm working on a full report, which should be done tomorrow. I'm not quite sure what to do with it, whether I should publish it as a personal I-D or just circulate it. What I'm hearing confirms my estimate that memory is the chief bottleneck (although my per-destination number was low), and that several currently available boxes will handle over 12K nets; i.e. 2 years growth at the current doubling every 14 months. People also felt that in 2 years, box capability will have increased, and numbers like 50K (i.e. 2 more years after that, at current rates) networks are well within reason. Interestingly enough, both of the techniques I mentioned to reduce bandwidth requirements by damping the number of changes advertised are in fact already in use! (Thanks for saying so, guys! Letting me look like a cretin in public. Oh well, just goes to show how in touch with current practise *I* am! :-) The obvious corollary to all this is that we run out of B's long before we get to 12K advertised, probably. This probably means that E is useful, *particularly* if we take the opportunity to stamp out the last vestiges of classism from the hosts. That would make any deployment of supernet masks easier. I remain cautious about supernet masks until we can guarantee that it will decrease the number of globally visible destinations, though. Noel From owner-Big-Internet@munnari.oz.au Tue Dec 17 02:29:42 1991 Received: by munnari.oz.au (5.64+1.3.1+0.50) id AA16062; Tue, 17 Dec 1991 02:29:56 +1100 (from owner-Big-Internet) Return-Path: Received: from europa.clearpoint.com by munnari.oz.au with SMTP (5.64+1.3.1+0.50) id AA16047; Tue, 17 Dec 1991 02:29:42 +1100 (from kasten@europa.clearpoint.com) Received: by europa.clearpoint.com (4.1/1.34) id AA20570; Mon, 16 Dec 91 10:24:14 EST Date: Mon, 16 Dec 91 10:24:14 EST From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9112161524.AA20570@europa.clearpoint.com> To: big-internet@munnari.oz.au Subject: Class E addresses and Domain Hi, I've been thinking about the issues with DNS and IN-ADDR.ARPA for the new Class E addresses. The other Frank and I will be putting the explanatory text into the Class E document. We'll also put in the two possible solutions as I've outlined them. I wanted to run this information by the group before editing the document. The new class E address is formatted as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1| NETWORK | Local Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The NETWORK and Local Address portions are split in the middle of the third byte of the address, thus, Class E network Number 10 would be 240.0.160.0. Host number 256 in this hypothetical network would have address 240.0.161.0. The problem is that the third byte of the address is also one of the sub-domains in the IN-ADDR.ARPA domain. A reverse name lookup for 0.161.0.240.IN-ADDR.ARPA would fail because the IN-ADDR.ARPA domain at the root nameservers would only have 0.160.0.240.IN-ADDR.ARPA in it. (At least this is how I understand it all to work.) As I see it there are two possible solutions: 1) Require that the name servers determine the network class of an IN-ADDR.ARPA request and apply that class's mask to the request before doing the lookup (in the above example, it would apply a mask of 0.240.255.255 to 0.161.0.240 and produce 0.160.0.240, if I correctly did my bit twiddling) This has the possible disadvantage of (possibly) requiring code changes to the root servers. I do not know if BIND, et al, already to this masking. If all of them do it, this is fine. 2) Have 16 entries in the IN-ADDR.ARPA domain for each assigned Class E network. Thus, when Class E network 240.0.160.0 is assigned, 16 entries are made in the IN-ADDR.ARPA domain: 240.0.160.0 240.0.161.0 240.0.162.0 240.0.163.0 240.0.164.0 240.0.165.0 240.0.166.0 240.0.167.0 240.0.168.0 240.0.169.0 240.0.170.0 240.0.171.0 240.0.172.0 240.0.173.0 240.0.174.0 240.0.175.0 This has the advantage of not requiring any code changes anyplace. It is all administratively done. Of course, the root domain files get bigger, but I imagine that they are pretty big anyway. Any feed back or insights that you have would be appreciated. Thanks Frank Kastenholz