From owner-big-internet@munnari.oz.au Thu Sep 2 18:37:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12565; Thu, 2 Sep 1993 18:37:59 +1000 (from owner-big-internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00375; Thu, 2 Sep 1993 14:14:14 +1000 (from kre@munnari.OZ.AU) Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB13178; Thu, 2 Sep 1993 07:07:31 +1000 (from solensky@ftp.com) Return-Path: Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA03588; Wed, 1 Sep 93 17:07:28 -0400 Date: Wed, 1 Sep 93 17:07:28 -0400 Message-Id: <9309012107.AA03588@ftp.com> To: kre@munnari.oz.au Subject: New growth charts available From: solensky@ftp.com (Frank T Solensky) Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Thu, 02 Sep 1993 14:13:53 +1000 Resent-Message-Id: <24251.746943233@munnari.OZ.AU> Resent-From: Robert Elz The monthly NFSnet growth charts have just been made available at munnari.oz.au:big-internet/nsf-netnumbers-9309.ps via anonymous FTP. A Unix compressed version is also available with a ".Z" suffix. For the benefit of those that may be new to the list: this PostScript file usually contains three graphs. The first is a plot of the number of networks represented in the NSFNet policy routing database from mid-1988 through the current time. It also includes a trend line which estimates how many network numbers (class A+B+C) that will appear over the next several years. The trend line, based on the suggestion by Van Jacobson, is the logistic curve which best fits the available data. The logistic curve plots as an "s"-shaped line that rises slowly in the beginning, climbs more rapidly in the middle and flattens out as it approaches a limiting value; it appears frequently in biological studies and was used in an independent effort by Vijay Gurbaxani in a similar analysis of the growth of BITNET in a CACM article [Dec. '90]. The second graph is the same as the first but uses a log scale for the network number count. It is important to realize that these curves do not take any CIDR route aggregations into account at this time; these will eventually be added. There were 6360 reachable network numbers this time last year, thus the growth rate over the last 12 months averaged out to 7.56%/month, or doubled every 9.5 months. The current trend line suggests that we'll run out of IPv4 net numbers on March 31, 2000 (24 days earlier than last month's trend line). The third graph illustrates how the estimate of the maximum count of network numbers -- the upper limit of the curve -- has changed from month to month. For example, using the data available in January 1992, this model predicted that the curve would flatten out at 6529 networks (a point we've long since passed). We would become more confident about the reliability of the estimate on the future part of the first curve if this graphs were relatively flat over several months. It's pretty clear from looking at this graph that this currently isn't the case: the prediction on the maximum net number count is now 308.8 million net numbers, compared to 81.6 million last month and 17377 this time last year. -- Frank From owner-big-internet@munnari.oz.au Sat Sep 4 17:04:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00403; Sat, 4 Sep 1993 17:06:49 +1000 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02074; Sat, 4 Sep 1993 04:01:57 +1000 (from craig@aland.bbn.com) Received: from port16.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06685 for big-internet@munnari.oz.au; Fri, 3 Sep 93 14:01:36 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA16674; Fri, 3 Sep 93 10:59:27 PDT Message-Id: <9309031759.AA16674@aland.bbn.com> To: wollman@uvm-gen.EMBA.UVM.EDU Cc: Craig Partridge Cc: Big-Internet mailing list Subject: re: address sizes From: Craig Partridge Date: Fri, 03 Sep 93 10:59:27 -0700 Sender: craig@aland.bbn.com [picking up on a thread after getting back from INTEROP] > > So my nightmare is that either: > > > (1) at the key point in the forwarding loop, the router stalls for > > tens of cycles to go get the last bytes of a variable length > > address; OR > > > (2) router performance suffers because everyone is loading 80 bytes > > of header, even though the average variable length header is only 40 > > bytes, because they are trying to avoid the stalls of (1). > > I have a few responses to this... > > 1) I think you have to solve the memory speed problem anyway, in order > to make fast networks work. New ideas and services are going to place > more demands on CPU and memory speed whether we have long > variable-length addresses or not, so if those services and speeds are > considered important enough, they will drive the technology. Yes and no. I have to find some way to move data from memory quickly. But in most of the system I can wide data paths (which processors find difficult due to pin limits) and plan ahead (e.g., schemes that plan what data gets moved from memory or over a bus some time before it actually gets moved). Processors pretty much limit me to planning ahead (e.g., use caches), and heavily penalize code for failing to plan correctly. > 4) It's not just the software that's getting more sophisticated. Some > of the problems that you mention can be alleviated by increasing the > intelligence of the hardware, or just by changing the way the hardware > interfaces to the rest of the system. In general, for fixed length addrs, the software is getting simplier (as we learn more, we make it less complicated). I'd like to continue that trend by building on fixed sized addrs. The other points were architectural issues saying we'll probably need variable sized addresses. I understand that point of view -- I'm simply interested in pointing out that there's a very real performance cost involved that one should factor into the balance. Craig From owner-Big-Internet@munnari.oz.au Sat Sep 4 21:33:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09137; Sat, 4 Sep 1993 21:34:59 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09099; Sat, 4 Sep 1993 21:33:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00835; Sat, 4 Sep 93 07:32:58 -0400 Date: Sat, 4 Sep 93 07:32:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309041132.AA00835@ginger.lcs.mit.edu> To: craig@aland.bbn.com, wollman@uvm-gen.emba.uvm.edu Subject: re: address sizes Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In general, for fixed length addrs, the software is getting simplier (as we learn more, we make it less complicated). I'd like to continue that trend by building on fixed sized addrs. Grrr! I thought we had decided not to use the infamous A-word any more!?!? :-) Here we have a *perfect* example of why... If you mean that you like fixed length selectors, I couldn't agree with you more. Whether in software *or* hardware, fixed length things are easier to deal with. (Anyone who doubts the hardware case should ask themselves why all RISC chips use fixed-length instructions...) The other points were architectural issues saying we'll probably need variable sized addresses. Yes, there are a lot of reasons to think that we need variable length locators (note different term). I understand that point of view -- I'm simply interested in pointing out that there's a very real performance cost involved that one should factor into the balance. You only have to perform that difficult balancing act if you continue to think that we have to perform both functions with one field. Me, I don't like those kind of balancing acts, you never get them really right, and they break down sooner, so the conclusion is obvious. I could put in a long handwave here about how applications like video- conferencing, etc, will mean the data mix will shift to longer and longer, and higher-bandwidth, flows, making a flow based system in which only a small percentage of total packets have any need to actually carry locators, but I'll skip it. Fission the Address! Noel From owner-Big-Internet@munnari.oz.au Sat Sep 4 21:48:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09960; Sat, 4 Sep 1993 21:51:09 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09838; Sat, 4 Sep 1993 21:48:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00875; Sat, 4 Sep 93 07:48:10 -0400 Date: Sat, 4 Sep 93 07:48:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309041148.AA00875@ginger.lcs.mit.edu> To: kre@munnari.oz.au, solensky@ftp.com Subject: Re: New growth charts available Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the growth rate over the last 12 months averaged out to 7.56%/month, or doubled every 9.5 months Hmm, this has dropped from the old 14 month figure. Growth rates are accelerating... The current trend line suggests that we'll run out of IPv4 net numbers on March 31, 2000 Hmm, and CIDR won't help this, since most of those numbers are class C. If we're still growing at 9 months doubling then (hard to believe, it's going to have to slow down *sometime*; not everyone in the world has a PC, if the user population is 5 million now and it doubles every 9 months, in 2000 we'd have a billion users... hmm, Europe, plus North America, plus Japan, plus... gee... Oh No :-) we can get an extra 18 months by throwing the back half of class A into the C sized pot. the prediction on the maximum net number count is now 308.8 million net numbers, compared to 81.6 million last month Say WHAT? 376% growth in predicted levelling out point in *ONE MONTH*? It seems to me that either i) somebody just injected a big chunk of noise by doing a large allocation (that's the problem with month-mont, as opposed to somewhat smoothed, as above), or ii) we're in for a *very* wild ride... Noel From owner-Big-Internet@munnari.oz.au Sun Sep 5 06:12:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25502; Sun, 5 Sep 1993 06:12:40 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25496; Sun, 5 Sep 1993 06:12:18 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA28684 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Sat, 4 Sep 1993 13:12:03 -0700 Date: Sat, 4 Sep 1993 13:12:03 -0700 From: Tony Li Message-Id: <199309042012.AA28684@lager.cisco.com> To: big-internet@munnari.oz.au Cc: wollman@uvm-gen.EMBA.UVM.EDU, Craig Partridge Subject: Variable length addresses In general, for fixed length addrs, the software is getting simplier (as we learn more, we make it less complicated). I'd like to continue that trend by building on fixed sized addrs. The other points were architectural issues saying we'll probably need variable sized addresses. I understand that point of view -- I'm simply interested in pointing out that there's a very real performance cost involved that one should factor into the balance. Now that it's after Interop, I would like to clear up this issue for once and for all. For those of you who did not visit the cisco booth, we demonstrated the silicon switch processor, which was switching over 240kpps. (Yours truly did the IP system code.) This is relevant because the length of the address has almost no effect on SSP performance. I don't have numbers for CLNP yet, but I expect that they will not be significantly different from the IP numbers. If there is a difference, it will be due to differences in the checksum... The point is that variable length addresses, in a good implementation, do not have a detrimental effect. Even in a simpler implementation, it is possible to encode variable length addresses in such a way that they do not have a significant performance hit. For example, if SIP addresses were length plus 7 bytes, and we all agreed to only use 7 byte addresses for now, a lower cost implementation could optimize for the 7 byte addresses easily. If we found it necessary to increase the number of bytes, we simply warn everyone and add another word (for the then-current favorite word size) worth of address bits. The point is that variable length addresses do not hurt, but allowing arbitrary lengths does. You can have the former without the latter. Given this, IPng without variable length addresses is nothing short of foolish. Tony From owner-big-internet@munnari.oz.au Sun Sep 5 08:59:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00382; Sun, 5 Sep 1993 08:59:46 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25615; Sun, 5 Sep 1993 06:15:59 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA29171 (5.67a/IDA-1.5); Sat, 4 Sep 1993 13:15:21 -0700 Date: Sat, 4 Sep 1993 13:15:21 -0700 From: Tony Li Message-Id: <199309042015.AA29171@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: kre@munnari.oz.au, solensky@ftp.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: New growth charts available The current trend line suggests that we'll run out of IPv4 net numbers on March 31, 2000 Hmm, and CIDR won't help this, since most of those numbers are class C. If we're still growing at 9 months doubling then (hard to believe, it's going to have to slow down *sometime*; not everyone in the world has a PC, if the user population is 5 million now and it doubles every 9 months, in 2000 we'd have a billion users... hmm, Europe, plus North America, plus Japan, plus... gee... Oh No :-) we can get an extra 18 months by throwing the back half of class A into the C sized pot. You should recall that we're still spinning up for CIDR, and that many folks are still allocating big blocks. It's not clear from the figures (Frank?) how much address space is actually in use. Tony From owner-Big-Internet@munnari.oz.au Sun Sep 5 11:28:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04569; Sun, 5 Sep 1993 11:29:01 +1000 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04566; Sun, 5 Sep 1993 11:28:37 +1000 (from medin@nsipo.nasa.gov) Received: Sat, 4 Sep 93 18:28:07 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9309050128.AA25693@dscs.arc.nasa.gov> To: Tony Li Cc: big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, Craig Partridge Subject: Re: Variable length addresses In-Reply-To: Your message of "Sat, 04 Sep 93 13:12:03 PDT." <199309042012.AA28684@lager.cisco.com> Date: Sat, 04 Sep 93 18:28:07 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Well, I'm not sure anyone said it was impossible to build hardware that couldn't switch variable length addresses fast, but rather how much effort one had to exert to do it. People can be quite ingenious in figuring out ways to get around problems... :-) It seems to me that much of the debate on the various issues is focused on the surface, rather than the assumptions various people have, and various views on cost/benefit tradeoffs. For example, there are many people who believe that current trends in router technology will end up with more and more of the forwarding function implemented in hardware, and that since it's possible to build hardware that can switch variable length addresses fast, that the benefits of variable length addresses outweigh the costs. It should be pointed out also that some other types of problems also become easier to deal with when your hardware can deal with this sort of generality and still go fast; I doubt cisco did it this way just so that CLNP could run fast... :-) Some others look at the router technology evolving too, but believe it's important that general purpose computer architectures used in things like RISC workstations should be able to be used as routers, without any specialized hardware, and be able to switch IPng at high speed. When they look at what variable length addresses do to forwarding performance in this environment, they see the costs as outweighing the benefits. There are other assumptions too, but in general I don't think people are fully explaining their sort of "world view" when arguing positions, and this leads to a lot of unecessary feistiness. I'm not pointing to any particular person here, but rather I think this is a characteristic of the debate overall. When you pin down some supporters of a candidate architecture and probe around a bit, I think you'll be surprised at the degree of solid logic present. Now, you might argue that the assumptions people are making are broken, but that's a different issue. :-) Thanks, Milo From owner-Big-Internet@munnari.oz.au Sun Sep 5 12:18:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05936; Sun, 5 Sep 1993 12:19:09 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05933; Sun, 5 Sep 1993 12:18:56 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA05535 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Sat, 4 Sep 1993 19:18:40 -0700 Date: Sat, 4 Sep 1993 19:18:40 -0700 From: Tony Li Message-Id: <199309050218.AA05535@lager.cisco.com> To: medin@nsipo.nasa.gov Cc: big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com In-Reply-To: "Milo S. Medin" (NASA ARC NSI Office)'s message of Sat, 04 Sep 93 18:28:07 -0700 <9309050128.AA25693@dscs.arc.nasa.gov> Subject: Variable length addresses It should be pointed out also that some other types of problems also become easier to deal with when your hardware can deal with this sort of generality and still go fast; I doubt cisco did it this way just so that CLNP could run fast... :-) Well, as a matter of fact... Some others look at the router technology evolving too, but believe it's important that general purpose computer architectures used in things like RISC workstations should be able to be used as routers, without any specialized hardware, and be able to switch IPng at high speed. When they look at what variable length addresses do to forwarding performance in this environment, they see the costs as outweighing the benefits. No, you're still missing the point. If you do variable length addresses, that have a fixed size today (that just happens to be a multiple of the word size), you can EASILY optimize a RISC implementation to handle the address quickly. For example, let's suppose that you want to switch CLNP quickly. If there was a decree that you only had to handle 20 byte NSAPs _even though the syntax allowed for variable length_, then you could make this very efficient, extremely easily. Checking for the length to be correct is trivial, and if the packet header were layed out correctly (I'm not claiming that CLNP is...), it would be a no-cost check. You might put the protocol version number, source address length, destination address length and other "must be constants" in the first word. If the first word of the packet does not match what is expected, leap to some general purpose code. This is a _trivial_ cost, compared to the fact that if we do NOT do variable length addresses, that our children (now there's a scary thought -- Milo with children ;-) will have to go through this all over again, when we've blown out the fixed length address. Please remember the Tacoma Narrows bridge. Don't under-engineer. Tony From owner-Big-Internet@munnari.oz.au Sun Sep 5 14:58:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11381; Sun, 5 Sep 1993 14:59:05 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11374; Sun, 5 Sep 1993 14:58:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04561; Sun, 5 Sep 93 00:58:16 -0400 Date: Sun, 5 Sep 93 00:58:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309050458.AA04561@ginger.lcs.mit.edu> To: medin@nsipo.nasa.gov, tli@cisco.com Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au, hbc@ginger.lcs.mit.edu Sigh, people who use the word "address". I am going to personally, publically, flame at each person who does until people start using "selector", "locator", etc as appropriate. If you think I'm being an obnoxious, arrogant, asshole, fine with me; that's my function. From: "Milo S. Medin" Well, I'm not sure anyone said it was impossible to build hardware that couldn't switch variable length addresses fast ... since it's possible to build hardware that can switch variable length addresses fast ... When they look at what variable length addresses do to forwarding performance I assume you mean "variable length selectors" in all these cases, right? the benefits of variable length addresses outweigh the costs. If you mean "variable length selectors" here, I probably don't agree with this (although I'm not solid yet). If you mean "varible length locators", I do. In fact, I don't know if either of the two potential future routing architectures currently being built (Nimrod and Unified) thinks you can do worldnet with fixed length locators. So, you probably have to have an internetwork layer with variable length locators... Then the question becomes "do I want the locator to be the selector". It seems to me that much of the debate on the various issues is focused on the surface, rather than the assumptions various people have, and various views on cost/benefit tradeoffs. Absolutely, but this point has been made before... in general I don't think people are fully explaining their sort of "world view" when arguing positions, Partially this is avoidable (e.g. people using terms which mean different things to different people, leading to guaranteed confusion, unless we keep a separate meaning binding context for each speaker), partially it's not; there are a lot of hidden assumptions about which conflicting engineering design principles to favor, and why. People are making tremendously complicated cost/benfit tradeoff estimates for the future; the result can hardly be anything but partially intuitive, and thus not completely explainable. From: Tony Li If you do variable length addresses, that have a fixed size today Again, do you mean selectors, locators, or a single field which does both? If there was a decree that you only had to handle [fixed length fields], _even though the syntax allowed for variable length_, then ... Checking for the length to be correct is trivial, Sure, but are you going to mandate from day one that people support receiving other lengths (albeit perhaps inefficiently)? If not, then this is really not much better than a header version; you still have to touch every host that wants to handle the new length if you switch.. This is a _trivial_ cost, compared to the fact that if we do NOT do variable length addresses, that our children ... will have to go through this all over again, when we've blown out the fixed length address. If you are speaking of locators here, I don't even think it'll take that long (unless they are ginormous, like 256 bits). *We* will get the (dubious) pleasure.... In the longer range, it may not be such a big deal; the network may mutate into something so different it needs a new internetwork packet format anyway. Then again, it might not.. Please remember the Tacoma Narrows bridge. Don't under-engineer. Absolutely. Tacoma Narrows = IPv4. The question is, are we smart enough to learn the lesson? Noel From owner-big-internet@munnari.oz.au Sun Sep 5 18:21:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17349; Sun, 5 Sep 1993 18:23:31 +1000 (from owner-big-internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09420; Sun, 5 Sep 1993 13:56:02 +1000 (from medin@nsipo.nasa.gov) Received: Sat, 4 Sep 93 20:55:47 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9309050355.AA26648@dscs.arc.nasa.gov> To: Tony Li Cc: big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com Subject: Re: Variable length addresses In-Reply-To: Your message of "Sat, 04 Sep 93 19:18:40 PDT." <199309050218.AA05535@lager.cisco.com> Date: Sat, 04 Sep 93 20:55:47 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Ok, I think you are saying that you should allow variable length syntax, but use it with a fixed length, so that all implementations that can't handle variable length addresses while maintaining high performance can optimize for the common case and still run fast. Right? I assume that the point of using variable length addresses in this way means that if people guessed wrong about the size, you could use a different size, even though this would cause some implementations to operate a lot slower, but at least you wouldn't have to reinvent the lower layer again and have to deploy new code quite so fast. This would allow people to use existing code, possibly with a significant performance penalty, which presumably would motivate them to deploy new code optimized for the new case as well, without requiring any flag day where everyone has to change. In essence, you're saying you use a variable address like a fixed address, and if people guess wrong about the common size, we can change this without as costly a transition. Now, given your previous statement about bounding the size (which would almost have to be done to implement things in this way), what would the upper bound be, and what happens if that turns out to be inadequate? I actually have some relatives with kids that apparently are a lot like me, but they aren't into computer networking (yet). :-) But since I'm not married yet, you won't have to worry about a pile of little Milo's for awhile... I'm still looking though. ;-) Thanks, Milo From owner-big-internet@munnari.oz.au Sun Sep 5 23:11:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25037; Sun, 5 Sep 1993 23:15:11 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17212; Sun, 5 Sep 1993 18:18:33 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA11935 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Sun, 5 Sep 1993 01:18:00 -0700 Date: Sun, 5 Sep 1993 01:18:00 -0700 From: Tony Li Message-Id: <199309050818.AA11935@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: medin@nsipo.nasa.gov, tli@cisco.com, big-internet@munnari.oz.au, hbc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Sun, 5 Sep 93 00:58:16 -0400 <9309050458.AA04561@ginger.lcs.mit.edu> Subject: Variable length addresses If you do variable length addresses, that have a fixed size today Again, do you mean selectors, locators, or a single field which does both? Whatever flavor you choose... any field that you expect to have a number of values that is some non-trivial function of the "size" of the network. If there was a decree that you only had to handle [fixed length fields], _even though the syntax allowed for variable length_, then ... Checking for the length to be correct is trivial, Sure, but are you going to mandate from day one that people support receiving other lengths (albeit perhaps inefficiently)? If not, then this is really not much better than a header version; you still have to touch every host that wants to handle the new length if you switch.. Yes. All implementations must support arbitrary length. However, all fields will be length X by decree... In the longer range, it may not be such a big deal; the network may mutate into something so different it needs a new internetwork packet format anyway. Then again, it might not.. Yup. And I hope it does. But at least we will get bit in a different portion of our collective anatomy. The question is, are we smart enough to learn the lesson? Look at the proposals on the table. You tell me... Tony From owner-big-internet@munnari.oz.au Mon Sep 6 01:12:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29202; Mon, 6 Sep 1993 01:12:50 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309051512.29202@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22559; Sun, 5 Sep 1993 21:39:58 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 5 Sep 1993 12:38:52 +0100 To: "Milo S. Medin" (NASA ARC NSI Office) Cc: Tony Li , big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, Craig Partridge Subject: Re: Variable length addresses In-Reply-To: Your message of "Sat, 04 Sep 93 18:28:07 PDT." <9309050128.AA25693@dscs.arc.nasa.gov> Date: Sun, 05 Sep 93 12:38:47 +0100 From: Jon Crowcroft >Well, I'm not sure anyone said it was impossible to build hardware that >couldn't switch variable length addresses fast, but rather how much effort >one had to exert to do it. People can be quite ingenious in figuring out >ways to get around problems... :-) right - according to informal output from cisco, they have quite clearly VERY smart people (e.g. ex-UCL graduates:-) making the routers go faster but what about fileservers, computer servers etc which have no special s/w different from more modest workstations these days? i dont want to have to buy 5, 15 or 50% more fileservers just so i get the same IPng performance as i used to with IPclassic... dec use trie h/w for nsap and other address-sanding - sun&&sequent&sgi dont. now show me s/w algoptihms that can do variable length lookkups as fast as fixed or even just witrh a constant add on & i will be innerested... (obviously a single homed host doesnt have to have more than the last hop match usually, but a lot of servers are multihomed and used as routers in the less well-funded parts of the matrix] jon From owner-Big-Internet@munnari.oz.au Mon Sep 6 01:32:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29553; Mon, 6 Sep 1993 01:33:04 +1000 (from owner-Big-Internet) Return-Path: Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29532; Mon, 6 Sep 1993 01:32:19 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Sun, 5 Sep 93 10:31:56 -0500 Message-Id: <9309051531.AA14017@iastate.edu> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: Variable length addresses In-Reply-To: Your message of Sat, 04 Sep 93 19:18:40 -0700. <199309050218.AA05535@lager.cisco.com> Date: Sun, 05 Sep 93 10:31:55 CDT From: John Hascall > Please remember the Tacoma Narrows bridge. Don't under-engineer. Please remember the Spruce Goose. Don't over-engineer... John From owner-big-internet@munnari.oz.au Mon Sep 6 21:42:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11141; Mon, 6 Sep 1993 21:43:12 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29860; Mon, 6 Sep 1993 16:45:33 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA07782 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Sun, 5 Sep 1993 23:45:00 -0700 Date: Sun, 5 Sep 1993 23:45:00 -0700 From: Tony Li Message-Id: <199309060645.AA07782@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: J.Crowcroft@cs.ucl.ac.uk, medin@nsipo.nasa.gov, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, tli@cisco.com In-Reply-To: Noel Chiappa's message of Sun, 5 Sep 93 18:53:45 -0400 <9309052253.AA06544@ginger.lcs.mit.edu> Subject: Variable length addresses This makes it even more imperative, in my view, that we separate the locator and selector functions, since I am *convinced* that large scale routing with policy and QOS mixins (which is what the Internet is going to have to have in the future) will need long, flexible locators. The Nimrod people all believe this; what about the SDRP/Unified guys? Tony? Of course. But in SDRP/Unified currently, it is not part of the network header. I don't know if we would change this for IPng. I kinda doubt it, as I don't see this as the common case. But we've been down this rathole before... Tony From owner-big-internet@munnari.oz.au Mon Sep 6 23:41:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB14743; Mon, 6 Sep 1993 23:42:11 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01447; Mon, 6 Sep 1993 17:29:13 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA09458 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Mon, 6 Sep 1993 00:28:49 -0700 Date: Mon, 6 Sep 1993 00:28:49 -0700 From: Tony Li Message-Id: <199309060728.AA09458@lager.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com In-Reply-To: Jon Crowcroft's message of Mon, 06 Sep 93 08:23:06 +0100 <199309060723.AA06879@hubbub.cisco.com> Subject: Variable length addresses what's wrong with a jump table - a good compileer would even generate on for a switch satement wirth contiguous (or near contiguous) cases... Absolutely nothing. I was trying to present a _very_ obvious implementation that does what I was suggesting. we can do variable lenght at worst in proportion to the ratio nof the worst length and the old fixed lenght, and at best wioth constant add on Yup. 'xactly. Tony From owner-Big-Internet@munnari.oz.au Mon Sep 6 23:55:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15127; Mon, 6 Sep 1993 23:56:04 +1000 (from owner-Big-Internet) Return-Path: Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15122; Mon, 6 Sep 1993 23:55:53 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA25132; Mon, 6 Sep 1993 09:53:47 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199309061353.AA25132@world.std.com> Subject: Re: Variable length addresses To: snmp@psi.com, jnc@ginger.lcs.mit.edu, hcb@world.std.com (Howard C Berkowitz) Date: Mon, 6 Sep 1993 09:53:47 -0400 (EDT) Cc: medin@nsipo.nasa.gov, tli@cisco.com, big-internet@munnari.oz.au, hbc@ginger.lcs.mit.edu In-Reply-To: <9309050458.AA04561@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 5, 93 00:58:16 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1102 Back in the prehistoric days when we had to pick the faster instructions when coding _application_ programs, I found it useful to avoid true variable length records. My alternative to full generality (i.e., a length-in-bytes field) was to use a bit string with a bit turned on whenever an optional field WAS present. I then used the bit string, either directly or more commonly through an indirect table, to jump to routines that processed that set of elements (or called a sequence of routines for each field). I wonder if the variable-vs.-fixed * discussion might use some of these ideas. While an overall is indeed of variable length, I suggest that it usually will contain a sequence of fixed-length elements. The presence or absence of these elements is carried in a bit string rather than a total length counter. I could see a pipelined processor architecture where processing is started on elements as soon as their flag is recognized. Hmmm... on thinking about this further, it's more of a pipelined decoder coupled with parallel element subprocessors. --- Howard From owner-big-internet@munnari.oz.au Mon Sep 6 15:19:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26651; Mon, 6 Sep 1993 15:21:16 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12750; Mon, 6 Sep 1993 08:54:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06544; Sun, 5 Sep 93 18:53:45 -0400 Date: Sun, 5 Sep 93 18:53:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309052253.AA06544@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, medin@nsipo.nasa.gov Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, tli@cisco.com but what about fileservers, computer servers etc which have no special s/w different from more modest workstations these days? I was going to make approximately this point, but you beat me to it! :-) I am less concerned about the performance impact on *routers* of internetwork pacekt headers with variable length (and potentially longish) fields in it, than I am in the impact on *hosts*. Routers are likely to have hardware assist of various kinds; in my vision of the future, most packets will be forwarded entirely in hardware. Not so in the hosts. They will still be constructing packet headers in software, filling in all the fields the hard way, etc (although tricks like reusing packet buffers can help some). Here's where long, variable length fields get unavoidably painful... This makes it even more imperative, in my view, that we separate the locator and selector functions, since I am *convinced* that large scale routing with policy and QOS mixins (which is what the Internet is going to have to have in the future) will need long, flexible locators. The Nimrod people all believe this; what about the SDRP/Unified guys? Tony? Noel From owner-Big-Internet@munnari.oz.au Tue Sep 7 07:54:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29995; Tue, 7 Sep 1993 07:55:57 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29971; Tue, 7 Sep 1993 07:54:07 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA05162 (5.65c+/IDA-1.4.4); Mon, 6 Sep 1993 17:53:19 -0400 Date: Mon, 6 Sep 93 15:17:25 EDT From: "William Allen Simpson" Message-Id: <1052.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Variable length {selector|locator} It never ceases to amaze me how many times we can discuss the same topic. Tony is arguing for self-encoding length fields. This was discussed exhaustively on this list over a year ago. Several of us proposed different methods. He suggests an octet (0-255), with 255 meaning extension. The only proposal which was formerly put forward using this technique is the so-called TUBA. I will believe they are serious when I see the draft for 7 byte (plus 1 for length) NSAPs. I personally will ignore TUBA until they agree to operate within the IETF standards framework. Another proposal was to use the current 32-bit IP number. The "class E" would be used to indicate 64-bit numbers, "class F" for 48-bit numbers, etc. The only proposal on the table using this technique is TPIX. And I'm not sure they plan on an extension to 48-bits or more. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Tue Sep 7 13:55:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12305; Tue, 7 Sep 1993 13:55:19 +1000 (from owner-big-internet) Return-Path: Received: from moink.NMSU.Edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03738; Tue, 7 Sep 1993 09:47:38 +1000 (from amolitor@moink.nmsu.edu) Received: by moink.nmsu.edu (5.61/eels); id AA28246; Mon, 6 Sep 93 17:46:53 -0600 Date: Mon, 6 Sep 93 17:46:53 -0600 From: amolitor@moink.nmsu.edu (Andrew Molitor) Message-Id: <9309062346.AA28246@moink.nmsu.edu> To: big-internet@munnari.oz.au Subject: Re: Variable length addresses Noel writes: >I am less concerned about the performance impact on *routers* of internetwork >pacekt headers with variable length (and potentially longish) fields in it, >than I am in the impact on *hosts*. Routers are likely to have hardware assist >of various kinds; in my vision of the future, most packets will be forwarded >entirely in hardware. I think it is part of Tony's position that hosts get to treat all the variable length things as fixed length, for the most part. In construction of headers, certainly, and in cracking incoming packets up via header prediction stuff. Later software revisions may use a different fixed size as the 'norm', and will interoperate, albeit slowly, with previous revisions. For the 'usual' case, there is no hit on outgoing packets, and some very small number of instructions + a branch on incoming packets. I'm convinced, marshmallow that I am. Andrew From owner-big-internet@munnari.oz.au Tue Sep 7 15:25:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15719; Tue, 7 Sep 1993 15:25:44 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309070525.15719@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB01218; Mon, 6 Sep 1993 17:23:47 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 6 Sep 1993 08:23:08 +0100 To: Tony Li Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com Subject: Re: Variable length addresses In-Reply-To: Your message of "Mon, 06 Sep 93 00:07:56 PDT." <199309060707.AA09064@lager.cisco.com> Date: Mon, 06 Sep 93 08:23:06 +0100 From: Jon Crowcroft > now show me s/w algoptihms that can do variable length lookkups as > fast as fixed or even just witrh a constant add on & i will be > innerested... >Something like this: > switch (ipng->destaddrlen) { > case SIXTEEN_OCTETS: > /* Highly optimized case to deal with the known optimal address > length, as dictated by the IETF in RFC 1984. Snarf the address > into our data cache quickly. */ > asm("..."); /* Grab 8 octets */ > asm("..."); /* Grab 8 more */ > /* Routing and/or reception code for the fast case goes here. */ > asm("..."); > asm("..."); > asm("..."); > asm("..."); > break; > default: > /* Brute force mode */ > for (i = 1; i <= ipng->destaddrlen; i++) { > /* Routing and/or reception code for the slow case goes here. > Break out of this loop when done. */ > } > } Tony what's wrong with a jump table - a good compileer would even generate on for a switch satement wirth contiguous (or near contiguous) cases... then you get rid of the loop (which uses an extra register which might flush a register which might...) i take the point then we can do variable lenght at worst in proportion to the ratio nof the worst length and the old fixed lenght, and at best wioth constant add on your case rests, m' lud... cheers jon From owner-big-internet@munnari.oz.au Tue Sep 7 17:52:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20815; Tue, 7 Sep 1993 17:52:10 +1000 (from owner-big-internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01764; Mon, 6 Sep 1993 17:37:39 +1000 (from mailists@mwassocs.demon.co.uk) Date: Mon, 06 Sep 1993 08:29:51 BST Message-Id: <9309060829.aa3816@mwassocs.demon.co.uk> From: mailists@mwassocs.demon.co.uk (Unread Mailing Lists) To: big-internet@munnari.oz.au Subject: Re: Variable length addresses X-Mailer: *Cinetic Mail Manager V2.1 >From: Jon Crowcroft > > > >dec use trie h/w for nsap and other address-sanding - sun&&sequent&sgi dont. > >now show me s/w algoptihms that can do variable length lookkups as >fast as fixed or even just witrh a constant add on & i will be >innerested... > Jon, you are falling into the what is the difference between hardware and software trap (e.g. if an algorithm is microcoded, is it in hardware or is it in software?). Anyway, in the end all the user cares about is "how many bangs per buck", and the lesson of MS Windows is that at the workstation end of the market, hardware cost is largely demand driven. So, OK, if your file server does require a faster CPU to cope with a more complex network access algorithm (whether that's CLNP or any other protocol), and there is enough demand for that faster CPU, expect the price of that faster CPU to drop as production volumes increase. Net result is that the user gets more functionality for the same price (e.g. I paid about the same for this 486 monster that I am using to type this, as I did for the Amstrad 1640 I used to have). >(obviously a single homed host doesnt have to have more than the last >hop match usually, but a lot of servers are multihomed and used as >routers in the less well-funded parts of the matrix] > > jon > > > -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.oz.au Wed Sep 8 03:17:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09656; Wed, 8 Sep 1993 03:17:47 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB09651; Wed, 8 Sep 1993 03:17:41 +1000 (from kasten@ftp.com) Received: by ftp.com id AA24230; Tue, 7 Sep 93 13:17:29 -0400 Date: Tue, 7 Sep 93 13:17:29 -0400 Message-Id: <9309071717.AA24230@ftp.com> To: tli@cisco.com Subject: Re: Variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com > Now, given your previous statement about > bounding the size (which would almost have to be done to implement things > in this way), what would the upper bound be, and what happens if that > turns out to be inadequate? > > I see no point in having less than a full byte for the length of the > number of bytes to be routed on. If you want to be really > conservative, you say that the value 255 in the length field is > reserved for future use. Think about A) cpu(or custom silicon) architectures -- what would make the length easier to deal with? Certainly it should be an integral number of bytes. Two bytes might be better than one (easier to extract from the header). B) having some strategically placed Must-Be-Zero fields. These fields could be used as "overflow bits" into which the length may expand, or for something else, which we have not thought of yet. Do not have special, reserved, values. That is simply more checking and special case code. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Sep 8 03:45:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB10604; Wed, 8 Sep 1993 03:45:42 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AB10592; Wed, 8 Sep 1993 03:45:28 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04651; Tue, 7 Sep 93 13:22:19 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9309071722.AA04651@rodan.UU.NET> Subject: Re: New growth charts available To: tli@cisco.com (Tony Li) Date: Tue, 7 Sep 1993 13:22:18 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au, solensky@ftp.com, big-internet@munnari.oz.au In-Reply-To: <199309042015.AA29171@lager.cisco.com> from "Tony Li" at Sep 4, 93 01:15:21 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 414 > You should recall that we're still spinning up for CIDR, and that many > folks are still allocating big blocks. It's not clear from the > figures (Frank?) how much address space is actually in use. One sample - of the 1659 AlterNet nets that I have in my local database, 588 of them are spare - i.e.: allocated to AlterNet from the NIC but not yet reallocated to customers. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.oz.au Wed Sep 8 03:52:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10825; Wed, 8 Sep 1993 03:52:49 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10817; Wed, 8 Sep 1993 03:52:37 +1000 (from dee@skidrow.lkg.dec.com) Received: by inet-gw-2.pa.dec.com; id AA03433; Tue, 7 Sep 93 10:52:33 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA10248 for big-internet@munnari.oz.au; Tue, 7 Sep 93 13:54:00 -0400 Message-Id: <9309071754.AA10248@skidrow.lkg.dec.com> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: Tony Li , big internet Subject: Re: Variable length addresses In-Reply-To: Your message of "Tue, 07 Sep 93 11:19:00 GMT." <24930907111942/0003858921NA4EM@mcimail.com> Date: Tue, 07 Sep 93 13:54:00 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: "Robert G. Moskowitz" <0003858921@mcimail.com> >>Please remember the Tacoma Narrows bridge. Don't under-engineer. I tought the problem with Galloping Gertie (the Tacoma Narrows bridge) was a fundamental misunderstaning of the importance of aerodynamic effects on bridge design. Such effects may be minor for small bridges or those not subject to high winds but are critical in large bridges. The designers thought that the way to make a bridge failure proof was to make it more flexible. In fact, they over-engineered flexibility. In the films of it failing, you can see the roadbed twist and turn to an incredible extent before it finally fails. I would think that the analogy to the Tacoma Narrows bridge would be an IPng that over-engineered field size by make them all big/variable but did nothing about the routing problem. Donald From owner-Big-Internet@munnari.oz.au Wed Sep 8 03:53:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10881; Wed, 8 Sep 1993 03:53:49 +1000 (from owner-Big-Internet) Return-Path: Received: from mailhost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB10874; Wed, 8 Sep 1993 03:53:37 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14) id AA21978; Tue, 7 Sep 93 11:53:20 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA12760; Tue, 7 Sep 93 11:53:32 MDT Message-Id: <9309071753.AA12760@goshawk.lanl.gov> To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} In-Reply-To: Your message of Mon, 06 Sep 93 15:17:25 -0400. <1052.bill.simpson@um.cc.umich.edu> Date: Tue, 07 Sep 93 11:53:31 MST From: peter@goshawk.lanl.gov >>> I personally will ignore >>> TUBA until they agree to operate within the IETF standards framework. Bill, Could you identify how the TUBA working group is not operating within the IETF standards framework? As for specifying 7 byte NSAPs, there is nothing in the current TUBA spec which precludes their use; perhaps you would care to write the ID on why this is a good idea and what you would encode in those 7 bytes. thanks in advance, peter From owner-Big-Internet@munnari.oz.au Wed Sep 8 04:43:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12577; Wed, 8 Sep 1993 04:43:38 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12568; Wed, 8 Sep 1993 04:43:17 +1000 (from craig@aland.bbn.com) Received: from port16.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA06776 for big-internet@munnari.oz.au; Tue, 7 Sep 93 14:42:58 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA03083; Tue, 7 Sep 93 11:40:43 PDT Message-Id: <9309071840.AA03083@aland.bbn.com> To: Frank Kastenholz Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.emba.uvm.edu, craig@aland.bbn.com Subject: Re: Variable length addresses From: Craig Partridge Date: Tue, 07 Sep 93 11:40:43 -0700 Sender: craig@aland.bbn.com Frank: On CPUs, I think the key influence is cache line sizes. IP processing (and TCP processing) are rapidly becoming memory bound, not processor bound and the question is how fast can you get the right piece of memory to the processor. So the ceiling of header-size/cache-line-size gives you a rough sense of performance. Here are some common sizes (now or anticipated). 512 bit cache lines support IPv4, SIP and CLNP (with addresses up to 20 bytes). 256 bit cache lines support IPv4 and SIP header in one load and CLNP addresses up to 10 bytes long. 64 bit lines support IPv4 in 3 loads, SIP in 3 loads, CLNP w/10 byte addresses in 4 loads, CLNP with 20 byte address in 7 loads. Craig From owner-Big-Internet@munnari.oz.au Wed Sep 8 05:57:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15714; Wed, 8 Sep 1993 05:57:19 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA15711; Wed, 8 Sep 1993 05:57:12 +1000 (from synclib!jack@uunet.uu.net) Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06989; Tue, 7 Sep 93 15:36:04 -0400 Received: from synclib.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 153450.9465; Tue, 7 Sep 1993 15:34:50 EDT Received: from daled.sync.com by synclib.sync.COM id aa01651; Tue, 7 Sep 93 12:34:34 PDT From: Jack Dietz To: big-internet@munnari.oz.au Subject: RE: Variable length addresses Reply-To: jdietz@synclib.sync.COM Date: Tue, 7 Sep 93 12:36:20 PDT Message-Id: <9309071936.1439D0@daled.sync.com> X-Mailer: SelectMAIL 1.0 Just an interjection: I see no point in having less than a full byte for the length of the number of bytes to be routed on. If you want to be really conservative, you say that the value 255 in the length field is reserved for future use. I'm not sure I understand the use of this length byte -- is it "the number of bytes to route on", the length of the address of the destination computer/ interface in full, or "the number of bytes to route on", the length of the address of the destination network (like a current netmask)? At any rate, I'm not sure I understand why those proposing variable-length addresses have desired byte-size granularity in addressing. With any hardware, word-size granularity is the easiest to deal with, by definition. All the proposed addressing extensions that I have seen (with the exception of TUBA) have used power-of-two length addresses. This is likely to be significant in the future, in that word sizes are likely to remain powers of two. Perhaps it could be more efficient to use an exponentially encoded length field, taking perhaps three bits to represent 0=32 bits ... 7=4K bits. That leaves plenty of room for expansion while keeping the variable-length component simpler to detect than inventing Class F, G, ... addresses. An OR and compare on the first word of the address can detect the optimized-for address length, or a 8 entry jump table can detect all cases in one go. Tony Jack Dietz // jdietz@sync.com Not speaking for his employer, his country, or the human race From owner-Big-Internet@munnari.oz.au Wed Sep 8 06:03:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16001; Wed, 8 Sep 1993 06:03:51 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15988; Wed, 8 Sep 1993 06:03:38 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA13042 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 7 Sep 1993 15:57:17 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 7 Sep 1993 15:57:17 -0400 Message-Id: <199309071958.AA41181@home.ans.net> To: asp@uunet.uu.net (Andrew Partan) Cc: big-internet@munnari.oz.au Subject: Re: New growth charts available In-Reply-To: (Your message of Tue, 07 Sep 93 13:22:18 D.) <9309071722.AA04651@rodan.UU.NET> Date: Tue, 07 Sep 93 15:58:07 -0500 From: Phill Gross > : > You should recall that we're still spinning up for CIDR, and that many > folks are still allocating big blocks. It's not clear from the > figures (Frank?) how much address space is actually in use. One sample - of the 1659 AlterNet nets that I have in my local database, 588 of them are spare - i.e.: allocated to AlterNet from the NIC but not yet reallocated to customers. Andrew, The NIC tries to account for block assignments (to providers like RIPE or Alternet) vs "real" assignments (to end users). Of course, the accuracy of the accounting depends on providers reporting the real assignments back to the NIC accurately and in a timely fashion. Are all you folks out there with block assignments reporting your "real" assignments back to the NIC? Phill From owner-big-internet@munnari.oz.au Wed Sep 8 06:21:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16538; Wed, 8 Sep 1993 06:21:53 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309072021.16538@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10418; Wed, 8 Sep 1993 03:39:35 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1659; Tue, 07 Sep 93 13:39:17 EDT Date: Tue, 7 Sep 93 13:39:16 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, tli@cisco.com Cc: big-internet@munnari.oz.au Subject: Variable length addresses Ref: Your note of Mon, 6 Sep 93 15:35:09 -0400 >You mean that "I think the SDRP/Unified community generally agrees that >any practical future Internet routing architecture will need long, >flexible locators" ? Deborah/Yakov, you guys listening ? Do you agree ? Noel, Without going into discussion on terminology, the Unified architecture assumes that all the hosts within a single internet have globally unambiguous addresses that can be used for network layer routing. Certainly both SIP, and PIP, and NSAPs, and TP/IX, as well as IPv4 addresses, are flexible enough to accommodate hierarchical address assignment. That is *as much flexibility* as Unified needs. The issue of "long" to a large extend is a matter of opinion. One may argue that SIP addresses are "long". Likewise, one may argue that NSAPs are "long", etc... >I'm not positive I understand this. My understanding is that in both >flows setup, and full source route mode, SDRP/Unified uses its own >packet format... I think there is still certain confusion about Unified and SDRP and how they relate to each other. So, just for the benefits of those who are confused, let me reiterate that the Unified Architecture for inter-domain routing has two components: a) hop-by-hop routing to support commonly used routes b) source-initiated forwarding to support special routes The hop-by-hop component doesn't use SDRP at all, but relies on BGP/IDRP protocols. It provides destination and Type of Service sensitive forwarding, but can also provide source sensitive forwarding, provided that there are fields in the network layer to support this (e.g. locally defined QoSs in CLNP). No new packet format is need for commonly used routes. The source-initiated forwarding is the component that uses SDRP. SDRP with IP relies on encapsulation to carry the forwarding information. However, there is nothing inherent in SDRP that would preclude the use of options to carry the information. In fact, a proposal to support provider based source route in CLNP would be a perfect example of how to carry SDRP forwarding information as an option in a network header. Likewise, source route with SIP would be yet another example of how to carry SDRP forwarding information without creating yet one more packet format. Yakov. From owner-Big-Internet@munnari.oz.au Wed Sep 8 06:34:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17025; Wed, 8 Sep 1993 06:34:42 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA17010; Wed, 8 Sep 1993 06:34:16 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA21529; Tue, 7 Sep 93 16:14:37 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9309072014.AA21529@rodan.UU.NET> Subject: Re: New growth charts available To: pgross@ans.net (Phill Gross) Date: Tue, 7 Sep 1993 16:14:37 -0400 (EDT) Cc: big-internet@munnari.oz.au In-Reply-To: <199309071958.AA41181@home.ans.net> from "Phill Gross" at Sep 7, 93 03:58:07 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 152 > Are all you folks out there with block assignments reporting your "real" > assignments back to the NIC? We are. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.oz.au Wed Sep 8 06:50:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17598; Wed, 8 Sep 1993 06:50:30 +1000 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17595; Wed, 8 Sep 1993 06:50:23 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA14497; Tue, 7 Sep 93 13:51:14 -0700 Date: Tue, 7 Sep 93 13:51:14 -0700 From: Eric Fleischman Message-Id: <9309072051.AA14497@atc.boeing.com> To: big-internet@munnari.oz.au, dee@skidrow.lkg.dec.com Subject: Re: Variable Length Addresses Cc: sip@caldera.usc.edu From: "Beast (Donald E. Eastlake, 3rd)" > I would think that the analogy to the Tacoma Narrows bridge would be > an IPng that over-engineered field size by make them all big/variable > but did nothing about the routing problem. IPng is a complex problem space. As Noel Chiappa has frequently pointed out, IPng may be primarily viewed as a routing problem. However, each of the IPng alternatives have redefined the entire network layer -- and not just the routing component. From this one may conclude a variety of things including that our current technology is currently unable to separate routing from addressing. Even a casual recollection of the themes expressed on this list over the past year will bring to mind aspects of this unfortunate binding of routing/addressing: EID, current flaming over Politically Correct "addressing terminology", etc. I, personally, value this discussion about variable length address field sizes. I feel this way because I believe that we are about to experience a fundamental change in our networking algorithm when currently non-networked "dumb" devices become network addressable. Already we in Boeing have our doors and elevators networked (for security reasons) and anticipate this trend to advance towards other devices (e.g., thermostats, smoke detectors, etc.). Many co-workers have several computers (mobile computing), distributed computing is becoming "the norm", and robots are also addressable today. Each of these obvious tendencies reduces the current correlation between human populations and device addressibility. I mention this because Steve Deering's defense of the SIP address space is based on a relationship of addresses to the human population (or, more accurately, to telephone numbers). However, I believe that there will eventually be no correlation of addressing (regardless of the definition of the term) and human populations. Because of the hierarchical definition of the SIP address space, and our experience with the inefficiencies of similar schemas, I find myself agreeing with Ross Callon that the current SIP space is theoretically adequate but probably not practically adequate for the address flexibility which we users would like SIP to provide. Certainly, designing in the possibility of embedding non-IP address types (e.g., X.121 addresses) into the "IP addresses" does have a certain definite appeal for specific application usages (i.e., the non-general case). Permitting this type of flexibility is independent from whether one "buys into" Steve's arguments or not. For this reason, I am unconvinced by Steve Deering's arguments concerning the adequacy of the current SIP 64 bit addressing fields: I would like to see SIP adopt a variable address field length scheme for the flexibility and extensibility I desire. Thus, I resonate strongly with Tony Li's generic suggestion (that I am here applying to the SIP instance) that the SIP spec provide for a variable "addressing field" definition but that initial implementations use the 64 bit alternative as currently planned. I personally believe that if such a re-definition (i.e., variable length field) should be made for the SIP address field, then my personal qualms about SIP's extensibility/flexibility would go away. It all seems so painless to me: nothing is lost from SIP's current definition by designing in an "escape valve" into the definition to comfort pessimists such as myself who suspect that the future will be vastly different (in unpredictable ways) from the present. Yet, if no such escape valve is designed into SIP and pessimists such as myself turn out to be correct, I will find no joy in saying "I told you so". Thus, I see the issue to be one of "extensibility" and flexibility in SIP -- especially because we users are in a "lose lose" situation should the definitions be inadequately extensible. In any case, any anology to the Tacoma narrows bridge is false because, after all, this is fundamentally a routing problem and not an addressing problem. Thus, the address field size is only indirectly related to the primary issue (routing). Yet until we can successfully decouple routing from the "network layer device location" problem, the viability of the entire network layer seems to be subject to the adequacy of the address field size. Hence my fondness for variable length addresses. Now, to all those who wish to "flame me" for my opinions expressed above, I want to say the following: (####) (#######) (#########) Don't have a cow, man. (#########) / (#########) / (#########) / __&__ (#########) / \ (#########) |\/\/\/| /\ /\ /\ / | | (#########) | | | V \/ \---. .----/ \----. | (o (o) (o)(o)(##) | | \_ / \ / C .---_) ,_C (##) | (o)(o) (o)(o) <__. .--\ (o)(o) /__. | .(*** /____, (##) C _) _C / \ () / | \__/ \ (#) | ,___| /____, ) \ > (C_) < /_____\ | | | / \ /----' /___\____/___ /_____/ \ OOOOOO /____\ ooooo /| | / \ / \ / \ / \ / Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.oz.au Wed Sep 8 06:55:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17822; Wed, 8 Sep 1993 06:55:22 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17818; Wed, 8 Sep 1993 06:55:10 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA27874; Tue, 7 Sep 93 13:55:03 -0700 Message-Id: <9309072055.AA27874@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: bsimpson@morningstar.com, big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 07 Sep 93 11:53:31 -0700. <9309071753.AA12760@goshawk.lanl.gov> Date: Tue, 07 Sep 93 13:55:02 -0700 From: Dave Crocker X-Mts: smtp I have a different suggestion than Peter's. 1. Please do not attack any of the IPng contenders in terms of process. I believe that none of the contenders have mothers who wear combat boots. (Or is that phrase too dated?) 2. If you must challenge a process behavior, then please raise the challenge with the appropriate INDIVIDUALS, rather than a mailing list. The formal appeals chain is: Working Group chair, Area Director, IESG. Choose the "lowest" one on the list that you can, please. 3. Limit the public discussion to technical advantages/deficiencies. d/ From owner-Big-Internet@munnari.oz.au Wed Sep 8 07:34:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19146; Wed, 8 Sep 1993 07:34:39 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19141; Wed, 8 Sep 1993 07:34:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18413; Tue, 7 Sep 93 17:34:14 -0400 Date: Tue, 7 Sep 93 17:34:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309072134.AA18413@ginger.lcs.mit.edu> To: craig@aland.bbn.com, jack@synclib.sync.com, kasten@ftp.com Subject: Re: Variable length selectors/locators Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu From: Frank Kastenholz strategically placed Must-Be-Zero fields. These fields could be used as "overflow bits" into which the length may expand, or for something else, which we have not thought of yet. Such fields aren't a bad idea, but I'm not sure how useful they are as extensions to existing fields. You still have a problem using them, until a large fraction of hosts are updated. Suppose an old host gets a packet with this field used; it won't handle it correctly. Perhaps this, plus the "Host Version" stuff from PIP, would be useful together, though.. From: Craig Partridge On CPUs, I think the key influence is cache line sizes. IP processing (and TCP processing) are rapidly becoming memory bound, not processor bound and the question is how fast can you get the right piece of memory to the processor. This is sort of what I was getting at with my point about the costs in hosts. Of course, this just means that *selectors* need to be as short as possible, and preferably fixed length; separate locators (which would be processed less) are much less of an issue. (I know, I know, in most architectures the locator *is* the selector at the moment, but maybe we need to revisit that assumption...) From: Jack Dietz At any rate, I'm not sure I understand why those proposing variable-length addresses have desired byte-size granularity in addressing. You have to distinguish between variable length locators, variable length selectors, and variable length host-identifiers (the 3 different functions performed by the IPv4 "address" field). There are lots of good reasons for variable length locators, which we went over previously, most of them having to do with making routing work well in a growing and complex Internet. I won't revisit this debate (about including link-level addresses, naming topology aggregates, handling growth without needing to renumber, etc, etc, etc). The only good reasons I've ever heard of for variable length host-identifiers (e.g. EID's) are i) so that we don't "hit the wall" if we run out, and ii) allowing local sub-allocation of host-identifiers (e.g. to individual processes). As for selectors, the only reason to make them variable length is if either locators or host-ids are used directly as selectors, which most schemes seem to want to. All the proposed addressing extensions that I have seen (with the exception of TUBA) have used power-of-two length addresses. Nimrod will use variable length locators and fixed size (probably power of two) selectors. This allows it the best of both worlds: fast, efficient packet processing in both hosts and routers, but the flexibility need to make routing work in a very large and growing Internet. Noel From owner-Big-Internet@munnari.oz.au Wed Sep 8 07:39:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19340; Wed, 8 Sep 1993 07:39:51 +1000 (from owner-Big-Internet) Return-Path: Received: from mailhost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19335; Wed, 8 Sep 1993 07:39:42 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14) id AA03242; Tue, 7 Sep 93 15:39:26 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA15945; Tue, 7 Sep 93 15:39:39 MDT Message-Id: <9309072139.AA15945@goshawk.lanl.gov> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} In-Reply-To: Your message of Tue, 07 Sep 93 13:55:02 -0700. <9309072055.AA27874@Mordor.Stanford.EDU> Date: Tue, 07 Sep 93 15:39:38 MST From: peter@goshawk.lanl.gov Dave, I concur with your overall message on handling IETF process disputes. I would think it reasonbable (and responsible) for unsubstantiated public claims to be substantiated or withdrawn. cheers, peter From owner-Big-Internet@munnari.oz.au Wed Sep 8 07:41:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19389; Wed, 8 Sep 1993 07:41:56 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19378; Wed, 8 Sep 1993 07:41:27 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA28452; Tue, 7 Sep 93 14:41:17 -0700 Message-Id: <9309072141.AA28452@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 07 Sep 93 15:39:38 -0700. <9309072139.AA15945@goshawk.lanl.gov> Date: Tue, 07 Sep 93 14:41:17 -0700 From: Dave Crocker X-Mts: smtp Peter, ---- Included message: I would think it reasonbable (and responsible) for unsubstantiated public claims to be substantiated or withdrawn. I would expect them to be dropped and not pursued further. But yes, it's tough not to take the bait to make these distractions drag out, isn't it? d/ From owner-Big-Internet@munnari.oz.au Wed Sep 8 10:55:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27159; Wed, 8 Sep 1993 10:55:35 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB27152; Wed, 8 Sep 1993 10:55:17 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA04408 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Tue, 7 Sep 1993 17:54:58 -0700 Date: Tue, 7 Sep 1993 17:54:58 -0700 From: Tony Li Message-Id: <199309080054.AA04408@lager.cisco.com> To: kasten@ftp.com Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.EMBA.UVM.EDU, craig@aland.bbn.com In-Reply-To: (Frank Kastenholz's message of Tue, 7 Sep 93 13:17:29 -0400 <9309071717.AA24230@ftp.com> Subject: Variable length addresses > I see no point in having less than a full byte for the length of the > number of bytes to be routed on. If you want to be really > conservative, you say that the value 255 in the length field is > reserved for future use. Think about A) cpu(or custom silicon) architectures -- what would make the length easier to deal with? Certainly it should be an integral number of bytes. Two bytes might be better than one (easier to extract from the header). I already did. ;-) B) having some strategically placed Must-Be-Zero fields. These fields could be used as "overflow bits" into which the length may expand, or for something else, which we have not thought of yet. Do not have special, reserved, values. That is simply more checking and special case code. Ugh. The reserved value is probably not necessary. Certainly checking it is not necessary (you make the behavior of the reserved value "undefined" at present -- current implementations can just not check). Adding overflow bits is unnecessary and slows things down. Tony From owner-Big-Internet@munnari.oz.au Wed Sep 8 14:22:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06803; Wed, 8 Sep 1993 14:22:50 +1000 (from owner-Big-Internet) Return-Path: Received: from chsun.chuug.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB06795; Wed, 8 Sep 1993 14:22:29 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (5.65c8/1.34) id AA20621; Wed, 8 Sep 1993 00:45:53 +0200 Message-Id: <199309072245.AA20621@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <06152-0@magnolia.eunet.ch>; Wed, 8 Sep 1993 00:45:34 +0200 Subject: Re: New growth charts available To: pgross@ans.net (Phill Gross) Date: Wed, 8 Sep 1993 00:45:29 +0200 (MET DST) Cc: asp@uunet.uu.net, big-internet@munnari.oz.au In-Reply-To: <199309071958.AA41181@home.ans.net> from "Phill Gross" at Sep 7, 93 03:58:07 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1083 From: Simon Poole Sender: poole@magnolia.eunet.ch > The NIC tries to account for block assignments (to providers like RIPE Phill, it might just be nit-picking: but RIPE is -not- a service provider, RIPE is the informal association of IP service providers in Europe and provides a forum for some of the necessary coordination between service providers. The block assignment of class C addresses to "RIPE" are further parceled out to actual service providers (for example us) and one per nation "neutral" assignment office (for Switzerland run by us). > or Alternet) vs "real" assignments (to end users). Of course, the accuracy > of the accounting depends on providers reporting the real assignments back > to the NIC accurately and in a timely fashion. > > Are all you folks out there with block assignments reporting your "real" > assignments back to the NIC? To anser your question: yes, for example our allocations are reported back to the RIPE office in Amsterdam and then to the NIC. -- EUnet Switzerland Simon Poole Zweierstrasse 35 Tel: +41 1 291 45 80 CH-8004 Zuerich Fax: +41 1 291 46 42 poole@eunet.ch From owner-big-internet@munnari.oz.au Wed Sep 8 15:31:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09967; Wed, 8 Sep 1993 15:31:57 +1000 (from owner-big-internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB16767; Wed, 8 Sep 1993 06:27:58 +1000 (from kasten@ftp.com) Received: by ftp.com id AA03667; Tue, 7 Sep 93 16:27:53 -0400 Date: Tue, 7 Sep 93 16:27:53 -0400 Message-Id: <9309072027.AA03667@ftp.com> To: craig@aland.bbn.com Subject: Re: Variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au, wollman@uvm-gen.emba.uvm.edu > Frank: > > On CPUs, I think the key influence is cache line sizes. IP processing > (and TCP processing) are rapidly becoming memory bound, not processor bound > and the question is how fast can you get the right piece of memory to the > processor. So the ceiling of header-size/cache-line-size gives you a > rough sense of performance. Here are some common sizes (now or anticipated). This all depends on the processor AND the memory architecture. At my previous job, we were building a bridge/router that had all of the buffers and "critical path code" in 0-waitstate memory and the CPU (an AMD29000) had a real good pipelining scheme. With about a day's worth of work you could tune the code so that you could be working on word X of the header while the memory-fetch pipeline was loading word X+1 into registers. In effect, we had 256Kbytes of cache for buffers and another 256Kbytes for code... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Wed Sep 8 15:51:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10822; Wed, 8 Sep 1993 15:51:38 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16980; Wed, 8 Sep 1993 06:33:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17810; Tue, 7 Sep 93 16:33:12 -0400 Date: Tue, 7 Sep 93 16:33:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309072033.AA17810@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au > You mean that "I think the SDRP/Unified community generally agrees that > any practical future Internet routing architecture will need long, > flexible locators"? Deborah/Yakov, you guys listening? Do you agree? I think so. Is our source route anything other than a locator? No, a source route is not a locator (i.e. address, sort of). I know lots of people treat heirarchical locators and source routes as if they were sort of the same thing, but I think this is a misapprehnsion, and explained why on the list recently (Date: Mon, 16 Aug 93 01:21:37, Date: Tue, 17 Aug 93 00:08:25, Date: Wed, 25 Aug 93 12:20:10). I'll be happy to go over this again, but we just had this debate recently.. :-( > My understanding is that in both flow setup, and full source route mode, > SDRP/Unified uses its own packet format, and yes, you don't need the > locator in the header for either one. Correct. Tilt! You were just asking if your source route is anything other than a locator, now you agree that the source routed packets (which presumably contain a source route) do not contain a locator? Noel From owner-big-internet@munnari.oz.au Wed Sep 8 16:55:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13301; Wed, 8 Sep 1993 16:55:30 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19470; Wed, 8 Sep 1993 07:43:37 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA24759 (5.65c+/IDA-1.4.4); Tue, 7 Sep 1993 17:39:41 -0400 Date: Tue, 7 Sep 93 17:03:10 EDT From: "William Allen Simpson" Message-Id: <1066.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: TUBA not part of IETF > Could you identify how the TUBA working group is not operating within the > IETF standards framework? > Already has been argued on the IETF list. Read the archives, starting with "Last Call: Use of ISO CLNP in TUBA" in July. # Date: Fri, 30 Jul 93 13:18:51 EDT # Sender: ietf-request@IETF.CNRI.Reston.VA.US # From: William Allen Simpson # Message-Id: <920.bill.simpson@um.cc.umich.edu> # To: ietf@CNRI.Reston.VA.US # Reply-To: bsimpson@MorningStar.Com # Subject: Re: Last Call: Use of ISO CLNP in TUBA # Wow, 358K of messages on this topic in 24 hours! A bit much for those # of us on 2400 and 9600 bps links, let alone actually reading it. # 1) At the Amsterdam IETF, it was clearly announced by one of the TUBA # co-chairs that even if TUBA were not adopted as IPng, the TUBA work # will continue. This means (to me) that the TUBA proponents are not # willing to work within the IETF standardization process. Having # such a process includes a decision when to *quit*. # 2) When directly asked whether the IPng would be proposed to OSI as # the CLNPng, the co-chair was unable to make a commitment. This is # particularly enervating (to me) as so many of the ISO authors also # participate in the IETF. Why bother having an "OSI-EXTEND" WG, if # we can't actually make substantive changes? Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Wed Sep 8 19:23:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18962; Wed, 8 Sep 1993 19:23:15 +1000 (from owner-big-internet) Return-Path: Received: from mailhost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04201; Wed, 8 Sep 1993 13:26:08 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14) id AA13505; Tue, 7 Sep 93 21:25:47 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA17857; Tue, 7 Sep 93 21:26:00 MDT Message-Id: <9309080326.AA17857@goshawk.lanl.gov> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} In-Reply-To: Your message of Tue, 07 Sep 93 14:41:17 -0700. <9309072141.AA28452@Mordor.Stanford.EDU> Date: Tue, 07 Sep 93 21:26:00 MST From: peter@goshawk.lanl.gov Dave, It is interesting to note that members of the IESG now endorse the policy of simple acceptance of untrue statements in areas they are responsible for. peter From owner-big-internet@munnari.oz.au Wed Sep 8 19:31:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19343; Wed, 8 Sep 1993 19:31:33 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05819; Wed, 8 Sep 1993 14:01:53 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA02503; Tue, 7 Sep 93 21:01:44 -0700 Message-Id: <9309080401.AA02503@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: Variable length {selector|locator} Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 07 Sep 93 21:26:00 -0700. <9309080326.AA17857@goshawk.lanl.gov> Date: Tue, 07 Sep 93 21:01:44 -0700 From: Dave Crocker X-Mts: smtp Peter, ---- Included message: It is interesting to note that members of the IESG now endorse the policy of simple acceptance of untrue statements in areas they are responsible for. As I said it my previous note, I DO appreciate the difficulty in not taking the bait to feed the heat rather than the content. So, I'll simply note that a statement like the one you made above cannot conceivable help things, except of course to feed that heat. I would appreciate your not distorting my comments in that manner. Dave From owner-Big-Internet@munnari.oz.au Wed Sep 8 23:46:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28556; Wed, 8 Sep 1993 23:46:39 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28553; Wed, 8 Sep 1993 23:46:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22604; Wed, 8 Sep 93 09:46:10 -0400 Date: Wed, 8 Sep 93 09:46:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309081346.AA22604@ginger.lcs.mit.edu> To: bsimpson@morningstar.com Subject: Re: TUBA not part of IETF Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > Could you identify how the TUBA working group is not operating within the > IETF standards framework? Already has been argued on the IETF list. Read the archives, starting with "Last Call: Use of ISO CLNP in TUBA" in July. # From: William Allen Simpson # 1) At the Amsterdam IETF, it was clearly announced by one of the TUBA # co-chairs that even if TUBA were not adopted as IPng, the TUBA work # will continue. This means (to me) that the TUBA proponents are not # willing to work within the IETF standardization process. Having # such a process includes a decision when to *quit*. Arrrgggghhhh, do we really have to go through this again? It was a total waste of time the first time, and the thought of having to do it again is really insupportable. Look, first, just because that's your interpretation of the rules, it doesn't make it so. The rules *do not* say that the IETF can force an active WG with a modest amount of support to quit. Carefully study RFC-1310, particularly sections 2.8 ("This provision is not intended to threaten legitimate and active Working Group efforts, but rather to provide an administrative mechanism for terminating a moribund effort") and 3.2.1 ("appears to enjoy enough community interest to be considered valuable"). Second, nobody has to come to the IETF to do standards for the Internet. They can write do them in a company or other context, and get them adopted universally. The IETF has no police powers to stop people running stuff on the Internet which wasn't done in an IETF context. If you throw people out of the tent, they will set up their own, where the rules may not be as congenial. That's one reason the rules don't *allow* the ability to coerce people the way you imply; we want them inside the IETF tent, not outside. If someone wants to keep working on something the rest of us think is useless, fine. That's their privilege. It may be a colossal waste of time, but I'd rather depend on the Internet as a whole just ignoring their stuff, than provide (fallible) people with the power to can technical efforts that do not receive general support. Such a power is just asking to be abused, and if it exists, it surely one day will be. You should support their right to keep working; one day it may be you who wants to keep going, and then you'll be happy we allow it. Noel From owner-big-internet@munnari.oz.au Thu Sep 9 00:28:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00727; Thu, 9 Sep 1993 00:28:52 +1000 (from owner-big-internet) Return-Path: Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27264; Wed, 8 Sep 1993 23:07:53 +1000 (from hcb@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA01141; Wed, 8 Sep 1993 09:06:59 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199309081306.AA01141@world.std.com> Subject: Routing architecture? To: big-internet@munnari.oz.au Date: Wed, 8 Sep 1993 09:06:58 -0400 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 464 As has been mentioned, it's hard to distinguish, at out present level of knowledge, between routing and addressing. I've found it harder and easier, however, to distinguish between the IPng documents and the routing architecture work (i.e., Nimrod, Unified) being mentioned.... I can't find the latter! Could someone post ftp (or other pointers) to these? Returning to IPng, I'd also appreciate the list-request addresses for TUBA, SIP, and TPIX. ---- Howard From owner-big-internet@munnari.oz.au Thu Sep 9 02:28:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04985; Thu, 9 Sep 1993 02:28:53 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00409; Thu, 9 Sep 1993 00:21:11 +1000 (from swb1@cornell.edu) Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA19657 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 8 Sep 1993 10:20:04 -0400 Message-Id: <199309081420.AA19657@postoffice.mail.cornell.edu> X-Sender: swb1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Sep 1993 10:20:14 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott W Brim Subject: Why people come (was TUBA not part of IETF) Cc: big-internet@munnari.oz.au Noel, >Second, nobody has to come to the IETF to do standards for the Internet. We were talking about this the other day. In your view, why *do* people come to IETF? What good is it? And by the way, how's the family? Thanks ... Scott From owner-Big-Internet@munnari.oz.au Thu Sep 9 02:36:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05273; Thu, 9 Sep 1993 02:37:10 +1000 (from owner-Big-Internet) Return-Path: Received: from rosebud.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05263; Thu, 9 Sep 1993 02:36:59 +1000 (from tep@SDSC.EDU) Received: from galt.sdsc.edu by mailserver.sdsc.edu (4.1/4.8) id AA23532; Wed, 8 Sep 93 09:37:17 PDT Received: by galt.sdsc.edu (4.1/1.8-client) id AA22545; Wed, 8 Sep 93 09:37:00 PDT Date: Wed, 8 Sep 93 09:37:00 PDT From: tep@SDSC.EDU Message-Id: <9309081637.AA22545@galt.sdsc.edu> To: big-internet@munnari.oz.au Cc: bsimpson@morningstar.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9309081346.AA22604@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: TUBA not part of IETF X-Organization: San Diego Supercomputer Center, San Diego, California Although I hesitate to fan the flames, and I am not a TUBA supporter, I must add my $0.02 to Noel's comment: If someone wants to keep working on something the rest of us think is useless, fine. That's their privilege. It may be a colossal waste of time, but I'd ^^^ rather depend on the Internet as a whole just ignoring their stuff, than provide (fallible) people with the power to can technical efforts that do not receive general support. Such a power is just asking to be abused, and if it exists, it surely one day will be. You should support their right to keep working; one day it may be you who wants to keep going, and then you'll be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ happy we allow it. Noel Non-TUBA efforts do not have a monopoly on brain-power or good-ideas. There is no telling what ideas may come out of TUBA (or any other group), that can be applied to the other IPng efforts. I strongly prefer multiple, independent, research efforts, even if they aren't on "the standards track". After all UNIX and TCP/IP were just research toys, just a few years ago :-) -- Tom E. Perrine (tep@SDSC.EDU) | Voice: +1 619 534-8328 San Diego Supercomputer Center | FAX: +1 619 534-5152 P. O. Box 85608 | Have you pinged your Cray today? San Diego CA 92186-9784 | From owner-Big-Internet@munnari.oz.au Thu Sep 9 03:42:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07889; Thu, 9 Sep 1993 03:43:07 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07883; Thu, 9 Sep 1993 03:42:56 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA08072); Wed, 8 Sep 93 12:42:43 CDT Received: by sabine.is.rice.edu (AA08468); Wed, 8 Sep 93 12:42:41 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9309081742.AA08468@sabine.is.rice.edu> Subject: Re: Why people come (was TUBA not part of IETF) To: swb1@cornell.edu (Scott W Brim) Date: Wed, 8 Sep 93 12:42:40 CDT Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <199309081420.AA19657@postoffice.mail.cornell.edu>; from "Scott W Brim" at Sep 8, 93 10:20 am X-Mailer: ELM [version 2.3 PL11] Noel, >Second, nobody has to come to the IETF to do standards for the Internet. To quote Gene Hastings, (thanks Gene) >> Didacticism for the day: >> Socialization is always a valid use of operators' fora. >> G -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-big-internet@munnari.oz.au Thu Sep 9 07:22:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15707; Thu, 9 Sep 1993 07:22:36 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309082122.15707@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10507; Thu, 9 Sep 1993 04:53:53 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4519; Wed, 08 Sep 93 14:53:39 EDT Date: Wed, 8 Sep 93 14:53:39 EDT From: yakov@watson.ibm.com To: hcb@world.std.com, big-internet@munnari.oz.au Subject: Routing architecture? Ref: Your note of Wed, 8 Sep 1993 09:06:58 -0400 (EDT) Howard, The Unified Architecture is documented in RFC1322. There is also a SIGCOM92 paper on the Unified written by Deborah Estrin, Steve Hotz and myself. The associated protocol specs (BGP, IDRP, SDRP) are also available. Yakov. P.S. There is also an article in ConneXions (Nov 1992) on SDRP. From owner-Big-Internet@munnari.oz.au Thu Sep 9 09:47:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21671; Thu, 9 Sep 1993 09:48:39 +1000 (from owner-Big-Internet) Return-Path: Received: from CNRI.Reston.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21647; Thu, 9 Sep 1993 09:47:42 +1000 (from jstewart@CNRI.Reston.VA.US) Received: from excelsior.cnri.reston.va.us by CNRI.Reston.VA.US id aa01216; 8 Sep 93 19:42 EDT From: IESG Secretary To: big-internet@munnari.oz.au, iepg@CNRI.Reston.VA.US, pip@thumper.bellcore.com, ripe@ripe.net, sip@caldera.usc.edu, tpix@world.std.com, tuba@lanl.gov Reply-To: ietf@CNRI.Reston.VA.US Subject: Fwd: A Direction for IPng Date: Wed, 08 Sep 1993 19:42:10 -0400 Sender: jstewart@CNRI.Reston.VA.US Message-Id: <9309081942.aa01216@CNRI.Reston.VA.US> Folks, Phill Gross asked me to forward this to you all FYI. /jws ------- Forwarded Message Date: Tue, 07 Sep 1993 14:02:30 -0400 From: Phill Gross To: IETF-Announce :; Subject: A Direction for IPng A Direction for IPng At the Amsterdam IETF meeting, we held a BOF, entitled the "IPDecide BOF", on the process and progress of the IPng activities. ("IPng" stands for "IP, the next generation". The IPDecide BOF was chaired by Brian Carpenter. Minutes are available in the IETF directories, with the file name .) The IPDecide BOF explored several facets of the IPng process, such as - "What is the basis for choosing the next generation IP (i.e., what are the technical requirements and decision criteria)." - "With the advent of CIDR and new, more stringent address assignment policies, are we comfortable that we truly understand the level of urgency?" - "Should the IETF or the marketplace make the final IPng decision". The BOF was held in a productive atmosphere, but did not achieve what could be called a clear consensus among the assembled attendees. In fact, despite its generally productive spirit, it did more to highlight the lack of a firm direction than to create it. The IPDecide BOF was followed the next evening by the open IESG plenary. During this session, the IESG and the assembled attendees discussed the IPng issues and seemed to arrive at a consensus based on the following set of bullets presented by the IETF chair: - "The IETF needs to move toward closure on IPng." That is, the IETF should take active steps toward a technical decision, rather than waiting for the "marketplace" to decide. - "The IESG has the responsibility for developing an IPng recommendation for the Internet community." That is, the IESG should provide leadership and take specific actions to help move the IETF toward a technical decision. - "The procedures of the recommendation-making process should be open and published well in advance by the IESG." - "As a part of the process, the IPng WGs may be given new milestones and other guidance to aid the IESG." - "There should be ample opportunity for community comment prior to final IESG recommendation (e.g., there will be an extended Last Call)." A Direction For IPng Building on this consensus, I'd like to announce a set of specific directions in the IESG that I hope will move us toward timely resolution of many of the key IPng issues. The IESG will establish a temporary, ad hoc, "area" to deal specifically with IPng issues. The charter for this new IESG area is to develop a recommendation on which, if any, of the current proposals should be adopted as the "next IP". This recommendation will be submitted to the IESG and to the Internet community for review. Following an adequate period of review to surface any community concerns, the IESG will issue a final IPng recommendation. All of the current IPng-related working groups will be moved immediately into this new area. This new area will be headed by two co-Area Directors from within the IESG. I have asked Allison Mankin (NRL), current Transport Services AD, and Scott Bradner (Harvard), current Operational Requirements AD, to serve as co-AD's for this temporary area. I am very pleased to report that they have agreed to take this important assignment. (Because this is expected to be a temporary assignment, Scott and Allison will also continue to serve in their current IESG positions during this period.) All IETF Areas are now expected to have Area Directorates. For the IPng Area, a Directorate will be especially important to bring additional viewpoints into the process. Therefore, I am asking that, as their first action, Scott and Allison form a specific IPng Directorate to act as a direction-setting and preliminary review body. The IPng process will continue to be completely open, and therefore reports and meeting notes from any IPng Directorate meetings will be published in timely fashion. Issues Toward IPng Resolution Two important issues need resolution immediately before we can expect progress toward an IPng recommendation: - What is the scope of the effort? That is, should IPng be limited to solving the well known scaling and address exhaustion issues; or should IPng also include advanced features such as resource reservation for real-time traffic? The argument in favor of considering advanced features is that migration to a new IP is (hopefully, only!) a once-in-a-generation occurance, and therefore all advanced features should at least be considered. Arguments opposed to considering advanced features include the fact that we may not have time for this level of effort before the scaling and address exhaustion problems confront us, and that we may not have the necessary understanding and experience to make all the correct choices at this time. - What is the available timeframe? That is, before we can even begin to make an informed decision about the scope, we need a better understanding of the urgency and time constraints facing us. Factors that affect the available time include the current rate of address assignments (which can give us an estimate of when we are currently projected to run out of addresses), the current policies governing address assignment (which can give us an understanding of how policies affect the assignment and utilization rates), the impact of CIDR aggregation, the development time for IPng, and the time needed to field and migrate to the new IPng. Therefore, I am asking the new AD's and the Directorate to start immediately the following specific activities to help guide their ultimate IPng recommendation: 1. Develop an understanding of the available timeframe, covering at least the following issues: - Review Internet growth metrics, such as the current address assignment and utilization rates. Develop an understanding of how the new address assignment policies impact the assignment and utilization rates. - Review the expected impact of CIDR address aggregation. Develop an understanding of the expected savings due to CIDR aggregation. - Develop new technical guidelines for classless Internet addressing. Specific examples include guidelines for how to utilize variable length subnet masks, and how to utilize currently unused Class A and B addresses in a classless fashion in hosts and routers. - Develop a strong understanding of the time required for the development, fielding, and migration for a new IP. - Based on all the above issues, (a) develop an estimate for how long we have to to develop and deploy an IPng. This could be a set of estimates based on best/worst case estimates for how each of the above factors will affect the available timeframe. (b) Consider whether more stringent assignment policies might provide additional time. If so, recommend such policies. (c) make a recommendation on whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. 2. Based on an informed judgement of the time constraints above, make a recommendation regarding the scope for IPng, i.e., should IPng consider scaling issues only or advanced topics also. 3. Based on the scope and time constraints, develop a clear and concise set of technical requirements and decision criteria for IPng. These should include, but not be limited to, the criteria outlined in the IESG statement (RFC1380). 4. Based on the decision criteria, scope, and time constraints, make a recommendation on which of the current IPng candidates to accept, if any. Finally, I am asking Scott and Allison to make a detailed report at the opening plenary of the next IETF meeting in November on the status of setting up their new area, and on their progress toward organizing the above work items. In particular, the status of the work items on timeframe should be fully reported. This will be followed by regular progress reports to the Internet community, at IETF meetings and in other appropriate forums. Please join me in giving Scott and Allison our full cooperation, and in thanking them for accepting this daunting assignment. I feel confident that we will now make significant progress on the important IPng issues facing the Internet community. Phill Gross IETF/IESG Chair P.S. All follow-up discussion of this message should be on the main IETF mailing list ietf@cnri.reston.va.us. ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Thu Sep 9 17:44:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11286; Thu, 9 Sep 1993 17:44:46 +1000 (from owner-Big-Internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11263; Thu, 9 Sep 1993 17:44:03 +1000 (from whyman@mwassocs.demon.co.uk) Date: Thu, 09 Sep 1993 08:40:01 BST Message-Id: <9309090840.aa3866@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: J.Crowcroft@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au (Big Internet Maillist) Subject: Re: Variable length addresses X-Mailer: Cinetic Mail Manager V2.1 >From: Jon Crowcroft >Message-ID: <"relay1.pip.726:07.08.93.11.09.01"@pipex.net> > > > > >>now show me s/w algoptihms that can do variable length lookkups as > >>fast as fixed or even just witrh a constant add on & i will be > >>innerested... > > >Anyway, in the end all the user cares about is "how many bangs per buck", and > >the lesson of MS Windows is that at the workstation end of the market, > >hardware cost is largely demand driven. So, OK, if your > >file server does require a faster CPU to cope with a more complex network access > >when you are talking about a change that affects 1.5 million >plus machines, I am talking INSTALLED BASE > >the uptake of windows-NT in the worlds 65 Million PCs is going to be >miniscule because very few of them can upgrade to 16Mbyte of memory >needed to run it at even 1/2 acceptable speed > >i thought that was at least 1 important criterion for new addressing >schemes... > >cheers >jon > I would agree that being able to run on the installed base is important, but the installed base should not be a brake on introducing new functionality. Otherwise, there would be no progress. We may argue whether variable length CLNP packets can be switched as fast as a protocol with a smaller fixed address (although as you can always assume a fixed length within a Routing Domain, the argument is more about address length than the variable length aspect), but there is no doubt that the installed base can switch CLNP. Out of your 1.5 million plus machines, how many are operating at 100% utilisation? A very small proportion is what I would suspect. Only those operating near their limit are going to be affected by any additional overhead due to switching longer addresses, and of these, many will be nearing an upgrade anyway. Furthermore, there will be no flag day for any transition between IP and TUBA. Users will upgrade at their own pace, and can defer the upgrade to TUBA until they need to upgrade anyway. For most users, the cost of switching longer addresses will be lost in the noise level, but the gain, in terms of long term stability and continuity of operation is real and cannot be lost for the sake of a few extra lines of 'C'. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-big-internet@munnari.oz.au Fri Sep 10 05:19:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07620; Fri, 10 Sep 1993 05:19:45 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309091919.7620@munnari.oz.au> Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28566; Fri, 10 Sep 1993 01:43:49 +1000 (from whyman@mwassocs.demon.co.uk) Date: Fri, 10 Sep 1993 01:43:49 +1000 From: whyman@mwassocs.demon.co.uk From owner-big-internet@munnari.oz.au Fri Sep 10 07:12:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11917; Fri, 10 Sep 1993 07:12:20 +1000 (from owner-big-internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28515; Fri, 10 Sep 1993 01:43:08 +1000 (from whyman@mwassocs.demon.co.uk) Date: Thu, 09 Sep 1993 15:00:09 BST Message-Id: <9309091500.aa3890@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: ericf@atc.boeing.com Cc: big-internet@munnari.oz.au (Big Internet Maillist) Subject: Re: Variable Length Addresses X-Mailer: Cinetic Mail Manager V2.1 >From: Eric Fleischman >Message-Id: <9309072051.AA14497@atc.boeing.com> >I am unconvinced by Steve Deering's arguments concerning the adequacy of >the current SIP 64 bit addressing fields: I would like to see SIP adopt >a variable address field length scheme for the flexibility and extensibility >I desire. Thus, I resonate strongly with Tony Li's generic suggestion (that >I am here applying to the SIP instance) that the SIP spec provide for a >variable "addressing field" definition but that initial implementations use >the 64 bit alternative as currently planned. > >I personally believe that if such a re-definition (i.e., variable length >field) should be made for the SIP address field, then my personal qualms >about SIP's extensibility/flexibility would go away. It all seems so >painless to me: nothing is lost from SIP's current definition by designing >in an "escape valve" into the definition to comfort pessimists such as >myself who suspect that the future will be vastly different (in >unpredictable ways) from the present. Yet, if no such escape valve is >designed into SIP and pessimists such as myself turn out to be correct, >I will find no joy in saying "I told you so". Thus, I see the issue to >be one of "extensibility" and flexibility in SIP -- especially because >we users are in a "lose lose" situation should the definitions be >inadequately extensible. > >Sincerely yours, > >--Eric Fleischman > > Eric, While your words seem very reasonable, I would ask the question, what is the difference between SIP supporting variable length addresses and CLNP. The answer can be nothing other than "the bits are in a different order!" Given that CLNP is the international standard and widely implemented, the only justification for a version of SIP with variable length addresses that there can be is not invented here. No, SIP must stand by its 64-bit address space and either win or hang because of it. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.oz.au Fri Sep 10 09:06:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16245; Fri, 10 Sep 1993 09:07:29 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16240; Fri, 10 Sep 1993 09:06:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04489; Thu, 9 Sep 93 19:06:18 -0400 Date: Thu, 9 Sep 93 19:06:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309092306.AA04489@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ietf@cnri.reston.va.us Subject: Nimrod funded Cc: jnc@ginger.lcs.mit.edu As some of you may recall, last June I decided that trying to "make Nimrod happen" as a part time, volunteer, activity, was not plausible. (For those you you who don't know what a 'Nimrod' is, it is a plan of mine for a new Internet routing and addressing architecture suitable for a very large Internet.) I decided that a project of this magnitude and importance called for a full-time, funded effort, and that I was not a suitable person to be the focus of that effort. I polled the IETF for a partner in this effort (i.e. write a proposal, get funding, get a protocol specified and a test implementation done), and of a number of responses, it seemed to me that one from Dr. Martha Steenstrup at BBN was the optimal. Martha and BBN put together a proposal to DARPA to do a Nimrod project, and I have been informed that this proposal has been accepted, and BBN has been authorized by DARPA to start work on the project, and that this project can now be announced publicly. A team of about 5 people (not all full-time) at BBN has already been selected, with Martha as Principal Investigator, and John Moy (of Proteon, the OSPF architect) and I as outside technical expertise. The project is supposed to do four things, in two phases (the first phase has been funded): Phase 1: - Finish defining the Nimrod architecture in detail - Prepare a set of specification documents and algorithm appendix documents Phase 2: - Do a test implemention of the protocols - Perform a field trial to evaluate the design We will be forming an IETF WG (with myself as a cochair, along with a Isidro Castineyra of BBN) as the focal point for this activity. The BBN effort will be completely integrated with the IETF activity. A draft WG charter has been prepared and submitted, and I expect that (after some negotiation with the IESG AD over the details of the charter) the WG will be set up in the near future. The Nimrod architecture and protocols will be designed within the IETF context, and the results released as either Experimental or standards track documents (probably the latter), as seems relevant. This path is being taken for two reasons. First, I feel that the IETF community provides an unparalled forum for discussion about, and critical review of, advanced networking technology. Second, should the Internet community decide to utilize the Nimrod technology, it will already have been through the usual community analysis and review process. An announcement about a mailing list, etc will be forthcoming shortly. Noel From owner-Big-Internet@munnari.oz.au Fri Sep 10 18:12:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06915; Fri, 10 Sep 1993 18:12:17 +1000 (from owner-Big-Internet) Return-Path: Received: from gate.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06912; Fri, 10 Sep 1993 18:12:09 +1000 (from whyman@mwassocs.demon.co.uk) Received: from mwassocs.demon.co.uk by gate.demon.co.uk id aa11877; 10 Sep 93 9:11 BST Date: Fri, 10 Sep 1993 08:39:05 BST Message-Id: <9309100839.aa3941@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: Tony Whyman To: Big Internet Maillist Subject: What you all missed yesterday X-Mailer: Cinetic Mail Manager V2.1 Sorry about the empty message yesterday, what I was trying to say was: ------------------------------------------------------------------------- Like most people, I have been willing to accept the premise that routing decisions made using longer addresses will take more CPU time than those made using shorter addresses. After all this is common sense, isn't it? However, thinking about this issue, I am not so sure. Consider the following. Firstly, assuming that route aggregation is being used for inter-domain routing and inter-domain routing decisions are therefore based on the matching of variable length address prefixes, then the basic routing decision algorithm is: IF address prefix for my local routing domain matches with destination address THEN route to local destination using rest of destination address ELSE look for inter-domain route with the longest matching address prefix, if any ENDIF. Now, with CLNP, and making the very sensible assumption that all addresses within the local Routing Domain are the same length, that basic decision can be simply made by comparing the packet's destination address (including address octet), with the address prefix for the local Routing Domain, itself prefixed with the length of addresses within the local RD (a constant). It's an octetstring comparison, and is made very quickly. After that, if it's a local address, then the remainder of the address is a known fixed length quantity, at a known offset from the start of the packet, and the CPU cost to route it simply depends on how long the address is, how much structure can be used to speed the decision, etc. If the address is in another Routing Domain, then you're into variable length prefix matching algorithms. Incidentially, the fact that the CLNP address is itself variable length only needs to be recognised in this case, right at the end, when a check needs to be made to ensure that the selected address prefix isn't longer than the destination address. So what's the difference between the cost of routing a CLNP packet and a fixed 64-bit address. Well, if the CLNP address was itself only 8 octets long, then the only extra cost of using CLNP appears to be including the extra (length) octet in the initial decision and the check at the end of the inter-domain routing decision. For longer CLNP address then obviously there is a comparitive increase in the overhead at each stage in the decision process. But, that is assuming that all decisions are based on octet aligned addresses. Most (maybe all) processor architectures I've worked with are much less efficient when comparing bitstrings than octetstrings. You often end up doing an initial mask on the bistring and then an octetstring compare. With the big address space that comes with CLNP, address prefixes can always be allocated on octet boundaries, and so this problem avoided. However, if the limited address space of 64-bits requires bit-aligned prefixes in order to have a hope of addressing the world, the cost of the routing decision process may actually be higher than with a longer CLNP address. So, if efficient utilisation of a 64-bit address space requires bit aligned address prefixes, the net result may be a routing decision process that is less efficient than that for a longer CLNP address. To put it another way, address length is not the only determinant of an efficient routing decision. Address structure and address component boundaries are at least as important, and whether an address is variable or fixed length is of a lower order of importance altogether. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-big-internet@munnari.oz.au Fri Sep 10 21:28:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12885; Fri, 10 Sep 1993 21:28:41 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10545; Sat, 4 Sep 1993 07:40:31 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA09612 (InterLock SMTP Gateway 1.1 for Big-Internet@munnari.OZ.AU); Fri, 3 Sep 1993 17:35:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 3 Sep 1993 17:35:13 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 3 Sep 1993 17:35:13 -0400 From: Dennis Ferguson Message-Id: <199309032138.AA73277@foo.ans.net> To: solensky@ftp.com (Frank T Solensky) Cc: Big-Internet@munnari.OZ.AU Subject: Better way to look at this? (Re: New growth charts available) In-Reply-To: (Your message of Wed, 01 Sep 93 21:07:28 GMT.) <9309012107.AA03588@ftp.com.ans-relay> Date: Fri, 03 Sep 93 17:38:00 -0500 > There were 6360 reachable network numbers this time last year, thus the > growth rate over the last 12 months averaged out to 7.56%/month, or > doubled every 9.5 months. The current trend line suggests that we'll > run out of IPv4 net numbers on March 31, 2000 (24 days earlier than last > month's trend line). While "number of networks" is still a useful measure to size the forwarding table in a default-free, "classful" router, it seems to me that past classed network totals are rapidly becoming useless as an indicator of future growth (if they ever were useful). Consider, for example, that with classless routing providing an organization with a single class B network, or 256 class C networks, or 1/256th of a class A network, will have an absolutely identical result both for the organization which obtains the address space and for classless forwarding tables, but will have drastically different results when added to your total of class A+B+C networks. In fact the number of "networks" consumed in making 256 such organizations happy might be anywhere from 1 to 65,536, even though the end result for classless routers and for our utilization of address space is identical. Indeed, I'd suggest that the huge increases in the number of reachable networks over the past year is a direct consequence of the policy of reducing the allocation of class B numbers in favour of multiple class C numbers, yet your analysis implicitly assumes that the proportion of class A, B and C networks being added to the routing database is historically constant. This assumption is incorrect, so I suspect any predictions derived from it are going to be equally incorrect. If we are eliminating network classes from our routers I think we've also got to eliminate network classes from the historical data we are analizing. I think a better way to look at this is to measure the fraction of allocatable address space we are using, since this directly measures how much of what we have is gone independent of how we decide to split up and parcel out the remaining address space in future. For the NSFnet routing database it is unfortunate that the historical split of class A, B and C networks in the database was not recorded, just the total number of networks. It turns out, however, that Merit does record the date on which each network in the database was first entered, and this can allow one to regenerate the approximate historical class A/B/C split (with some caveats). I've included my best effort at doing this below. I've also included in the table two other numbers, the percentage of the address space configured in the database for each month (where a class A network is 0.445%, a class B is 0.00174% and a class C 0.0000068%) and the percentage of the address space consumed by configured class B+C networks only. Note that at the end of August I counted 26 class A networks, 3891 class B networks and 11332 class C networks, for a total of 15249 networks. This represents 18.47% of the allocatable address space, with the 26 class A networks accounting for 11.61% of the address space and the remaining class B+C networks making up 6.86% of the address space. I would point out that the bulk of the address space currently in use on the routed Internet resides in the 26 class A networks. While I'd be willing to be persuaded otherwise, I think trying to derive future trends from historical data which includes these class A networks is not going to provide a happy result, for a couple of reasons: (1) 26 is not a big enough number to be statistically significant. While the thousand's of class B and C networks we've added in the past may say something about the future, the 26 class A networks probably don't say much at all. It is conceivable, for example, that we may never add another class A network to the routing database. (2) We've stopped allocating class A networks, making it more likely that class A additions won't occur very frequently in the future. (3) At no time has the amount of B+C space added to the database in a single month amounted to the equivalent of the addition of one class A network. Hence, in terms of trends, months when a single class A network is added are anomalies (should a class A network be removed we would probably see a month with an equally anomalous decrease in total routed address space). (4) I suspect currently allocated class A networks are substantially less efficiently used than our currently allocated class B/C networks. Since our current allocation policies are focussed on increasing the efficiency of use of the address space, I suspect trends derived from the better-used parts of the current routed address space may be better indicators of the future. Given this stated bias towards ignoring class A networks, I would point out that the average monthly growth of class B+C address space utilization over the past 12 months has been 2.75% (including the class A's gives a growth rate of 2.71%). This is a doubling time of 25 or 26 months. This compares to 4.13% for the 12 months ending September 1992, and 4.27% for the 12 months ending September 1991. In fact the 12 months just ended shows a lower average monthly growth rate of class B+C space than any 12 month period since the database was established. I have no idea what this implies in terms of future growth, but I'm pretty sure any analysis which concludes from the last 12 months of data that we are going to run out of address space sooner than previously thought has got to be defective. The CIDR-inspired allocation policies in place for the last year seem to have made a difference for the better in terms of the rate at which we consume the address space, though at the expense of forwarding table size for classful routers. Dennis Ferguson ============================================================ This data is derived from ftp.merit.edu:/nsfnet/announced.networks/country.now which lists, among other things, network numbers and their date of insertion in the nsfnet routing database. The historical monthly total number of networks in the database should be comparable to the data found in ftp.merit.edu:/nsfnet/statistics/history.netcount from which historical network number graphs are usually produced, but with (at least) the following known defects: (1) network numbers which were in the database at one time, but which have since been deleted, are not included (2) some (unknown but hopefully small) number of networks in country.now have been deleted and re-added to the database for some reason(s). For example, 128.100 is listed as having been added in October, 1991, but certainly should have been in the database from 1988 onwards. (3) The country.now file shows the ARPANET/MILNET networks being added to the database in January, 1990, while history.netcount shows this bump in April, 1990. I don't know why. The effect of (1) and (2) will be to make older totals smaller than they actually were. The table shows the total number of networks, and then breaks this down into class A, B and C networks. In addition it shows the fraction of total allocatable address space this represents, as well as the fraction of allocatable address space the Class B and C networks alone represent. The latter numbers are computed using ((#A*65536) + (#B*256) + #C) / ((128*65536) + (16384*256) + 2097152) ((#B*256) + #C) / ((128*65536) + (16384*256) + 2097152) expressed as a percentage. Total %Address %Address Space Month Nets Class A Class B Class C Space (Class B+C Only) ============================================================== 8807 166 1 128 37 0.67 0.22 8808 175 2 133 40 1.13 0.23 8809 187 3 139 45 1.58 0.24 8810 232 5 175 52 2.54 0.31 8811 259 5 195 59 2.57 0.34 8812 274 5 205 64 2.59 0.36 8901 288 6 212 70 3.05 0.37 8902 322 6 234 82 3.09 0.41 8903 353 6 257 90 3.13 0.45 8904 401 6 287 108 3.18 0.50 8905 455 6 321 128 3.24 0.56 8906 491 8 340 143 4.17 0.59 8907 513 9 351 153 4.63 0.61 8908 598 9 408 181 4.73 0.71 8909 650 9 443 198 4.79 0.77 8910 674 9 460 205 4.82 0.80 8911 737 9 492 236 4.88 0.86 8912 766 9 512 245 4.91 0.89 9001 1187 12 758 417 6.68 1.32 9002 1226 12 775 439 6.71 1.35 9003 1281 12 803 466 6.76 1.40 9004 1362 12 852 498 6.85 1.49 9005 1411 12 880 519 6.90 1.54 9006 1469 13 907 549 7.39 1.59 9007 1584 13 985 586 7.53 1.72 9008 1726 13 1059 654 7.65 1.85 9009 1801 13 1101 687 7.73 1.92 9010 1886 13 1146 727 7.81 2.00 9011 1964 13 1174 777 7.86 2.05 9012 2029 13 1201 815 7.90 2.10 9101 2169 13 1266 890 8.02 2.21 9102 2250 13 1315 922 8.10 2.30 9103 2334 13 1362 959 8.19 2.38 9104 2453 14 1410 1029 8.72 2.47 9105 2589 14 1492 1083 8.86 2.61 9106 2797 15 1606 1176 9.51 2.81 9107 2910 15 1663 1232 9.60 2.91 9108 3070 15 1747 1308 9.75 3.06 9109 3199 16 1805 1378 10.30 3.16 9110 3365 16 1864 1485 10.40 3.26 9111 3548 16 1934 1598 10.53 3.38 9112 4091 16 2105 1970 10.83 3.68 9201 4322 16 2199 2107 10.99 3.85 9202 4575 16 2335 2224 11.23 4.09 9203 4765 17 2420 2328 11.83 4.24 9204 5074 18 2523 2533 12.45 4.42 9205 5309 18 2580 2711 12.55 4.52 9206 5525 18 2646 2861 12.67 4.63 9207 5812 19 2741 3052 13.28 4.80 9208 6162 19 2829 3314 13.44 4.96 9209 6427 19 2889 3519 13.54 5.06 9210 7100 20 3043 4037 14.26 5.33 9211 7541 20 3111 4410 14.38 5.46 9212 8258 22 3254 4982 15.53 5.71 9301 8754 22 3312 5420 15.63 5.81 9302 9370 22 3399 5949 15.79 5.97 9303 10260 22 3482 6756 15.94 6.12 9304 11122 23 3557 7542 16.52 6.25 9305 12172 23 3648 8501 16.69 6.42 9306 13133 24 3724 9385 17.27 6.56 9307 14089 25 3817 10247 17.89 6.73 9308 15249 26 3891 11332 18.47 6.86 From owner-Big-Internet@munnari.oz.au Sat Sep 11 03:06:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21667; Sat, 11 Sep 1993 03:06:28 +1000 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21664; Sat, 11 Sep 1993 03:06:17 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA06371; Fri, 10 Sep 93 10:07:10 -0700 Date: Fri, 10 Sep 93 10:07:10 -0700 From: Eric Fleischman Message-Id: <9309101707.AA06371@atc.boeing.com> To: dee@skidrow.lkg.dec.com, whyman@mwassocs.demon.co.uk Subject: Re: Variable Length Addresses Cc: big-internet@munnari.oz.au, ericf@atc.boeing.com Dear group, Recently there has been some traffic in regards to my criticism of the 64 bit "addressing field" value for SIP. Subsequent to my posting, the formation of SIPP (SIP plus PIP) working group union has been announced. The purpose of this note is two-fold: 1) I wish to say that I fully concur with From: "Beast (Donald E. Eastlake, 3rd)" who said: > PS: Personally I think that 64 bits is a great size for an end > idenitifier to be in every packet while addresses (locators?) are > something else and quite likely should be variable length. I regret that I did not originally state my position with the clarity and terseness of Don's statement. 2) I am looking forward to seeing the new SIPP specifications in full anticipation that my original criticism of the SIP flexibility and extensibility limitations have been corrected. Thus, I expect/hope that my criticism of SIP will not be true for SIPP. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.oz.au Sat Sep 11 03:59:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22854; Sat, 11 Sep 1993 04:01:10 +1000 (from owner-Big-Internet) Return-Path: Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22826; Sat, 11 Sep 1993 03:59:42 +1000 (from pgross@ans.net) Received: from interlock.ans.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA21594; Fri, 10 Sep 93 13:59:32 -0400 Received: by interlock.ans.net id AA03014 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 10 Sep 1993 13:48:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 10 Sep 1993 13:48:15 -0400 Message-Id: <199309101749.AA42676@home.ans.net> To: Noel Chiappa Cc: big-internet@munnari.oz.au Subject: Re: Nimrod funded In-Reply-To: (Your message of Thu, 09 Sep 93 19:06:18 D.) <9309092306.AA04489@ginger.lcs.mit.edu> Date: Fri, 10 Sep 93 13:49:02 -0500 From: Phill Gross Martha and BBN put together a proposal to DARPA to do a Nimrod project, and I have been informed that this proposal has been accepted... Congratulations, Noel, and BBN. This is good news. I look forward to seeing the charter for your new WG. Phill From owner-big-internet@munnari.oz.au Sat Sep 11 07:08:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29492; Sat, 11 Sep 1993 07:09:01 +1000 (from owner-big-internet) Return-Path: Received: from flash.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15001; Fri, 10 Sep 1993 22:59:12 +1000 (from dave@mail.bellcore.com) Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA00936; Fri, 10 Sep 93 08:58:50 -0400 Received: from [128.96.90.196] (mac16) by eve (4.1/4.7) id AA08167; Fri, 10 Sep 93 09:00:33 EDT Date: Fri, 10 Sep 93 09:00:32 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9309101300.AA08167@eve> To: Tony Li From: dave@mail.bellcore.com (David Piscitello) X-Sender: dave@128.96.90.55 Subject: Re: Variable length addresses Cc: big-internet@munnari.oz.au CLNP currently does not reserve the value of 255 for future use in the source and destination address length fields because the overall header is bounded by a one-octet length indicator field. This effectively bounds the maximum length of the addresses to whatever is left over when you subtract the fixed part of the header, segmentation part, and options (the overall length of which must be (255-fixedPartLength - segmentationPartLength - addressPartLength). I would imagine that if you needed very large addresses in TUBA environments, for example, version 2 of clnp would make a modification to both the header length and address length indicators. > >I see no point in having less than a full byte for the length of the >number of bytes to be routed on. If you want to be really >conservative, you say that the value 255 in the length field is >reserved for future use. > >Tony David M. Piscitello Bellcore dave@mail.bellcore.com From owner-big-internet@munnari.oz.au Sat Sep 11 11:37:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10569; Sat, 11 Sep 1993 11:37:58 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20601; Sat, 11 Sep 1993 02:29:33 +1000 (from dee@skidrow.lkg.dec.com) Received: by inet-gw-2.pa.dec.com; id AA13201; Fri, 10 Sep 93 09:29:18 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA08067 for big-internet@munnari.oz.au; Fri, 10 Sep 93 12:30:47 -0400 Message-Id: <9309101630.AA08067@skidrow.lkg.dec.com> To: whyman@mwassocs.demon.co.uk Cc: ericf@atc.boeing.com, big-internet@munnari.oz.au (Big Internet Maillist) Subject: Re: Variable Length Addresses In-Reply-To: Your message of "Thu, 09 Sep 93 15:00:09 BST." <9309091500.aa3890@mwassocs.demon.co.uk> Date: Fri, 10 Sep 93 12:30:47 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: ericf@atc.boeing.com >>From: Eric Fleischman >>Message-Id: <9309072051.AA14497@atc.boeing.com> > >>I am unconvinced by Steve Deering's arguments concerning the adequacy of >>the current SIP 64 bit addressing fields: I would like to see SIP adopt >>a variable address field length scheme for the flexibility and extensibility >>I desire. Thus, I resonate strongly with Tony Li's generic suggestion (that >>I am here applying to the SIP instance) that the SIP spec provide for a >>variable "addressing field" definition but that initial implementations use >>the 64 bit alternative as currently planned. >> >>... >>Sincerely yours, >> >>--Eric Fleischman >Eric, >While your words seem very reasonable, I would ask the question, what is >the difference between SIP supporting variable length addresses and CLNP. >The answer can be nothing other than "the bits are in a different order!" I don't accept that at all. There are quite a number of differences including the handling of options, fragmentation, alignment, etc. >Given that CLNP is the international standard and widely implemented, the >only justification for a version of SIP with variable length addresses >that there can be is not invented here. No, SIP must stand by its >64-bit address space and either win or hang because of it. Bullshit. There would be real technical differences between SIP with variable length addresses and CLNP. Even if there weren't, who would want something burdened by ISO change control? Rejecting an idea because it is "not invented here" is evil. Rejecting an implementaion, deployment, and change system because it is ISO is just recognizing the historic reality of their colossal failure. CLNP is just IPv4 with some minor improvements and some minor damage. While I can't say that SIP incorporates all that may have been learned since the old IPv4/CLNP generaltion, it does incorporate some. >Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 Donald PS: Personally I think that 64 bits is a great size for an end idenitifier to be in every packet while addresses (locators?) are something else and quite likely should be variable length. From owner-Big-Internet@munnari.oz.au Sat Sep 11 11:55:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11501; Sat, 11 Sep 1993 11:56:39 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11451; Sat, 11 Sep 1993 11:55:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17034; Fri, 10 Sep 93 21:54:45 -0400 Date: Fri, 10 Sep 93 21:54:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309110154.AA17034@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, pgross@ans.net Subject: Re: Nimrod funded Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I look forward to seeing the charter for your new WG. It went in to the AD yesterday, so hopefully soon... Noel From owner-big-internet@munnari.oz.au Sat Sep 11 13:18:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13308; Sat, 11 Sep 1993 13:18:53 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24443; Sat, 11 Sep 1993 04:50:52 +1000 (from solensky@ftp.com) Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA18130; Fri, 10 Sep 93 14:50:29 -0400 Date: Fri, 10 Sep 93 14:50:29 -0400 Message-Id: <9309101850.AA18130@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Better way to look at this? (Re: New growth charts available) From: solensky@ftp.com (Frank T Solensky) Cc: dennis@ans.net, solensky@ftp.com, Big-Internet@munnari.oz.au Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com > From jnc@ginger.lcs.mit.edu Fri Sep 10 10:37:21 1993 > To: dennis@ans.net, solensky@ftp.com > Subject: Re: Better way to look at this? (Re: New growth charts available) > Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > > it seems to me that past classed network totals are rapidly becoming > useless as an indicator of future growth (if they ever were useful). ... > > Yes. An interesting sidelight of this is that it's going to be even harder to > predict the effect of the growth of the network on the growth of routing > tables in the routers, since no router will have a "complete" routing table > any more. At least in the old days, backbone routers had to have every > network number .. so you knew the worst case pretty easily. Yeah, that going to be a problem.. I guess that the worst case would become the regional that aggregates the largest number of its nets to one CIDR announcement. > This all sounds absolutely on target to me. .. Perhaps someone (Frank?) > can try and fit some logistic curves to the "% of total space in routed > B and C numbers", and see what comes out? Just a quick ack: I'm working on it now, along with trying to come up with a historic time series for the size of the CIDR'd routing tables. The sudden appearance of the ARPA/MILNET tables throws the logistic curve fitting program out of kilter, but the three years since may be enough to work with. Thanks (again) Dennis for the additional perspective. -- Frank From owner-big-internet@munnari.oz.au Sat Sep 11 19:09:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21113; Sat, 11 Sep 1993 19:09:52 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04033; Thu, 9 Sep 1993 14:48:18 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA01190 (5.65/1.23); Thu, 9 Sep 93 00:47:53 -0400 Date: Thu, 9 Sep 93 00:47:53 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9309090447.AA01190@sadye.emba.uvm.edu> To: Big-Internet mailing list Subject: Variable-length s, Redux (I'm beginning to appreciate the value of not using the `A word'... it seems to make Noel's responses much easier to understand.) About a month ago, I responded to a message from Craig Partridge about Variable-length s. In my response I stated that variable-length s in Pip don't seem to be a problem, since Pip doesn't do mask-and-match. Craig responded that this wasn't what he was concerned about---he was more interested in the problem of memory speed and cache effects. Unfortunately, because I can be a bit dense sometimes, I let this lie and decided to argue other points. This evening as I was walking up to the office, it suddenly hit me that I had the right idea, but just didn't develop it far enough. First, I'll make Noel happy by adopting his terminology. In Pip, there is a section of the header called the ``transit part'', which consists of fields that routers will be interested in looking at. The final field in the transit part is called the FTIF chain, and it's where the sort of thing that Noel doesn't want us to call an ``address'' is stored. In the near-term Pip architecture, this field serves the length of what I think Noel calls a ``locator''. (For Pip, this is actually a funny thing that looks a bit like a source route.) However---and this is the important part---*only one element* of the FTIF chain is ever active at a time, and this element is pointed to by one of the other transit part fields. (Actually, it gives the array index in 16-bit words.) This element can be roughly considered to be fixed-length, and it serves the role of what Noel calls a ``selector'', if I remember aright. So I had the right idea all along. Because Pip is not mask-and-match, the traditional step of ``parsing the '' is actually done in a distributed fashion, so that no one router ever needs to examine the whole chain. If we then assume that addresses turn out to be like the ones listed in the Pip near-term architecture, and take Craig's 512-bit cache line size (what machine is this?), then we can fit the entire host part (32 bytes), the fixed-length part of the transit part (12 bytes), eight FTIFs (4 bytes), and the first 16 bytes of either user data or options information, all into one cache line. For smaller cache line sizes, there are bits of all of these structures that you can ignore and still not do too badly. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant ------------------------------------ Here's my interpretation of the Pip docs as far as what a transit part consists of: struct pip_transit { pip_16 pt_mbz; /* must be zero */ pip_8 pt_ptoff; /* offset of next transit part (words) */ pip_8 pt_hdcontents; /* HD set number */ pip_32 pt_hd; /* handling directive */ pip_8 pt_ftifoff; /* which ftif is active */ pip_8 pt_rccontents; /* RC set number */ pip_16 pt_rc; /* routing context */ pip_16 pt_ftifs[1]; /* a variable number of ftifs follow */ }; From owner-big-internet@munnari.oz.au Sat Sep 11 20:24:58 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23219; Sat, 11 Sep 1993 20:25:07 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17629; Sat, 11 Sep 1993 00:36:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10419; Fri, 10 Sep 93 10:35:52 -0400 Date: Fri, 10 Sep 93 10:35:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309101435.AA10419@ginger.lcs.mit.edu> To: dennis@ans.net, solensky@ftp.com Subject: Re: Better way to look at this? (Re: New growth charts available) Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu it seems to me that past classed network totals are rapidly becoming useless as an indicator of future growth (if they ever were useful). ... will have an absolutely identical result both for the organization which obtains the address space and for classless forwarding tables, but will have drastically different results when added to your total ... the end result for classless routers and for our utilization of address space is identical. Yes. An interesting sidelight of this is that it's going to be even harder to predict the effect of the growth of the network on the growth of routing tables in the routers, since no router will have a "complete" routing table any more. At least in the old days, backbone routers had to have every network number (non-backbone routers often had only defaults plus a select set of 'interesting' network numbers), so you knew the worst case pretty easily. the huge increases in the number of reachable networks over the past year is a direct consequence of the policy of reducing the allocation of class B numbers in favour of multiple class C numbers ... analysis implicitly assumes that the proportion of class A, B and C networks being added to the routing database is historically constant ... assumption is incorrect ... any predictions derived from it are going to be equally incorrect. ... if we are eliminating network classes from our routers I think we've also got to eliminate network classes from the historical data we are analizing. I think a better way to look at this is to measure the fraction of allocatable address space we are using ... trying to derive future trends from historical data which includes these class A networks is not going to [be useful] This all sounds absolutely on target to me. In fact the 12 months just ended shows a lower average monthly growth rate of class B+C space than any 12 month period since the database was established. ... any analysis which concludes from the last 12 months of data that we are going to run out of address space sooner than previously thought has got to be defective. Food for thought. Perhaps someone (Frank?) can try and fit some logistic curves to the "% of total space in routed B and C numbers", and see what comes out? I'm sure Scott Bradner and Allison Mankin's effort will find all this data most thought-provoking. The CIDR-inspired allocation policies in place for the last year seem to have made a difference for the better in terms of the rate at which we consume the address space, though at the expense of forwarding table size for classful routers. This just points out the need to get on with CIDRizing the routers. Oddly enough, the IESG has just released the CIDR documents, but the BGP-4 stuff (which is crucial to CIDR) is still not done. Noel From owner-Big-Internet@munnari.oz.au Sun Sep 12 00:00:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29168; Sun, 12 Sep 1993 00:01:04 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29115; Sun, 12 Sep 1993 00:00:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22557; Sat, 11 Sep 93 10:00:30 -0400 Date: Sat, 11 Sep 93 10:00:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309111400.AA22557@ginger.lcs.mit.edu> To: dennis@ans.net, solensky@ftp.com Subject: Re: Better way to look at this? (Re: New growth charts available) Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In fact the 12 months just ended shows a lower average monthly growth rate of class B+C space than any 12 month period since the database was established. ... The CIDR-inspired allocation policies in place for the last year seem to have made a difference for the better in terms of the rate at which we consume the address space Now that I think about it, the first follows directly from the second. When sites were allocating a single class B (to minimize the load on the routing, and give themselves some room for growth), a lot of the space they were allocating was i) unused, and ii) unlikely to ever *be used* (i.e. wasted). Now that we are allocating address space in chunks more closely related to the actual needs of sites, *of course* the growth rate has declined. It'll be interesting to see when the best fit curve predicts we run out of C, plus two more C sized spaces from A#.... It's probably a long ways off, far enough to skip to the next generation IP, Flow-IP.. How do you spell relief? C-I-D-R! Noel From owner-Big-Internet@munnari.oz.au Sun Sep 12 03:29:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04682; Sun, 12 Sep 1993 03:29:37 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04674; Sun, 12 Sep 1993 03:29:23 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29891; Sat, 11 Sep 93 10:29:09 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA19869; Sat, 11 Sep 93 10:32:10 PDT Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4) id AA23451; Sat, 11 Sep 1993 10:29:06 +0800 Date: Sat, 11 Sep 1993 10:29:06 +0800 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9309111729.AA23451@bigriver.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: pgross@ans.net, big-internet@munnari.oz.au In-Reply-To: <9309110154.AA17034@ginger.lcs.mit.edu> Subject: Re: Nimrod funded Content-Length: 68 I have it and will be getting comments back to Noel next week. Bob From owner-Big-Internet@munnari.oz.au Sun Sep 12 03:41:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05051; Sun, 12 Sep 1993 03:41:50 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05048; Sun, 12 Sep 1993 03:41:40 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA12624 (5.67a/IDA-1.5 for Big-Internet@munnari.oz.au); Sat, 11 Sep 1993 10:41:28 -0700 Date: Sat, 11 Sep 1993 10:41:28 -0700 From: Tony Li Message-Id: <199309111741.AA12624@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Big-Internet@munnari.oz.au Subject: Re: Better way to look at this? (Re: New growth charts available) ... but the BGP-4 stuff (which is crucial to CIDR) is still not done. Noel, It is effectively done. The process is waiting for an implementation report, which requires that an implementor test the features of the protocol and report on the testing that was done. Since _the_ major feature of BGP-4 is aggregation, and since we just recently got this working to our satisfaction (i.e. interoperability with another implementation), we will be able to move forward shortly. This delay in the standards track has in no way hampered anyone who wanted to implement. Oh yeah, and the editors have a little work to do too to clarify one issue.... ;-) Tony From owner-Big-Internet@munnari.oz.au Mon Sep 13 20:09:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01435; Mon, 13 Sep 1993 20:10:49 +1000 (from owner-Big-Internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01409; Mon, 13 Sep 1993 20:09:50 +1000 (from whyman@mwassocs.demon.co.uk) Date: Mon, 13 Sep 1993 11:04:56 BST Message-Id: <9309131104.aa4025@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: big-internet@munnari.oz.au (Big Internet Maillist) Subject: SIP and PIP Merger and CLNP X-Mailer: Cinetic Mail Manager V2.1 As my long term objective is to see a single worldwide standard for an internetworking protocol, I cannot but welcome the burying of the hachet between two of the contenders for that crown, for whatever reasons they may have for doing this. However, now that SIPP is one entity, its promoters should really start to think about how SIPP will relate to CLNP. While the more extreme "you ISO-man you die" tendency of the IETF may wince at even the mere thought of looking at an ISO specification, it is in the interests of future interoperability that there should be a convergence. I can't remember whether it was on a mailing list or in a personal communication, but someone recently made the point "would ISO accept a future IPng as a CLNPng", assuming that IPng was not CLNPng. Although some may not care whether ISO ratifies the IPng, there are good technical reasons for wanting to do this, apart from the political ones. The simple fact is that if SIPP is not technically better than CLNP, and perhaps more important, a submission to ISO could not be made that demonstrated its superiority to CLNP, then the work that goes into SIPP will have just been a waste of time. Worse than that, if a SIPP inferior to CLNP became the IPng simply because of blind prejudice, then the loser would be the internet community as a whole. So, I put it to the SIPP group that they should prepare, as part of the SIPP work, the technical justification as to why SIPP is superior to CLNP. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-big-internet@munnari.oz.au Tue Sep 14 02:49:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16217; Tue, 14 Sep 1993 02:49:56 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12394; Tue, 14 Sep 1993 01:08:10 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14558; Mon, 13 Sep 1993 17:07:45 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA16746; Mon, 13 Sep 1993 17:06:32 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9309131506.AA16746@dxcern.cern.ch> Subject: Re: SIP and PIP Merger and CLNP To: whyman@mwassocs.demon.co.uk Date: Mon, 13 Sep 1993 17:06:31 +0200 (MET DST) Cc: big-internet@munnari.oz.au In-Reply-To: <9309131104.aa4025@mwassocs.demon.co.uk> from "Tony Whyman" at Sep 13, 93 11:04:56 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 620 >--------- Text sent by Tony Whyman follows: ... > So, I put it to the SIPP group that they should prepare, as part of the SIPP > work, the technical justification as to why SIPP is superior to CLNP. > Therefore, the TUBA group should prepare, as part of the TUBA work, the technical justification as to why CLNP is superior to SIPP. No, this is the wrong thing to do for both groups. They should both justify how well they satisfy the promised IE(ngineering)SG criteria. We want consensus, not winners and losers. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-big-internet@munnari.oz.au Tue Sep 14 03:25:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17528; Tue, 14 Sep 1993 03:25:49 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08880; Mon, 13 Sep 1993 23:43:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01089; Mon, 13 Sep 93 09:43:17 -0400 Date: Mon, 13 Sep 93 09:43:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309131343.AA01089@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, whyman@mwassocs.demon.co.uk Subject: Re: SIP and PIP Merger and CLNP Cc: jnc@ginger.lcs.mit.edu While the more extreme "you ISO-man you die" tendency of the IETF may wince at even the mere thought of looking at an ISO specification, it is in the interests of future interoperability that there should be a convergence. ... Although some may not care whether ISO ratifies the IPng, there are good technical reasons for wanting to do this, apart from the political ones. The simple fact is that if SIPP is not technically better than CLNP, and perhaps more important, a submission to ISO could not be made that demonstrated its superiority to CLNP, then the work that goes into SIPP will have just been a waste of time. ... So, I put it to the SIPP group that they should prepare, as part of the SIPP work, the technical justification as to why SIPP is superior to CLNP. You seem to have skipped a step here that I think you should go away and think about, which is "is CLNP, or something like it, the technically optimal next step for the Internet to adopt"? Your entire line of reasoning seems to suppose, as a given, that CLNP is a technically superior (or at least plausible) alternative. I can't speak for others, but I personally find all the IPng candidates basically unappealing. They are all minor tweaks to a basic paradigm, the pure datagram model, that I don't think is the optimal model for future development. This is not the place to include the whole argument, but suffice it to say that a pure datagram model may be a good semantic match to the capabilities of yesterday's underlying transmission technologies (e.g. Ethernet), but it is (for theortical reasons that have been clear for more than a decade) a poor semantic match to the capabilities of future technologies (e.g. ATM). In light of this, I reckon that any pure datagram IPng design which has bigger or smaller "addresses", hop counts, etc, is just rearranging the buggy whip holder location on a horse carriage. (I like to make the admittedly sarcastic crack that if the IPng designers had been sent off to design TCP/IP in 1975, they'd have come back with X.25 with a larger sequence number space.) If we are forced through some grim combination of events to pick one of the IPng candidates, I will sit down and evaluate the minor technical points of each (as they change from month to month) to find the best one, but it's not a choice I want to have to make. So, before you say "why not CLNP, it's there and an international standard", I say "why CLNP, it's obsolescent"? Not everyone who doesn't like CLNP likes SIPP; the world is not divided into two political camps. Also, I have a (hopefully) useful piece of observation, which I do not mean as simply complaint, but purvey in the hope it will lead to a more productive relationshop. I'm trying not to put words in your mouth here, but one of the things many IETF people find intensely annoying is the attitude that "you should adopt this ISO standard *because* it is an ISO standard". So what, many of us say? What we are interested in is the technically best standard for the Internet, not whose gold seals some proposal bears. I'm not making a statement about whether you personally have this attitude, but I will simply note that I find interesting your statement that SIPP needs to "prepare ... the technical justification as to why SIPP is superior to CLNP." Why should not CLNP equally have to prepare a technical justification as to why it is superior to SIPP? Noel From owner-big-internet@munnari.oz.au Tue Sep 14 18:45:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22549; Tue, 14 Sep 1993 18:46:08 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09683; Tue, 14 Sep 1993 13:14:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10885; Mon, 13 Sep 93 23:14:05 -0400 Date: Mon, 13 Sep 93 23:14:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309140314.AA10885@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hcb@world.std.com Subject: Re: Routing architecture? Cc: jnc@ginger.lcs.mit.edu to distinguish between the IPng documents and the routing architecture work (i.e., Nimrod, Unified) being mentioned.... I can't find the latter! Could someone post ftp (or other pointers) to these? There's an old, long, and not well-polished I-D which describes the basic thinking and fundamental archietecture of Nimrod (now offline as an I-D), which is available from thyme.lcs.mit.edu via anonymous FTP from the file "pub/ip.routing.architecture". Noel From owner-Big-Internet@munnari.oz.au Tue Sep 14 19:38:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24514; Tue, 14 Sep 1993 19:40:00 +1000 (from owner-Big-Internet) Return-Path: Received: from sun2.nsfnet-relay.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24480; Tue, 14 Sep 1993 19:38:47 +1000 (from cziwprf@pluto.ulcc.ac.uk) Via: uk.ac.ulcc.pluto; Tue, 14 Sep 1993 10:34:55 +0100 From: Peter Furniss Message-Id: <25234.9309140934@pluto.ulcc.ac.uk> Subject: Re: SIP and PIP Merger and CLNP To: whyman@mwassocs.demon.co.uk Date: Tue, 14 Sep 93 10:34:46 BST Cc: big-internet@munnari.oz.au In-Reply-To: <9309131104.aa4025@mwassocs.demon.co.uk>; from "Tony Whyman" at Sep 13, 93 11:04 am Reply-To: P.Furniss@ulcc.ac.uk X-Mailer: ELM [version 2.3 PL11] Although it may not be helpful to consider directly why SIPP is superior to CLNP (or vice versa), it would seem appropriate that design of any IPng-candidate consider whether it can be used to support the OSI CLNS (i.e. service), since that would be the criterion on whether it was a candidate for CLNPng. Convergence is about making sure one solution solves everybodies problems. I'm not well informed on the network layer, so I'm not sure how feasible this is. I would not expect anyone to put great effort into this ! Peter Furniss From owner-big-internet@munnari.oz.au Wed Sep 15 03:59:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12003; Wed, 15 Sep 1993 03:59:53 +1000 (from owner-big-internet) Return-Path: Received: from flash.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03458; Tue, 14 Sep 1993 23:56:52 +1000 (from dave@mail.bellcore.com) Received: from eve.bellcore.com by flash.bellcore.com (5.61/1.34) id AA07067; Tue, 14 Sep 93 09:56:08 -0400 Received: from [128.96.90.196] (mac16) by eve (4.1/4.7) id AA28863; Tue, 14 Sep 93 09:57:53 EDT Date: Tue, 14 Sep 93 09:57:52 EDT X-Station-Sent-From: eve.bellcore.com Message-Id: <9309141357.AA28863@eve> To: Dennis Ferguson From: dave@mail.bellcore.com (David Piscitello) X-Sender: dave@128.96.90.55 Subject: Re: Better way to look at this? (Re: New growth charts available) Cc: Big-Internet@munnari.OZ.AU Dennis, I did not see any further mail discussing your analysis. This is unfortunate, since it may mean that your message was overlooked. Perhaps I could encourage you to send it to ietf-general? I think your analysis is far and away the most insightful and useful I've seen thus far. Some of this should be obvious, but it seems it is not; as you point out, the support of organizations through multiple class C's rather than a single B or A consumes network numbers faster, but does not imply a corresponding growth in connected networks. And your analysis of A's and the questionable nature of including these in the overall consumption rates is also on target. Thanks for the very helpful analysis. David M. Piscitello Bellcore dave@mail.bellcore.com From owner-big-internet@munnari.oz.au Wed Sep 15 04:37:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13344; Wed, 15 Sep 1993 04:38:27 +1000 (from owner-big-internet) Return-Path: Received: from nic.stpaul.ncr.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04928; Wed, 15 Sep 1993 00:26:49 +1000 (from preece@ncrcos.StPaul.NCR.COM) Received: from ncrcos.StPaul.NCR.COM by nic.StPaul.NCR.COM (4.0/NCR-STP/1.0) id AA27065; Tue, 14 Sep 93 09:26:01 CDT Received: from [131.222.24.231] (csdpc231) by ncrcos.StPaul.NCR.COM (4.1/NCR-STP/1.0) id AA02772; Tue, 14 Sep 93 09:24:49 CDT From: "Bently H. Preece" Date: Tue, 14 Sep 93 09:24:25 CDT Message-Id: <2121.preece@ncrcos_POPMail/PC_3.2.2> Reply-To: X-Popmail-Charset: English To: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP On Mon, 13 Sep 93 09:43:17 -0400, Noel Chiappa (refering to Mr. Whyman's comment) wrote: > I find interesting your statement that SIPP needs >to "prepare ... the technical justification as to why SIPP is superior to >CLNP." Why should not CLNP equally have to prepare a technical justification >as to why it is superior to SIPP? To be considered for IPng, it obviously must. However, CLNP and IP are so similar that there is no good reason why there should be two standards. If SIPP (or any other IPng) is better than CLNP for the internet world, then it's probably better for the OSI world. The wheels turn slower at ISO and their goals are different, but they do have intelligent people over there. If you can make a good case, then it should be worth the effort to herd it through the ANSI and ISO committees too. I also like some of Mr. Chiappa's other comments: > ... a pure datagram model may be a good semantic match to the >capabilities of yesterday's underlying transmission technologies (e.g. >Ethernet), but it is (for theortical reasons that have been clear for more >than a decade) a poor semantic match to the capabilities of future >technologies (e.g. ATM). -Ben P. --- Bently H. Preece NCR Network Products Division software engineer 2700 Snelling Ave. N. Bently.Preece@StPaul.NCR.COM St. Paul, MN USA 55113 From owner-big-internet@munnari.oz.au Wed Sep 15 05:35:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15157; Wed, 15 Sep 1993 05:36:09 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05449; Wed, 15 Sep 1993 00:45:21 +1000 (from dee@skidrow.lkg.dec.com) Received: by inet-gw-2.pa.dec.com; id AA03786; Tue, 14 Sep 93 07:44:49 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA08811 for big-internet@munnari.oz.au; Tue, 14 Sep 93 10:44:47 -0400 Message-Id: <9309141444.AA08811@skidrow.lkg.dec.com> To: whyman@mwassocs.demon.co.uk Cc: big-internet@munnari.oz.au (Big Internet Maillist) Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Mon, 13 Sep 93 11:04:56 BST." <9309131104.aa4025@mwassocs.demon.co.uk> Date: Tue, 14 Sep 93 10:44:47 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: big-internet@munnari.oz.au (Big Internet Maillist) >As my long term objective is to see a single worldwide standard for >an internetworking protocol, I cannot but welcome the burying of the >hachet between two of the contenders for that crown, for whatever >reasons they may have for doing this. However, now that SIPP is one >entity, its promoters should really start to think about how SIPP >will relate to CLNP. I don't see anything wrong with thinking about this but its not very important. CLNP is a tiny part of the world internetworking. It would make more sense, for example, to start thinking about how SIPP will relate to IPX. IPX is much more widely used and Novell is obviously trying to become a future IP and take over the WAN market. They have set up an IANA equivalent to register network numbers and they have hired Radia Perlman away from DEC and the only reason I can think of that they would want to do that is to come up with good WAN IPX routing. [As an aside, the only reason ISO has excellent routing protocols is that they were *not* produce via the execrable ISO political protocol devlopment process but simply adopted wholesale from DEC.] >... >I can't remember whether it was on a mailing list or in a personal >communication, but someone recently made the point "would ISO accept a future >IPng as a CLNPng", assuming that IPng was not CLNPng. Although some may not >care whether ISO ratifies the IPng, there are good technical reasons for >wanting to do this, apart from the political ones. > >The simple fact is that if SIPP is not technically better than CLNP, and I just don't see how the superior IETF process is going to come up with something for IPng that is inferior to the aged CLNP. >perhaps more important, a submission to ISO could not be made that >demonstrated its superiority to CLNP, then the work that goes into SIPP will They competition between the IPng candidates will produce lots of documents showing their superiority to IP and maybe even CLNP. But in any case CLNP is close enough to IP that they would serve that puprose. As open, freely accessible documents, you would be welcome to make a bundle of them and sent them to ISO with a cover letter. I'm not sure why the IETF would ever think it needs to justify itself or its decisions to ISO. >have just been a waste of time. Worse than that, if a SIPP inferior >to CLNP became the IPng simply because of blind prejudice, then the >loser would be the internet community as a whole. I agree with that but there's no chance of it happening so it does not seem very relavent. >So, I put it to the SIPP group that they should prepare, as part of the SIPP >work, the technical justification as to why SIPP is superior to CLNP. As I point out above, the technical justification of why SIPP or other IPng candidates are superior to IP will be 95 to 99% of what you are looking for. Maybe there will be someone who will want to do the last 1% but I certainly don't see it as worth it. The decisions of ISO are pretty irrelavent to the real world which is dominated by IETF and proprietary protocols. >Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 Donald From owner-big-internet@munnari.oz.au Wed Sep 15 05:59:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16296; Wed, 15 Sep 1993 06:00:14 +1000 (from owner-big-internet) Return-Path: Received: from relay1.pipex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07694; Wed, 15 Sep 1993 01:50:23 +1000 (from andy@spider.co.uk) Received: from pipex.net by relay1.pipex.net with SMTP (PP) id <08808-0@relay1.pipex.net>; Tue, 14 Sep 1993 16:49:23 +0100 Received: from 134.191.64.3 by relay2.pipex.net with SMTP (PP) id <17944-0@relay2.pipex.net>; Tue, 14 Sep 1993 16:49:03 +0100 Received: by widow.spider.co.uk; Tue, 14 Sep 93 16:56:13 +0100 From: Andy Davis Date: Tue, 14 Sep 93 16:44:36 +0100 Message-Id: <1246.9309141544@raft.spider.co.uk> Received: by raft.spider.co.uk; Tue, 14 Sep 93 16:44:36 +0100 To: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP Cc: jnc@ginger.lcs.mit.edu, whyman@mwassocs.demon.co.uk Noel, I think you are right to hold back from putting words in Tony Whymans mouth when you suggested that others believe "you should adopt this ISO standard *because* it is an ISO standard". I don't think that was the point of his message, and is certainly not something that I would endorse. What is important though is that we judge proposals on their technical and practical merits. Let us suppose for a moment that people don't jump into a paradigm shift this time around, and that IPng turns out to be Yet Another Datagram Protocol. Before every end user and every computer manufacturer and every internetworking vendor goes out and spend countless thousands of dollars implementing it, we will want to be sure it adds something to what we are doing. Let's see; so far, most of the people I listed above have got IPv4, IPX, DECNet, Appletalk, and of course CLNP - all datagram protocols. For completeness, before implementing and deploying SIPP as our primary internet protocol, we would want to know that:- 1. SIPP is superior in that role to IPv4. 2. SIPP is superior in that role to IPX. 3. SIPP is superior in that role to DECNet (4). 4. SIPP is superior in that role to Appletalk. 5. SIPP is superior in that role to CLNP. Now, I would hope that number 1 is true, else we can all stop now! We may be able to assume numbers 2 through 4 by inspection. But what Tony is asking is whether number 5 is true. And by the way, the improvement had better be material, not just hypothetical - we're talking a lot of development dollars here. The technical superiority of SIPP to CLNP must be demonstrated not because CLNP is an ISO standard, but because it exists in abundance. I've got CLNP; you've got CLNP; I'll bet they even interoperate. Of course, CLNP is not perfect, but as has been pointed out by Cisco and others, we've even cracked how to make it go fast! The SIPP development *could* probably improve on it, but echoing your comments on technology shifts, I could argue that ever decreasing refinements of a mature technology is not the way of the future. Andy From owner-big-internet@munnari.oz.au Wed Sep 15 06:07:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16522; Wed, 15 Sep 1993 06:07:55 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08943; Wed, 15 Sep 1993 02:30:06 +1000 (from dee@skidrow.lkg.dec.com) Received: by inet-gw-2.pa.dec.com; id AA10434; Tue, 14 Sep 93 09:29:55 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA09598 for big-internet@munnari.oz.au; Tue, 14 Sep 93 12:29:54 -0400 Message-Id: <9309141629.AA09598@skidrow.lkg.dec.com> To: P.Furniss@ulcc.ac.uk Cc: whyman@mwassocs.demon.co.uk, big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Tue, 14 Sep 93 10:34:46 BST." <25234.9309140934@pluto.ulcc.ac.uk> Date: Tue, 14 Sep 93 12:29:54 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: Peter Furniss To: whyman@mwassocs.demon.co.uk Cc: big-internet@munnari.oz.au In-Reply-To: <9309131104.aa4025@mwassocs.demon.co.uk>; from "Tony Whyman" at S ep 13, 93 11:04 am >Although it may not be helpful to consider directly why SIPP is >superior to CLNP (or vice versa), it would seem appropriate that >design of any IPng-candidate consider whether it can be used to support >the OSI CLNS (i.e. service), since that would be the criterion on >whether it was a candidate for CLNPng. Convergence is about making >sure one solution solves everybodies problems. Well, the underlying transmission fabrics and physical link protocols (Ethernet, FDDI, ATM, PPP, ...) all provide for multiple protocols these days so CLNP, IPv4, IPX, AppleTalk, etc., are all going to be supported in some sense for the forseeable future. It has been said that a lot of networks are now "Religiously multi-protocol", However, the ability to encapuslate CLNP and IPv4 in any IPng is a reasonable criteria. As long as there is some datagram from of IPng and it has some reasonable form of broadcast (oops, I guess that's only needed to support IPv4 :-), even if IPng is mostly flows or something, this should be quite easy. >I'm not well informed on the network layer, so I'm not sure >how feasible this is. I would not expect anyone to put great effort >into this ! > >Peter Furniss Donald From owner-big-internet@munnari.oz.au Wed Sep 15 06:26:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17208; Wed, 15 Sep 1993 06:26:22 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10707; Wed, 15 Sep 1993 03:18:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13656; Tue, 14 Sep 93 13:17:39 -0400 Date: Tue, 14 Sep 93 13:17:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309141717.AA13656@ginger.lcs.mit.edu> To: andy@spider.co.uk, big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP Cc: jnc@ginger.lcs.mit.edu ... you suggested that others believe "you should adopt this ISO standard *because* it is an ISO standard". I don't think that was the point of his message ... What is important though is that we judge proposals on their technical and practical merits. ... Before every end user and every computer manufacturer and every internetworking vendor goes out and spend countless thousands of dollars implementing it ... the improvement had better be material, not just hypothetical - we're talking a lot of development dollars here. The technical superiority of SIPP to CLNP must be demonstrated not because CLNP is an ISO standard, but because it exists in abundance. I keep hearing this, that CLNP has a big practical advantage, because "it is out there already". I think this advantage is much overrated, and in fact is almost non-existent. First, let's look at the hosts. Tuba is *not* off the shelf ISO *or* TCP software; a certain amount of software engineering, documentation, quality control, manufacturing engineering, etc, etc must be done before it is even available as a product. True, the software engineering may be a little less than a whole new internetwork layer, but the other aforementioned facets of making a Tuba product available will not be much affected by the fact that CLNP exists already. Then, all the hosts have to go out and get it, and install it, etc, etc, and this is a *phenomenally* massive undertaking. *There is no CLNP installed-base advantage in hosts*. Hosts make up the vast majority of the things which will be affected by an IPng decision, so I challenge the assertion that there's a significant installed-base advantage for CLNP. Now, let's look at the routers; in the noise, true, but still there. First, router vendors write new forwarding modules for different protocols, and deploy them, on a regular basis. This is something they can do without a monumental effort, so the fact that you save this for CLNP isn't that big a deal. Second, CLNP *by itself* is not all you need in routers. All routers need act as hosts a lot, or you'd have an unmaintainable network. So, all the routers have SNMP to manage them, remote login for various purposes, etc, etc etc. All this will have to be modified for Tuba as well. So much for the installed-base advantage to Tuba in routers. I won't even bother to get into the fact that CLNP has no off the shelf general policy routing available (I don't count IDRP, which doesn't support general source policies), and so CLNP router support will need to be modified for that, and, oh yeah, where's the CLNP version of DHCP, and where are the CLNP multi-cast specs and deployed code, etc, etc, etc. In short, although CLNP does have some head start over other alternatives, it simply is not nearly so great as its proponents claim. In fact, it's small enough that it could very easily be outweighed by other factors. Again, this is not to be taken as "support of SIPP"; I don't like SIPP any better or worse (modulo second order stuff) than I like CLNP. I just don't believe this 'installed-base advantage' line. Let us suppose for a moment that people don't jump into a paradigm shift this time around, and that IPng turns out to be Yet Another Datagram Protocol. Finally, of course, I totally disagree with this assumption. This whole SIPP/CLNP/etc dustup is just a pointless sideshow, as far as I'm concerned. It's utterly irrelevant who wins. Noel From owner-big-internet@munnari.oz.au Wed Sep 15 10:36:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27396; Wed, 15 Sep 1993 10:36:17 +1000 (from owner-big-internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21595; Wed, 15 Sep 1993 08:10:56 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29621; Tue, 14 Sep 93 18:02:15 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA05403; Tue, 14 Sep 93 18:12:19 EDT Date: Tue, 14 Sep 93 18:12:19 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9309142212.AA05403@cabernet.wellfleet> To: andy@spider.co.uk, big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP Cc: rcallon@wellfleet.com For completeness, before implementing and deploying SIPP as our primary internet protocol, we would want to know that:- 1. SIPP is superior in that role to IPv4. 2. SIPP is superior in that role to IPX. 3. SIPP is superior in that role to DECNet (4). 4. SIPP is superior in that role to Appletalk. 5. SIPP is superior in that role to CLNP. Now, I would hope that number 1 is true, else we can all stop now! We may be able to assume numbers 2 through 4 by inspection. But what Tony is asking is whether number 5 is true. And by the way, the improvement had better be material, not just hypothetical - we're talking a lot of development dollars here. The technical superiority of SIPP to CLNP must be demonstrated not because CLNP is an ISO standard, but because it exists in abundance. I've got CLNP; you've got CLNP; I'll bet they even interoperate. Of course, CLNP is not perfect, but as has been pointed out by Cisco and others, we've even cracked how to make it go fast! The SIPP development *could* probably improve on it, but echoing your comments on technology shifts, I could argue that ever decreasing refinements of a mature technology is not the way of the future. Generally I think that you have very good points here. I think that it would be very easy to write a document which demonstrates why SIPP is superior to CLNP, and would also be very easy to write a document which demonstrates why CLNP is superior to SIPP. Part of the problem here is that we don`t all agree on what makes a proposal superior. As has been seen in recent mailing list discussions, we don't even agree on what makes it possible to forward a protocol at high speed (although strangely the router vendors seem to be concentrated on the same side of this issue ;-). I don't think that documents by the advocates of a particular proposal which talk about their benefits will do much to shed real light on the comparison. I would much rather have documents which make it very clear in detail exactly what each proposal is, and then have folks who understand how to build and deploy systems (including routers, end systems, and overall networks) look at each proposal in painful detail and try to find the problems. It would also be nice if we could find the time and resources to deploy each proposal on a reasonably large scale. There have been times in the past where the Internet has deployed new standards which some "old fart experts" said had real scaling problems, only to find a year or two later that the proposal really did have problems. Generally this resulted in a new replacement protocol coming out later. The most obvious example of this that I can think of is the long list of routing protocols that we have used over the years (I count 16 or 17 routing protocols for IP since I started working on IP, although admittedly at least two of these are proprietary and two or three never went anywhere). We can't afford to take the same approach to a next generation IP -- we have to start off with something that will scale or we will be in trouble. Ross From owner-big-internet@munnari.oz.au Wed Sep 15 20:24:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17641; Wed, 15 Sep 1993 20:24:34 +1000 (from owner-big-internet) Return-Path: Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14495; Wed, 15 Sep 1993 18:39:01 +1000 (from A.A.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H2Z2TYYRGG8Y77CK@research.ptt.nl>; Wed, 15 Sep 1993 10:39:02 +0200 Date: Wed, 15 Sep 1993 10:39:01 +0200 From: Alex Reijnierse Subject: Re: SIP and PIP Merger and CLNP To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Message-Id: <01H2Z2TZ03OI8Y77CK@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-internet@munnari.oz.au X-Vms-To: IN%"jnc@ginger.lcs.mit.edu" X-Vms-Cc: IN%"big-internet@munnari.oz.au" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Hi, > Now, let's look at the routers; in the noise, true, but still there. First, > router vendors write new forwarding modules for different protocols, and > deploy them, on a regular basis. This is something they can do without a > monumental effort, so the fact that you save this for CLNP isn't that big a > deal. Second, CLNP *by itself* is not all you need in routers. All routers > need act as hosts a lot, or you'd have an unmaintainable network. So, all the > routers have SNMP to manage them, remote login for various purposes, etc, etc > etc. All this will have to be modified for Tuba as well. So much for the > installed-base advantage to Tuba in routers. Four comments: 1. The above statements effect all IPng's, not just TUBA. 2. What about the fact that TUBA transition can start this minute? CLNP is available in all major routers, even TUBA software is in some of them. Management of these systems can still be done with IP until TUBA management is available. This is because management is primarily a local matter and therefore does not need globally unique addresses. 3. What about the fact that with TUBA, hosts need only one (1) network layer to support both the TUBA and OSI protocol stack. Thus, one network layer (CLNP) serves the following applications: FTP and FTAM, Telnet and VT, X.400 and SMTP, etc.... 4. What about the integrated routing protocols for IPv4 and CLNP? This also eases TUBA migration and lowers network management effort. - Alex From owner-Big-Internet@munnari.oz.au Thu Sep 16 00:15:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27177; Thu, 16 Sep 1993 00:15:32 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27163; Thu, 16 Sep 1993 00:15:15 +1000 (from dee@skidrow.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA20513; Wed, 15 Sep 93 07:15:06 -0700 Received: by skidrow.lkg.dec.com (5.57/fma-100391/rcb-930105) id AA16880 for big-internet@munnari.oz.au; Wed, 15 Sep 93 10:13:42 -0400 Message-Id: <9309151413.AA16880@skidrow.lkg.dec.com> To: "Beast (Donald E. Eastlake, 3rd)" Cc: big-internet@munnari.oz.au (Big Internet Maillist) Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Tue, 14 Sep 93 10:44:47 EDT." <9309141444.AA08811@skidrow.lkg.dec.com> Date: Wed, 15 Sep 93 10:13:42 -0400 From: "Beast (Donald E. Eastlake, 3rd)" X-Mts: smtp From: "Beast (Donald E. Eastlake, 3rd)" Cc: big-internet@munnari.oz.au (Big Internet Maillist) >I don't see anything wrong with thinking about this but its not very >important. CLNP is a tiny part of the world internetworking. It would >make more sense, for example, to start thinking about how SIPP will >relate to IPX. IPX is much more widely used and Novell is obviously >trying to become a future IP and take over the WAN market. They have >set up an IANA equivalent to register network numbers and they have >hired Radia Perlman away from DEC and the only reason I can think of >that they would want to do that is to come up with good WAN IPX >routing. ... IPX even sort of has 48 bit End Identifiers and a 32 bit net/subnet number. >Donald Donald From owner-Big-Internet@munnari.oz.au Thu Sep 16 01:17:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29133; Thu, 16 Sep 1993 01:18:04 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29130; Thu, 16 Sep 1993 01:17:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21470; Wed, 15 Sep 93 11:17:41 -0400 Date: Wed, 15 Sep 93 11:17:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309151517.AA21470@ginger.lcs.mit.edu> To: dee@skidrow.lkg.dec.com Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > Novell is obviously trying to become a future IP and take over the WAN > market. They have set up an IANA equivalent to register network numbers > and they have hired Radia Perlman away from DEC and the only reason I > can think of that they would want to do that is to come up with good WAN > IPX routing. I've heard rumors about this, but I'd love to hear more. Can anyone from Novell tell us more, or is this still hush-hush? (Aieee, a plot to take over the Internet!) IPX even sort of has 48 bit End Identifiers and a 32 bit net/subnet number. You can make a good argument that the 32 bit network numbers are not enough (even with CIDR style masking) to really handle a global internet. Then again, the rumors I heard had tiny glimmers of a new address format... Noel From owner-big-internet@munnari.oz.au Thu Sep 16 02:04:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01067; Thu, 16 Sep 1993 02:04:16 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27884; Thu, 16 Sep 1993 00:34:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21207; Wed, 15 Sep 93 10:33:39 -0400 Date: Wed, 15 Sep 93 10:33:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309151433.AA21207@ginger.lcs.mit.edu> To: A.A.Reijnierse@research.ptt.nl, jnc@ginger.lcs.mit.edu Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu 1. The above statements effect all IPng's, not just TUBA. Absolutely true. 2. What about the fact that TUBA transition can start this minute? Again, true. However, recall that I was just taking issue with the claim that "CLNP has an advantage as IPng since it has a giant installed base"; that may true, but Tuba has no such installed base. 3. What about the fact that with TUBA, hosts need only one (1) network layer to support both the TUBA and OSI protocol stack. Who cares about the OSI protocol stack? It's basically dead as a doornail; some of the applications may get picked up and used by the Internet, but that's it. Besides, a host internet layer takes about three days to code, and about 4K of code; not exactly a big deal. (Also, if I were you, I'd be careful about mentioning it, lest people see backers of CLNP for IPng as simply attempting to use it as a ruse to get the ISO camel's CLNP nose into the Internet tent....) 4. What about the integrated routing protocols for IPv4 and CLNP? This also eases TUBA migration and lowers network management effort. Very minimally. Most of the management work with routers has to do with configuring them, and the configuration has to do with routing policy stuff, which is expressed in the addresses of the protocol in question. Since the address spaces of IPv4 and CLNP are not congruent, there are no savings here. Noel From owner-Big-Internet@munnari.oz.au Thu Sep 16 02:59:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03191; Thu, 16 Sep 1993 03:00:06 +1000 (from owner-Big-Internet) Return-Path: Received: from x400gate.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03180; Thu, 16 Sep 1993 02:59:44 +1000 (from dawkins@bnr.ca) X400-Received: by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Sep 1993 12:57:56 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Sep 1993 12:56:31 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 15 Sep 1993 07:56:00 -0400 Date: Wed, 15 Sep 1993 11:56:00 +0000 X400-Originator: /DD.ID=1544653/G=Spencer/I=PS/S=Dawkins/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.433:15.08.93.16.56.31] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: SIP and P... From: "Spencer (P.S.) Dawkins" Sender: "Spencer (P.S.) Dawkins" Message-Id: <"7460 Wed Sep 15 12:56:47 1993"@bnr.ca> To: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP IPX the next IP, and correspondingly a gating capability for IPng? I wouldn't DREAM of confusing what happens at Interop with what happens in real life, but Bo Pitzger of Interop said IPX was second behind IP and growing faster on InteropNet in San Francisco. I agree with Donald Eastlake's view of Radia Perlman's move to Novell. Actually, a good perspective on Radia's move: Bo said InteropNet had added protocols to the point of ab- surdity, and that this Interop was the first where a proto- col was actually DROPPED from InteropNet due to lack of interest/use. That protocol was DecNet. He also said only 5 exhibitors out of 900 were EMITTING OSI packets (presumably, someone may have been LISTENING at an analyzer vendor's booth, but they weren't listening to much), so they were looking at dropping OSI next if things don't pick up. My opinion is that this makes DEC's migration from DecNet to DecNet V/OSI just another great move in the nick of time. If I'd been Radia, I'd have gone to work on SLIPng just to get away from this madness, but that's just MY opinion. Have a nice day. Spencer From owner-big-internet@munnari.oz.au Thu Sep 16 05:20:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08829; Thu, 16 Sep 1993 05:20:32 +1000 (from owner-big-internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29310; Thu, 16 Sep 1993 01:24:23 +1000 (from whyman@mwassocs.demon.co.uk) Date: Wed, 15 Sep 1993 16:11:00 BST Message-Id: <9309151611.aa4090@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: dee@skidrow.lkg.dec.com Cc: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP X-Mailer: Cinetic Mail Manager V2.1 >From: "Beast (Donald E. Eastlake, 3rd)" >X-Mts: smtp > > The decisions of ISO are >pretty irrelavent to the real world which is dominated by IETF and >proprietary protocols. > > >Donald > This must count as one of the most naive statements that I have read recently. The "real world" is not dominated by the "IETF and proprietary protocols", it is dominated by politicians and National Administrations. We live in a world where free trade only exists because of the international infrastructure that exists to co-ordinate and regulate such markets, and which prevents (or at least tries to prevent) politicians from adopting protectionist tendancies. Protectionism may be by explicit tariffs or by national standards which operate against other country's products. Either way the impact is the same. ISO and the ITU are part of the infrastructure that helps maintain free international markets in areas such as telecommunications, and trying to undermine or destroy their role will ultimately benefit no one. If there is a problem with ISO or ITU then it should be fixed. Cynics, will at this point refer to examples such as X.25 and its national variants. But that is to ignore how painfully slow it has been to drag some Administrations away from monopoly and protectionism. X.25 was developed in the 1970's, when it was still acceptable to have many national opt out clauses. Much progress has been made in the meantime, and the OSI standards do not have these opt outs. We have progressed to the point where we have International Standardised Profiles, which can define product conformance and be the basis of certification worldwide. That is no mean achievement. Viewed from the IETF, ISO and ITU may seem slow. But the ITU is part of the United Nations. Its members are national administrations. They have all to agree on a ITU-TS recommendation before it can be published, and that is not necessarily an easy matter. But when agreement comes, it is much more difficult to erect protectionist barriers against products that implement it. ISO is less formal, with its membership being commerce, academia and goverment through national standards bodies. But the problems in getting agreement and the value in final agreement is similar. But, such standards do need to be comprehensive. Take modem standards as an example. Modems are now internationally interoperable (we've moved away from the I've got a Bell 103, he's got a V.21 situation), but there is no worldwide standard for the interconnect to the telephone company. This is where national standards come in, and guess what, you have to buy nationally adapted modems, at a small cost of course. If you really are to realise free trade, the standard has to cover everything, and that again slows down the process. And, just where is the IETF in all this. Against ISO and the ITU it's no more than a self-appointed industry lobby, and this makes its work vulnerable to protectionism. Never trust politicians, and with telecomms you have a convergence of an economically significant industry with the free flow of information. Both are traditional targets for the aspiring politician. IETF developed standards with their lack of formal standing and often missing detail are easy targets for anyone that wants to erect technology based trade barriers. IETF is good at being a publishing house for new ideas. It is less good at coming to agreement on difficult decisions, or at giving its work a standing at a level higher than the market place. ISO and ITU are not necessarily the best place to take a new idea, but do have clear decision making processes, and their work has real stature when it comes to international trade and regulation. It strikes me that there is a real opportunity for synergy here, and I really would like to see the end of uninformed comment. Now back to technical matters........ -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.oz.au Thu Sep 16 07:12:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12837; Thu, 16 Sep 1993 07:12:35 +1000 (from owner-Big-Internet) Return-Path: Received: from ppp.dbc.mtview.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12828; Thu, 16 Sep 1993 07:12:18 +1000 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA06763; Wed, 15 Sep 93 14:09:03 -0700 To: whyman@mwassocs.demon.co.uk Cc: dee@skidrow.lkg.dec.com, big-internet@munnari.oz.au Reply-To: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Wed, 15 Sep 1993 16:11:00 -0000." <9309151611.aa4090@mwassocs.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <6757.748127337.1@dbc.mtview.ca.us> Date: Wed, 15 Sep 1993 14:08:59 -0700 Message-Id: <6760.748127339@dbc.mtview.ca.us> From: Marshall Rose I regret that I am not empowered to sentence you to reality. In the interests of world peace, I won't continue this thread, other than to note that the ISO, ITU, etc., are becoming increasingly irrelevant in today's world. To argue otherwise requires one to turn a blind eye to market trends of the last decade. /mtr From owner-big-internet@munnari.oz.au Thu Sep 16 07:48:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14184; Thu, 16 Sep 1993 07:49:04 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05399; Thu, 16 Sep 1993 03:59:03 +1000 (from solensky@ftp.com) Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA02358; Wed, 15 Sep 93 13:59:11 -0400 Date: Wed, 15 Sep 93 13:59:11 -0400 Message-Id: <9309151759.AA02358@ftp.com> To: big-internet@munnari.oz.au Subject: Re: Better way to look at this? (Re: New growth charts available) From: solensky@ftp.com (Frank T Solensky) Cc: dennis@ans.net Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com As promised, I've modified the analysis of the growth curves along the lines recommended by Dennis Ferguson last week. The results are most interesting (however, since putting together a PostScript version of the graphs and making a 5:30 flight are proving themselves to be mutually exclusive options, I'll summarize and get the graphs to Robert as soon as I can, probably Monday night). 1) As Dennis pointed out, the growth of the consumed Class B and C address space is less rapid than before. The logistic curve flattens out in the early 1997 timeframe: at that point, Class B+C addresses take up just over than 11% of the total address space (or about one-third of the combined Class B and C space itself). 2) As with the other studies, I dropped the last several months to determine if this leveling off point is consistant. It is, and remains within the range of 11% to 17% as far back as October 1992 (in fact, it gradually declines through this period). 3) I've also estimated the size of the routing tables once CIDR is deployed throughout the existing routes, aggregating only consecutively numbered 'classful' addresses into a single routing announcement. While there's still a bit of hacking needed on the files (eg: there's no tests for bitmask boundary alignments, consecutively numbered entries in the file where the site's location is spelled slightly differently are counted as different networks), the number of routing table entries drop from a current 15741 to about 9559 -- a savings of almost 40 percent. 4) I then reran this program to get approximations for a historic time series and ran a logistic curve on the result. This ramps up to about 450,000 networks near the end of the decade and levels out at 42.1 million networks (Again, a reminder: the historic data is subject to the same limitations Dennis mentioned plus those used to calculate the number of CIDR'd networks described above. The resulting trend line is likely to be revised once these issues are corrected but there's no guarentee as to which way it will go). 5) When placed together, the two graphs don't reconcile to each other very well. The utilization of Class B+C space levels off quickly, but the number of connected organizations continues to grow. It seems highly unlikely that a large number of networks will get connected without taking up any of the existing address space. Caveats for 4 notwithstanding, I doubt that the eventual corrections will cause that curve to level off in a much shorter timeframe. Essentially, this suggests that there may be significantly less pressure on us to deploy some IPng than previously believed. Does this mean we can fold up the tents and forget about IPng? I'm hesitant to go as far as that at this point. When I started running the regressions on the classful net number counts a few years ago, the projected maximum stayed in the neighborhood of 4000 networks for long time and didn't reach 10000 until March '92, so I suspect that the reliability of these curves as harbingers of more than the very short-term future may be lacking. -- Frank From owner-big-internet@munnari.oz.au Thu Sep 16 15:05:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04264; Thu, 16 Sep 1993 15:05:36 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02442; Thu, 16 Sep 1993 14:16:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00546; Thu, 16 Sep 93 00:16:18 -0400 Date: Thu, 16 Sep 93 00:16:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309160416.AA00546@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ietf@cnri.reston.va.us Subject: Nimrod mailing list Cc: jnc@ginger.lcs.mit.edu A mailing list for Nimrod is being set up; this mailing list will be used by the WG when it is OK'd by the IETF. To be added, please send mail to "nimrod-wg-request@bbn.com". Nothing will happen instantly, but I hope to begin discussion on the many open issues of the Nimrod architecture in the not too distant future. Noel From owner-Big-Internet@munnari.oz.au Thu Sep 16 22:19:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20279; Thu, 16 Sep 1993 22:19:29 +1000 (from owner-Big-Internet) Received: from kirk.Bond.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20276; Thu, 16 Sep 1993 22:19:19 +1000 (from s1126@kowande.Bond.edu.au) Received: from SURF.KOWANDE.Bond.edu.au by kirk.Bond.edu.au using SMTP (5.65b) Return-Path: Received: from SAND.KOWANDE.Bond.edu.au by surf.kowande.Bond.edu.au using SMTP (5.65b) id AA16493; Thu, 16 Sep 93 22:19:20 -1000 Date: Thu, 16 Sep 1993 22:16:14 -1000 (GMT-10:00) From: Arief Kurnia Astrakusuma Sender: Arief Kurnia Astrakusuma Reply-To: Arief Kurnia Astrakusuma Subject: SUBSCRIBE To: big-internet@munnari.oz.au Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Dear the administrator, I would like to subscribe to General Discussion of Routing & Addressing. Name : Arief Kurnia Astrakusuma Email: s1126@kowande.bond.edu.au Thanks. Regards, Arief Kurnia Astrakusuma From owner-big-internet@munnari.oz.au Fri Sep 17 03:03:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00604; Fri, 17 Sep 1993 03:04:21 +1000 (from owner-big-internet) Return-Path: Received: from CNRI.Reston.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23099; Thu, 16 Sep 1993 23:42:13 +1000 (from amr@CNRI.Reston.VA.US) Received: from CNRI.Reston.VA.US by CNRI.Reston.VA.US id aa16148; 16 Sep 93 9:32 EDT To: whyman@mwassocs.demon.co.uk Cc: Bob.Hinden@eng.sun.com, dee@skidrow.lkg.dec.com, big-internet@munnari.oz.au Subject: Standardsmaking Bodies Date: Thu, 16 Sep 93 09:32:35 -0400 From: Tony Rutkowski Message-Id: <9309160932.aa16148@CNRI.Reston.VA.US> Tony, >This must count as one of the most naive statements that I have read recently. >The "real world" is not dominated by the "IETF and proprietary protocols", it >is dominated by politicians and National Administrations. We live in a world .... >ISO and the ITU are part of the infrastructure that helps maintain free >international markets in areas such as telecommunications, and trying to >undermine or destroy their role will ultimately benefit no one. If there is a >problem with ISO or ITU then it should be fixed. I am responding at the behest of Bob Hinden. I host a global standards making discussion group ; and have dealt with the issues you raise for more nearly 15 years as both an engineer and lawyer variously at the FCC, as ITU's Counsellor to the Secretary-General and Chief of Telecommunication Regulation, and now as Internet Society Vice-President and a Director in a large global telecommunications company. Your characterization of the "real world" was indeed accurate until about three years ago - when a lot of things in that world began to change dramatically. But first some basic facts. The ISO is by law a private international organization no different in its legal status that the Internet Society which serves as the organizational umbrella for the IETF. It's standards have only the force and effect given to them by the marketplace or by national enactments. Although the ITU as you not is a public international organization affiliated with the U.N., it's standards under the various international treaties do not have the force and effect of law. Indeed, all but a relative handful of the thousands of standards adopted by them are essentially unknown and ignored. The IETF standards are clearly the world's NON-PROPRIETARY open systems standards of choice. And the release of Microsoft's Windows NT based on these standards last week, as well as the committment to IETF standards by essentially everyone in the marketplace today, is what really counts, not "formal standing" - which may well be a liability. Correspondingly, the use of ITU-TSS (CCITT) and ISO standards as non- tariff trade barriers by countries and industry segments has occasionally reached legenday proportions. Over the past three years, numerous new kinds of international standards making organizations and coalitions have emerged in the telecom and info systems field. This resulted in - among other things - a continuing "standards summit" of these organizations to deal with the problems. Beginning with the initial policy panel which I chaired, a regularly updated "standardsmaking architecture" chart has been issued - which depicts the various bodies and their interactions. To make a long and complex story short, most of the substantive standards making activities in the telecom and information fields have transitioned to other kinds of bodies and activities. For example, the real ATM standards work occurs in the ATM Forum, and the ITU-TSS is only a minor player largely after the fact. Why has this happened? I suppose this is the stuff of theses and history books. It has been roundly discussed on the Standards-Forum. The consensus seems to be that standards making bodies in this field can be grouped into two types - "old model" groups that follow processes that were suitable for a very slow moving, uncompetitive, hardware-oriented, environment; and "new model" groups that have emerged and exhibit the converse characteristics. It's not clear what the "old model" groups can do anymore, and it seems unlikely that they can or will be adequately reformed. They have already been substantially replaced by new "infrastructure." I personally think this is very healthy, and better reflects the dynamic, competitive, robust environment in which we now work. --tony From owner-big-internet@munnari.oz.au Fri Sep 17 03:34:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01605; Fri, 17 Sep 1993 03:34:56 +1000 (from owner-big-internet) Return-Path: Received: from volitans.MorningStar.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24325; Fri, 17 Sep 1993 00:02:20 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.dsf4.merit.edu by volitans.MorningStar.Com (5.65a/93052901) id AA03180; Thu, 16 Sep 93 10:01:54 -0400 Date: Wed, 15 Sep 93 17:57:16 EDT From: "William Allen Simpson" Message-Id: <1360.bill.simpson@um.cc.umich.edu> To: "Spencer (P.S.) Dawkins" Cc: big-internet@munnari.oz.au Reply-To: bsimpson@MorningStar.Com Subject: Re: SIP and PIP Merger and CLNP > If I'd been Radia, I'd have gone to work on SLIPng just to > get away from this madness, but that's just MY opinion. > We already have SLIPng done, it's called "PPP". Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Fri Sep 17 04:03:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02499; Fri, 17 Sep 1993 04:03:57 +1000 (from owner-big-internet) Return-Path: Received: from x400gate.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28727; Fri, 17 Sep 1993 02:06:57 +1000 (from dawkins@bnr.ca) X400-Received: by mta x400gate.bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 16 Sep 1993 12:05:37 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 16 Sep 1993 12:05:22 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Thu, 16 Sep 1993 07:05:00 -0400 Date: Thu, 16 Sep 1993 11:05:00 +0000 X400-Originator: /DD.ID=1544653/G=Spencer/I=PS/S=Dawkins/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.260:16.08.93.16.05.22] X400-Content-Type: P2-1984 (2) Content-Identifier: re: SIP and P... From: "Spencer (P.S.) Dawkins" Sender: "Spencer (P.S.) Dawkins" Message-Id: <"16264 Thu Sep 16 12:05:25 1993"@bnr.ca> To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au Subject: re: SIP and PIP Merger and CLNP No, PPP is a real protocol. It can't possibly be SLIPng! Actually, I was thinking more about someone with a PhD working on a one-byte protocol like SLIP as the depths of hell, ie, I was kidding without smileys. Sorry for the ambiguous reference, and we now return you to yer regularly scheduled mailing list. Spencer From owner-big-internet@munnari.oz.au Fri Sep 17 12:29:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21536; Fri, 17 Sep 1993 12:29:42 +1000 (from owner-big-internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00393; Fri, 17 Sep 1993 02:55:24 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 16 Sep 1993 09:55:19 -0700 Date: Thu, 16 Sep 1993 09:55:19 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199309161655.AA15474@zephyr.isi.edu> To: big-internet@munnari.oz.au, solensky@ftp.com Subject: Re: Better way to look at this? (Re: New growth charts available) *> *> Essentially, this suggests that there may be significantly less pressure *> on us to deploy some IPng than previously believed. *> *> Does this mean we can fold up the tents and forget about IPng? I'm *> hesitant to go as far as that at this point. When I started running *> the regressions on the classful net number counts a few years ago, *> the projected maximum stayed in the neighborhood of 4000 networks for *> long time and didn't reach 10000 until March '92, so I suspect that *> the reliability of these curves as harbingers of more than the very *> short-term future may be lacking. *> -- Frank *> *> *> Hi, Frank. I would like to make a couple of points. 1. I have an hypothesis that the Internet growth process is made up of a number of distinct user populations, each with its own S-shaped growth curve. That is, each begins at some time, grows exponentially, and then saturates. I would guess that the university/research population is well into saturation, while the enterprise population is still a few years from the crossover point. People have suggested a dozen different plausible new (and huge) populations that could hit us, maintaining overall exponential growth for a long time. 2. Strictly technical stock market analysis, which does not take into account investor psychology, can lose big. We have an analogous problem. If the world perceives that we are moving/have moved quickly to exapnd the address space, the new populations I mentioned above may well hit us. If not, no major new populations will arrive, and we will soon (within a few years) enter the saturation regime. So, there is a lot of feedback between the conclusion of the study you are making, and the conclusion of the study you are making... If one's goal is maximum growth of the Internet (and if you are in business, that is a likely goal!), then this seems to favor an early IETF decision on IPng. Soon would be much more important than "right". Having said all this, I should add that I think it is only part of the story. A challenge at least as large as expanding the address space is accomodating multimedia by installing integrated service in the Internet. Another critical challenge is to provide sufficient security; without that, major new growth cannot occur. I think we need to spend as much effort improving the service provided by the Internet infrastructure, as we are spending on solving the scaling problems for the current services. That means that we need to get it "right", and we need to consider all aspects, not just scaling of the address space. Bob Braden From owner-big-internet@munnari.oz.au Fri Sep 17 15:42:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29731; Fri, 17 Sep 1993 15:44:08 +1000 (from owner-big-internet) Return-Path: Received: from shiva2.cac.washington.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23500; Fri, 17 Sep 1993 13:24:13 +1000 (from gray@cac.washington.edu) Received: by shiva2.cac.washington.edu (5.65/UW-NDC Revision: 2.28 ) id AA02080; Thu, 16 Sep 93 20:23:59 -0700 Date: Thu, 16 Sep 1993 20:14:41 -0700 (PDT) From: Terry Gray Subject: Re: Better way to look at this? (Re: New growth charts available) To: solensky@ftp.com, big-internet@munnari.oz.au In-Reply-To: <199309161655.AA15474@zephyr.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just want to add my complete agreement with Bob's comments, especially the importance of psychological factors such as the *perception* of address scarcity. I believe that this particular issue has already begun to distort decision-making in many organizations. Hence, my own belief that swift action is needed. (But of course we need a good, forward-looking solution as well as a quick one... ) -teg On Thu, 16 Sep 1993, Bob Braden wrote: > Hi, Frank. I would like to make a couple of points... From owner-big-internet@munnari.oz.au Sat Sep 18 04:46:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28867; Sat, 18 Sep 1993 04:46:33 +1000 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23642; Sat, 18 Sep 1993 02:40:41 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA23202; Fri, 17 Sep 93 12:41:01 -0400 Date: Fri, 17 Sep 93 12:41:01 -0400 Message-Id: <9309171641.AA23202@worldlink.worldlink.com> From: David Piscitello To: braden@ISI.EDU (Bob Braden) Cc: big-internet@munnari.oz.au Subject: Re: Better way to look at this? (Re: New growth charts available) If one's goal is maximum growth of the Internet (and if you are in business, that is a likely goal!), then this seems to favor an early IETF decision on IPng. Soon would be much more important than "right". If a company I had invested in had made such a statement, I'd short the stock. I believe that "right" is important here, and the fact that the sky is not falling is good news. Having said all this, I should add that I think it is only part of the story. A challenge at least as large as expanding the address space is accomodating multimedia by installing integrated service in the Internet. Another critical challenge is to provide sufficient security; without that, major new growth cannot occur. I think we need to spend as much effort improving the service provided by the Internet infrastructure, as we are spending on solving the scaling problems for the current services. That means that we need to get it "right", and we need to consider all aspects, not just scaling of the address space. (sigh of relief...) I feel better now:-) From owner-Big-Internet@munnari.oz.au Sat Sep 18 05:05:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29498; Sat, 18 Sep 1993 05:05:50 +1000 (from owner-Big-Internet) Return-Path: Received: from nic.stpaul.ncr.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29495; Sat, 18 Sep 1993 05:05:39 +1000 (from preece@ncrcos.StPaul.NCR.COM) Received: from ncrcos.StPaul.NCR.COM by nic.StPaul.NCR.COM (4.0/NCR-STP/1.0) id AA03317; Fri, 17 Sep 93 14:05:28 CDT Received: from [131.222.24.231] (csdpc231) by ncrcos.StPaul.NCR.COM (4.1/NCR-STP/1.0) id AA09138; Fri, 17 Sep 93 14:04:42 CDT From: "Bently H. Preece" Date: Fri, 17 Sep 93 14:03:54 CDT Message-Id: <234.preece@ncrcos_POPMail/PC_3.2.2> Reply-To: X-Popmail-Charset: English To: big-internet@munnari.oz.au Subject: OSI vs. TCP/IP oh-no! (was Re: SIP and PIP Merger and CLNP) I regret that I am not empowered to sentence you to reality. In the interests of world peace, I won't continue this thread, other than to note that the ISO, ITU, etc., are becoming increasingly irrelevant in today's world. To argue otherwise requires one to turn a blind eye to market trends of the last decade. What are the data showing these market trends? (Something like dollars spent on OSI vs. dollars spent on TCP/IP over the last decade, or ?) Does this affect whether CLNP is appropriate for IPng? What is the installed base of CLNP now? Anybody know? --- Bently H. Preece NCR Network Products Division software engineer 2700 Snelling Ave. N. Bently.Preece@StPaul.NCR.COM St. Paul, MN USA 55113 From owner-big-internet@munnari.oz.au Sat Sep 18 06:52:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03183; Sat, 18 Sep 1993 06:53:17 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26854; Sat, 18 Sep 1993 03:52:51 +1000 (from swb1@cornell.edu) Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA25467 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Fri, 17 Sep 1993 13:46:03 -0400 Message-Id: <199309171746.AA25467@postoffice.mail.cornell.edu> X-Sender: swb1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Sep 1993 13:45:55 -0400 To: braden@isi.edu (Bob Braden), big-internet@munnari.oz.au From: Scott W Brim Subject: Re: Better way to look at this? (Re: New growth charts available) Bob, therefore would you say that if we decide we have more time than we thought, that we will have even more time than the more time we thought we had? That sounds very good to me. Let's do it. I fundamentally don't think our goal should be maximum growth of the Internet, unless we are oriented toward using its growth as a means to make money. Our goal should be establishing a foundation for long-term usefulness to the world. The growth will take care of itself sooner or later. Scott > If the world perceives that we are moving/have moved > quickly to exapnd the address space, the new populations I mentioned > above may well hit us. If not, no major new populations will > arrive, and we will soon (within a few years) enter the saturation > regime. From owner-Big-Internet@munnari.oz.au Sat Sep 18 07:15:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03860; Sat, 18 Sep 1993 07:15:40 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03856; Sat, 18 Sep 1993 07:15:31 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26959; Fri, 17 Sep 93 14:15:23 -0700 Message-Id: <9309172115.AA26959@Mordor.Stanford.EDU> To: David Piscitello Cc: braden@ISI.EDU (Bob Braden), big-internet@munnari.oz.au Subject: Re: Better way to look at this? (Re: New growth charts available) Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 17 Sep 93 12:41:01 -0400. <9309171641.AA23202@worldlink.worldlink.com> Date: Fri, 17 Sep 93 14:15:22 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: If one's goal is maximum growth of the Internet (and if you are in business, that is a likely goal!), then this seems to favor an early IETF decision on IPng. A challenge at least as large as expanding the address space is accomodating multimedia by installing integrated service in the Internet. Another critical challenge is to provide sufficient security Dave, I think you've opened an important door in this forum. It gets discussed, periodically, in smaller fora (or fauna?) but I believe that it's discussion more generally, recently, has been limited to the IPng debate. It might be useful to consider it separately. What are they key limiting factors to the next major wave of Internet development? You've listed address space (clearly the routing problem is part of this) security multi-media And we've heard often of the need for mobile hosts I'd be interested in whether there are topics that are essential and are being missed. (We also need to be fairly precise in determining the KINDS of security we need, as well as the specifics meant by "multi-media". Similarly, I'm not sure we have a community consensus about the TYPES of mobility that we deem essential. Generally, we, the IETF, don't have a plan. We just have people show up with enthusiasm and good ideas. That's pretty accidental, though and may well be missing important stuff. Dave From owner-big-internet@munnari.oz.au Sat Sep 18 13:23:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15894; Sat, 18 Sep 1993 13:23:23 +1000 (from owner-big-internet) Return-Path: Received: from SunSite.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13901; Sat, 18 Sep 1993 12:22:43 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper (tipper.oit.unc.edu) by SunSITE.unc.edu (SMI4.1/FvK 1.02) id AA07724; Fri, 17 Sep 93 22:22:33 EDT Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA23585; Fri, 17 Sep 93 22:22:32 EDT Message-Id: <9309180222.AA23585@tipper> X-Really-To: sunsite.unc.edu To: Dave Crocker Cc: David Piscitello , braden@isi.edu (Bob Braden), big-internet@munnari.oz.au Subject: Re: Better way to look at this? (Re: New growth charts available) In-Reply-To: Your message of "Fri, 17 Sep 93 14:15:22 PDT." <9309172115.AA26959@Mordor.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Sep 93 22:22:32 -0400 From: Simon E Spero If wer're dealing with the Internet DS9, as opposed to just IPNG, then here's my shopping list. 1) No practical restriction number of attached hosts, or the topology of the hosts. 2) Directory service for white and yellow pages functions (e.g. whois++) 3) Reserved channels with guranteed bandwidth 4) Host/Entity mobility with undue penalty relative to static hosts. 5) resource replication (really part of 2) From owner-Big-Internet@munnari.oz.au Mon Sep 20 17:00:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19737; Mon, 20 Sep 1993 17:00:25 +1000 (from owner-Big-Internet) Return-Path: Received: from PANDANUS.NTU.EDU.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19732; Mon, 20 Sep 1993 17:00:14 +1000 (from coleman@PANDANUS.NTU.EDU.AU) Received: from [138.80.130.104] (COLEMAN.NTU.EDU.AU) by pandanus.cs.ntu.edu.au with SMTP id AA09181 (5.65c/IDA-1.4.4 for ); Mon, 20 Sep 1993 16:28:26 +0930 Message-Id: <199309200658.AA09181@pandanus.cs.ntu.edu.au> Date: Mon, 20 Sep 1993 16:31:27 +0930 To: big-internet@munnari.oz.au From: coleman@pandanus.ntu.edu.au (James P H Coleman) Subject: help From owner-Big-Internet@munnari.oz.au Mon Sep 20 17:17:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20403; Mon, 20 Sep 1993 17:18:21 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20384; Mon, 20 Sep 1993 17:17:49 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA19935 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Mon, 20 Sep 1993 00:17:12 -0700 Date: Mon, 20 Sep 1993 00:17:12 -0700 From: Tony Li Message-Id: <199309200717.AA19935@lager.cisco.com> To: big-internet@munnari.oz.au Cc: 0005066432@mcimail.com ("Tansin A. Darcos & Company"), dkatz@cisco.com, karl@empirical.com, feit@tigger.jvnc.net Subject: Long IP addresses (relocated here from IETF) From: Paul Robinson Is there a discussion being done on this somewhere? Yes, there is an ongoing discussion of all of the IPng variants and design parameters. We normally hold such discussions on big-internet. You're welcome to join in. I think that you'll find that there are a large number of people who feel that 64 bits is enough. Many others want 160. However, I think that the discussion is more vehemently about fixed length vs. variable length. Another thing to think about is router caching. Caching an 8-byte address and perhaps a route to it of another 4 bytes, is easier, faster and uses less memory than caching a 20-byte address that might have a 10-byte routing. Memory is inexpensive, but it's not free. Using a very long address would require that fewer addresses could be cached, meaning that as there are more transactions, fewer of them can be cached in the router for fast retransmission. Using a long address is irrelevant (surprise!). What does matter is if you can form aggregates or not. If you can aggregate, then both the routing table and the cache shrink dramatically. For example, the entire CLNP routing table here at cisco has four entries in it. You're now arguing about the difference between 20*4 = 80 bytes or 8*4 = 32 bytes. Not surprisingly, aggregation of routing information is a very high requirement for IPng. From: karl@mel-brooks.tgv.com Reply-To: karl@empirical.com Just curious -- has anyone done a comparision of how long it takes to do a OSI/CLNP route lookup versus an IP route lookup when using classless IP routing? Hmph. Well, I can tell you how long it takes to do route lookups today, but I don't think that it carries forward nicely. In the brave new world of CIDR, the cost of an route lookup may go down (for some implemenations). Today, on the stuff that we have in the lab, the cost of an IP or CLNP route lookup is in the wash... That is to say that the difference is effectively zero. Tony From owner-Big-Internet@munnari.oz.au Mon Sep 20 20:44:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27105; Mon, 20 Sep 1993 20:44:32 +1000 (from owner-Big-Internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27102; Mon, 20 Sep 1993 20:44:21 +1000 (from 0003858921@mcimail.com) Received: by MCIGATEWAY.MCIMail.com id aa08657; 20 Sep 93 10:35 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac08417; 20 Sep 93 10:23 GMT Date: Mon, 20 Sep 93 10:26 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Big Internet Maillist Subject: Re: SIP and PIP Merger and CLNP Message-Id: <52930920102625/0003858921NA3EM@mcimail.com> Donald said: >I don't see anything wrong with thinking about this but its not very >important. CLNP is a tiny part of the world internetworking. It would >make more sense, for example, to start thinking about how SIPP will >relate to IPX. IPX is much more widely used and Novell is obviously >trying to become a future IP and take over the WAN market. They have >set up an IANA equivalent to register network numbers and they have >hired Radia Perlman away from DEC and the only reason I can think of >that they would want to do that is to come up with good WAN IPX >routing. [As an aside, the only reason ISO has excellent routing >protocols is that they were *not* produce via the execrable ISO >political protocol devlopment process but simply adopted wholesale >from DEC.] Novell already has their 'new' routing protocol for Netware 4.0 and it is based on IS-IS. They claim that it is better than IS-IS and that OSPF is already 'showing its warts'. But if a new routing technology comes out of IETF, Novell is better than ever equiped to support it too. After all, we are finally playing with Netware IP... Bob From owner-Big-Internet@munnari.oz.au Mon Sep 20 21:14:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27896; Mon, 20 Sep 1993 21:14:18 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27892; Mon, 20 Sep 1993 21:14:09 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08349; Mon, 20 Sep 93 07:14:05 EDT Date: Mon, 20 Sep 93 07:14:05 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9309201114.AA08349@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: dependable accounting and billing One of the things that people appear to either be overlooking or handwaving on is the problem of _dependably_ figuring out who to charge for a particular packet. This is NOT easy to do in the absence of strong (e.g. cryptographic digital signatures) authentication where that authentication can be used on packets in transit. This "in-transit" requirement basically rules out most of the security protocol work being discussed in IP-SEC since they are designed to operate only on an end-to-end basis (no in-transit checks). One would need to have a digital signature in each packet in order to authenticate the packet at intermediate points. Each intermediate point would need to be able to perform the authentication. Because those intermediate nodes would most probably not be under the same administration, the "shared" secret of any symmetric digital signature would have to be shared very widely indeed (both ends plus every site in the middle) -- probably so widely as to not provide any meaningful assurance that the packet is authentic. Note that I've completely ignored the non-trivial effort required to do key management in such a scheme. If one uses an asymmetric digital signature on a packet by packet basis so that one can have both in-transit authentication and reasonable assurance, one is likely to have serious performance problems. It turns out that most (all ?) asymmetric digital signature techniques in the published literature are computationally expensive. Folks who think that ATM is going to make this easier haven't studied the problem enough or looked at the ATM signalling protocols. The ATM signalling protocols have the same need for digital signatures to provide dependable accounting. Those protocols do not currently support digital signatures. The Telco folks are talking about charge by the bit (actually 53 byte cells) and just have a hardware counter on their gateway device that counts cells which go by either to or from you. One of the real joys about this is that you will get to pay for junk traffic and also for traffic from would-be intruders. Most of the "traffic policing" work in the ATM area has completely ignored the issues of dependable policing and assurance that one's mechanisms are doing what one thinks they are doing. They are relying on customers not understanding that they aren't using dependable billing/accounting mechanisms. Anyone who thinks that _I_ am going to just blindly trust that I am being billed correctly for traffic doesn't know me very well. Other folks and (perhaps more importantly) large corporations are also likely to question their bills. I don't see any straight forward way to dependably implement traffic-sensitive pricing on a less granular basis than the current method (pay based on bandwidth of the connection to the service provider) without incurring significant additional cost due to the dependable accounting/billing mechanisms. In the current scheme, we get assurance because the connection hardware limits the size of the bit pipe and the hardware requires a human to change it (probably two humans, one on each end). This makes verification of the bit pipe size straight forward. I do understand the appeal to economists and some others of this traffic sensitive pricing. After all, economists make their living analysing theoretical price/demand models and traffic sensitive pricing is an interesting economic problem. However, I really don't think that those advocating this approach have sufficiently considered the technical obstacles to dependable accounting/billing mechanisms. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Mon Sep 20 23:36:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02666; Mon, 20 Sep 1993 23:36:45 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02661; Mon, 20 Sep 1993 23:36:28 +1000 (from kasten@ftp.com) Received: by ftp.com id AA07703; Mon, 20 Sep 93 09:36:23 -0400 Date: Mon, 20 Sep 93 09:36:23 -0400 Message-Id: <9309201336.AA07703@ftp.com> To: swb1@cornell.edu Subject: Re: Better way to look at this? (Re: New growth charts available) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: braden@isi.edu (Bob Braden), big-internet@munnari.oz.au > had? That sounds very good to me. Let's do it. I fundamentally don't > think our goal should be maximum growth of the Internet, unless we are > oriented toward using its growth as a means to make money. Our goal should > be establishing a foundation for long-term usefulness to the world. The > growth will take care of itself sooner or later. > Scott, your statement is correct on the surface of it -- there is no need for growth (or growability) simply for growth's sake. However, one of the things that makes the Internet useful is the fact that I can interact with a lot of different people, computers, resources, etc. So, I would claim that growability is a necessary condition for long-term usefulness. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Tue Sep 21 01:36:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07136; Tue, 21 Sep 1993 01:37:02 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06277; Tue, 21 Sep 1993 01:13:55 +1000 (from swb1@cornell.edu) Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA26527 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 20 Sep 1993 11:11:52 -0400 Message-Id: <199309201511.AA26527@postoffice.mail.cornell.edu> X-Sender: swb1@postoffice.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 20 Sep 1993 11:11:36 -0400 To: kasten@ftp.com From: Scott W Brim Subject: Re: Better way to look at this? (Re: New growth charts available) Cc: big-internet@munnari.oz.au At 9:36 AM 9/20/93 -0400, Frank Kastenholz wrote: >So, I would claim that growability is a necessary condition for >long-term usefulness. Oh, absolutely. Bob pointed out that to maximize near-term growth of the Internet we would need to decide on IPng as soon as possible, and I was coming out against maximizing near-term growth as a goal, because that would lead us into the trap many corporations have fallen into, valuing next quarter's bottom line more than the health of the corporation in five years. I believe (with Noel) that none of the options that are ready for analysis and critical evaluation at this time are good enough for the long term usefulness of the Internet, and that it would weaken the Internet to make such a decision now. Let me embellish that a bit. There will be an Internet, and the users will find ways to get work done, no matter what the set of offered features is (cf. "mail-enabled" applications, "video fax", ...). What we (IETF) decide or don't decide isn't going to change that. Also, the Internet will be huge, no matter what -- we don't need to generate growth, nor do we need to make room for growth! Even if the Internet were carved up into a lot of separate address spaces, the users and the vendors would find a way to make it work to their satisfaction. Even if we did nothing for IPng, people would find a way to make room for growth. The most important goal is not to make the Internet big, or even to make a big Internet possible, but rather to make possible an environment of extreme flexibility to support future, completely unimaginable needs. In the process we want to make bigness easy, but we shouldn't lose perspective. Do you remember that Feynman quote? I can dig it up again if you like. Scott From owner-Big-Internet@munnari.oz.au Tue Sep 21 02:22:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08545; Tue, 21 Sep 1993 02:22:56 +1000 (from owner-Big-Internet) Return-Path: Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08541; Tue, 21 Sep 1993 02:22:26 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22926; Mon, 20 Sep 93 12:13:55 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA06470; Mon, 20 Sep 93 12:24:23 EDT Date: Mon, 20 Sep 93 12:24:23 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9309201624.AA06470@cabernet.wellfleet> To: Bently.Preece@StPaul.NCR.COM, big-internet@munnari.oz.au Subject: Re: OSI vs. TCP/IP oh-no! (was Re: SIP and PIP Merger and CLNP) Cc: rcallon@wellfleet.com What are the data showing these market trends? (Something like dollars spent on OSI vs. dollars spent on TCP/IP over the last decade, or ?) Does this affect whether CLNP is appropriate for IPng? What is the installed base of CLNP now? Anybody know? --- Bently; Well, I am not going to say how large the installed base of CLNP is (I don't actually know). However, I do have a few observations: - The demand for any particular Internet layer protocol is largely based on what applications are running over it and what host systems make use of it. Thus we should not use installed base as an implicit measure of technical quality. - It is generally **MUCH** easier on router vendors and network providers if the routing protocols / internet protocols work well and are easy to deploy and debug. Thus you will find engineers from routing vendors argueing for protocols which they feel are technically sound and will be deployable and debuggable. Thus technical quality is *very* important to folks from the routing vendors. When you see folks from routing vendors getting excited about the IPng debate, it is probably based on this one issue. - I have noticed a recent increase in the requests from customers for CLNP (and ES-IS, IS-IS) support. I do not know what has caused this, or how significant it is. In any case, I don't consider the installed base of CLNP to be a significant issue. We (and all other router vendors) will implement whatever IPng is chosen by the IETF. If I decide to prefer TUBA/CLNP, or any other IPng candidate, then this would be based on technical quality, manageability, and scalability, not on installed base. Ross From owner-Big-Internet@munnari.oz.au Tue Sep 21 04:12:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11760; Tue, 21 Sep 1993 04:12:29 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11757; Tue, 21 Sep 1993 04:12:21 +1000 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2237; Mon, 20 Sep 93 14:11:58 EDT Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 1231; Mon, 20 Sep 1993 14:11:58 -0400 Date: Mon, 20 Sep 93 14:05:16 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: dependable accounting and billing To: Ran Atkinson , big-Internet@munnari.oz.au In-Reply-To: <9309201114.AA08349@itd.nrl.navy.mil> Message-Id: <930920.140516.EDT.VALDIS@vtvm1.cc.vt.edu> On Mon, 20 Sep 93 07:14:05 EDT you said: > One of the things that people appear to either be overlooking >or handwaving on is the problem of _dependably_ figuring out who to >charge for a particular packet. This is NOT easy to do in the absence >of strong (e.g. cryptographic digital signatures) authentication where >that authentication can be used on packets in transit. This >"in-transit" requirement basically rules out most of the security >protocol work being discussed in IP-SEC since they are designed to >operate only on an end-to-end basis (no in-transit checks). Hmm.. is this Yet Another Reason to be glad that most vendors seem to botch the implementation of source routed packets? (I am told that the fact that most vendors don't properly build the reverse path is the only reason that most alledged "fixes" for Yellow Pages snarfing program add any security at alll)... I can see it now - industrial espionage by making your competitor pay your long-haul packet charges.. (Only half a smiley here - I know that Of Course all the IPng vendors will have as completely bug-free code as the current products on the market).. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-big-internet@munnari.oz.au Tue Sep 21 04:43:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12891; Tue, 21 Sep 1993 04:44:41 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08768; Tue, 21 Sep 1993 02:28:25 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ccb6.merit.edu by vela.acs.oakland.edu with SMTP id AA01744 (5.65c+/IDA-1.4.4); Mon, 20 Sep 1993 12:27:58 -0400 Date: Mon, 20 Sep 93 11:57:15 EDT From: "William Allen Simpson" Message-Id: <1396.bill.simpson@um.cc.umich.edu> To: big-Internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: dependable accounting and billing > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > I do understand the appeal to economists and some others of > this traffic sensitive pricing. After all, economists make their > living analysing theoretical price/demand models and traffic sensitive > pricing is an interesting economic problem. However, I really don't > think that those advocating this approach have sufficiently considered > the technical obstacles to dependable accounting/billing mechanisms. > Yes, this is precisely the point I was trying to make on the ietf list, where M-M proposed a per-packet economic rationale, without counting the bandwidth cost of the certification and billing. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Tue Sep 21 05:03:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13497; Tue, 21 Sep 1993 05:03:40 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09143; Tue, 21 Sep 1993 02:42:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03465; Mon, 20 Sep 93 12:40:54 -0400 Date: Mon, 20 Sep 93 12:40:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309201640.AA03465@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tli@cisco.com Subject: Re: Long IP addresses (relocated here from IETF) Cc: 0005066432@mcimail.com, dkatz@cisco.com, feit@tigger.jvnc.net, jnc@ginger.lcs.mit.edu, karl@empirical.com Subject: Long IP addresses (relocated here from IETF) I think that you'll find that there are a large number of people who feel that 64 bits is enough. Many others want 160. Assuming you are speaking of "locators" here (I don't know of many people who think we need host-identifiers longer than 64 bits), may I remind you that the world is not divided solely into those who like 64 bits (SIP?) and 160 bits (CLNP)? Some us like longer, variable length, locators... However, I think that the discussion is more vehemently about fixed length vs. variable length. How true.... Given how thoroughly we have beaten the topic to death here, though, is there really anything to be gained by doing so one more time? Noel From owner-big-internet@munnari.oz.au Tue Sep 21 09:20:01 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22091; Tue, 21 Sep 1993 09:20:15 +1000 (from owner-big-internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11675; Tue, 21 Sep 1993 04:05:43 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) id AA05191; Mon, 20 Sep 93 11:05:27 PDT Message-Id: <9309201805.AA05191@cincsac.arc.nasa.gov> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: Big Internet Maillist Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Mon, 20 Sep 93 10:26:00 GMT." <52930920102625/0003858921NA3EM@mcimail.com> Date: Mon, 20 Sep 93 11:05:27 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Novell already has their 'new' routing protocol for Netware 4.0 and it is based on IS-IS. They claim that it is better than IS-IS and that OSPF is already 'showing its warts'. But if a new routing technology comes ou t of IETF, Novell is better than ever equiped to support it too. After all , we are finally playing with Netware IP... Bob One point about OSPF. It's the only standard IP LS routing protocol with ANY real operational experience. All the problems found thus far have been implementation problems, which I believe you'll find with almost any routing protocol as complex. People may make claims all they want, but OSPF is used as the core of several networks with very complicated routing systems (NSI and BARRNET come to mind immediately). Before people flame about IS-IS being used in the NSFNet backbone, I believe that that isn't the standard IS-IS as defined for passing IP, and is "customized" in many ways. Talk is cheap. The real world has a tendency to use routing differently than the designers intended. Actually, I consider OSPF a tremendous sucess in this aspect. Thanks, Milo From owner-Big-Internet@munnari.oz.au Tue Sep 21 12:04:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28038; Tue, 21 Sep 1993 12:04:44 +1000 (from owner-Big-Internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28018; Tue, 21 Sep 1993 12:04:04 +1000 (from 0003858921@mcimail.com) Received: by MCIGATEWAY.MCIMail.com id ac16906; 21 Sep 93 1:49 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af16751; 21 Sep 93 1:44 GMT Date: Tue, 21 Sep 93 01:49 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: "Milo S. Medin" Cc: Big Internet Maillist Subject: Re: SIP and PIP Merger and CLNP Message-Id: <60930921014906/0003858921NA1EM@mcimail.com> >People may make claims all they want, but OSPF is used as the core of >several networks with very complicated routing systems (NSI and BARRNET >come to mind immediately). If you check with Wellfleet and Tymplex you will find that Chrysler has a VERY large OSPF network. I believe we are now at 6 admin areas and soon more. We have interop (most of the time :) between Wellfleet, Tymplex, and our old Proteons. I was told by the Meta group that we are the only such site that has done so. So I know from what my colleagues that maintain our routed network have gone through that OSPF is real. I have not heard of any similiarly large IS-IS network, let alone a Novell network of this size. Bob Moskowitz Chrysler Corp From owner-big-internet@munnari.oz.au Tue Sep 21 13:24:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01202; Tue, 21 Sep 1993 13:26:04 +1000 (from owner-big-internet) Return-Path: Message-Id: <9309210326.1202@munnari.oz.au> Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26526; Tue, 21 Sep 1993 11:23:23 +1000 (from hgs@research.att.com) Received: by research.att.com; Mon Sep 20 21:23 EDT 1993 Date: Mon, 20 Sep 93 21:22:44 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: big-internet@munnari.oz.au Subject: The more things change... "The size of address fields is a question of continuing controversy. An 8-bit network number supports up to 256 nets; that is fine for now, but eventually it should be made larger. ... We have avoided variable-length address fields in the Pup design because they increase the per-packet processing costs." IEEE Trans. on Comm., Vol. 28 (4), April 1980. From owner-big-internet@munnari.oz.au Tue Sep 21 17:03:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08915; Tue, 21 Sep 1993 17:03:23 +1000 (from owner-big-internet) Return-Path: Received: from dreggs.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02933; Tue, 21 Sep 1993 14:12:35 +1000 (from pfortin@cisco.com) Received: from dallas-dynamic.cisco.com by dreggs.cisco.com with TCP; Mon, 20 Sep 93 21:11:56 -0700 Date: Mon, 20 Sep 93 21:11:56 -0700 Message-Id: <9309210411.AA28817@dreggs.cisco.com> X-Sender: pfortin@dreggs.cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Robert G. Moskowitz" <0003858921@mcimail.com>, "Milo S. Medin" From: pfortin@cisco.com (Pierre Fortin) Subject: Re: SIP and PIP Merger and CLNP Cc: Big Internet Maillist At 1:49 9/21/93 +0000, Robert G. Moskowitz wrote: >>People may make claims all they want, but OSPF is used as the core of >>several networks with very complicated routing systems (NSI and BARRNET >>come to mind immediately). > >If you check with Wellfleet and Tymplex you will find that Chrysler has a >VERY large OSPF network. I believe we are now at 6 admin areas and soon ^^^^^^^^^^^^^^^^^^^^^^^ Just HOW big is this net? I keep hearing "rumors" about large OSPF nets, but I just can't seem to find them... Please, this is not a shot; I just would like to get an idea where these big nets are, along with their size. >more. We have interop (most of the time :) between Wellfleet, Tymplex, and >our old Proteons. I was told by the Meta group that we are the only such >site that has done so. > >So I know from what my colleagues that maintain our routed network have gone >through that OSPF is real. I have not heard of any similiarly large IS-IS >network, let alone a Novell network of this size. ^^^^^^^^^ There it is again.... :^) :^) >Bob Moskowitz >Chrysler Corp TIA, Pierre -- Pierre Fortin Office: 1.214.770.5565 direct: 770.5554 Fax: 770.5559 ciscoSystems Inc., 15851 N. Dallas Pkwy, Suite 1055, Dallas, TX 75248 From owner-big-internet@munnari.oz.au Tue Sep 21 18:04:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11106; Tue, 21 Sep 1993 18:04:26 +1000 (from owner-big-internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04105; Tue, 21 Sep 1993 14:45:37 +1000 (from medin@nsipo.nasa.gov) Received: Mon, 20 Sep 93 21:45:28 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9309210445.AA10058@dscs.arc.nasa.gov> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: Big Internet Maillist Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: Your message of "Tue, 21 Sep 93 01:49:00 GMT." <60930921014906/0003858921NA1EM@mcimail.com> Date: Mon, 20 Sep 93 21:45:28 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Bob, I didn't mean to imply that there wern't any other larger users of OSPF than NSI and BARRNET. I know of a large private net in England as well, and several corporate networks. The academic nets tend to carry larger link state databases than the private nets, even though they have fewer routers, because of the amount of external routes they carry. But LSP processing has to occur whether it's an external or router links LSP... My point is that I'm not aware of others running any operational IS-IS or Novell LS based network of similar size or complexity. You usually end up finding poor decisions in implementation strategy when you have several thousand LSP's floating around. People are finding those in OSPF because people are actually using it in nets of reasonable size, unlike the other LS based protocols... Thanks, Milo From owner-big-internet@munnari.oz.au Wed Sep 22 02:46:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29494; Wed, 22 Sep 1993 02:46:45 +1000 (from owner-big-internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19318; Tue, 21 Sep 1993 22:16:55 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai02949; 21 Sep 93 12:07 GMT Date: Tue, 21 Sep 93 12:09 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Pierre Fortin Cc: Big Internet Maillist Subject: Re: SIP and PIP Merger and CLNP Message-Id: <05930921120950/0003858921NA4EM@mcimail.com> >Just HOW big is this net? I keep hearing "rumors" about large OSPF nets, >but I just can't seem to find them... Please, this is not a shot; I just >would like to get an idea where these big nets are, along with their size. I understand that we have around 160 Tymplexs, 30 Wellfleets, and 40 (old) Proteons. The Tymplexs (mostly at the Tech Center) average 6 used interfaces each. The Wellfleets (corp and plants) are LNs, typically full, probably averaging 10 interfaces (plants less, corp more). The Proteons are old and typically have 4 interfaces. This is in one big 'happy' network. We are looking hard at doing our own autonomous nets. I for one would like to see an internal BGP backbone; others feel that RIP would do it for the backbone. Then watch out for the Chrysler Finance net being installed now and over the next 6 months of over 100 branches on a Frame Relay (from MCI) net coming into 4 T1s at Chrysler Corp. We originally planed the CFC net with point to point links which would have meant over 100 interfaces at corp to handle it; 3 Wellfleets BCNs with no designable backup. Good thing that the Frame Relay became a real option before pilot! And if our Dealer support decide to do TCP/IP over our satellite to our 6,000 dealers... But this one is hotly debated and has major detractors. Bob From owner-big-internet@munnari.oz.au Thu Sep 23 09:46:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10832; Thu, 23 Sep 1993 09:46:25 +1000 (from owner-big-internet) Return-Path: Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05986; Thu, 23 Sep 1993 07:57:30 +1000 (from dkatz@cisco.com) Received: by large.cisco.com id AA01973 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 22 Sep 1993 14:57:01 -0700 Date: Wed, 22 Sep 1993 14:57:01 -0700 From: Dave Katz Message-Id: <199309222157.AA01973@large.cisco.com> To: medin@nsipo.nasa.gov Cc: 0003858921@mcimail.com, big-internet@munnari.oz.au In-Reply-To: "Milo S. Medin" (NASA ARC NSI Office)'s message of Mon, 20 Sep 93 21:45:28 -0700 <9309210445.AA10058@dscs.arc.nasa.gov> Subject: SIP and PIP Merger and CLNP I personally know of several networks running IS-IS with several hundred routers and thousands of end systems, and these networks are continuing to grow. Date: Mon, 20 Sep 93 21:45:28 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Bob, I didn't mean to imply that there wern't any other larger users of OSPF than NSI and BARRNET. I know of a large private net in England as well, and several corporate networks. The academic nets tend to carry larger link state databases than the private nets, even though they have fewer routers, because of the amount of external routes they carry. But LSP processing has to occur whether it's an external or router links LSP... My point is that I'm not aware of others running any operational IS-IS or Novell LS based network of similar size or complexity. You usually end up finding poor decisions in implementation strategy when you have several thousand LSP's floating around. People are finding those in OSPF because people are actually using it in nets of reasonable size, unlike the other LS based protocols... Thanks, Milo From owner-Big-Internet@munnari.oz.au Thu Sep 23 15:38:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24278; Thu, 23 Sep 1993 15:38:42 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24275; Thu, 23 Sep 1993 15:38:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27289; Thu, 23 Sep 93 01:38:24 -0400 Date: Thu, 23 Sep 93 01:38:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309230538.AA27289@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ietf@cnri.restob.va.us Subject: Nimrod list about to start debating.. Cc: jnc@ginger.lcs.mit.edu I notice the Nimrod mailing list is missing a lot of names I would have thought would have been interested. Starting early next week, we are going to list all open architectural and design issues with Nimrod, and then immediately start going over them one at a time. Once this process is completed, I will be loathe to go back over anything without good reason, and "I just joined" won't count. So, fair warning: if you want to put in your two cents, get on the list now, by sending mail to "nimrod-wg-request@bbn.com". Noel PS: I have requested that the old (admittedly dense and turgid) Nimrod I-D be placed back online, for those who want something to read about Nimrod. From owner-big-internet@munnari.oz.au Thu Sep 23 22:28:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08618; Thu, 23 Sep 1993 22:29:06 +1000 (from owner-big-internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07641; Thu, 23 Sep 1993 21:57:37 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai22276; 23 Sep 93 11:44 GMT Date: Thu, 23 Sep 93 11:48 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Dave Katz To: medin Cc: big internet Subject: Re: SIP and PIP Merger and CLNP Message-Id: <53930923114835/0003858921NA4EM@mcimail.com> >I personally know of several networks running IS-IS with several >hundred routers and thousands of end systems, and these networks are >continuing to grow. Are they running one admin area or a few. There was a comment here a while ago about the overhead of the Dykstra calculations of multiple admin areas with IS-IS that was claimed that OSPF does not suffer from. Given some wierd things that I have seen on our network that I attribute to the Dykstra calcs, this is an interesting point... Bob From owner-big-internet@munnari.oz.au Thu Sep 23 23:39:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11473; Thu, 23 Sep 1993 23:40:07 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10669; Thu, 23 Sep 1993 23:13:49 +1000 (from dino@cisco.com) Received: by regal.cisco.com id AA25540 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Thu, 23 Sep 1993 06:13:32 -0700 Date: Thu, 23 Sep 1993 06:13:32 -0700 From: Dino Farinacci Message-Id: <199309231313.AA25540@regal.cisco.com> To: 0003858921@mcimail.com Cc: dkatz@cisco.com, medin@nsipo.nasa.gov, big-internet@munnari.oz.au In-Reply-To: "Robert G. Moskowitz"'s message of Thu, 23 Sep 93 11:48 GMT <53930923114835/0003858921NA4EM@mcimail.com> Subject: SIP and PIP Merger and CLNP >> Are they running one admin area or a few. There was a comment here a while >> ago about the overhead of the Dykstra calculations of multiple admin areas >> with IS-IS that was claimed that OSPF does not suffer from. Given some >> wierd things that I have seen on our network that I attribute to the Dykstra >> calcs, this is an interesting point... At a given point there was 160 nodes of the shortest path tree. Dino From owner-big-internet@munnari.oz.au Fri Sep 24 04:31:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21287; Fri, 24 Sep 1993 04:31:29 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14645; Fri, 24 Sep 1993 01:06:37 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA06015 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 23 Sep 1993 11:00:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 23 Sep 1993 11:00:14 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 23 Sep 1993 11:00:14 -0400 From: Dennis Ferguson Message-Id: <199309231504.AA66127@foo.ans.net> To: Dave Katz Cc: medin@nsipo.nasa.gov, 0003858921@mcimail.com, big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: (Your message of Wed, 22 Sep 93 21:57:01 GMT.) <199309222157.AA01973@large.cisco.com> Date: Thu, 23 Sep 93 11:04:26 -0500 Dave, > I personally know of several networks running IS-IS with several > hundred routers and thousands of end systems, and these networks are > continuing to grow. But the more interesting question is, how many external routes were they carrying? OSPF and IS-IS are not particularly dissimilar with respect to internal routing, so I would not expect there to be a great deal of difference between the two with respect to internal network size. Their major design difference stems from how they handle external routes (separate LSAs for externals versus 256 "buckets" into which external routes are distributed), so it is in the handling of large numbers of external routes that I would expect interesting differences to occur. Just from a comparison of the protocols I would suspect that OSPF scales better with respect to external routing. If you assume that protocol traffic is dominated by tracking changing external routes rather than normal, periodic database refreshes, a condition which the current Internet probably meets, then maintaining N external routes will cost OSPF O(N*logN) while it costs IS-IS closer to O(N*N) when N >> 256. Of course none of this says much about real world performance. While OSPF is a bit more complex than IS-IS (suggesting that real world OSPF implementations have a greater probability of being incorrect), IS-IS allows a much wider variety of ways to achieve the same results, some of which are much less advantageous than others (suggesting that there is a greater probability of getting IS-IS implementations which are correct but stupid?). The major differences, and the toughest routing problems we have, are all in the handling of external routes, so I think comparing networks which carry a lot of externals make for the most interesting data points when comparing real-world OSPF versus IS-IS. If you want an opinion which is (I think) only biased by having read both protocol documents, I think the two protocols are substantially similar but where they diverge I almost always like what OSPF did better. I think OSPF's only major flaw is the use of IP address information as link state advertisement ID's. While this is fine for IP it makes the protocol far less adaptable for other purposes, particularly those where the addresses won't fit in 4 bytes. There are (obviously) an increasing number of network layer protocols which could make good use of OSPF's technology (SIP, and even CLNP, come to mind, not to mention internal routing on a variety of lower-layer carrier networks), but the cost of adapting the protocol is unfortunately high. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Fri Sep 24 04:42:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21672; Fri, 24 Sep 1993 04:42:22 +1000 (from owner-Big-Internet) Return-Path: Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21669; Fri, 24 Sep 1993 04:42:15 +1000 (from dkatz@cisco.com) Received: by large.cisco.com id AA03017 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Thu, 23 Sep 1993 11:42:01 -0700 Date: Thu, 23 Sep 1993 11:42:01 -0700 From: Dave Katz Message-Id: <199309231842.AA03017@large.cisco.com> To: 0003858921@mcimail.com Cc: medin@nsipo.nasa.gov, big-internet@munnari.oz.au In-Reply-To: "Robert G. Moskowitz"'s message of Thu, 23 Sep 93 11:48 GMT <53930923114835/0003858921NA4EM@mcimail.com> Subject: SIP and PIP Merger and CLNP Multiple areas. Dykstra calculations in IS-IS are isolated by area boundaries. I believe that IS-IS and OSPF work the same way in this aspect. Date: Thu, 23 Sep 93 11:48 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> >I personally know of several networks running IS-IS with several >hundred routers and thousands of end systems, and these networks are >continuing to grow. Are they running one admin area or a few. There was a comment here a while ago about the overhead of the Dykstra calculations of multiple admin areas with IS-IS that was claimed that OSPF does not suffer from. Given some wierd things that I have seen on our network that I attribute to the Dykstra calcs, this is an interesting point... Bob From owner-Big-Internet@munnari.oz.au Fri Sep 24 07:34:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27404; Fri, 24 Sep 1993 07:34:34 +1000 (from owner-Big-Internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27394; Fri, 24 Sep 1993 07:34:16 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13427; Thu, 23 Sep 93 17:25:22 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA08236; Thu, 23 Sep 93 17:36:04 EDT Date: Thu, 23 Sep 93 17:36:04 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9309232136.AA08236@cabernet.wellfleet> To: dennis@ans.net Subject: Re: OSPF and IS-IS (was SIP and PIP Merger and CLNP) Cc: big-internet@munnari.oz.au Dennis; ...The major differences, and the toughest routing problems we have, are all in the handling of external routes... This depends upon what you mean by "we". This is certainly true in the Internet, but is mostly *NOT* true in commercial networks (some of which are *much* larger than any Internet backbones or regionals, but have very few externals). Thus your statement is true for someone who is primarily concerned with keeping Internet backbones going, but is not true for router vendors, who need to be concerned with BOTH Internet customers and commercial customers (understanding of course that some customers are a combination of both). If you want an opinion which is (I think) only biased by having read both protocol documents, I think the two protocols are substantially similar but where they diverge I almost always like what OSPF did better. I know that we have discussed this privately in detail, and for what you want to do OSPF has advantages in more flexibly dealing with externals and with a larger dynamic range of link metrics. However, there are some other offsetting advantages the other way, and the implementors that I have talked to are not necessarily of the same opinion. I wish that we could get over the "my protocol is better than your protocol" discussions, and rather concentrate on technical details where it would be a good idea to update one protocol or the other in order to make improvements. Clearly both protocols have benefitted from public discussions and from valuable input from many folks (in both cases including multiple implementations prior to standardization). But the more interesting question is, how many external routes were they carrying? OSPF and IS-IS are not particularly dissimilar with respect to internal routing, so I would not expect there to be a great deal of difference between the two with respect to internal network size. Their major design difference stems from how they handle external routes (separate LSAs for externals versus 256 "buckets" into which external routes are distributed), so it is in the handling of large numbers of external routes that I would expect interesting differences to occur. Hmmm. There is an interesting point here. IS-IS was of course originally designed for CLNP and NSAPs, which have sort of Super-CIDR built in from the start (since it was always intended to scale to a network in every home). Thus the number of external advertisements can be expected to be relatively small. Current address assignments for CLNP in the Internet have been done in keeping with NSAP Guidelines and thus the external tables are in fact *very* small. IP of course started out with flat routing to networks, which requires much larger numbers of externals, which fits into the OSPF design more naturally. I think that what you are complaining about is that with IS-IS when a single external advertisement changes, the entire LSP has to be reissued (containing many externals). However, with OSPF when a single external advertisement changes, only that one external is re-issued (since each LSU contains many LSAs, and each LSA is individually sequenced). This makes OSPF more efficient when one external link changes, but IS-IS more efficient when there is a periodic update of the entire External database in a network with many redundant links (since redundant LSPs are easier to discard quickly). However, as CIDR becomes more widespread, when one individual network somewhere becomes detacted, fewer places in the Internet will find out (since in most cases it would be part of a CIDR aggregation, and the overall aggregation will still need to be advertised. This implies that as CIDR becomes more widespread, each individual network becoming disconnected from their provider will require information to be propagated to a smaller amount of the entire Internet, and the periodic refresh will become a relatively larger percentage of the overall Internet external advertisements. Ross From owner-big-internet@munnari.oz.au Fri Sep 24 10:28:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03789; Fri, 24 Sep 1993 10:29:08 +1000 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25157; Fri, 24 Sep 1993 06:30:07 +1000 (from schoff@psi.com) Received: from mac2.troy.psi.com by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA04797; Thu, 23 Sep 93 16:30:47 -0400 X-Mailer: InterCon TCP/Connect II 1.1 Message-Id: <9309231636.AA58363@schoff230.reston.psi.com> Date: Thu, 23 Sep 1993 16:36:58 +0000 From: "Martin L. Schoffstall" To: atkinson@itd.nrl.navy.mil (Ran Atkinson), big-Internet@munnari.oz.au Subject: Re: dependable accounting and billing Everytime I hear this accounting spiel I think of Mother Bell's estimates back before "Direct Dial" where every other highschool graduate was going to be an Operator to put through phone calls in the US of A. Somehow the solution (lots of black and red cables with some value added eye-hand coordination) was sidestepped. What is the problem that accounting per packet is going to solve? Is there another (non-accounting-per-packet) solution to (whatever) the problem (is)? Marty ---------- > Date: Mon, 20 Sep 93 07:14:05 EDT > From: atkinson@itd.nrl.navy.mil (Ran Atkinson) > Message-Id: <9309201114.AA08349@itd.nrl.navy.mil> > To: big-Internet@munnari.oz.au > Subject: dependable accounting and billing > > > One of the things that people appear to either be overlooking > or handwaving on is the problem of _dependably_ figuring out who to > charge for a particular packet. This is NOT easy to do in the absence > of strong (e.g. cryptographic digital signatures) authentication where > that authentication can be used on packets in transit. This > "in-transit" requirement basically rules out most of the security > protocol work being discussed in IP-SEC since they are designed to > operate only on an end-to-end basis (no in-transit checks). > > One would need to have a digital signature in each packet in > order to authenticate the packet at intermediate points. Each > intermediate point would need to be able to perform the > authentication. Because those intermediate nodes would most probably > not be under the same administration, the "shared" secret of any > symmetric digital signature would have to be shared very widely indeed ( > both ends plus every site in the middle) -- probably so widely as to > not provide any meaningful assurance that the packet is authentic. Note > that I've completely ignored the non-trivial effort required to do key > management in such a scheme. > > If one uses an asymmetric digital signature on a packet by > packet basis so that one can have both in-transit authentication and > reasonable assurance, one is likely to have serious performance > problems. It turns out that most (all ?) asymmetric digital signature > techniques in the published literature are computationally expensive. > > Folks who think that ATM is going to make this easier haven't > studied the problem enough or looked at the ATM signalling protocols. > The ATM signalling protocols have the same need for digital signatures > to provide dependable accounting. Those protocols do not currently > support digital signatures. The Telco folks are talking about charge > by the bit (actually 53 byte cells) and just have a hardware counter on > their gateway device that counts cells which go by either to or from > you. One of the real joys about this is that you will get to pay for > junk traffic and also for traffic from would-be intruders. Most of > the "traffic policing" work in the ATM area has completely ignored the > issues of dependable policing and assurance that one's mechanisms are > doing what one thinks they are doing. They are relying on > customers not understanding that they aren't using dependable > billing/accounting mechanisms. > > Anyone who thinks that _I_ am going to just blindly trust that > I am being billed correctly for traffic doesn't know me very well. > Other folks and (perhaps more importantly) large corporations are also > likely to question their bills. I don't see any straight forward way > to dependably implement traffic-sensitive pricing on a less granular > basis than the current method (pay based on bandwidth of the > connection to the service provider) without incurring significant > additional cost due to the dependable accounting/billing mechanisms. In > the current scheme, we get assurance because the connection > hardware limits the size of the bit pipe and the hardware requires a > human to change it (probably two humans, one on each end). This makes > verification of the bit pipe size straight forward. > > I do understand the appeal to economists and some others of > this traffic sensitive pricing. After all, economists make their > living analysing theoretical price/demand models and traffic sensitive > pricing is an interesting economic problem. However, I really don't > think that those advocating this approach have sufficiently considered > the technical obstacles to dependable accounting/billing mechanisms. > > Ran > atkinson@itd.nrl.navy.mil > From owner-big-internet@munnari.oz.au Fri Sep 24 10:55:42 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05067; Fri, 24 Sep 1993 10:55:54 +1000 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28131; Fri, 24 Sep 1993 07:57:32 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA08429 (5.65c/IDA-1.4.4nsd for ); Thu, 23 Sep 1993 14:57:22 -0700 Received: by jaspar.NSD.3Com.COM id AA17210 (5.65c/IDA-1.4.4-910730); Thu, 23 Sep 1993 14:57:19 -0700 Date: Thu, 23 Sep 1993 14:57:19 -0700 From: "Cyndi M. Jung" Message-Id: <199309232157.AA17210@jaspar.NSD.3Com.COM> To: dennis@ans.net Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, dhg@NSD.3Com.COM, dino@cisco.com >If you want an opinion which is (I think) only biased by having read >both protocol documents, I think the two protocols are substantially >similar but where they diverge I almost always like what OSPF did >better. I know two people who have implemented both and prefer IS-IS - but maybe they are just telling me that to please me. One of them is Dino Farinacci from cisco, and the other is Der-Hwa Gan at 3Com. I think IS-IS handles multiple areas in a better way than OSPF - OSPF requires that all non-backbone areas be "connected" to the backbone area (0.0.0.0), either directly (a router attached to the backbone area on one interface, the non-backbone router on another interface), or indirectly through statically configured Virtual Links. This constrains the topology as far as area boundaries, and the choice of area boundaries should be made based on other reasons (I believe), such as the likelihood of mobility amoung a set of machines, link failure (put the leper colony in it's own area so as not to pollute the higher quality links), administrative control, and possibly a numbering scheme that promotes summarization of routing information. Another major difference between the protocols is how they synchronize the database. The method OSPF uses is wicked - it is no wonder that the Proteon implementation always limited new adjacencies to 2, it is an intense operation bringing up a new adjacency. But once the adjacencies are up, the periodic flooding cannot be limited to a few adjacencies at a time, and the DR has a big effort if it has many adjacencies at that time. IS-IS uses the CSNP and PSNP to detect any discrepencies in the database, and is much more graceful about synchronizing - sometimes a protocol can try so hard to be fast that it actually becomes slower, which is what OSPF is doing with the synchronization. What makes OSPF a better protocol than IS-IS is that there is an active community of people interested in it's success, and the feedback process that includes design, development, deployment, problem discovery ("gee, I never expected anyone to try to do that with it"), enhancement design, development, deployment, etc. is alive and healthy - despite what they say in the trade rag articles. The hype, vitriole, and chest-beating has subsided, but the protocol is getting a reasonable amount of field experience. IS-IS is getting field experience, but not on the networks run by people that are vocal on the Internet mailing lists, so it doesn't benefit from a "community". There is much work that can be done, such as operating more effectively on different types of links e.g. it runs the point-to-point subset on X.25, where the work that Radia Perlman did to define it's operation over SMDS could well be applied to X.25. I'll have to look at what you've measured for the cost of handling an External - if it is an OSI External, the cost is difficult to measure since it can be a very short prefix for a very large number of routes, or a long prefix for only a few routes. If it is the cost of handling the IP Externals, perhaps improvements can be made - after all, change control for that specification rests with the IETF. Cyndi Jung From owner-big-internet@munnari.oz.au Fri Sep 24 11:47:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06945; Fri, 24 Sep 1993 11:47:44 +1000 (from owner-big-internet) Return-Path: Received: from world.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04368; Fri, 24 Sep 1993 10:40:51 +1000 (from ariel@world.std.com) Received: by world.std.com (5.65c/Spike-2.0) id AA04755; Thu, 23 Sep 1993 20:39:44 -0400 Date: Thu, 23 Sep 1993 20:39:44 -0400 From: ariel@world.std.com (Robert L Ullmann) Message-Id: <199309240039.AA04755@world.std.com> To: big-internet@munnari.oz.au Hi, I've been incommunicado for a while, moving from Process Software to Lotus Development Corporation. New telephone: +1 617 693 1315 Home (same as before): +1 617 247 7959 Email: ariel@world.std.com Just to forstall the obvious question: yes, I have a Lotus.COM address; I am using forwarding to arrange different things while testing some software. Just use the world.std.com address and rely on it getting forwarded correctly, ok? :-) I have been busily incorporating many comments into IPv7, please forgive me if I have not directly responded; I will presently. A new draft for Internet version 7 (aka TP/IX and RAP) should be out in a few weeks, and I look forward to seeing you in Houston. Best Regards, Robert From owner-big-internet@munnari.oz.au Fri Sep 24 16:23:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16998; Fri, 24 Sep 1993 16:24:09 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07692; Fri, 24 Sep 1993 12:08:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06573; Thu, 23 Sep 93 22:08:06 -0400 Date: Thu, 23 Sep 93 22:08:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309240208.AA06573@ginger.lcs.mit.edu> To: cmj@nsd.3com.com, dennis@ans.net Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, dhg@nsd.3com.com, dino@cisco.com, jnc@ginger.lcs.mit.edu I think IS-IS handles multiple areas in a better way than OSPF - OSPF requires that all non-backbone areas be "connected" to the backbone area (0.0.0.0), either directly (a router attached to the backbone area on one interface, the non-backbone router on another interface), or indirectly through statically configured Virtual Links. This comment has me confused, because I thought that in IS-IS, all level 2 routers had to be directly connected (i.e each level 2 router must share a physical link with another); i.e. no virtual links a la OSPF. From RFC-1195: IS-IS requires that the set of level 2 routers be connected. Should the level 2 backbone become partitioned, there is no provision for use of level 1 links to repair a level 2 partition. So, in IS-IS, if you have an area which is not connected to the backbone, how can the router which connects that level 1 area to whichever other one it is connected to (which is a level 2 router, no?) be anything other than disconnected from the other level 2 routers? If it were connected, that area would be directly connected to the backbone, yes? Noel From owner-big-internet@munnari.oz.au Fri Sep 24 16:41:46 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17711; Fri, 24 Sep 1993 16:42:08 +1000 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08573; Fri, 24 Sep 1993 12:34:40 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA01005 (5.65c/IDA-1.4.4nsd for ); Thu, 23 Sep 1993 19:33:18 -0700 Received: by jaspar.NSD.3Com.COM id AA17831 (5.65c/IDA-1.4.4-910730); Thu, 23 Sep 1993 19:33:15 -0700 Date: Thu, 23 Sep 1993 19:33:15 -0700 From: "Cyndi M. Jung" Message-Id: <199309240233.AA17831@jaspar.NSD.3Com.COM> To: jnc@ginger.lcs.mit.edu Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, dhg@nsd.3com.com, dino@cisco.com Noel, I think your source of confusion is that unfortunately the word "backbone" is used in both protocols, but means completely different things in each. In OSPF, it refers to an area with the special area ID of 0.0.0.0, with the property that every other area is "connected" to it, either directly or via the statically configured Virtual Links. In IS-IS, the "connected Level 2 backbone" means that between any two Level 2 routers in the domain there is a path on which all routers support Level 2. This is key to flooding the Level 2 LSPs - all Level 2 routers in the domain have the complete set of Level 2 information, which are the Area Addresses of the domain and the prefixes of destination reachable outside the domain. The topologies supported by this are much more general than those supported by OSPF - there is no need to connect an area back to the "backbone area", but there must be a "connected Level 2 backbone". Cyndi --------------------------------------------------------------------------- > I think IS-IS handles multiple areas in a better way than OSPF - OSPF > requires that all non-backbone areas be "connected" to the backbone > area (0.0.0.0), either directly (a router attached to the backbone area > on one interface, the non-backbone router on another interface), or > indirectly through statically configured Virtual Links. >This comment has me confused, because I thought that in IS-IS, all level 2 >routers had to be directly connected (i.e each level 2 router must share a >physical link with another); i.e. no virtual links a la OSPF. From RFC-1195: > IS-IS requires that the set of level 2 routers be connected. Should > the level 2 backbone become partitioned, there is no provision for > use of level 1 links to repair a level 2 partition. >So, in IS-IS, if you have an area which is not connected to the backbone, how >can the router which connects that level 1 area to whichever other one it is >connected to (which is a level 2 router, no?) be anything other than >disconnected from the other level 2 routers? If it were connected, that area >would be directly connected to the backbone, yes? From owner-big-internet@munnari.oz.au Fri Sep 24 17:14:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18931; Fri, 24 Sep 1993 17:14:13 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10754; Fri, 24 Sep 1993 13:32:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06931; Thu, 23 Sep 93 23:31:10 -0400 Date: Thu, 23 Sep 93 23:31:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309240331.AA06931@ginger.lcs.mit.edu> To: cmj@nsd.3com.com, jnc@ginger.lcs.mit.edu Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, jmoy@proteon.com I think your source of confusion is that unfortunately the word "backbone" is used in both protocols, but means completely different things in each. In OSPF, it refers to an area with the special area ID of 0.0.0.0, with the property that every other area is "connected" to it, either directly or via the statically configured Virtual Links. In IS-IS, the "connected Level 2 backbone" means that between any two Level 2 routers in the domain there is a path on which all routers support Level 2. When I discussed this with John many moons ago, asking why he had this area 0 thing, instead of a separate backbone level like IS-IS, he said that it was functionally more or less the same thing as IS-IS level 2, except that since it looked more or less like the other OSPF areas, you didn't need a whole separate set of mechanisms to flood its LSP's, etc. So, if you think of the OSFP backbone area as being OSPF's version of the lS-IS level 2 backbone, I think you find that they are more or less the same, except that the OSPF backbone does not have the connectivity requirements of IS-IS. From RFC-1247, section 3.1: It is possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links. Virtual links can be configured between any two backbone routers that have an interface to a common non-backbone area. In other words, it's possible to have an OSPF area which is not connected to a physically contiguous set of OSPF backbone routers, but rather is only connected to another OSPF area, and uses a virtual link through that second area to get to the rest of the OSPF areas. The topologies supported by this are much more general than those supported by OSPF - there is no need to connect an area back to the "backbone area", but there must be a "connected Level 2 backbone". But doesn't each IS-IS area have to be connected to the connected level 2 backbone? From RFC-1195: However, level 1 routers do not know the identity of routers or destinations outside of their area. Level 1 routers orward all traffic for destinations outside of their area to a level router in their area. Doesn't this mean that an IS-IS area *must* be connected to the connected level 2 backbone, if a level 1 router inside that IS-IS area wants to be able to send traffic outside it? In other words, in IS-IS you can't have an area which is not physically connected to the backbone, but only to another area, no? (OSPF, of course, can, as discussed above, but let's leave this aside for now.) I'm puzzled by your mention of "topologies supported by this are much more general than those supported by OSPF"; I don't quite see what it is that you can do with IS-IS that OSPF can't do. There is also another minor difference: in IS-IS, the level 2 map only contains the level 2 routers, along with which areas, etc, are reachable through each level 2 router. In OSPF, the backbone map can also contain networks. However, this is as much a consequence of the ISO addressing model, which has only individual hosts below areas (whereas IP has both (sub)networks and hosts) as anything else. Of course, treating the OSPF backbone as a (special) area provides this capability naturally, since the abilty to include networks in area maps is part of OSPF's basic area functionality. Noel From owner-big-internet@munnari.oz.au Sat Sep 25 18:43:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09501; Sat, 25 Sep 1993 18:43:57 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04739; Sat, 25 Sep 1993 15:59:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14069; Sat, 25 Sep 93 01:59:20 -0400 Date: Sat, 25 Sep 93 01:59:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9309250559.AA14069@ginger.lcs.mit.edu> To: cmj@nsd.3com.com, jnc@ginger.lcs.mit.edu Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I must be really naive, but I assumed that the whole debate about 2 levels of the protocols (both OSPF and IS-IS) had already been done, and all those interested had fully understood the differences in the approaches taken by the two protocols as well as the ramifications of those approaches I think this is basically true. delete this now if you just don't care ... I will try to keep my preferences out of it. Likewise. What is an Area? It is a group of routers that share a common database about their collective local topologies This is a somewhat limited definition; I prefer to think to think of an area as a (usually contigous, modulo special hacks like level 1 partition repair in IS-IS, and virtual links in OSPF) section of the network topology, including routers, networks and hosts. Neighboring non-backbone routers will exchange summary information about their own areas, but will not pass on information they have learned from other areas Strictly speaking, this statement contains an error; from RFC-1247 (the OSPF spec): Area border routers: A router that attaches to multiple areas. ... Backbone routers: A router that has an interface to the backbone. This includes all routers that interface to more than one area (i.e., area border routers). From this it appears that OSPF does not have neighbouring routers in different areas which are "non-backbone routers". It is true (as in your example below) that you can have backbone routers which are not connected (ether directly, or through virtual links) to the rest of the backbone, but the OSPF spec prohibits this. From RFC-1247: The backbone must be contiguous. It is possible to define areas in such a way that the backbone is no longer contiguous. In this case the system administrator must restore backbone connectivity by configuring virtual links. In the diagram below, Area D relies solely on a Virtual Link between Y and Ra for "connection" to the backbone area ... But Area E cannot get "connected" to the backbone area - Virtual Links can span only a single area. This is not correct. As soon as a virtual link is configured between Y and Ra, Y *is* part of the backbone area. You can then configure another virtual link between Y and Z to connect E to the backbone area. Your error appears to be caused by confusion about the OSPF "backbone area". The OSPF "backbone area" is not an area like the other OSPF areas; it is used *very* differently. Think of it as OSPF's equivalent of the level 2 backbone in IS-IS; that's more or less exactly what it is, except that the OSPF version does not have to be physically contiguous, as IS-IS does. It is not just a "distinguished area"; it's an area as a clever hack to avoid having to have a whole separate set of code, packet formats, etc to handle level 2 LSP's, etc. An aribitrary number of areas can be configured, all strung out in sequence, with 2 areas separated by many other areas, with that being the only requirement. Of course, if an area is very large, it may be necessary to promote some of the routers on the interior of the area to run Level 2 in order to "complete the Level 2 backbone", but that does not impose any constraints on the topology of the areas, that is, the choice of the area boundaries. For example, the following topology is supported in IS-IS but not in OSPF: Again, incorrect. Just as you can "hack" an IS-IS backbone together by promoting interior routers to level 2, you can get together an OSPF backbone by configuring virtual links between Yb-Yc, Xa-Xb, etc, etc. This is effectively the same thing, in fact: you are using internal routers to give you connectivity between the true border routers. It's just that in IS-IS, you do it by making interior routers level 2 routers, whereas in OSPF you do it by configuring virtual links which use the interior routers to maintain connectivity. I must admit, I'd not thought of the trick of promoting interior routers to level 2 routers to perform this in IS-IS. Of course, this is a somewhat expensive solution: the level 2 topology map is now more complex (i.e. more expensive to store and transmit to the true border routers), and all the promoted interior routers have to maintain and store the level 2 map as well as their level 1 map, etc, etc. this is what the protocol supports, that this is different from OSPF The method of support is different, but not the results. As a matter of fact, OSPF could use the same trick IS-IS does to support this configuration (promote interior routers to backbone routers), but there's no reason to, as the OSPF virtual link solution is easy to configure, and cheaper in operation. The two protocols propogate external information very differently - in OSPF, externals are known to all the routers in all the areas, except for the STUB areas, but in IS-IS, only the Level 2 routers know about externals. Why? I don't know - probably because the two protocols were designed by different groups of people. OSPF area internal routers know about external routes to i) allow picking of optimal exit routers from the area, and, much more importantly, ii) to allow virtual links to carry externally destined traffic. If internal routers of areas with virtual links across them *didn't* know about externals, such traffic wouldn't know where to go once it got into an area. IS-IS doesn't have to worry about this, since their backbone is physically contiguous, and any level 1 router handed such a packet simply passes it to the nearest level 2 router. Of course, if you don't care about picking the absolute optimal exit router from an area, and don't have virtual links configured across an area, you can dispense with the overhead of the external information, which is what the OSPF "stub area" feature allows you to do. Noel From owner-big-internet@munnari.oz.au Sat Sep 25 19:22:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10618; Sat, 25 Sep 1993 19:22:16 +1000 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27384; Sat, 25 Sep 1993 11:57:46 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA14922 (5.65c/IDA-1.4.4nsd for ); Fri, 24 Sep 1993 18:57:11 -0700 Received: by jaspar.NSD.3Com.COM id AA20547 (5.65c/IDA-1.4.4-910730); Fri, 24 Sep 1993 18:57:08 -0700 Date: Fri, 24 Sep 1993 18:57:08 -0700 From: "Cyndi M. Jung" Message-Id: <199309250157.AA20547@jaspar.NSD.3Com.COM> To: jnc@ginger.lcs.mit.edu Subject: Re: SIP and PIP Merger and CLNP Cc: big-internet@munnari.oz.au I really didn't mean to get into another round of OSPF versus IS-IS - I just wanted to balance the PROS and CONS a little bit. Perhaps I should just leave people to their current prejudices, but sometimes it just gets to be a bit much. I must be really naive, but I assumed that the whole debate about 2 levels of the protocols (both OSPF and IS-IS) had already been done, and all those interested had fully understood the differences in the approaches taken by the two protocols as well as the ramifications of those approaches - I thought it was just me that had to see it in operation to get a feel for it. I don't know how to make this short and clear - delete this now if you just don't care (or already know), but I am going to try to describe the difference between the two approaches. I will try to keep my preferences out of it. What is an Area? It is a group of routers that share a common database about their collective local topologies, i.e. their link state information. Why would this be less than all the routers in the system? Because that database may be quite large, depending on such factors as the total number of routers in the system and the number of interfaces on each. Areas are a way of making the network topology "modular", with perturbations of one area staying within the borders of that area. How are OSPF area borders defined? Each interface of a router can be in a different area - there can be multiple interfaces into the same area, including the case where all interfaces are in the same area. When two routers share a common subnet (IP and physical), the interfaces of those routers on that subnet must be in the same area - a single IP subnet cannot be in two different areas at the same time. This is basic - area borders exist within the router. How are IS-IS area borders defined? Each router is wholly contained within an area - the border, then is on the link between routers of different areas. The area is identified by the Area Address of the router - the leading portion of it's network address (strip off the "host" portion and you are left with the Area Address). If all the neighbors of a given router are within the same area (same Area Address), then the router is NOT at the border of an area. If some neighbor has a different Area Address, that router is at the border. This, too, is basic. Information about an area stays within that area - both OSPF and IS-IS are similar in this regard. Inter-area information is handled quite differently by the two protocols. Inter-area information in OSPF is exchanged at the boundary of the backbone area (0.0.0.0) and a neighboring area in the form of a summary. Much of that takes place within one router, since the "borders" are within a router, except for those areas that are not "physically" connected to the backbone area. Neighboring non-backbone routers will exchange summary information about their own areas, but will not pass on information they have learned from other areas - only via the backbone area can a non-backbone area learn about networks reachable in another area to which none of their routers are attached. (I think I said it right, but pictures are really helpful at times like this). Let A, B and C be areas that are each connected to the backbone area. Let A and B share a router X - make it simple, let X have one interface in Area A and one other interface in Area B. Let Area C be attached only to the backbone and not to either Area A or B. Let Ra, Rb, and Rc be the routers attaching these 3 non-backbone areas to the backbone area. If Rb fails, Area B will still have information about what networks are within Area A because router X is still connecting the two areas, but it will no longer know what it can reach within area C because it could only learn that from the backbone - even though there is still a physical path, the path over which the routing information is learned is down, so the information is lost, and so is connectivity between systems in Area B and systems in Area C. -------------------------------------------------------------- | | | Backbone Area - AreaID = 0.0.0.0 | | | -------------------------------------------------------------- | | | Ra Rb Rc | | | __________________ __________________ _______________ | | | | | | | Area A |--X--| Area B | | Area C | | | | | | | ------------------ ------------------ --------------- Actually, systems in Area B will only be able to communicate with systems in Area A, since Router X will only announce into Area B the summary of information from areas it belongs to. This is not a problem - please don't think this is a criticism of the protocol. This is only to illustrate the way the inter-area information is shared when there are multiple areas. Single points of failure can be avoided by using redundant routers to attach the non-backbone areas into the backbone area. For a cheaper solution, a Virtual Link between X and Ra can be configured and the necessary information can be learned that way. In the diagram below, Area D relies solely on a Virtual Link between Y and Ra for "connection" to the backbone area (and so to other Areas B and C). If Area A has redundant routers, then Y can have a Virtual Link to each - fine. But Area E cannot get "connected" to the backbone area - Virtual Links can span only a single area. Again, please don't think this is a criticism of the protocol. You need to know this if you are going to use the protocol, as it impacts the way you plan the areas. -------------------------------------------------------------- | | | Backbone Area - AreaID = 0.0.0.0 | | | -------------------------------------------------------------- | | | Ra Rb Rc | | | __________________ __________________ _______________ | | | | | | | Area A |--X--| Area B | | Area C | | | | | | | ------------------ ------------------ --------------- | Y | __________________ | | | Area D | | | ------------------ | Z | __________________ | | | Area E | | | ------------------ It is true, you can break up the backbone area so that it is no longer contiguous, then string it together with Virtual Links so that the inter-area information is known throughout, but each Virtual Link still can only span a single area, and if the entire OSPF system grows large, the backbone area must also grow. This is still basic, and I'm going to keep it that way - I'm trying to keep the scope of this to the DIFFERENCES between the two protocols in how they have a two level hierarchy - intra-area and inter-area. I may just be able to do that. Are you ready for inter-area information in IS-IS? You must be - you've put up with it up to this point. It isn't much longer. In contrast, IS-IS does not have a "backbone area". Rather, at the common border between two areas, each area must have a router running Level 2 - this is not a hardship, all products supporting IS-IS can do this. All Level 2 routers within the domain share a common database, that is, the Level 2 Link State information. The Level 2 information is used to compute the next hops to the other areas in the domain. The only way for a Level 2 router to get this information is from another Level 2 router, so comes the requirement that the Level 2 "backbone" (or "subdomain" as it is also called) be "connected". This "connectedness" is not centralized as it is in OSPF, rather there must simply be some path between any pair of them that passes through all Level 2 routers. An aribitrary number of areas can be configured, all strung out in sequence, with 2 areas separated by many other areas, with that being the only requirement. Of course, if an area is very large, it may be necessary to promote some of the routers on the interior of the area to run Level 2 in order to "complete the Level 2 backbone", but that does not impose any constraints on the topology of the areas, that is, the choice of the area boundaries. For example, the following topology is supported in IS-IS but not in OSPF: __________________ __________________ _______________ | | | | | | | Area A Xa-----Xb Area B Yb-----Yc Area C | | | | | | | ---------Za------- ------------------ --------------- | | | _________Zd_______ __________________ _________________ | | | | | | | Area D Sd-----Se Area E Te-----Tf Area F | | | | | | | ------------------ ------------------ ----------------- Why would anybody want to do this? I can't say off-hand, though I also can't say off-hand why they shouldn't be able to do this if that's what their application environment requires, or if that's how their departments work best. The point I'm trying to make is that this is what the protocol supports, that this is different from OSPF, and is something someone using this protocol to run a network needs to know about it. There may not be any real need to use any topology other than those supported by OSPF. The two protocols propogate external information very differently - in OSPF, externals are known to all the routers in all the areas, except for the STUB areas, but in IS-IS, only the Level 2 routers know about externals. Why? I don't know - probably because the two protocols were designed by different groups of people. Have a nice weekend. Cyndi From owner-big-internet@munnari.oz.au Tue Sep 28 09:13:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07213; Tue, 28 Sep 1993 09:13:38 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25846; Tue, 28 Sep 1993 03:07:18 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA04093 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 27 Sep 1993 13:00:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 27 Sep 1993 13:00:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 27 Sep 1993 13:00:53 -0400 From: Dennis Ferguson Message-Id: <199309271705.AA72838@foo.ans.net> To: "Cyndi M. Jung" Cc: big-internet@munnari.oz.au Subject: Re: SIP and PIP Merger and CLNP In-Reply-To: (Your message of Sat, 25 Sep 93 01:57:08 GMT.) <199309250157.AA20547@jaspar.NSD.3Com.COM> Date: Mon, 27 Sep 93 13:05:02 -0500 Cyndi, > I really didn't mean to get into another round of OSPF versus IS-IS - I > just wanted to balance the PROS and CONS a little bit. Perhaps I should > just leave people to their current prejudices, but sometimes it just gets > to be a bit much. I think we have reached a new low when one cannot express an opinion without having it discounted immediately as "prejudice" by people who can have utterly no idea of the technical basis for that opinion and in fact weren't even interested enough to ask. It is like the networking weenie version of political correctness applied to routing protocol design. I can hardly wait for the IPng debates (which I, fortunately, have yet to form an opinion about) to heat up. In fact I also believe (and stated) that the major differences between IS-IS and OSPF are terminology, if you can manage to strip this away you find two routing protocols which are substantially similar and differ only in the details. I think your most recent note is in fact confused by terminology variations, and as such is actually obscuring the interesting differences. > For example, the following topology > is supported in IS-IS but not in OSPF: > > __________________ __________________ _______________ > | | | | | | > | Area A Xa-----Xb Area B Yb-----Yc Area C | > | | | | | | > ---------Za------- ------------------ --------------- > | > | > | > _________Zd_______ __________________ _________________ > | | | | | | > | Area D Sd-----Se Area E Te-----Tf Area F | > | | | | | | > ------------------ ------------------ ----------------- In fact, if we can agree (as Steve Deering likes to point out) that "topology" refers to links and routers and not something more mysterious, I think OSPF supports the above just fine. Making the following translation: - make every IS-IS level 1 router an OSPF router running in a single, non-backbone area only. - make every IS-IS level 2 router an OSPF router running in two areas, a local non-backbone area as well as the backbone area (0.0.0.0) and OSPF will be a plug-compatable replacement for IS-IS in the above topology as it is drawn. The differences here are really limited to the amount and nature of additional configuration you'll need to do. With IS-IS the level 2 routers in the same area (say Za and Xa) will need to have interfaces on a common subnet. If this subnet is shared by Za and Xa exclusively, with no level 1/non-backbone routers, for OSPF you can just configure the subnet as part of the backbone area. Otherwise for OSPF you'll need to configure the interface as part of Area A and instead configure a virtual link between Xa and Za. Either way works just fine, the only difference here is that with IS-IS the level 2 routers will be able to find each other by multicast discovery in either case while, in the latter case, you'll need to explictly tell OSPF about its backbone area neighbours. Conversely, with IS-IS, if Xa and Za don't have a subnet in common you'll need to configure additional level 2 routers between them. With OSPF you have the choice of similarly configuring additional backbone area routers, or just configuring a virtual link between Xa and Za and leaving the routers between them operating in the non-backbone-area only. So in fact I think IS-IS and OSPF will route the above topology more-or-less equally well, as I would have suspected since the protocols are substantially similar. The basic difference between them in this application seems to be that IS-IS will require slightly less configuration to do it while OSPF gives you more options for intra-area routing of inter-area packets when the area border routers don't share a common subnet. I am pretty sure these are the basic "PROS and CONS" of the protocols in the above topology. Now, in this particular instance, I prefer what OSPF did. I don't mind the extra configuration and like having the additional options. This is my opinion. I recognize, of course, that reasonable people can come to a different opinion based on the same understanding of the issues (perhaps, in this case, router vendors with customer support people who need to explain this stuff to users in particular). I can understand this, and feel no compulsion to discount their opinions as mere "prejudice" just because they differ from my own. Can you same the same, Cyndi? Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Tue Sep 28 16:24:06 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22627; Tue, 28 Sep 1993 16:21:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA08833; Tue, 28 Sep 1993 16:21:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA08780; Tue, 28 Sep 1993 16:16:01 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22385; Tue, 28 Sep 1993 16:15:05 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@murtoa.cs.mu.OZ.AU Reply-To: Big-Internet-Request@munnari.OZ.AU Subject: Big-Internet list changes (and test message) Date: Tue, 28 Sep 1993 16:15:00 +1000 Message-Id: <3679.749196900@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Hi everyone - as mooted some time ago, I am in the process of changing how the Big-Internet list runs here locally. This should have almost no visible effect on any of you who don't go gazing at the Received headers of B-I messages... That is, the address to send messages to the list is still Big-Internet@munnari.OZ.AU the address to send administrivia (list additions, deletions, general comments, loads of $'s, ...) remains Big-Internet-request@munnari.OZ.AU and the address for your mailer to send bounce messages (and which should not be used for anything else) continues as owner-Big-Internet@munnari.OZ.AU The latter is the one that you should see in the envelope sender field (Mail From:
in SMTP). The B-I archives are still available via anonymous FTP from munnari.oz.au:big-internet/list-archive/* in the same format as before (one file for each month during which there have been any messages on the list). One previously unannounced change is that some of the oldest archives have now been compressed (using the unix(tm) "compress" utility). With luck this change will speed up delivery of messages to the list (I intend watching to see how quickly this message makes it through the queue, at least to the point where all that can be delivered immediately has been delivered), as well as lowering the load on munnari somewhat. One cost that you may notice is that there is now a small chance that should the Big-Internet delivery system, or its mailer, crash during delivery, some of you may receive two copies of any message being delivered at the time - previously the chance of that was very slim indeed, and would have affected at most one recipient, now there's a bigger chance that more extra copies might be sent. I hope this never occurs, but it is possible. The list itself has not been altered yet, that will happen after I convince myself that this message has succeeded. Unless there is a problem and I need to repeat this test, this message will be all that you hear about the change though. While I'm here I may also take the time to point out that mail to Big-Internet-request is handled by an exceedingly intelligent automaton, that can easily cope with all the simple commands like "add", "subscribe", "unsub", "remove", etc, without flinching, what's more it also copes with rather more vague requests, in almost any variant of English that you care to submit, and occasionally, with real luck, other languages as well (but don't push it too far...). However, Big-Internet-request is not a rescue service, nor a suicide prevention hotline, and tends to simply ignore plaintive cries of "help", unless they contain something rather more substantive for it to work on. Intelligence does have its price however, and the automaton may often be found contemplating its navel when messages arrive, so I'm afraid instant responses are rare indeed. Messages that are acted upon are acknowledged. More administrivia... A note of caution please: Please don't use Big-Internet for slanging matches, protocol wars, or other similar mudslinging. Messages work much better to get your point across when they're sent after some thought, considered, rationally and calmly, and with non-zero informative content. Also, please no messages to Big-Intenet from news systems. If you gateway B-I into a news system, fine (though I'd appreciate it if you could arrange to refrain sending back "duplicate rejected" messages), however the gateway should be one way, it should never send messages back to the mailing list, no matter how you set it up. Readers who wish to contribute to discussions should do so by sending mail to the list submission address noted above. Note: "mail". Finally, addresses that cause mail to repeatedly bounce will be sliently removed from the list - the number of bounce messages tolerated tends to depend on the phase of the moon, but more importantly, upon the nature of the message - messages that bounce because of "quota exceeded", "no space on device", etc, are usually simply ignored (however if this happens to you you have missed a message, and will need to consult the archives to discover its content). Messages that say "user unknown" or "host unknown" tend to cause more rapid action to be taken, though never because of just one, or even two, of those. I do appreciate it if at all possible you can have yourself removed from the list before you vanish from the address at which you're receiving the list however. Thanks, Robert Elz Big-Internet-request@munnari.oz.au ps: please don't reply to this message unless you detect a fault somewhere, and if you do reply, reply to the administrivia address ONLY.