From owner-big-internet@munnari.oz.au Sun Nov 1 02:05:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12515; Sun, 1 Nov 1992 02:05:09 +1100 (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 AA12346; Sun, 1 Nov 1992 02:00:31 +1100 (from kre) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01737; Sat, 31 Oct 1992 07:00:48 +1100 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA16956; Fri, 30 Oct 92 12:00:37 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA11187; Fri, 30 Oct 92 15:00:36 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA18929; Fri, 30 Oct 92 14:57:57 EST Date: Fri, 30 Oct 92 14:57:57 EST From: Frank T Solensky Message-Id: <9210301957.AA18929@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New growth charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Sun, 01 Nov 92 02:00:06 +1100 Resent-Message-Id: <18792.720543606@munnari.oz.au> Resent-From: Robert Elz There's some new charts that display the NSFnet Routing Tables growth. It should be anonFTPable from "munnari.oz.au:big-internet/nsf-netnumbers-9211.ps" by the time you read this message. The model from last month predicted that there would be 6934 networks today. The actual number is 7354. There were 3556 last year at this time, so it seems pretty safe to say that the growth hasn't started to flatten out yet. The new model pushes the total potential number of networks up from 17,778 last month to 22,551 networks (an increase of 26.9%) and predicts 7425 for December 1st. Since this is only 71 more than today's count, my own prediction is that we'll already have pushed past that level before the IETF conference starts on the 16th -- it'll take a few months before this sudden increase gets fully factored into the trend line. It seemed surprising to see just how far off the prediction was this time, so I started looking at some of the announcement messages to see why this was. The following is based on some very broad assumptions about the "Network Name" field in the "additions" messages sent out by Merit being a reasonable approximation about how routes could be aggregated (caveat emptor), but out of the 565 Class C network numbers that were added this month, 323 were part of a block of 4 or more networks that could be advertised with a single announcement once CIDR is deployed; 221 of those were were within blocks that could be aggregated into blocks of 16 networks or more. -- Frank From owner-Big-Internet@munnari.oz.au Sun Nov 1 05:46:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18645; Sun, 1 Nov 1992 05:46:43 +1100 (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 AA18636; Sun, 1 Nov 1992 05:46:28 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 31 Oct 92 10:46:07 -0800 Date: Sat, 31 Oct 92 10:46:07 -0800 From: Tony Li Message-Id: <9210311846.AA06071@lager.cisco.com> To: big-internet@munnari.oz.au Subject: Change of service provider (was Vote NO on R-L-G) [Please note: I am dragging this conversation here and away from the IETF list.] I would like to emphasize one paragraph from our text which is being widely ignored: Note that an address change need not happen immediately. A domain which has changed service providers may still advertise its prefix through its new service provider. Since upper levels in the routing hierarchy will perform routing based on the longest prefix, reachability is preserved, although the aggregation and scalability of the routing information has greatly diminished. Thus, a domain which does change its topology should change addresses as soon as convenient. The timing and mechanics of such changes must be the result of a multilateral agreement between the old service provider, the new provider, and the domain. The last sentence of this paragraph is key. Tony From owner-Big-Internet@munnari.oz.au Mon Nov 2 02:30:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00145; Mon, 2 Nov 1992 02:30:34 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211011530.145@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00116; Mon, 2 Nov 1992 02:30:24 +1100 (from jcurran@nic.near.net) To: Noel Chiappa Cc: big-internet@munnari.oz.au Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Sat, 31 Oct 92 19:41:49 -0500. <9211010041.AA24985@ginger.lcs.mit.edu> Date: Sun, 01 Nov 92 10:30:09 -0500 From: John Curran -------- ] From: Noel Chiappa ] Subject: Re: Vote NO on R-L-G IP Address Allocation proposal ] Date: Sat, 31 Oct 92 19:41:49 -0500 ] ] [jcurran] ] It is imaginable that TRD's might charge for carrying this route, ] and utilize the funds to augment their routing capability. ] ] I have been assured by a number of providers that they will not either a) make ] subscribers change the IP address when the customers switch providers, or b) ] charge the customer for the privilege of keeping (and advertising in the ] routing) their old address. The reason given is that they don't want to do ] anything which might drive the customer away. That's fine... the first time that a TRD changes for the routing entry, they can either absorb the cost internally or pass it along. It's entirely a business issue for that particular network provider. ] Allowing the customer to keep their old address, OK, but it's going to cost ] *everyone*, i.e. *all* the providers, not just the provider that customer is ] hooked up to, to do that! Where do they expect to get the resources from to ] meet that cost, if they don't charge for the privilege? Well, they will have ] to put it in overhead, and change *everyone* a little extra... I.e. people who ] are nice guys and change their addresses are going to be stuck paying for ] those who are lazy. Not necessarily the best strategy, but many businesses operate this way. ] A rate structure which is not based on real costs is a sure recipe for trouble ] down the line. People who are willing to change their addresses will desert to ] providers who give a price break for such people, etc... Yep. ] Of course, if addresses weren't so deeply wired in everywhere, changing them ] would be easier, especialy if we had tools to help automate the process. I ] think that's what we *really* should be pushing toward; a system in which it ] *is* easy to change addresses. Full agreement here. The fact that datagrams do not carry a toplogically independent endpoint identifier results in people using addresses as if they were endpoints. Making addresses bigger (ala TUBA, IPAE/SIP, IPAE/IP, SIP, etc..) does not solve the problem. Everytime a network address is used in higher layers (ex. ftp, nfs, rpc, "authentication"), it just makes the problem worse. A DNS name in every packet is not practical, but some identifier of the source entity as opposed to source interface would at least free higher- level applications from the pain of topology changes. /John From owner-Big-Internet@munnari.oz.au Mon Nov 2 05:46:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06128; Mon, 2 Nov 1992 05:46:46 +1100 (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 AA06125; Mon, 2 Nov 1992 05:46:38 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25754; Sun, 1 Nov 92 13:46:26 -0500 Date: Sun, 1 Nov 92 13:46:26 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211011846.AA25754@ginger.lcs.mit.edu> To: jcurran@nic.near.net, jnc@ginger.lcs.mit.edu Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the first time that a TRD changes for the routing entry Hmm, but will the TRD's start charging for routing entries? Sure, if they do, other smaller providers will have to follow suit, or otherwise adjust. Making addresses bigger ... does not solve the problem. Everytime a network address is used in higher layers ([e.g.] ftp, nfs, rpc, "authentication"), it just makes the problem worse. The problem is not so much use of addresses in higher layers, but the reliance on addresses *staying the same*. People put them in configuration files, etc, etc, instead of some *other* name, such as a DNS name. A DNS name in every packet is not practical, but some identifier of the source entity as opposed to source interface would at least free higher- level applications from the pain of topology changes. This is a separate issue. EID's (which were intended to be packet-friendly) might help, but I've been thinking about whether we really need EID's in all packets. I've runout of time to answer mail, but I'll try and write these thoughts down and send them in. Noel From owner-Big-Internet@munnari.oz.au Mon Nov 2 09:59:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15011; Mon, 2 Nov 1992 09:59:31 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14998; Mon, 2 Nov 1992 09:59:12 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12121>; Sun, 1 Nov 1992 14:58:49 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 1 Nov 1992 14:58:47 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, brian@lloyd.com, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Sun, 01 Nov 92 10:38:21 PST." <9211011838.AA25731@ginger.lcs.mit.edu> Date: Sun, 1 Nov 1992 14:58:35 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov1.145847pst.10779@skylark.parc.xerox.com> Noel, When I said: > It does not make sense to talk about assigning hierarchical addresses > "on the basis of topology"... I meant that it is an incomplete characterization of the task. If you give me a graph and tell me to chop it into sub-graphs, sub-sub-graphs, etc. "on the basis of topology", that does not, in itself, tell me the criteria I should use to do the partitioning. For example, do you care how deep or how wide the hierarchy is? Shall I treat all edges as equal? What makes one partitioning better than another? In response to my message, you proposed one criterion for doing the partitioning: minimize the cost of routing plus the cost of suboptimal delivery paths. You seem to imply that that is the "natural" criterion or the only sensible one. I think that is too simplistic a view. First, there is no single measure of path optimality -- a minimal delay path is often not a maximal bandwidth path, for example. Are you suggesting that there be separate address hierarchies for different TOS requirements? (That might be a good idea, but I'm not sure if that is what you are proposing.) Second, your partitioning would be subject to change every time a link or router went down or came up. Are you suggesting that the entire addressing hierarchy should be re-evaluated and (potentially) globally distributed every time such an event occurs in the Internet? Third, there may be other criteria more important than routing and path optimization that should be taken into account when assigning the addressing hierarchy. For example, by making organizational boundaries also be addressing boundaries, it is feasible for different organizations to run different routing protocols internally, according to their particular requirements, and for new routing protocols to be deployed piecemeal rather than everywhere at once. You wrote: > You can use just about any hierarchical division of the actual network mesh > you want, but using anything except strictly topological considerations will > *inevitably* drive up Co, by increasing Cr. "Strictly topological considerations" means considerations only of *connectivity*. In order to perform your preferred partitioning, you also have to take into consideration the *cost* of sending packets across each connection, in order to compute Cn. If you want to have a single addressing hierarchy, you'll have to assign a single cost metric to each edge. What shall that metric be? Unity (i.e., hops)? Delay? Bandwidth? Monetary expense? Administrative distance? Geographical distance? A function of several of those (like the "blended" metrics in cisco's IGRP)? Any one of the preceding? If you allow it to be any one of the preceding, then we may actually be in agreement. Steve From owner-Big-Internet@munnari.oz.au Tue Nov 3 02:58:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29931; Tue, 3 Nov 1992 02:58:40 +1100 (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 AA29926; Tue, 3 Nov 1992 02:58:33 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23259; Mon, 2 Nov 92 07:58:12 -0800 Message-Id: <9211021558.AA23259@Mordor.Stanford.EDU> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 22 Oct 92 17:53:13 -0700. <9210230053.AA08439@aland.bbn.com> Date: Mon, 02 Nov 92 07:58:12 -0800 From: Dave Crocker X-Mts: smtp Craig, Having now read your proposed list and the comments about it, here's a few of my own: I like the attempt to develop rank-ordering of the criteria and had hoped that the IESG list would engender a discussion along these lines. While your list looks quite good, it seems to omit some issues that the IESG list attempted to raise. Further, I found Jon Crowcroft's exercise extremely enlightening, primarily for the resulting failure to give enough discrimination between the alternatives. Either there really isn't that much difference, or the definitions are not precise enough to obtain stable evaluations, or we need some more criteria. I believe that the problem is a great deal of the second and some of the third. While the two-level distinction you make between essential versus desired is a very good idea, I think we further need to distinguish between those things with immediate solutions possible and those that must be classed as research, even if they are highly desireable. I claim that the available timeframe, prior to router table choking and IP address exhaustion, do not leave us enough time to treat the research items as high priority, no matter how much we would wish otherwise. Hence, the best we can say about proposed protocols, with respect to such research topics, is that current analysis suggests that the protocol seem to -- or not to -- preclude development of the desired feature. 1. The protocol must allow a straightforward transition plan from the current IPv4. I'm certainly biased towards having this item high on the list, but the work with IPAE has suggested to me that this area of concern subdivides in some important ways. For example: a. Transition effort -- What is the difficulty of the software upgrade? Operational upgrade? b. Transition disruption -- Whether or not the effort is easy, how much disruption (outages or partitioning) occurs during transisition? c. Familiarity of the proposed details -- I believe that the new protocol greatly increases in human cost as it has less similarity with IP. Some folks think this issue is a red herring. I very much think that the herring will pickle _us_ if we don't attend to it very carefully. d. Maturity -- How much experience is there with the proposed specification? With the software that implements it? With the operations that use it? e. Incremental benefit -- This generally falls under the category of seduction vs. coercion. Do users, operators, etc. experience direct benefit when they start using the new protocol, or must they wait until some much-larger critical mass is achieved? 2. The protocol must scale to allow the addressing of billions of end-syste ms. Address space and routing table compression appear to be separate concerns here. Attending to the former does not guarantee any of the latter soon enough. So, When is routing table compression achieved? 3. The protocol must permit the use of routing schemes which allow routing tables to grow at a rate much less than linearly with the number of constituent networks. router [costing $5K 1992 USD] in the year 2000 will have around 1 gigab yte of router table memory and at that time there will be about 2 million networks and 75 million end-systems). While I think that your numbers certainly are reasonable, I believe that we also need to keep in mind plausible, high-end, worst-case numbers. For example, if IP explodes into the global mass market, I suspect that 10 million networks and 250 million end-systems could happen. 4. The protocol must work across an internetwork with individual link speed s ranging from a few kilobits per second to hundreds of gigabits per seco nd. Note that there is a difference between single-stream behavior and aggregate behavior for the node. The node might be able to keep one high-speed stream full, but at the expense of overall performance. So, we should find a finer-grained (set of) metric(s) for characterizing per-datagram handling cost. 5. The protocol must support an unreliable datagram delivery service. Yup. 6. The protocol must allow for both unicast and multicast addressing. Since this is a loud point of contention, I will repeat a point raised earlier: Is the solution mature? Hypothetical? The amount of practical experience with the spec, the software, and the operations, is important. 7. The protocol must support some means for cost recovery. Craig, I am entirely in agreement with your concern, here, but believe that this item must not be above the line and, at least, needs much tighter definition. Do you mean 'accounting'? What does it mean to satisfy or not satisfy this requirement? I believe that this topic is extremely important for real-world Internet operation and growth but also believe that we, the IETF, haven't done nearly enough homework to make it a requirement. It is a research topic, since there are no clear solutions in the pipeline. *************************************************************************** 8. The protocol should support guaranteed flows. Research topic. Best you can do is guess that the proposal doesn't preclude their use. Saying more is to impose operational requirements on a an item that has no operational experience. While Flows has a strong backing, it hasn't gone through enough community review and experience to assert that it is the treatment of choice, in my opinion, and I don't know of any alternative that has. This belongs in a later, would-be-nice category. Sorry. 9. The protocol should support mobile hosts. More IETF work has been done on this, but I believe it also is a research topic. Dynamic host configuration and dynamic network routing to mobile hosts, and other support of mobile hosts is not a topic that we have a coherent view about, in spite of the community interest in the topic. I believe that we have not even properly answered questions about the appropriate place in the architecture to solve various mobile host requirements. DNS? Media layer? Internet layer? Application layer? Which services are required? Why? Perhaps a small sub-community of the IETF has fully fleshed-out the answers to these questions, but I don't see any sign of general community consensus (or even understanding -- I know I sure am confused about the topic.) Another 'sorry.' 10. The protocol should permit the use of security in the network. Another research topic. I don't believe that we have a coherent IETF view about the services or mechanisms that are needed to support this. (And I assume that one of the Security Steve's will correct me if I am wrong about this.) [This is not just for the military, but for banks, etc. And note "Banks" sounds remote and specialized. What about normal commerce, such as EDI? Paying your credit card bill?... I believe that this is a full-system need. ----- Comments on notes from others: Chiappa's 'robustness': Yes, but what does this really mean? How do we evaluate proposals for this? McLaughlin's resource limited concern: Thankyouthankyouthankyou. We cannot dismiss this community with a wave of the hand. It exists and will continue to exist. I also entirely agree with you later point that Internet growth is a highly asynchronous process of many independent decisions and that we need to try to attend to the concerns of different constituencies, if possible. (My own suspicion is that fixing the addressing and routing problem is entirely an imposition for end-system hosts, until we drop off the IP address exhaustion cliff, so that we are unlikely to entice them.) Koch's point about low-end speed is well-taken. We should try not to kill the existing 1200 baud users. Dave From owner-Big-Internet@munnari.oz.au Tue Nov 3 03:52:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01539; Tue, 3 Nov 1992 03:53:17 +1100 (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 AA01528; Tue, 3 Nov 1992 03:52:42 +1100 (from craig@aland.bbn.com) Received: from port16.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07762; Mon, 2 Nov 92 11:52:14 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA17562; Mon, 2 Nov 92 08:50:57 PST Message-Id: <9211021650.AA17562@aland.bbn.com> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: re: Criteria for selecting IPv7 From: Craig Partridge Date: Mon, 02 Nov 92 08:50:56 -0800 Sender: craig@aland.bbn.com Hi Dave: Thanks for the comments. Many of them I'm actually in agreement with -- apparently my original text wasn't wordsmithed right, so you read something different from what was intended. We'll make the appropriate fixes. (Frank Kastenholz is working over the draft with me). > While your list looks quite good, it seems to omit some issues that the > IESG list attempted to raise. Yep. Actually, I don't think the IESG has a list, just a catch bag of ideas. I eliminated some topics that seemed ill-defined to me (just as you're proposing to do to my list :-)). > While the two-level distinction you make between essential versus > desired is a very good idea, I think we further need to distinguish > between those things with immediate solutions possible and those that > must be classed as research, even if they are highly desireable. I > claim that the available timeframe, prior to router table choking and > IP address exhaustion, do not leave us enough time to treat the > research items as high priority, no matter how much we would wish > otherwise. I've got another point of view. Right now we're all running around looking for an IPv7 solution that will allow us to continue to grow the Internet. That's a *push* solution: we'll have beat folks into upgrading software to keep the Internet alive. I think we need *pull* solutions -- features of the new protocol that will cause folks to run out an acquire improved software because it has new functionality they need. In fact, if the protocol lacks some pull, the transition will be longer, because folks will be slower to convert. Another point is that we're architecting this new protocol to last 20 years (or we'd better be) and the transition is going to take several years. If we're smart now and solve a lot of the impending problems (or provide needed services) we'll smooth transition and be much happier in the end. Indeed, if we shut our eyes now and race to "a solution", we may find no one wants to buy it in a few years because it doesn't solve their problems. That having been said, we need to be careful in estimating what we can do. My list of less critical features represented a list of research work items which the research community is close to transitioning to the standards community. I did not put anything in that list that I did not believe could be implemented and deployed within the next six months as part of experimental deployments of IPv7. (Yes, someone would have to work hard on a given particular item to get it done, but the point is that we're in that last mile on them.) Note too, that extensibility doesn't solve the problem -- at least, to date, extensions are a big performance hit. > 6. The protocol must allow for both unicast and multicast addressing. > > Since this is a loud point of contention, I will repeat a point raised > earlier: Is the solution mature? Hypothetical? The amount of > practical experience with the spec, the software, and the operations, > is important. Read the notes that go with this point. I tried to indicate that the minimum standard was local multicasting (same subnet) and that we can talk about the maturity of wide area multicasting. I don't think there's any debate these ideas that *broadcast* is a bad idea. IP should not be hammering all hosts on a multiprotocol subnet with IP-specific messages. So IPv7 oughta support at least enough multicasting that we can stop broadcasting. Given that we've got wide-area multicasting partially deployed, I think there's an argument to say that we ought to do wide-area multicasting too. (Again, a pull argument -- being able to listen in to IETF multicasts is a selling point -- so let's make sure we can still multicast!). > > 7. The protocol must support some means for cost recovery. > > Craig, I am entirely in agreement with your concern, here, but believe > that this item must not be above the line and, at least, needs much > tighter definition. Do you mean 'accounting'? What does it mean to > satisfy or not satisfy this requirement? I need to have some way to provide you IPv7 connectivity and bill you. Again, read the comments -- billing as we do today, based on the bandwidth of your leased-line, is just fine. The point is that IPv4 is a commercially provided networking service and we cannot break that. The point here is not to impose more work but to keep what we have. Accounting in the fuller sense is certainly a research topic and I wasn't lobbying for it. Craig From owner-Big-Internet@munnari.oz.au Tue Nov 3 03:59:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01716; Tue, 3 Nov 1992 04:00:15 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211021700.1716@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01706; Tue, 3 Nov 1992 03:59:58 +1100 (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, 2 Nov 1992 16:59:14 +0000 To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 - holy grails & plea for peace In-Reply-To: Your message of "Mon, 02 Nov 92 07:58:12 PST." <9211021558.AA23259@Mordor.Stanford.EDU> Date: Mon, 02 Nov 92 16:59:11 +0000 From: Jon Crowcroft >While your list looks quite good, it seems to omit some issues that the >IESG list attempted to raise. Further, I found Jon Crowcroft's exercise >extremely enlightening, primarily for the resulting failure to give >enough discrimination between the alternatives. i agree - however my conclusion from this is that all the proposaed solns are technically ok in the short and medium term - i.e. there is no Holy Grail solution it is better to pick one and provide the right catalysts for it to go than to argue over the merits when we dont understand the problem space of the long term requirements yet anyhow... >Koch's point about low-end speed is well-taken. We should try not >to kill the existing 1200 baud users. no solution will suceed that "kills" any significant user base, imho jon From owner-Big-Internet@munnari.oz.au Tue Nov 3 05:20:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03629; Tue, 3 Nov 1992 05:20:40 +1100 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03621; Tue, 3 Nov 1992 05:20:08 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA15101; Mon, 2 Nov 92 10:19:48 -0800 Date: Mon, 2 Nov 92 12:36:27 EDT From: "William Allen Simpson" Message-Id: <877.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: Vote NO on R-L-G IP Address Allocation proposal I favor geographic route aggregation over provider route aggregation because of my experience with the topology we currently have. I'm right here in the "heartland". It makes no sense to me that packets to a PSI subscriber in Michigan always go away to Cornell, then back here; or an Alternet subscriber always go to NearNet and thence to Washington DC, before hopping to California. Talk about your non-optimal routes! Worse, those are two of the busiest gateways, so I experience tremendous packet loss. I believe the topology should be driven by geographic reality, and that this is an administrative issue. This applies to Nimrod, Unified, or any other routing scheme we may come up with in the future. Under geographic aggregation, when an exchange is too congested, it could easily be split, and the routes would still aggregate without massive changes. The fact that a multiregional provider (or large company) has internal cross-country links is really of no benefit except to the internal routing. IFF the provider has only a single exterior connection, then ITS routes should be the exceptions! The other providers could charge extra, or otherwise pressure the laggard to interconnect. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Tue Nov 3 07:30:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07120; Tue, 3 Nov 1992 07:30:10 +1100 (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 AA05183; Tue, 3 Nov 1992 06:21:13 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29025; Mon, 2 Nov 92 14:21:00 -0500 Date: Mon, 2 Nov 92 14:21:00 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211021921.AA29025@ginger.lcs.mit.edu> To: craig@aland.bbn.com, dcrocker@mordor.stanford.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I've noticed a tendency, of late, for increasing conservatism in design in the IETF. While I think a certain amount of conservatism is OK (we are after all responsible for a large operational network), let's not let it go so far as to stifle creative growth. I know this is a hard line to tread, and one not subject to easy quantitive measurement, but if we get to the point where we can't do anything bold a lot of the more creative and innovative engineers are going to go elsewhere. The world has a name for a biological system with maximal internal resistance to state-change: dead. With that mindset in hand, let me offer a few comments on your notes. I believe that the new protocol greatly increases in human cost as it has less similarity with IP. This is a good point, but we ought to handle it with better documentation, etc, rather than limit *necessary* technical innovation to achieve it. All that will get us is a system everyone understands, and which is not as useful. > router [costing $5K 1992 USD] in the year 2000 will have around 1 > gigabyte of router table memory I think I forgot to comment on this in Craig's original, so let me do so here. The issue is not just *protocol* scaling (i.e. resource consumption in memory, bandwidth and CPU), but *human* scaling (in configuration and management). As I have lamented on previously, if people would just keep their grubby paws out of the routing and simply let traffic take the most efficient path, routing would be relatively easy. The problem is, they won't; they want to impose their own policy ideas on how things work. If I may digress momentarily, the single greatest problem of the "Information Age" is that people are drowning in a sea of information. Our machines can give us access to far more data that we can possibly use, and *the* great future challenge is *not* going to be building a system which can give us access to *more* data, but rather finding out how to use what we've *already got*! Where this comes into our realm is the size of the routing database. Just because we can create a router that can handle 1 million routing table entries doesn't mean people will be able to use it! As long as people want some control over where their traffic goes, we have to find less "brute- force" solutions. Effective policy controls will be much harder in a system with million entry routing tables. The amount of practical experience with the [multicast] spec, the software, and the operations, is important. I think you are being too conservative here. Applications are going to drive the network, and one very important application is going to be video teleconferencing. This alone tells me that multicast support *at some level* (i.e. perhaps not in the same sublevel of the internetworking layer as unicast (i.e.in routing, etc)), but definitely ubiquitous and efficient, is absolutely critical. [Accounting] is a research topic, since there are no clear solutions in the pipeline. Well, then, we've been falling down on the job. In a funny way, I'm glad you think we don't know enough; I've said all along (after I listened to Van, that is :-) that in many areas we don't yet *know* enough to do IPv7, and that we should be delaying until we do. While Flows has a strong backing, it hasn't gone through enough community review and experience to assert that it is the treatment of choice, in my opinion, and I don't know of any alternative that has. Again, I think this is overly conservative. It's been clear for a decade that 'classical' datagram and VC networks have advantages and disadvantages, and that one way to get the advantages of both was to design a system which was intermediate between the two. I've yet to hear an argument that said that this line of reasoning was wrong. Sure, we may not know the details yet, but I'm pretty sure flows are here to stay. dynamic network routing to mobile hosts, and other support of mobile hosts is not a topic that we have a coherent view about, in spite of the community interest in the topic. Again, I think this is overly conservative; mobile hosts have been a *known* issue for 15 years! Arguments are proceeeding as to how to handle them, but unless we force a resolution by making them a definite goal for inclusion, this will just get put off until "the next revision". Alternatively, we'll see happening what is happening now; support for them will be added as a disgusting bag on the side of the existing design. (Also, your comment assumes a solution; why do we have to suport mobile hosts in the routing?) Another research topic. I don't believe that we have a coherent IETF view about the services or mechanisms that are needed to support [security]. If we aren't planning on building a securable network, we might as well go home right now. Again, maybe this is just one more argument that we need to spin up some research work and delay the new protocol a bit. Chiappa's 'robustness': Yes, but what does this really mean? How do we evaluate proposals for this? If designing protocols was as easy as 'paint-by-numbers', any bozo could do it. Sure, there isn't a hard and fast way of measuring robustness, but a good engineer knows it when they see it! There are a number of ways that protocols (and *implementations*, which are just as important here) are robust; they can operate correctly no matter how badly malformed packets you force feed them; they can be designed to minimize the amount of configuration needed, to lessen the chances of getting it wrong; they can operate "reasonably" in the presence of incorrect configuration, etc, etc, etc. We should try not to kill the existing 1200 baud users. Who said anything about making the system useless for 1200 baud users? All I'm saying is that if you have a choice between adding a feature which will be *unbelievably* useful in 10 years, thereby making 1200 baud users 20% worse off, and not adding the feature to avoid impacting them, it's crazy to leave the feature out. Anyone who thinks *I'm* crazy for thinking this, well, feel free. Let's display a little vision, here, huh? Noel From owner-Big-Internet@munnari.oz.au Tue Nov 3 11:55:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19198; Tue, 3 Nov 1992 11:55:42 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19126; Tue, 3 Nov 1992 11:55:11 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12303>; Mon, 2 Nov 1992 16:54:47 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 2 Nov 1992 16:54:33 -0800 To: Dave Katz Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Sun, 25 Oct 92 22:24:38 PST." <9210260624.AA03118@regal.cisco.com> Date: Mon, 2 Nov 1992 16:54:27 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov2.165433pst.10779@skylark.parc.xerox.com> Regarding the need for all providers to interconnect within a metro area, under my geographic addressing proposal, Dave Katz wrote: > I see this as a serious sticking point--there must be a common touch-down > point (akin to a telco POP) to which all "long-haul" providers connect, > and from which all destinations in the city must be equally reachable. That's not quite correct, and I'd like to prevent any misunderstanding on this point (not that Dave misunderstands, I'm sure, but others might take his words literally). Having a common POP is *one* way, and perhaps the conceptually simplest way, to provide the necessary interconnection, but it is not the only way. The rule is simply that each provider (whether long-haul or local) serving a metro area must have a *path* -- not necessarily a direct connection -- to every other provider serving the same metro. It is greatly to be preferred that that path falls entirely within the metro area; if it does not, some kind of tunneling mechanism would likely be necessary over that part of the path that is outside the metro (similar in nature and purpose to the tunneling mechanism in IS-IS for healing partitioned Areas). As an example of an alternative to a common POP, one or more providers operating within a metro area may offer transit service to other providers that are not themselves directly interconnected. (In graph-theoretic terms, the set of nodes and links within a metro area are simply required to form a connected graph. That's all that is required to enable routers outside the metro to abstract the metro as a single node.) Steve From owner-Big-Internet@munnari.oz.au Tue Nov 3 12:47:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21759; Tue, 3 Nov 1992 12:48:12 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21733; Tue, 3 Nov 1992 12:47:37 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12268>; Mon, 2 Nov 1992 17:47:01 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 2 Nov 1992 17:46:55 -0800 To: Scott_Brim@cornell.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Mon, 26 Oct 92 14:02:08 PST." <9210262202.AB18663@mitchell.cit.cornell.edu> Date: Mon, 2 Nov 1992 17:46:50 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov2.174655pst.10779@skylark.parc.xerox.com> Scott Brim wrote: > ...trying to do geographic addressing with 32 bits (including host) is > futile. I agree with that. Steve From owner-Big-Internet@munnari.oz.au Tue Nov 3 14:59:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28148; Tue, 3 Nov 1992 14:59:26 +1100 (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 AA28122; Tue, 3 Nov 1992 14:59:06 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01990; Mon, 2 Nov 92 22:58:47 -0500 Date: Mon, 2 Nov 92 22:58:47 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211030358.AA01990@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Let me state, up top here, what I think the critical point is. (Those who don't feel like plowing through the detailed reply can then stop!) Given a physical network mesh topology, you can divide the topology into an abstraction hierarchy for purposes of addressing and routing in any number of ways. Some, no doubt, will be 'better' than others. However, using administrative or geographic considerations as guides in setting up the abstraction hierarchy, as opposed to topological relationships in the network, is essentially useless to the routing. Why? Because the whole point of an abstraction hierarchy is to allow the routing system to reduce its overhead by aggregating ("abstraction" is the general term I use, but aggregating will be more easily understood by those who think in terms of routing tables). Anytime an abstraction heirarchy, guided by non-topological considerations such as geography or administration, 'aggregates' things which are not topologically related, it is just plain wasting its time as far as the routing is concerned. In addressing (in the JNC sense), topology is king. For example, if A.0 ... A.N are all contiguous, and A.7 is somewhere else in the network, you might as well have given A.7 the name X.0 for all the good it is going to do the routing. Why did you name A.7 as part of the A.* series, when it is somewhere else? Because something *other* than the network topology (e.g. administrative or geographic convenience) was driving your choice. Don't get me wrong, administrative convenience is not to be sneezed at, but before I'd start doing this sort of thing to the routing, I'd look to see if I could make life easier for the administrators in some other way. Routing under policy, resource usage, etc, constraints in a very large network is going to be hard enough, without trying to make it easier for the number bureacrats to give out numbers. None of this is to say that it's *impossible* to take considerations other than topological realtionships into account when defining an abstraction heirarchy, but realize that the routing will be negatively impacted every time you do. This is a very quick scan of a much more complex problem, in which policy routing and the tremendous problems of "thinning" play a large role, but here again is the Golden Rule of Abstraction: -> Anytime an abstraction heirarchy 'aggregates' things which are not -> topologically related, it is just plain wasting its time as far as -> the routing is concerned. Now, on to reply in detail. When I said: > It does not make sense to talk about assigning hierarchical addresses > "on the basis of topology"... I meant that it is an incomplete characterization of the task. If you give me a graph and tell me to chop it into sub-graphs, sub-sub-graphs, etc. "on the basis of topology", that does not, in itself, tell me the criteria I should use to do the partitioning. Clearly we had a minor miscommunication. Yes, simply saying "divide the topology into an abstraction hierarchy for purposes of addressing and routing" provides no guidance on how to do so. However, to me, "assigning addresses [creating the abstraction hierarchy, actually] on the basis of topology" means "consider topological relationships in the actual network mesh to be of *paramount* inportance in establishing the abstraction hierarchy". I took your shorthand phrase to mean that you didn't believe this, as I believe you don't, if you consider administrative or geographic considerations to be suitable guides for setting up the abstraction hierarchy. However, this miscommunication *is* minor, since I believe we still disagree on the relative importance, in constructing the abstraction hierarchy, of actual topological relationshops and administrative/geographic considerations. Let's move on to that topic. For example, do you care how deep or how wide the hierarchy is? I don't have a specific answer to this question, because I don't have a good model for the costs of running the routing. Let me step back for a second (as usual :-). I have generally classed the costs of running the routing system, Co, into two sub-components; Cr, which is the actual overhead of running the routing, which is easily measurable, and Cn, which is 'invisible' overhead. It consists *not only* of extra hops taken by non-optimal routing, but the (varied) costs of traffic which could not be forwarded because a suitable path could not be found, even though one exists, because the routing system has thrown away some crucial information in the process of doing policy routing and scaling, etc, etc. (My apologies if I didn't make this clear in the previous note, but I was trying to simplify the analysis for the IETF list...) Perhaps this is an overly large space to cover with one term, and I should really have many cost components, and split the old Cn into a 'new' Cn which is *only* non-optimal routes, and a number of other C for other 'hard-to-qualify' components. For example, Cnf would be the example given, of non-forwardable traffic. Management and configuration costs would be Cmc. Co would then be Cr + Cn + Cnf + Cmc + ... My assumption is that, in general, we wish to minimize Co. Why? The routing is just a means to an end. It doesn't do anything for you *directly*. Only getting a packet from the source to the destination can produce some useful result. The routing is *pure overhead*. In the context of this, how wide and deep the hierarchy should be is clearly a little tricky to answer. Is management of the policy and other configuration components of the routing databases a substantial cost component? If so, then you want to minimize the number of items in the routing database, which means more and smaller levels. (There's a direct tradeoff between number of levels and size of each level, for a fixed number of destinations.) For example, a system with 6 levels of 100 items in each level is a lot less information for the average switch to manage (600 items, assuming each switch has a full database) that one which has 3 levels of 10,000 items (30,000 items), even though each can handle the same number of tracked destinations, 10^12. In addition to minimizing Cmc, this would also minimize Cr. However, if the abstraction process needed 'thins' (a technical term defined in the Nimrod document) a lot of information, this will drive up both Cn (for traffic which does flow), and Cnf, since you may not be able to find routes. Without more data, and better cost models, it's hard for me to say where the right setting for the number_of_levels/size_of_level knob is. This is why Nimrod is laden with "analog" knobs; because I don't think we know enough yet to set cost/benefit tradeoffs in concrete, and because different people will have different answers even when we *do* know enough. Shall I treat all edges as equal? By edges I assume you mean links? Clearly, this is not appropriate, but again, without a better cost model, I can't say. What makes one partitioning better than another? I think I answered this. We are trying to minimze the cost of the routing, which, as far as I can see, is *all* overhead; the routing in and of itself doesn't do anything useful. In response to my message, you proposed one criterion for doing the partitioning: minimize the cost of routing plus the cost of suboptimal delivery paths. You seem to imply that that is the "natural" criterion or the only sensible one. I apologize for not explaining in enough detail that I'm actually considering all the costs of routing. I do think that minimizing the overall costs of routing (hard though they may be to quantify) is a reasonable criterion. I think that is too simplistic a view. First, there is no single measure of path optimality -- a minimal delay path is often not a maximal bandwidth path, for example. Exactly, and this was this stumbling block I kept falling over in the late 80's when I was thinking about the problems of abstraction. As soon as you need to do "thinning" to do abstraction, you have immediately moved *beyond* what an automatic algorithm can *reasonably* do correctly for you. That's the whole reason for flexible outgoing and incoming (what used to be called LAC) abstraction control in Nimrod; the system can't make these decisions automatically. Are you suggesting that there be separate address hierarchies for different TOS requirements? No, but Martha has proposed that if, for a certain class of traffic, Cn and Cnf rise sufficiently high because the abstraction heirarchy is poorly attuned (through a poor decision process in the thinning process) to that class of traffic, that you might have multiple parallel abstraction hiearchies tuned to various classes of traffic. I'm dubious that the savings in Cn and Cnf would outweight the costs in Cr, but I suppose it's possible. Second, your partitioning would be subject to change every time a link or router went down or came up. Are you suggesting that the entire addressing hierarchy should be re-evaluated and (potentially) globally distributed every utime such an event occurs in the Internet? As I think I alluded to in the previous message (where I was talking about how you wouldn't try to optimize the abstraction hierarchy to *absolutely* minimize Co, for this very reason), this is not the goal. I have previously discussed, on this list, *another* cost function, Crn, the cost of renumbering some portion of the network, and it's relationship to the difference between i) the Co of the current hierarchy and ii) the Co of the optimal abstraction hierarchy. When that difference gets larger than Crn, it makes sense (in terms of cost) to renumber the addresses. All this really is is a restatement of the principle that an optimal abstraction hierarchy is isomorphic to a particular graph topology; if you change the second, you have to change the first. Third, there may be other criteria more important than routing and path optimization that should be taken into account when assigning the addressing hierarchy. Because of the extremely wide range of semantic available through policy routing tools, even doing just routing optimization is going to be effectively impossible in an algorithmic way, at least, certainly without a fairly detailed traffic model. Whether we will be *able* to handle *any* additional considerations remains to be seen, although as I noted to start with, it is possible. For example, by making organizational boundaries also be addressing boundaries, it is feasible for different organizations to run different routing protocols internally, according to their particular requirements, and for new routing protocols to be deployed piecemeal rather than everywhere at once. Hah! You just ran into one of my pet peeves! Private routing protocols are not something I think we need to support, although I do concede we do need to support private policies, as well as private route selection algorithms. However, let's not get into this rathole just yet. In order to perform your preferred partitioning, you also have to take into consideration the *cost* of sending packets across each connection, in order to compute Cn. Look, I doubt anyone's actually going to be computing C to design their abstraction hierarchy anytime soon. It's just too difficult, and anyway it's impossible without tons of data, for instance a detailed profile of the traffic requirements. I don't think anyone knows how to compute C for a multi-level addressing system, although some people do compute/measure (see Jose Garcia-Luna's work on modelling the costs of running various routing protocols) Cr for simplistic single level systems. I'm sure we'll be getting PhD theses in this area for decades to come! :-) This does not mean the cost model is useless; it provides a valuable framework in which to think about routing systems. If you want to have a single addressing hierarchy, you'll have to assign a single cost metric to each edge. What shall that metric be? Unity (i.e., hops)? Delay? Bandwidth? Monetary expense? Administrative distance? Geographical distance? A function of several of those (like the "blended" metrics in cisco's IGRP)? Any one of the preceding? I don't agree with your premise, which I think comes from a hop-hop distributed computation view of routing. I explicitly consider *only* map-distribution non-hop-hop-routed routing architectures as suitable. In this model, your statement does not make sense; each edge will have a number of attributes, some being metrics (delay, throughput, etc), and some being transit policy (accpetable use, etc); this information will be available when the route computation happens. As I have explained, with policy routing, you have to have a model of the traffic, and the QOS/policy requirements of the traffic, before you can evaluate Co for a particular proposed abstraction hierarchy. Noel From owner-Big-Internet@munnari.oz.au Tue Nov 3 18:53:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07975; Tue, 3 Nov 1992 18:54:11 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07961; Tue, 3 Nov 1992 18:53:52 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12405>; Mon, 2 Nov 1992 23:53:23 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 2 Nov 1992 23:53:12 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Mon, 02 Nov 92 19:58:47 PST." <9211030358.AA01990@ginger.lcs.mit.edu> Date: Mon, 2 Nov 1992 23:52:56 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov2.235312pst.10779@skylark.parc.xerox.com> Noel, > Anytime an abstraction heirarchy, > guided by non-topological considerations such as geography or administration, > 'aggregates' things which are not topologically related... Sigh. I thought you would have understood that when I talked about "partitioning the Internet into regions" or "chopping up a graph into sub-graphs" that I was referring to topologically-contiguous pieces. YES, the first rule of hierarchical addressing is that each labelled component -- region, sub-region, sub-sub-region, etc. -- be internally connected. UNDER THAT CONSTRAINT, you can use administrative, geographic, or other criteria for choosing addressing boundaries, and I contend that there are good reasons to do so. Consider this example: The internet topology of the Stanford campus can be assigned a unique hierarchical address prefix. (In the Internet, that prefix is currently "36", a Class A network number.) For that to work, the topology must be internally-connected. If there is disconnected piece of Stanford internet somewhere else, like in Monterey, then that piece would get a *different* prefix. The fact that I am using an administrative criterion to place an addressing boundary between Stanford and BARRNET, which are topologically adjacent but under the control of different administrations (at least, in theory :-), does *not* imply that I would assign the same address prefix to other pieces of Stanford that are elsewhere in the Internet. The routing suboptimality that is the consequence of hierarchical addressing/ routing shows up as follows: the path between any two hosts on the Stanford campus is constrained to follow links internal to the campus, which means the routing will not exploit external paths that might be "shorter" under some metric; furthermore, the two hosts may become unreachable from each other as a result of an internal partition, even though there might be an external path between the two. Assuming those shortcomings are actually relevant (i.e., the campus has multiple external connections and some external paths are shorter than internal paths), their importance is far outweighed by the administrative and network management convenience of having a well-known and static addressing and routing boundary between Stanford's assets and BARRNET's assets. > However, to me, "assigning > addresses [creating the abstraction hierarchy, actually] on the basis of > topology" means "consider topological relationships in the actual network > mesh to be of *paramount* inportance in establishing the abstraction > hierarchy". I took your shorthand phrase to mean that you didn't believe > this, as I believe you don't, if you consider administrative or geographic > considerations to be suitable guides for setting up the abstraction > hierarchy. No, you have still misunderstood me, as I hope I have explained above. I do believe that the set of nodes and links labelled by each hierarchical address prefix should be topologically contiguous. However, I am advocating the use of administrative or geographic criteria for determining the boundaries between those contiguous chunks of topology. Using such criteria can yield significant network management benefits that are much more important than achieving the best possible routes with the lowest possible routing overhead. You seem to be advocating a more dynamic choice of addressing boundaries, based on some sort of ill-defined, multi-dimensional optimization of routing costs, some of which, you admit, are uncomputable or unquantifiable. That does not strike me as a very realistic proposal. > If you want to have a single addressing hierarchy, you'll have to > assign a single cost metric to each edge. What shall that metric be? > Unity (i.e., hops)? Delay? Bandwidth? Monetary expense? > Administrative distance? Geographical distance? A function of several > of those (like the "blended" metrics in cisco's IGRP)? Any one of the > preceding? > > I don't agree with your premise, which I think comes from a hop-hop > distributed computation view of routing. No, it has nothing to do with hop-by-hop anything. There is a graph -- a mesh of nodes and links. You said your addressing hierarchy is chosen to minimize Cr + Cn for such a graph. I (apparently falsely) assumed that the minimization was something you intended to compute directly from the graph, since you claimed that hierarchical address assignment should be done strictly "on the basis of topology", which is what the graph is. However, to compute Cn, as you defined it in your earlier message, you would have to at least assign a weight to each link, in order to compute how much each path deviates from optimal. If you assign multiple weights to each link, there is no longer a well-defined optimal path between any two nodes. > I explicitly consider *only* map-distribution non-hop-hop-routed routing > architectures as suitable. In this model, your statement does not make > sense; each edge will have a number of attributes, some being metrics > (delay, throughput, etc), and some being transit policy (accpetable use, > etc); this information will be available when the route computation happens. We are talking about an *address assignment computation*, not a route computation. > All this really is is a restatement of the principle that an optimal > abstraction hierarchy is isomorphic to a particular graph topology; if you > change the second, you have to change the first. I don't think it's particularly useful to talk about a single "optimal abstraction hierarchy" for any given topology, unless you can define "optimal" a lot more concretely and rigorously than you have so far. Steve From owner-big-internet@munnari.oz.au Tue Nov 3 20:57:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13255; Tue, 3 Nov 1992 20:57:54 +1100 (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 AA28579; Tue, 3 Nov 1992 15:08:52 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02048; Mon, 2 Nov 92 23:08:40 -0500 Date: Mon, 2 Nov 92 23:08:40 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211030408.AA02048@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@angband.stanford.edu Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: jnc@ginger.lcs.mit.edu I believe the topology should be driven by geographic reality, and that this is an administrative issue. Don't get me wrong, I'm not necessarily saying this is a bad goal. As switching and transmission delays decrease, until we are dealing primarily with the speed of light, if you want to build a physical network topology that minimizes transmission delays you wind up with one in which you *don't* send traffic from SF to LA via NY! Einstein will always be with us (until BeijingPacketData unveils its new tachyon hub-hub link technology :-)! At that point, using geography to guide the abstraction hierarchy will make more sense, but note that at that point the topology will follow the geography anyway (modulo private networks for geographically distributed entities), so it will all be sort of moot. None of this invalidates my claim that the addressing hierarchy should follow the network topology. Noel From owner-big-internet@munnari.oz.au Tue Nov 3 21:22:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14193; Tue, 3 Nov 1992 21:22:29 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28516; Tue, 3 Nov 1992 15:06:42 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12343>; Mon, 2 Nov 1992 20:06:09 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 2 Nov 1992 20:06:02 -0800 To: Ross Callon Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Mon, 26 Oct 92 13:49:37 PST." <9210262149.AA10826@us1rmc.bb.dec.com> Date: Mon, 2 Nov 1992 20:05:54 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov2.200602pst.10779@skylark.parc.xerox.com> Ross, You wrote: > Also, Steve Deering (author of the geographic proposal) has stated > that geographic addressing is of dubious feasibility with 32 bit > addresses. Could this be fixed (temporarily) by dividing the Internet > into a small number of large areas (much larger than the originally > proposed city codes)? I understand that there are current plans to allocate some blocks of IP addresses to different continents, but the reduction of routing table size achievable by such coarse aggregation is far less than a decimal order of magitude. That seems like a pretty marginal benefit, to me -- might as well just apply more thrust (the massive resources approach). Your later observation is apropos: > Finally, I am concerned that if we turn to geographic addressing but > make the areas too large then we will end up with the same problems > occurring again, but in one or more of the areas. Steve From owner-big-internet@munnari.oz.au Wed Nov 4 01:03:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22496; Wed, 4 Nov 1992 01:05:20 +1100 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10885; Tue, 3 Nov 1992 20:04:59 +1100 (from kre) To: Steve Deering Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Mon, 02 Nov 92 23:52:56 -0800. <92Nov2.235312pst.10779@skylark.parc.xerox.com> Date: Tue, 03 Nov 92 20:04:45 +1100 Message-Id: <19598.720781485@munnari.oz.au> From: Robert Elz I think all this argument/discussion about topological/metro addressing is getting no-where. It seems that everyone agrees, and which I suspect is only rational, that topological addressing is all that can work (scale to the levels that will be needed). The metro addressing plan seems to be no more than some administrative control on what the topology should be. Implementing that then allows addresses to be assigned in slightly different ways, which may aid administrative convenience. If it can be done, I doubt that anyone would regard it as a poor idea - the question is whether the administrative restrictions on topology can possibly work. Personally I suspect not, there will always be providers operating in some city (metro area), with a good customer that likes that provider, and who asks "can you connect my office over there" (some other metro area), and the provider will say "yes" (of course they will, its revenue), and run a ling into the other metro area - but almost certainly won't bother to add extra links to other providers in that area, nor probably even to create tunnels, or similar to make it appear that links exist. Instead the remote site will just be given an address in the metro area where the provider normally operates, and its geographical location will be ignored. If you think this won't happen I believe you're deluding yourself. This doesn't mean that the aim is unworthy - that is, that as much as possible the topologies should be arranged so that local areas are connected internally, and addressing agregation can be performed based on location - but only because the topology follows the geography. kre From owner-Big-Internet@munnari.oz.au Wed Nov 4 02:02:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24468; Wed, 4 Nov 1992 02:02:59 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211031502.24468@munnari.oz.au> Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24455; Wed, 4 Nov 1992 02:02:11 +1100 (from rcraig@cisco.com) Received: from [192.135.250.51] by diablo.cisco.com with SMTP (16.6/16.2) id AA29110; Tue, 3 Nov 92 06:59:34 -0800 Date: Tue, 3 Nov 92 06:59:34 -0800 To: Big-Internet@munnari.oz.au From: rcraig@cisco.com (Robert Craig) X-Sender: rcraig@diablo.cisco.com (Unverified) Subject: Crossroads The immediate problems we are trying to address are the exhaustion of the IP address space and the breakdown of routing protocols in the face of too many networks (problem caused by lack of aggregation). We do not have the luxury of time to implement a new architecture to resolve these problems. Thus, we are forced to deploy a temporary solution while the new architecture is designed and tested. Any temporary solution must support ipv4. It is desirable that a temporary solution require minimum effort to implement. This translates to minimum number of hosts/gateways affected, least effort spent designing and implementing new protocols, least administrative overhead for deployment. The best case is nobody has to change their ip address or software except on their exterior gateway. I've devised a possible solution based on the proposals put forward by Wang & Crowcroft, Callon, Fuller, Li, Yu, & Varadhan, Solensky & Kastenholz, Tsuchiya, Chiappa, Hinden & Crocker, and others. I freely admit that it's a hack, but a hack is what is needed ;->. It does resolve the problems of IP address space exhaustion and routing protocol overload. It does require minimal effort to implement, and its impact is confined to border gateways and a subset of all domain name servers. It involves the creation of a meta-Internet using a form of "address translation". Described simply, routing outside autonomous systems is based on the high-order 32 bits of a 64 bit IP address, composed of a 32 bit autonomous system number and the original 32 bit IP address. At the systems' boundaries are "border" gateways, which handle the translation from 32 bit IP address to 32_bit_AS_#.32_bit_IP_addr. There is *no* network number information outside the system. All routing decisions are based on autonomous system number. Extending the autonomous system number to 32 bits allows it to be treated as an IP network number, so existing routing protocols may be used. Autonomous system numbers will have to be re-allocated to allow for the maximum aggregation at boundaries (ideally, all autonomous systems belonging to a regional should be aggregated into one AS number announcement). Presumably, there are many fewer AS #'s than network numbers (and the only systems that care about AS numbers are routers), so this should be much less painful than reallocating IP network numbers. Within each autonomous system, virtually the entire IP address space is available for use (outside, addresses are qualified by the use of the AS #). Each system becomes responsible for administering the entire IP address space for his customers. A mechanism is required for the resolution of domain names to autonomous system number to support routing by AS number. Extending the DNS to include records for mapping domain name onto autonomous system and border gateway should suffice. Only domain name servers which are considered authoritative for an autonomous system need to support the enhancements. Within the AS, life proceeds just as before. A further mechanism is required to support routing from end systems to border gateways. The end system (or its nearest router) must recognize that the system it is sending to is external, and must forward packets to the border gateway. This is the tricky part... End systems should be kept in the dark to minimize impact. This means that source-routing variants are unacceptable, unless *all* packets are loosely-source-routed via the border gateway (clearly a bad thing). A variation on a theme would have "external" destinations resolve to addresses reserved by the administrators of the AS for use as exterior (i.e., these addresses may not be used within the AS, they are reserved to refer to exterior systems): packets would magically flow to the border gateway through the "default" route mechanism. This approach necessitates keeping a great deal of state in the border gateway concerning which "exterior" address maps to which host session. Multiple border gateways for a single autonomous system would have to synchronize their states, as well. I've written a draft rfc on this proposal, which I will make available if anyone's interested. Robert. ----------------------------------------------------- Robert Craig 1155 boul Rene Levesque ouest cisco Systems 25ieme etage (514) 393-3243 Montreal, Quebec H3B 2K4 From owner-Big-Internet@munnari.oz.au Wed Nov 4 02:44:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25947; Wed, 4 Nov 1992 02:45:00 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211031545.25947@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25943; Wed, 4 Nov 1992 02:44:53 +1100 (from lyman@BBN.COM) Date: Tue, 3 Nov 92 10:40:46 EST From: A. Lyman Chapin To: tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au, tuba@lanl.gov Subject: Re: Protocol Transitions (was Re: concerns about CLNP) >Date: Fri, 23 Oct 92 16:16:34 EDT >From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) >To: desjardi@boa.gsfc.nasa.gov, kasten@ftp.com >Subject: Re: Protocol Transitions (was Re: concerns about CLNP) >Cc: big-internet@munnari.oz.au, tuba@lanl.gov > >> >> While we're at it, let's make sure the new protocol has autoconfigura- >> tion at least as good as CLNP/ES-IS does! That way, address/ID changes >> are no big deal. >> >> Dick >> > >I am under the impression that X3S3.3 has given up the >project to do auto-configuration of NSAP address >prefixes that, in concert with good directory service >management, would have gone a long way towards really >making address/ID changes no big deal........ > >PX Paul, Not at all - the amendments to ISO/IEC 9542 (ES-IS for CLNP) and ISO/IEC 10030 (ES-IS for X.25) for "Dynamic Discovery of OSI NSAP Addresses by End Systems" are alive and well, awaiting ballot as draft amendments ISO/IEC 9542/DAM1 and ISO/IEC 10030/DAM1 respectively. They should complete these final ballots early next year. - Lyman From owner-Big-Internet@munnari.oz.au Wed Nov 4 03:41:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27426; Wed, 4 Nov 1992 03:42:14 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211031642.27426@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27414; Wed, 4 Nov 1992 03:41:03 +1100 (from clynn@BBN.COM) Date: Tue, 3 Nov 92 11:34:11 EST From: Charles Lynn To: Robert Craig Cc: Big-Internet@munnari.oz.au Subject: Re: Crossroads Robert, Your proposal is similar to one I proposed back in July (look in the big-internet archives for Message-Id: <9207162256.10210@munnari.oz.au>), except that it has the same drawback that the other proposals that I have seen have, i.e., how can it be incrementally deployed? If an old packet is changed to use the "new" techniques, how can it be delivered except by a "peer" that recognizes the new technique and convert it back to the old? It appears that one has to start with a network, e.g., a national backbone, and wrap ALL its entrances & exits with modified gateways, then proceed to its attached networks, e.g., the regionals, and convert ALL of its (unconverted) attachment points, etc. Using autonomous system numbers for the "provider attachment point" is one way to manage the high-order 32 bits. The increase in routing table size would only be equal to the number of autonomous systems (my proposal does not increase the routing table size during a transition since the high-order 32 bit addresses are already in the routing tables). I do not agree that "source-routing variants are unacceptable, unless *all* packets are loosely-source-routed via the border gateway (clearly a bad thing)" ;-) Charles Lynn From owner-Big-Internet@munnari.oz.au Wed Nov 4 03:30:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27280; Wed, 4 Nov 1992 03:32:08 +1100 (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 AA27263; Wed, 4 Nov 1992 03:30:57 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04663; Tue, 3 Nov 92 11:30:28 -0500 Date: Tue, 3 Nov 92 11:30:28 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211031630.AA04663@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, rcraig@cisco.com Subject: Re: Crossroads Cc: jnc@ginger.lcs.mit.edu Congratulations! You seem to have reinvented yet another variant of the Network Address Translator (NAT), an idea developed by Paul Tsuchiya and Van Jacobsen. Your variant doesn't exactly match any of the variants I named in the taxonomy of NAT variants I sent to this list some months back, but it appears to be close to the variants I labelled I-NAT or B-NAT, depending on what routing protocol you use. The part you label "the tricky part..." has already been examined in some detail by both Paul and Van, as well as others, and I believe they actually field-tested boxes which did this. NAT schemes of all flavors are currently somewhat out of favor, primarily because they require munging around in all packets flowing through border routers, looking for IP addresses buried in the data. I have predicted that they will make a comeback when we are "up against the wall"; we'll see, I guess. Noel From owner-Big-Internet@munnari.oz.au Wed Nov 4 04:00:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27977; Wed, 4 Nov 1992 04:03:03 +1100 (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 AA27943; Wed, 4 Nov 1992 04:00:35 +1100 (from craig@aland.bbn.com) Received: from port16.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28173; Tue, 3 Nov 92 11:59:53 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA25255; Tue, 3 Nov 92 08:58:37 PST Message-Id: <9211031658.AA25255@aland.bbn.com> To: Ross Callon Cc: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Subject: re: re: Vote NO on R-L-G IP Address Allocation proposal From: Craig Partridge Date: Tue, 03 Nov 92 08:58:36 -0800 Sender: craig@aland.bbn.com > You are assuming that changing addresses *needs* to be difficult. > ... > Thus, your points make sense when applied to the current IP, but > if they make sense when applied to a new IP, then we have defined > the new IP very badly. Ross: Just because I think CLNP is wrong for IPv7 doesn't mean I'm an idiot.(:-)) I haven't said anything suggesting that changing addresses will be hard in IPv7, and indeed, I firmly hope changing address is easy in IPv7. > PS: Why is this discussion on the IETF mailing list? Shouldn't > we move this to Big-Internet? It was on IETF because the call to stop RLG was on the IETF list (as it should have been). But I've replied to big-interent. From owner-Big-Internet@munnari.oz.au Wed Nov 4 06:01:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00278; Wed, 4 Nov 1992 06:04:09 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00239; Wed, 4 Nov 1992 06:01:32 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12509>; Tue, 3 Nov 1992 11:01:11 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 3 Nov 1992 11:01:09 -0800 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Tue, 03 Nov 92 01:04:45 PST." <19598.720781485@munnari.oz.au> Date: Tue, 3 Nov 1992 11:00:56 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov3.110109pst.10779@skylark.parc.xerox.com> Noel wrote: > None of this invalidates my claim that the addressing hierarchy should > follow the network topology. I don't think anyone here is disputing that claim. (Some proposals, such as my metro-based scheme, do impose constraints on the topology so that your desired property can be satisfied.) Robert wrote: > It seems that everyone agrees, and which I suspect is only > rational, that topological addressing is all that can work > (scale to the levels that will be needed). What exactly do you mean by "topological addressing", and in what ways are the various proposals for provider-based addressing or metro-based addressing *not* "topological addressing"? > If it [metro addressing plan] can be done, I doubt that anyone would > regard it as a poor idea - the question is whether the administrative > restrictions on topology can possibly work. > > Personally I suspect not, there will always be providers > operating in some city (metro area), with a good customer > that likes that provider, and who asks "can you connect > my office over there" (some other metro area), and the provider > will say "yes" (of course they will, its revenue), and run > a ling into the other metro area - but almost certainly won't > bother to add extra links to other providers in that area, > nor probably even to create tunnels, or similar to make it > appear that links exist. Instead the remote site will just > be given an address in the metro area where the provider > normally operates, and its geographical location will be > ignored. Certainly. In my City Code draft, I said that a site's addresses would identify the city of the provider attachment -- that's what the global routing needs to know; the site itself may be anywhere. (Another example is an organization with a large, geographically-dispersed, internal internet that connects to the public Internet in only one city. All of that organization's computers would have addresses "belonging to" the city where the public connection is, regardless of the physical locations of the computers themselves.) The scenario you described works fine. The customer would have to decide if the value of sticking with that particular provider outweighs the potential cost of changing addresses, if the customer should later decide to connect the remote office to a provider in the office's own metro area. I've said this before, but it bears repeating: the *only* reason for doing metro-based addressing is to improve the scalability of the global routing in a way that does not require sites to change their internet addresses in the (expected) *most common* case of provider switching, that is, the case of a single-site organization or household switching to a different provider in the same metropolitan area. Metro-based addressing does *not* eliminate *all* cases of having to change addresses, and it is encumbered by all sorts of economic, logistical, and even regulatory concerns that do not arise in a pure provider-based hierarchy. A technical solution that allows address changes to to occur painlessly and automatically would certainly be preferred, if such a solution can be devised. If the CLNP folks have a solution, I would love to hear an explanation of it. In particular, I'd like to know: - how frequently can a site change providers, and is it necessary to keep an attachment to the old provider for some transition period after attaching to the new provider (i.e., is there a period of time during which I have to pay two providers and, if so, how long is that period)? - what happens to connections or sessions that are established at the time of the switch-over? - if a host learns that it has a new address prefix, how does it know if it is a *replacement* prefix (because of a change of provider) or an *additional* prefix (because of the addition of a second provider for the site)? If a host has multiple prefixes (due to a transition period between one provider and another, or due to the availability of multiple providers), how does it decide which of those prefixes to use in the source address field of any packets it sends? - do the site's interior routers need to be manually reconfigured when there is a change of addresses? - is the Directory automatically updated to reflect changes of address? If so, how? Is there a period of time during which the directory may contain obsolete addresses, and if so, what happens when someone sends packets to those addresses? I suspect that many of these questions are answered in various ANSI drafts and documents from Ross that I have not yet had time to hunt down and read. Perhaps Ross or someone else could give us a condensed description of the CLNP autoconfiguration scheme, enough to convince us that it is, in fact, feasible to make address changes automatic and painless. I'd be quite happy to relegate metro-based addressing to the ash heap of history, if I can be so convinced. Steve From owner-big-internet@munnari.oz.au Wed Nov 4 06:17:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00621; Wed, 4 Nov 1992 06:22:12 +1100 (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 AA28884; Wed, 4 Nov 1992 04:56:13 +1100 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA10518; Tue, 3 Nov 92 09:55:28 -0800 Received: by us1rmc.bb.dec.com; id AA17011; Tue, 3 Nov 92 12:52:57 -0500 Message-Id: <9211031752.AA17011@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Tue, 3 Nov 92 12:52:58 EST Date: Tue, 3 Nov 92 12:52:58 EST From: Ross Callon To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Apparently-To: craig@aland.bbn.com, big-internet@munnari.oz.au Subject: re: changing addresses (was re: Vote NO on R-L-G .....) >> You are assuming that changing addresses *needs* to be difficult. >> ... >> Thus, your points make sense when applied to the current IP, but >> if they make sense when applied to a new IP, then we have defined >> the new IP very badly. > > Just because I think CLNP is wrong for IPv7 doesn't mean I'm an > idiot.(:-)) I haven't said anything suggesting that changing addresses > will be hard in IPv7, and indeed, I firmly hope changing address is easy > in IPv7. Does this mean that your comment about changing addresses being a non-starter was only meant to apply to the current IP? Ross From owner-Big-Internet@munnari.oz.au Wed Nov 4 06:23:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00648; Wed, 4 Nov 1992 06:24:24 +1100 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00635; Wed, 4 Nov 1992 06:23:14 +1100 (from minshall@wc.novell.com) Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AB20206; Tue, 3 Nov 92 11:21:59 PPE Date: Tue, 3 Nov 92 11:21:59 PPE Message-Id: <9211031821.AB20206@wc.novell.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa), Steve Deering From: minshall@wc.novell.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au OK, i'm a little lost here. Steve says "hey, i want to assign addresses which conform to topology, but i just want to use geography as the means to decide how to slice up the topology". On the other hand, Steve says "well, maybe there might be tunnels if two providers in a given metro don't have any intra-metro interconnection". So, that confuses me just a bit, but maybe this is the exception that proves the rule (?). Then, Noel and Steve sort of bash it out. But, it seems to me that what Steve is proposing is that, viewed from a sufficient distance, "geographic" == "topology", but that up close (like in the metro itself), "geographic" == "approximately random". Which is to say, to me, like subnets. I think the randomness is OK in a (small enough) locale. On the other hand, since Steve hasn't explicitly said "yeah, well within the metro, topology gets tossed out the window with the bathwater", i think maybe i don't understand. Which is to say, my impression of Steve's plan (this *has* to be Steve's plan, right?), out of one provider's CO will be lines connecting to customers with addresses like A.1, A.4, A.5, A.8, ...; while out of a different provider's CO will be lines connecting to customers with addresses like A.2, A.3, A.16, etc. Thus, within the metro, you've lost the topological significance of that metro's addresses. The metro plan makes sense to me as a way of decoupling providers from "addresses". Even when Ross says that systems should reconfigure their addresses, i think "well, then at the least you probably are going to have to, in practice, restart all your systems when you change providers", and it is getting harder and harder these days to even *FIND*, let alone restart, all the systems that are IP hosts. (Note, also, that the VERY important thing Ross points out is the need to accept both the old and the new addresses for some relatively lengthy period of time while the globally distributed DNS sorts itself out.) Greg Minshall From owner-big-internet@munnari.oz.au Wed Nov 4 06:27:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00813; Wed, 4 Nov 1992 06:32:25 +1100 (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 AB29041; Wed, 4 Nov 1992 05:04:47 +1100 (from craig@aland.bbn.com) Received: from port16.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA03902; Tue, 3 Nov 92 13:04:15 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA25686; Tue, 3 Nov 92 10:02:42 PST Message-Id: <9211031802.AA25686@aland.bbn.com> To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: changing addresses (was re: Vote NO on R-L-G .....) In-Reply-To: Your message of Tue, 03 Nov 92 12:52:58 -0500. <9211031752.AA17011@us1rmc.bb.dec.com> From: Craig Partridge Date: Tue, 03 Nov 92 10:02:42 -0800 Sender: craig@aland.bbn.com > Does this mean that your comment about changing addresses being a > non-starter was only meant to apply to the current IP? Absolutely -- the comment was in the context of a proposal to use the RLG scheme in IPv4. Craig From owner-big-internet@munnari.oz.au Wed Nov 4 13:27:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10681; Wed, 4 Nov 1992 13:30:16 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02979; Wed, 4 Nov 1992 08:23:52 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Tue, 3 Nov 92 16:23:29 EST Received: by chiya.bellcore.com (4.1/4.7) id for rcraig@cisco.com; Tue, 3 Nov 92 16:23:28 EST Date: Tue, 3 Nov 92 16:23:28 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9211032123.AA23888@chiya.bellcore.com> To: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, rcraig@cisco.com Subject: Re: Crossroads > NAT schemes of all flavors are currently somewhat out of favor, > primarily because they require munging around in all packets flowing through > border routers, looking for IP addresses buried in the data. I have predicted > that they will make a comeback when we are "up against the wall"; we'll see, > I guess. > > Noel Yes, I have made this prediction also, tho privately I guess..... PX ps. Well, Noel. That's twice that we have agreed, although the first time was just an agreement to disagree...... From owner-big-internet@munnari.oz.au Wed Nov 4 19:40:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24808; Wed, 4 Nov 1992 19:40:44 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28307; Wed, 4 Nov 1992 04:22:06 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12442>; Tue, 3 Nov 1992 09:21:25 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 3 Nov 1992 09:21:18 -0800 To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Tue, 03 Nov 92 08:10:55 PST." <9211031610.AA00837@goshawk.lanl.gov> Date: Tue, 3 Nov 1992 09:21:16 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov3.092118pst.10779@skylark.parc.xerox.com> Peter, > While a decimal order of magnitude may not seem like much to you, the > facts are that there are very few networks which are suffering any > real problems in terms of routing table size. For them, a shrinkage of > table size (by even a factor of two) is a big deal. A shrinkage of > a decimal order of magnitude is fantastic. Assuming the > network is doubling every 12 months an order of decimal magnitude > decrease translates into 3 years. I said that aggregation by continent would yield far *less* than an order of magnitude reduction. For example, the routing tables in the North American backbones would shrink by less than a factor of two if you removed all of the non-North American entries. I think you want to achieve *at least* a factor of ten reduction, so that you can get your three years of breathing room. And that still leaves the problem of another renumbering three years from now. > I suspect one reason many people have trouble thinking about > geographic addressing using IP is that they are concerned about > finding some fixed width, fixed position field for putting in > the geographic tag. I agree that this is a lose. But then again, > we do have masks, so we don't have to be stuck with fixed fieldism. I understand and heartily agree with that. > There also seems to be an extreme focus on optimality. Why would the > routing system care if there were two prefixes for London or three for > San Francisco? If we blow the initial prefix for some area, perhaps > too large or too small, it can be split (especially if the assignments > within that prefix were made with some order (geography) in mind ) or > add another prefix to accomodate more end systems for that geographic patch. I understand that, too. However, note that you will have to assign a significantly larger block of addresses to an area than would otherwise be necessary, if "assignments within that prefix [are to be made] with some order (geography) in mind". That means you need a bigger address space than IP's in order to do that type of assignment, I think. > Plans which allocate the same amount of address space to each of the > continents seem silly to me. Yes, but long-term plans that allocate address space based only on the short-term needs of each of the continents are also silly (doomed to either significant entropy or frequent renumbering) -- think of the day when every household in China and India has an IP LAN. If your proposal for geographic IP addresses is only intended as a short-term scheme to hold us until a new packet format with bigger addresses can be deployed, fine. But the following paragraph leads me to suspect otherwise: > As to the utility of geographic addressing in the IP world one > might ask: if we had been using geographic addressing, and a > routing system exploiting it, since 1987, would we be discussing a > change in packet formats or would we be discussing "what is policy". If > the answer is that there is utility in geography, then one should also > remember that there is an unassigned block of over 1 billion IP > addresses out there. 1 billion is not enough to handle the worst (best?) case forecast for the Internet. (But why am I arguing with you? You are one of the few people who actually *agrees* with me on the value of geographic addressing!) Steve From owner-big-internet@munnari.oz.au Wed Nov 4 19:52:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25290; Wed, 4 Nov 1992 19:52:04 +1100 (from owner-big-internet) Return-Path: Received: from enlil.premenos.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02895; Wed, 4 Nov 1992 08:19:19 +1100 (from mark@enlil.premenos.sf.ca.us) Received: by enlil.premenos.sf.ca.us (AIX 3.2/UCB 5.64/4.03) id AA59441; Tue, 3 Nov 1992 13:15:26 -0800 Date: Tue, 3 Nov 1992 13:15:26 -0800 From: mark@enlil.premenos.sf.ca.us (Mark Grand) Message-Id: <9211032115.AA59441@enlil.premenos.sf.ca.us> To: big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Tue, 03 Nov 92 20:04:45 +1100 <19598.720781485@munnari.oz.au> Subject: Vote NO on R-L-G IP Address Allocation proposal Restricting the topology of an addressing scheme to being geographical will cause a confusion because there are a number of situations in which it does not quite fit. I know of a company that is planning a private network the will have nodes in a number of geographically distant locations. For a variety of reasons it is intended that most of these locations will not have a direct gateway to the internet. >From an administrative standpoint it would be desirable to have the addresses given out by the company that owns the net. Since there will be multiple gateways to the internet located in different cities, it is unclear how addresses would be assigned. Also, geographically based addressing presents some challanges for mobile hosts. ================ Mark Grand Premenos Corporation 510-602-2000 x2073 1000 Burnett, Second Floor mark@premenos.sf.ca.us Concord, CA 94520 From owner-big-internet@munnari.oz.au Wed Nov 4 19:51:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25274; Wed, 4 Nov 1992 19:51:54 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28099; Wed, 4 Nov 1992 04:11:38 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA13694; Tue, 3 Nov 92 10:11:32 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA01547; Tue, 3 Nov 92 10:11:31 MST Message-Id: <9211031711.AA01547@goshawk.lanl.gov> To: Robert Elz Cc: Steve Deering , jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Tue, 03 Nov 92 20:04:45 +1100. <19598.720781485@munnari.oz.au> Date: Tue, 03 Nov 92 10:11:30 MST From: peter@goshawk.lanl.gov Robert, I don't believe in mandating a fixed addressing scheme where everyone has to have geographic addresses. (it is a little too late for that!) We are stuck with provider based addressing and flat addressing for now. However, there is utility to network service providers in using a geographic addressing and routing scheme. I believe this is the direction the Internet should be heading, and that we will accomodate the three methods of addressing (flat, provider and geographic), in the interim as we transition to geographic. Let's look at your case, the renegade operator who makes Perth Computer Company look like it is in Canberra. That operator will pull the line for a couple of reasons, one is to please the customer at hand; in addition it might be to draw infrastructure out to Perth to create more business opportunities, including the ability to draw other customers in the Perth area and to provide transit between the two geographic areas. It seems to me that agreeing to use geographic addressing is in the providers best interest since it eases switching and he can optionally use his own infrastructure to get to Perth. Worst case here is that the Perth Computer Company looks like it is in Canberra and the operator carries a long prefix for it internally and carries a short prefix for the connectivity to the rest of Perth. (One could imagine companies in the middle of nowhere wanting that exclusive Silicon Valley or Route 128 address and paying a provider to carry traffic as if you were located in Sunnyvale or Boston.) Given that the top level addressing proposed is continental we are already driving the system towards geographic addressing. We might as well do it right and finish the job. cheers, peter From owner-big-internet@munnari.oz.au Wed Nov 4 20:21:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26498; Wed, 4 Nov 1992 20:21:54 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09680; Wed, 4 Nov 1992 12:55:56 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12636>; Tue, 3 Nov 1992 17:55:16 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 3 Nov 1992 17:55:12 -0800 To: minshall@wc.novell.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Tue, 03 Nov 92 03:21:59 PST." <9211031821.AB20206@wc.novell.com> Date: Tue, 3 Nov 1992 17:55:11 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov3.175512pst.10779@skylark.parc.xerox.com> Greg, > Steve says "hey, i want to assign addresses which conform to topology, but > i just want to use geography as the means to decide how to slice up the > topology". On the other hand, Steve says "well, maybe there might be > tunnels if two providers in a given metro don't have any intra-metro > interconnection". So, that confuses me just a bit, but maybe this is the > exception that proves the rule (?). The tunnels are used to turn two or more disconnected pieces of topology into a connected piece of topology. For metro-based addressing and routing, the topology identified by a particular metro prefix must be connected, so that, from the point of view of routers outside the metro, any of the metro boundary routers works as well as any other, for reaching any destination address within the metro. The tunnels play the same role as the tunnels in the Columbia mobile IP scheme, where they are used to connect a tiny piece of a subnet's address space (the roaming host) back to the rest of the subnet's topology (at the home base). For metro-based routing, I would expect tunnels to be the exception, rather than the rule, because tunneling is ugly and inefficient, and because providers will be able to offer better service (lower latency and probably higher bandwidth) if they connect to their competitors within the same metro area, instead of using expensive long-haul links that pass through other metro areas. Does that clear up your confusion at all? > On the other hand, since Steve hasn't explicitly said "yeah, well within > the metro, topology gets tossed out the window with the bathwater", i think > maybe i don't understand. Which is to say, my impression of Steve's plan > (this *has* to be Steve's plan, right?), out of one provider's CO will be > lines connecting to customers with addresses like A.1, A.4, A.5, A.8, ...; > while out of a different provider's CO will be lines connecting to > customers with addresses like A.2, A.3, A.16, etc. Your impression is correct. Routing to individual sites within a metro is flat, the same way that: - routing to individual countries is flat, within the global internet - routing to individual cities is flat, within a country - routing to individual subnets is flat, within a site - routing to individual hosts is flat, within a subnet > Thus, within the metro, you've lost the topological significance of that > metro's addresses. Once you get into the metro, you route on the next-lower component of the address, which is the site identifier. I explicitly do *not* treat provider boundaries within a metro as addressing boundaries, in order that addresses may be portable from one provider to another. Yes, I realize that the number of internet sites in a metropolitan area may someday reach millions, but I claim that by the time that happens (if not already) it will be feasible and affordable to do flat routing to millions of geographically proximate sites, and to do it with facilities belonging to multiple, competing providers. Steve From owner-big-internet@munnari.oz.au Wed Nov 4 20:50:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27553; Wed, 4 Nov 1992 20:51:08 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10552; Wed, 4 Nov 1992 13:26:44 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12647>; Tue, 3 Nov 1992 18:26:08 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 3 Nov 1992 18:26:00 -0800 To: mark@enlil.premenos.sf.ca.us (Mark Grand) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Tue, 03 Nov 92 12:53:53 PST." <9211032053.AA50499@enlil.premenos.sf.ca.us> Date: Tue, 3 Nov 1992 18:25:59 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov3.182600pst.10779@skylark.parc.xerox.com> Mark Grand wrote: > Restricting the topology of an addressing scheme to being geographical > will cause a confusion because there are a number of situations in > which it does not quite fit. I know of a company that is planning a > private network the will have nodes in a number of geographically > distant locations. For a variety of reasons it is intended that most > of these locations will not have a direct gateway to the internet. > From an administrative standpoint it would be desirable to have the > addresses given out by the company that owns the net. Since there > will be multiple gateways to the internet located in different cities, > it is unclear how addresses would be assigned. Yes, this is a scenario in which neither the metro-based addressing nor the provider-based addressing scheme is ideal. Under metro-based addressing, the company that owns the network would obtain blocks of addresses from each of the metro areas in which it *is* connected to the Internet, which the company would then dole out to its internal subnets and hosts. There are several ways of doing that assignment, with varying degress of sensitivity to the geographic information in the addresses, but I regret that I don't have time to go into it now. (Ask Ross -- he's much better at explaining this stuff than me!) > Also, geographically based addressing presents some challanges for > mobile hosts. Metro-based addressing can be used just fine to route a packet to the point where a mobile host, or a mobile subnet, is attached (whether by wire or wirelessly) to the non-mobile topology. Steve From owner-big-internet@munnari.oz.au Wed Nov 4 21:13:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28224; Wed, 4 Nov 1992 21:13:18 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26829; Wed, 4 Nov 1992 03:11:19 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11696; Tue, 3 Nov 92 09:10:56 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA00837; Tue, 3 Nov 92 09:10:55 MST Message-Id: <9211031610.AA00837@goshawk.lanl.gov> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Mon, 02 Nov 92 20:05:54 -0800. <92Nov2.200602pst.10779@skylark.parc.xerox.com> Date: Tue, 03 Nov 92 09:10:55 MST From: peter@goshawk.lanl.gov Steve, Ross and Scott, While a decimal order of magnitude may not seem like much to you, the facts are that there are very few networks which are suffering any real problems in terms of routing table size. For them, a shrinkage of table size (by even a factor of two) is a big deal. A shrinkage of a decimal order of magnitude is fantastic. Assuming the network is doubling every 12 months an order of decimal magnitude decrease translates into 3 years. This can make differences in investment in equipment, engineering costs to work around routers that are too small, and hassles in assigning addresses. The more thrust notion is sounds great, except I don't see any router vendors jumping up and down and saying: yes we will have your wiz band special routers available for you RSN and we can give you great pricing on that massive order of 20 units. Most network providers will be happy to simply see BGP-4 get out the door from many of these vendors and that is simply a matter of programming :-). The best thing about routing in a geographic system is with enough zones, you push the complexity of the system (interconnections, routing, number of systems) down to the leaf end of the system where good scaling properties are possible and *cost effective*. I suspect one reason many people have trouble thinking about geographic addressing using IP is that they are concerned about finding some fixed width, fixed position field for putting in the geographic tag. I agree that this is a lose. But then again, we do have masks, so we don't have to be stuck with fixed fieldism. It is an unnecessary assumption for each sub-topology or geographic area to be the same size in terms of number of IP addresses. Fairness in allocation of addresses should be made along line of what is needed to route the system. Plans which allocate the same amount of address space to each of the continents seem silly to me. There also seems to be an extreme focus on optimality. Why would the routing system care if there were two prefixes for London or three for San Francisco? If we blow the initial prefix for some area, perhaps too large or too small, it can be split (especially if the assignments within that prefix were made with some order (geography) in mind ) or add another prefix to accomodate more end systems for that geographic patch. As to the utility of geographic addressing in the IP world one might ask: if we had been using geographic addressing, and a routing system exploiting it, since 1987, would we be discussing a change in packet formats or would we be discussing "what is policy". If the answer is that there is utility in geography, then one should also remember that there is an unassigned block of over 1 billion IP addresses out there. cheers, peter From owner-big-internet@munnari.oz.au Wed Nov 4 21:22:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28502; Wed, 4 Nov 1992 21:22:42 +1100 (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 AA02734; Wed, 4 Nov 1992 08:07:08 +1100 (from craig@aland.bbn.com) Received: from port16.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA20464; Tue, 3 Nov 92 16:05:57 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA26996; Tue, 3 Nov 92 13:04:38 PST Message-Id: <9211032104.AA26996@aland.bbn.com> To: big-internet@munnari.oz.au Subject: revised criteria list Reply-To: Craig Partridge From: Craig Partridge Date: Tue, 03 Nov 92 13:04:38 -0800 Sender: craig@aland.bbn.com Hi folks: Frank Kastenholz volunteered to help me knock my original e-mail note into a real Internet Draft and we think we've tightened up and improved the list. Thanks to many of you for your helpful comments! The official ID should be out tomorrow or Thursday but given that some folks are preparing support papers for the various proposals based on this list, here's what we sent to the IETF Secretariat. Craig E-mail: craig@aland.bbn.com or craig@bbn.com ============================================================================ INTERNET DRAFT Criteria for Choosing IP Version 7 (IPv7) 3 November 1992 Craig Partridge BBN Systems and Technologies Frank Kastenholz FTP Software, Inc 2 High Street North Andover, Mass 01845-2620 USA kasten@ftp.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or Internet Draft IPv7 Criteria November 1992 munnari.oz.au to learn the current status of any Internet Draft. This is a working document only, it should neither be cited nor quoted in any formal document. This document will expire before 8 May 1993. Distribution of this document is unlimited. Please send comments to the author(s). Partridge & Kastenholz Exp. 8 May 1993 [Page 1] Internet Draft IPv7 Criteria November 1992 1. Introduction This note attempts to codify and organize the criteria to be used in evaluating the protocols being proposed for adoption as IP Version 7. The criteria presented are culled from several sources, including "IP Version 7" [1], "IESG Deliberations on Routing and Addressing" [2], "Towards the Future Internet Architecture" [3], and the ongoing discussions held on the Big-Internet mailing list and the mailing lists devoted to the individual IPv7 efforts. Partridge & Kastenholz Exp. 8 May 1993 [Page 2] Internet Draft IPv7 Criteria November 1992 2. Goals The criteria are presented as an ordered list. We believe that by ordering priorities, it becomes easier to evaluate the various proposals and determining each proposal's relative strengths and weaknesses. Such a mechanism has proven valuable in past efforts; see [4]. We have attempted to state the criteria in the form of goals or requirements and not demand specific engineering solutions. In determining the relative order of the various criteria, we have had two guiding principles. First, IPv7 must offer an internetwork service akin to that of IPv4, but improved to handle the well-known and widely-understood problems of scaling the Internet architecture to more end-points and an ever increasing range of bandwidths. Second, it must be desirable for users and network managers to upgrade their equipment to support IPv7. At minimum, this second point implies that there must be a straightforward way to transition systems from IPv4 to IPv7. But it also strongly suggests that IPv7 should offer features that IPv4 does not; new features provide a motivation to deploy IPv7 more quickly. Partridge & Kastenholz Exp. 8 May 1993 [Page 3] Internet Draft IPv7 Criteria November 1992 3. Note on Terminology The existing proposals currently tend distinguish between end- point identification of, e.g., individual hosts, and topological addresses of network attachment points. In this note we do not make that distinction. We use the term "Address" as it is currently used in IPv4; i.e., for both the identification of a particular endpoint or host AND as the topological address of a point on the network. We presume that if the endpoint/address split remains, the proposals will make the proper distinctions with respect to the criteria enumerated below. Partridge & Kastenholz Exp. 8 May 1993 [Page 4] Internet Draft IPv7 Criteria November 1992 4. Protocol Criteria This section enumerates the criteria against which the IP Version 7 proposals will be evaluated. This is an ordered enumeration. Each criterion is presented in its own section. The first paragraph of each section is a simple, one or two sentence statement of the criterion. Additional paragraphs then explain the criterion in more detail, clarify what it does and does not say and provide some justification for its position in the list. 4.1. Scale CRITERION The IPv7 Protocol must scale to allow the identification and addressing of 10**11 end systems. The IPv7 Protocol, and its associated routing protocols and architecture must allow for up to 10**9 individual networks. The routing schemes must scale with the number of constituent networks at a rate that is much less than linear. DISCUSSION The whole purpose of the IPv7 effort is to allow the Internet to grow beyond the size constraints imposed by the current IPv4 addressing and routing technologies. Both aspects of scaling are important. If we can't route then connecting all these hosts is worthless, but without connected hosts, there's no point in routing, so we must scale in both directions. Particular attention in any proposal should be paid to describing the routing hierarchy, how the routing and addressing will be organized, how different layers of the routing interact, and relationship between addressing and routing. Placement This criteria is the essential problem motivating the transition to IPv7. If the proposed protocol does not satisfy this criteria, there is no point in considering Partridge & Kastenholz Exp. 8 May 1993 [Page 5] Internet Draft IPv7 Criteria November 1992 it. 4.2. Robust Service CRITERION The network service should be robust. DISCUSSION Murphy's Law applies to networking. Any IPv7 proposal must be well-behaved in the face of malformed packets, mis-information, and occasional failures of links, routers and hosts. IPv7 should perform gracefully in response to willful management and configuration mistakes (i.e. service outages should be minimized). Putting this requirement another way, IPv7 must make it possible to continue the Internet tradition of being conservative in what is sent, but liberal in what one is willing to receive. Placement If the protocol is not robust, no one will want to transition to it. So this criteria comes above ease of transition. 4.3. Transition CRITERION The protocol must have a straightforward transition plan from the current IPv4. DISCUSSION A smooth, orderly, transition from IPv4 to IPv7 is needed. If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it. We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Partridge & Kastenholz Exp. 8 May 1993 [Page 6] Internet Draft IPv7 Criteria November 1992 Rather IPv7 will need to co-exist with IPv4 for some period of time. This may imply that hosts and routers may need to be able to support both IPv4 and IPv7 simultaneously. There may also be single protocol (i.e. IPv4-only and IPv7-only) hosts on the network. If IPv4 and IPv7 are not interoperable, then the need for and use of protocol- translating gateways to enable such hosts to communicate should be examined. In any case, the difficulty of running a network that is transitioning from IPv4 to IPv7 must be minimized. (A good target is that running a mixed IPv4-IPv7 network should be no more and preferably less difficult than running IPv4 in parallel with existing non-IP protocols). Furthermore, a network in transition must still be robust. IPv7 schemes which maximize stability and connectivity in mixed IPv4-IPv7 networks are preferred. The transition plan must address the following general areas of the Internet's infrastructure: + Host Protocols and Software + Router Protocols and Software + Security and Authentication + Domain Name System + Network Management + Operations Tools (e.g., Ping and Traceroute) + Operations and Administration procedures The impact on protocols which use IP addresses as data (e.g. DNS, SNMP and FTP) must be specifically addressed. Placement If the transition scheme is painful, no one will transition. But we should only transition if the protocol we transition to solves the scaling problems and is useful to use. Partridge & Kastenholz Exp. 8 May 1993 [Page 7] Internet Draft IPv7 Criteria November 1992 4.4. Media CRITERION The protocol must work across an internetwork of many differnet LAN, MAN, and WAN media, with individual link speeds ranging from a kilobit per second to hundreds of gigabits per second. Multiple-access and point-to-point media must be supported, as must both media supporting switched and permanent circuits. DISCUSSION The joy of IP is that it works over just about anything. That ease of adding new technologies, and continuing to operate with old technologies must be maintained. We believe this range of speed is right for the next twenty years, though it may be we should say terabits at the high-end. By switched circuits we mean both "permanent" connections such as X.25 and Frame Relay services AND "temporary" types of dialup connections similar to today's SLIP and dialup PPP services. The latter form connection implies that dynamic network access (i.e., the ability to unplug a machine, move it to a different point on the network topology, and plug it back in, possibly with a changed IPv7 address) is required. By work, we mean we have hopes that a stream of IPv7 datagrams (whether from one source, or many) can come close to filling the link at high speeds, but also scales gracefully to low speeds. Placement We might accept a less flexible protocol if it solves the addressing and routing problems and we can transition to it. But those goals having been achieved, we need to make sure the protocol is general. 4.5. Unreliable Datagram Service CRITERION The protocol must support an unreliable datagram delivery service. Partridge & Kastenholz Exp. 8 May 1993 [Page 8] Internet Draft IPv7 Criteria November 1992 DISCUSSION We like IP's datagram service and it seems to work very well. So we should keep it. Placement Datagram service matters less than being able to get the data from here to there over different media. 4.6. Addressing CRITERION The protocol must allow for both unicast and multicast addressing. Part of the multicast capability is a requirement to be able to send to "all IP hosts on THIS network". DISCUSSION IPv4 has made heavy use of the ability to multicast requests to all IPv4 hosts on a subnet, especially for autoconfiguration. This ability must be retained in IPv7. Unfortunately, IPv4 currently uses the local media broadcast address to multicast to all IP hosts. This behavior is anti-social in mixed-protocol networks and should be fixed in IPv7. There's no good reason for IPv7 to send to all hosts on a subnet when it only wishes to send to all IPv7 hosts. The protocol must make allowances for media that do not support true multicasting. In the past few years, we have begun to deploy support for wide-area multicast addressing in the Internet, and it has proved valuable. This capability should not be lost in the transition to IPv7. The ability to restrict the range of a broadcast or multicast to specific networks is also important. Placement Multicast addressing is clearly less important than being able to get the data to all end-systems, with the kind of service we prefer. But multicasting is an essential Partridge & Kastenholz Exp. 8 May 1993 [Page 9] Internet Draft IPv7 Criteria November 1992 service, and thus has priority over ease of configuration and cost recovery. 4.7. Configuration, Administration, and Operation CRITERION The protocol must permit easy and largely distributed configuration and operation. Automatic configuration is required. DISCUSSION People complain that IP is hard to manage. We cannot plug and play. We should fix that problem. We do note that fully automated configuration, especially for large, complex networks, is still a topic of research. Our concern is mostly for small and medium sized, less complex, networks; places where the essential knowledge and skills would not be as readily available. In dealing with this criterion, address assignment and delegation procedures and restrictions should be addressed by the proposal. Furthermore, "ownership" of addresses (e.g. user or service provider) has recently become a concern and the issue should be addressed. Placement The previous criteria all deal with essential functions of the protocol itself, without which the protocol would be useless. Thus, this criterion is placed after these functions. 4.8. Accounting CRITERION The protocol must support some means for cost recovery. DISCUSSION Commercial providers need to be able to puzzle out some way to charge for services. Charging based on leased- line capacity as most IP providers do today, is acceptable. Partridge & Kastenholz Exp. 8 May 1993 [Page 10] Internet Draft IPv7 Criteria November 1992 This point does not say that the protocol must support billing or per-packet accounting. It simply says that any design for IPv7 should keep in mind that there are commercial IP providers who have to be able to charge for IP service. Placement If we don't have the right services and if we can not actually configure and operate the protocol, billing for use of the network isn't useful, so this goes below the previous criteria. 4.9. Extensibility CRITERION The protocol must be extensible; it must be able to evolve to meet the future service needs of the Internet. This evolution must be achievable without requiring network-wide software upgrades. DISCUSSION We do not today know all of the things that we will want the Internet to be able to do 10 years from now. At the same time, it is not reasonable to ask users to transition to a new protocol with each passing decade. Thus, we believe that it must be possible to extend IPv7 to support new services and facilities. Furthermore, it is essential that any extensions can be incrementally deployed to only those systems which desire to use them. Systems upgraded in this fashion must still be able to communicate with systems which have not been so upgraded. Placement This criterion is primarily concerned with future developments in internetworking technology. The preceeding criteria all deal with current pressing issues. We must address our current problems before we start dealing with tomorrow's; therefore, this criterion is placed after the preceeding criteria. This criterion also is a more general case of the following criterion, in that if extensibility is provided, then the technological advances discussed in Partridge & Kastenholz Exp. 8 May 1993 [Page 11] Internet Draft IPv7 Criteria November 1992 the following criteria can presumably be provided for. Partridge & Kastenholz Exp. 8 May 1993 [Page 12] Internet Draft IPv7 Criteria November 1992 At this point we make a significant break. We go from what we believe to be essential criteria that IPv7 must meet, to strongly desired items. 4.10. Support for Guaranteed Flows CRITERION The protocol should support guaranteed flows. DISCUSSION Multimedia is now on our desktop and will be an essential part of future networking. So we have to find ways to support it; and a failure to support it may mean users choose to use protocols other than IPv7. The IETF multicasts have shown that we can currently support multimedia over internetworks with some hitches. If we can achieve the needed support for guaranteed flows in IPv7, we will dramatically increase its success. Placement At worst, we can consider adding support for guaranteed flows as an extension, so it falls after extensibility. 4.11. Support for Mobility CRITERION The protocol should support mobile hosts. DISCUSSION Again, mobility is becoming increasingly important. Look at the portables that everyone is carrying. Note the strength of the Apple commercial showing someone automatically connecting up her Powerbook to her computer back in the office. There have been a number of pilot projects showing ways to support mobility in IPv4. All have some drawbacks. But like guaranteed flows, if we can support mobility, IPv7 will have features that will encourage transition. Placement We suspect that conferencing and multimedia support from Partridge & Kastenholz Exp. 8 May 1993 [Page 13] Internet Draft IPv7 Criteria November 1992 one's regular office computer is more important than mobility. 4.12. Allow Secure Operation CRITERION The protocol should not preclude secure operation. DISCUSSION We need to be sure that we have not created a network that is a cracker's playground. Placement For all that security is important, most sites seem to value it less than functionality. 4.13. Explicit Non-Goals Fragmentation The technology exists for path MTU discovery. Presumably, IPv7 will continue to provide this technology. Therefore, we believe that IPv7 Fragmentation and Reassembly, as provided in IPv4, is not necessary. IPv4/IPv7 Communication It is not necessary that IPv4-only and IPv7-only hosts be able to communicate directly with each other. Partridge & Kastenholz Exp. 8 May 1993 [Page 14] Internet Draft IPv7 Criteria November 1992 5. References [1] Internet Architecture Board, IP Version 7, Draft 8, Internet Draft, July, 1992. [2] Gross, P. and P. Almquist, IESG Deliberations on Routing and Addressing, Internet Draft, September 1992. [3] Clark, D., et al, Towards the Future Internet Architecture Network Working Group Request For Comments 1287, December 1991. [4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the design of TCP/IP was guided, in large part, by an ordered list of requirements. Partridge & Kastenholz Exp. 8 May 1993 [Page 15] Internet Draft IPv7 Criteria November 1992 Table of Contents Status of this Memo .................................... 1 1 Introduction .......................................... 2 2 Goals ................................................. 3 3 Note on Terminology ................................... 4 4 Protocol Criteria ..................................... 5 4.1 Scale ............................................... 5 4.2 Robust Service ...................................... 6 4.3 Transition .......................................... 6 4.4 Media ............................................... 8 4.5 Unreliable Datagram Service ......................... 8 4.6 Addressing .......................................... 9 4.7 Configuration, Administration, and Operation ........ 10 4.8 Accounting .......................................... 10 4.9 Extensibility ....................................... 11 4.10 Support for Guaranteed Flows ....................... 13 4.11 Support for Mobility ............................... 13 4.12 Allow Secure Operation ............................. 14 4.13 Explicit Non-Goals ................................. 14 5 References ............................................ 15 Partridge & Kastenholz Exp. 8 May 1993 [Page ii] From owner-big-internet@munnari.oz.au Wed Nov 4 21:50:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29414; Wed, 4 Nov 1992 21:51:00 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211041051.29414@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12504; Wed, 4 Nov 1992 14:09:13 +1100 (from jcurran@nic.near.net) To: Craig Partridge Cc: Dave Crocker , big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Mon, 02 Nov 92 08:50:56 -0800. <9211021650.AA17562@aland.bbn.com> Date: Tue, 03 Nov 92 22:08:38 -0500 From: John Curran ] From: Craig Partridge ] Subject: re: Criteria for selecting IPv7 ] Date: Mon, 02 Nov 92 08:50:56 -0800 ] ] ... ] I've got another point of view. Right now we're all running around looking ] for an IPv7 solution that will allow us to continue to grow the Internet. ] That's a *push* solution: we'll have beat folks into upgrading software to ] keep the Internet alive. I think we need *pull* solutions -- features of ] the new protocol that will cause folks to run out an acquire improved software ] because it has new functionality they need. In fact, if the protocol lacks ] some pull, the transition will be longer, because folks will be slower ] to convert. This is *very* important point; particularly when we consider that the we're asking organizations to change every one of their hosts in order to alleviate pain on TRD providers. It would be great if all of the connected organizations migrated to IPv7 because "it's the right thing" to do, but realistically we had better have some carrots as well as sticks. Autoconfiguration, mobility, security, and service guarantees are all likely carrots. Some proposals may also have their own unique set of motivators that will encourage migration: ATM suitability in the case of SIP, protocol reduction with the selection of TUBA. Keeping the functional criteria seperate from the consequential benefits is probably useful at this time, since our first pass at solutions should be to eliminate those which will not address the problem at hand. Once several solutions have been "validated", then the second order benefits (such as ease of transition, added functionality, etc...) can be weighed against one another. I don't think that we should be trying to balance these issues through the basic criteria. /John From owner-big-internet@munnari.oz.au Wed Nov 4 22:52:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01131; Wed, 4 Nov 1992 22:54:11 +1100 (from owner-big-internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01237; Wed, 4 Nov 1992 06:54:05 +1100 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA19786; Tue, 3 Nov 92 11:53:35 -0800 Date: Tue, 3 Nov 92 11:53:34 PST From: Vince Fuller To: rcraig@cisco.com (Robert Craig) Cc: Big-Internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Crossroads In-Reply-To: Your message of Tue, 3 Nov 92 06:59:34 -0800 Message-Id: The immediate problems we are trying to address are the exhaustion of the IP address space and the breakdown of routing protocols in the face of too many networks (problem caused by lack of aggregation). ... I've devised a possible solution based on the proposals put forward by Wang & Crowcroft, Callon, Fuller, Li, Yu, & Varadhan, Solensky & Kastenholz, Tsuchiya, Chiappa, Hinden & Crocker, and others. [looks like you've covered just about everyone...:-] ... It involves the creation of a meta-Internet using a form of "address translation". Described simply, routing outside autonomous systems is based on the high-order 32 bits of a 64 bit IP address, composed of a 32 bit autonomous system number and the original 32 bit IP address. At the systems' boundaries are "border" gateways, which handle the translation from 32 bit IP address to 32_bit_AS_#.32_bit_IP_addr. There is *no* network number information outside the system. All routing decisions are based on autonomous system number. This is starting to sound a lot like the original IPAE proposal. Tell me, are you encapsulating "local" IP datagrams (i.e. those with addresses which are significant only inside an AS) inside "inter-AS" datagrams (i.e. those which use inter-AS addresses)? --Vince From owner-big-internet@munnari.oz.au Thu Nov 5 04:48:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12284; Thu, 5 Nov 1992 04:48:44 +1100 (from owner-big-internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11278; Thu, 5 Nov 1992 03:59:31 +1100 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA22388; Wed, 4 Nov 92 12:01:31 EST Received: by sword.bellcore.com;id 9211041655.AA27119 Message-Id: <9211041655.AA27119@sword.bellcore.com> Date: Wed, 4 Nov 1992 12:03:03 -0500 To: Big-Internet@munnari.oz.au, tuba@lanl.gov From: dave@sabre.bellcore.com Subject: Re: IETF at Crossroads Back on Oct 22, Peter Ford wrote: >in terms of using Fletcher over TP4 payloads, why not use TCP over >CLNP as in the TUBA proposal? In terms of changing from Fletcher to >the IP/TCP checksum, it seems to me that it might be worthwhile to feed >this change back into the ISO standard, using the implementation >experience of the Internet community to support the change. As anecdotal evidence that ISO standards are amenable to change, I wish to point out that the ISO Transport Protocol Specification indicates that the use of additional (other) checksums is for further study. One could easily negotiate the use of the IP/TCP checksum in the connection request processing. In CLNP, one would perhaps have to rely on some information piggybacked in the version field, perhaps. Fact is, it could be done, and easily. All you gotta do is ask (seems to me I've said this before on this list, and flames of skepticism appeared in large numbers--please resist the temptation to flame publicly and reply on this last point to me directly?) --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-big-internet@munnari.oz.au Thu Nov 5 04:50:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12334; Thu, 5 Nov 1992 04:50:34 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211041750.12334@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11218; Thu, 5 Nov 1992 03:56:52 +1100 (from jcurran@nic.near.net) To: Steve Deering Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Tue, 03 Nov 92 09:21:16 -0800. <92Nov3.092118pst.10779@skylark.parc.xerox.com> Date: Wed, 04 Nov 92 11:56:18 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Vote NO on R-L-G IP Address Allocation proposal ] Date: Tue, 3 Nov 1992 09:21:16 PST ] ] > [From: peter@goshawk.lanl.gov] ] > ] > While a decimal order of magnitude may not seem like much to you, the ] > facts are that there are very few networks which are suffering any ] > real problems in terms of routing table size. For them, a shrinkage of ] > table size (by even a factor of two) is a big deal. A shrinkage of ] > a decimal order of magnitude is fantastic. Assuming the ] > network is doubling every 12 months an order of decimal magnitude ] > decrease translates into 3 years. ] ] I said that aggregation by continent would yield far *less* than an ] order of magnitude reduction. For example, the routing tables in the ] North American backbones would shrink by less than a factor of two if you ] removed all of the non-North American entries. ] ] I think you want to achieve *at least* a factor of ten reduction, so that ] you can get your three years of breathing room. And that still leaves ] the problem of another renumbering three years from now. Hmm. If we're discussing allocation policies for the existing (remaining?) IPv4 address space, then I don't see any significant benefit to geographic assignment, and as others have indicated, significant risk of "losing" large parts of the address space due to the large continental block size. If we want to insure a 10-to-one aggregation, then allocate blocks of 128 network numbers to network providers as needed. Each block will result in a single route for in TRDs routing tables. Delegation of assignment authority can still be performed (e.g. have the IR assign RIPE 32 blocks at a time), and we'll still receive the majority of the benefits that CIDR has to offer. There will be some loss due to underutilization of these blocks, but certainly not of the same magnitude that the continental plan will result in. There will also be some additional routing information needed to handle smooth provider changes without network renumbering, but this could occur for 10% percent of the sites and we would still have a 10-to-one aggregration. Most of the IPv7 plans have a point of their timeline that reads "32-bit address depletion"; this will occur much sooner if blocks of the address space have been sequestered away by continent. Reclaimation of unused network numbers may work, but I'll hold judgement till I've seen it in action. Perhaps a trial effort with the class B network assignments would help prove the viability of large-scale reclaimation... Of course, if we're talking about allocation policies for a much larger address space which will have to last for all of the forseeable future (i.e. the IPv7 address space), then geographic allocation is a great candidate for handling a million or so networks. In this case, the loss of address space poses nowhere near the problem that we'll face with large geographic allocations during IPv4's final years. /John From owner-Big-Internet@munnari.oz.au Thu Nov 5 03:56:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11260; Thu, 5 Nov 1992 03:58:39 +1100 (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 AA11206; Thu, 5 Nov 1992 03:56:22 +1100 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08153; Wed, 4 Nov 92 08:55:58 -0800 Received: by us1rmc.bb.dec.com; id AA08688; Wed, 4 Nov 92 11:53:27 -0500 Message-Id: <9211041653.AA08688@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 4 Nov 92 11:53:28 EST Date: Wed, 4 Nov 92 11:53:28 EST From: Ross Callon To: minshall@wc.novell.com Cc: big-internet@munnari.oz.au Apparently-To: minshall@wc.novell.com, big-internet@munnari.oz.au Subject: re: Re: Vote NO on R-L-G IP Address Allocation proposal > The metro plan makes sense to me as a way of decoupling providers from > "addresses". Even when Ross says that systems should reconfigure their > addresses, i think "well, then at the least you probably are going to have > to, in practice, restart all your systems when you change providers", and > it is getting harder and harder these days to even *FIND*, let alone > restart, all the systems that are IP hosts. Well, I can't speak for other proposals, but the idea with TUBA reconfiguration is that the hosts pick up the address changes automatically via listening to packets transmitted by routers. Thus, hosts do not have to be restarted, nor is it necessary to even find the hosts. Existing TCP connections continue to operate without interuption during the address change. It should be possible (and, I think, a good idea) to add a similar capability to any other proposal for IPv7, although I don't think folks have actually done this yet. Ross From owner-big-internet@munnari.oz.au Thu Nov 5 04:50:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12343; Thu, 5 Nov 1992 04:50:54 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211041750.12343@munnari.oz.au> Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10071; Thu, 5 Nov 1992 03:00:47 +1100 (from rcraig@cisco.com) Received: from [192.135.250.51] by diablo.cisco.com with SMTP (16.6/16.2) id AA04234; Wed, 4 Nov 92 07:57:59 -0800 Date: Wed, 4 Nov 92 07:57:59 -0800 To: big-internet@munnari.oz.au From: rcraig@cisco.com (Robert Craig) X-Sender: rcraig@diablo.cisco.com Subject: Crossroads (long) Noel Chiappa writes: > Congratulations! You seem to have reinvented yet another variant of >the Network Address Translator (NAT), an idea developed by Paul Tsuchiya and >Van Jacobsen. I didn't claim to devise the idea, simply to repackage it with some possibly novel ideas, such as treating the 32 bit extension to the address as an IP network number in its own right, permitting the use of existing routing protocols. > Your variant doesn't exactly match any of the variants I named in the >taxonomy of NAT variants I sent to this list some months back, but it appears >to be close to the variants I labelled I-NAT or B-NAT, depending on what >routing protocol you use. Could you point me to more reading on the "Open Routing" routing protocol? Is it part of Nimrod (which I confess I haven't had time to read yet...)? > The part you label "the tricky part..." has already been examined in >some detail by both Paul and Van, as well as others, and I believe they >actually field-tested boxes which did this. Is anything available which documents their experiments? > NAT schemes of all flavors are currently somewhat out of favor, >primarily because they require munging around in all packets flowing through >border routers, looking for IP addresses buried in the data. I have predicted >that they will make a comeback when we are "up against the wall"; we'll see, >I guess. The idea of keeping a single homogeneous Internet is a very attractive one, and one which I am sure the next architecture, whatever it may be, will preserve. Practically speaking, however, we are damn close to being against the wall and had better start deploying workaround(s) *now*. Yes, the workarounds may involve some short-term pain (such as fixing applications which encode IP addresses in the data portion; many ftp clients nowadays have an option to turn off the "PORT" command). Is there a practical alternative to some form of NAT which can be easily deployed? Charles Lynn writes: >Your proposal is similar to one I proposed back in July (look in the >big-internet archives for Message-Id: <9207162256.10210@munnari.oz.au>), I only joined this mailing list a month or two ago...I'll certainly retrieve it. >except that it has the same drawback that the other proposals that I >have seen have, i.e., how can it be incrementally deployed? If an old >packet is changed to use the "new" techniques, how can it be delivered >except by a "peer" that recognizes the new technique and convert it >back to the old? It appears that one has to start with a network, >e.g., a national backbone, and wrap ALL its entrances & exits with >modified gateways, then proceed to its attached networks, e.g., the >regionals, and convert ALL of its (unconverted) attachment points, etc. This is a point I had not considered, and a serious impediment, if true. Consider the following case: AS 1 is part of a NAT-net (or the germ of one) and also has old-style gateways to the existing Internet. So long as addresses in AS 1 do not conflict with those in use in the Internet, and the gateways in AS 1 have enough routing information to make the decision on whether to forward packets to Internet gateways or to NAT (this could be as simple as "network numbers x and y should be routed to the NAT gateway, all else defaults to the Internet gateway), there should be no problem. The administrator of AS 1 has to be careful to pick his "reserved exterior network" numbers to avoid duplicating those in use in the Internet, during the period of transition. As each autonomous system converts, its allocated IP address space is freed-up, lessening the likelihood of collision. When we start sticking NAT networks together, and attempt to use them as transit systems to reach the existing Internet, we may have problems. Could we not treat the Internet as "another" NAT network and place border gateways on the AS's that connect to it? In the worst case, it may mean that each AS which converts must retain their existing Internet connection until such time as the whole of the Internet has converted, but as far as I can determine, treating the Internet as just another NAT network should suffice. >Using autonomous system numbers for the "provider attachment point" is >one way to manage the high-order 32 bits. The increase in routing >table size would only be equal to the number of autonomous systems (my >proposal does not increase the routing table size during a transition >since the high-order 32 bit addresses are already in the routing >tables). Ah, but there is *no* increase in routing table size with my variant either ;-> The existing Internet's network numbers are now internal to this "AS" and are not influenced by anything happening in any of the other AS's. Between AS's the only routing information is autonomous system number, so the total effect is to reduce the "external" routing information from 7000 or so networks at present to however many autonomous system numbers are required, taking into account the effect of aggregation, probably 1 AS number for each regional network. >I do not agree that "source-routing variants are unacceptable, unless >*all* packets are loosely-source-routed via the border gateway >(clearly a bad thing)" ;-) Perhaps I wasn't clear: source-routing is bad because it involves the end system in the routing decision, in the case under discussion (i.e., it's not *always* bad, sometimes it's even necessary). In this case, it is a bad thing because it means that the software on the end system must change. How many end systems are there currently connected to the Internet? Vince Fuller writes: >This is starting to sound a lot like the original IPAE proposal. Tell me, are >you encapsulating "local" IP datagrams (i.e. those with addresses which are >significant only inside an AS) inside "inter-AS" datagrams (i.e. those which >use inter-AS addresses)? Yes, it sounds a lot like it, since I borrowed freely from the IPAE and other proposals, as I stated in the preamble to my note...My approach does not involve encapsulation, rather translation. It might actually be easier to use encapsulation. Heck, there are a thousand variations on this, as Noel Chiappa pointed out. How about a variant of EIP's approach of treating the "network" address as a new IP option? Is this encapsulation or translation? More like prestidigitation ;-> Robert. ----------------------------------------------------- Robert Craig 1155 boul Rene Levesque ouest cisco Systems 25ieme etage (514) 393-3243 Montreal, Quebec H3B 2K4 From owner-Big-Internet@munnari.oz.au Thu Nov 5 06:50:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15683; Thu, 5 Nov 1992 06:50:32 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15680; Thu, 5 Nov 1992 06:50:23 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 4 Nov 92 14:45:55 EST Received: by chiya.bellcore.com (4.1/4.7) id for minshall@wc.novell.com; Wed, 4 Nov 92 14:45:53 EST Date: Wed, 4 Nov 92 14:45:53 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9211041945.AA25349@chiya.bellcore.com> To: callon@bigfut.enet.dec.com, minshall@wc.novell.com Subject: re: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au > > Well, I can't speak for other proposals, but the idea with TUBA > reconfiguration is that the hosts pick up the address changes > automatically via listening to packets transmitted by routers. > Thus, hosts do not have to be restarted, nor is it necessary to > even find the hosts. Existing TCP connections continue to operate > without interuption during the address change. How is it that hosts operate without interuption, given that TCP uses the address to help identify the connection? > > It should be possible (and, I think, a good idea) to add a similar > capability to any other proposal for IPv7, although I don't think > folks have actually done this yet. > It is my intent to put this is Pip. It is straightforward with Pip, because the ID used for identification is already separated from the "address". But, Pip one-ups this, because it has a mode of operation where internal hosts and routers actually never need know their "inter-domain" prefix at all. So, they are *completely* isolated from external addressing conventions....... PX From owner-Big-Internet@munnari.oz.au Thu Nov 5 08:02:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17361; Thu, 5 Nov 1992 08:02:35 +1100 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17358; Thu, 5 Nov 1992 08:02:27 +1100 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA23584; Wed, 4 Nov 92 12:59:47 -0800 Date: Wed, 4 Nov 92 12:59:46 PST From: Vince Fuller To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: callon@bigfut.enet.dec.com, minshall@wc.novell.com, big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: re: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of Wed, 4 Nov 92 14:45:53 EST Message-Id: How is it that hosts operate without interuption, given that TCP uses the address to help identify the connection? A wild guess (I haven't read the TUBA spec): only the 48-bit host ID field from the CLNP address is used in the TCP/UDP psuedo-header? If it isn't done this way in the TUBA spec, it should be if decoupling of addresses from endpoint ID's is desireable (IMHO, a good idea). --Vince From owner-big-internet@munnari.oz.au Thu Nov 5 10:11:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01512; Thu, 5 Nov 1992 10:11:22 +1100 (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 AA16205; Thu, 5 Nov 1992 07:17:25 +1100 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA22833; Wed, 4 Nov 92 12:17:17 -0800 Received: by us1rmc.bb.dec.com; id AA14984; Wed, 4 Nov 92 15:14:47 -0500 Message-Id: <9211042014.AA14984@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 4 Nov 92 15:14:48 EST Date: Wed, 4 Nov 92 15:14:48 EST From: Ross Callon To: big-internet@munnari.oz.au Cc: callon@bigfut.enet.dec.com Apparently-To: big-internet@munnari.oz.au Subject: re: address changes (was Vote NO on R-L-G ...) >>> Well, I can't speak for other proposals, but the idea with TUBA >>> reconfiguration is that the hosts pick up the address changes >>> automatically via listening to packets transmitted by routers. >>> Thus, hosts do not have to be restarted, nor is it necessary to >>> even find the hosts. Existing TCP connections continue to operate >>> without interuption during the address change. > > Regarding uninteruptable TCP connections. This assumes that TCP > is aware of the new NSAP address so the source NSAP address in the CLNP > header is set appropriately. Yes. The proposal is that at the same time that you update a host to understand TUBA (Internet applications over CLNP) you also update the host to understand how to deal with address changes and mobile hosts. This means that a host has to know what to do when its own address changes, and also what to do when the address of something that it is talking to changes (ie, how to receive a "change address of remote system" message, which could be sent as either a new ICMP message type, or could be implicit in the protocol operation -- either approach is possible and easy to specify, we just have to pick one). > It is true that the connection can be identified by system-id. But the > TCP layer interface to CLNP must provide source and destination NSAPs > for the packet. I didn't see any mechanism in your proposals specifically > addressing this outside of TCP/UDP. The address reconfiguration (so each host knows its own address, and knows when this changes) is based on work which is pretty nearly complete in ANSI/OSI. The details of the other parts of the operation (dealing with changes in address of remote hosts during active TCP connections, and dealing with addresses received from DNS which are old) are understood, but haven't been written down yet. I will not personally have time to write these down in the forseeable future. Hopefully someone else will do this after discussions at the upcoming IETF meeting. Ross From owner-big-internet@munnari.oz.au Thu Nov 5 17:22:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28048; Thu, 5 Nov 1992 17:22:38 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20174; Thu, 5 Nov 1992 16:23:48 +1100 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA13343; Wed, 4 Nov 92 21:23:40 PST Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA24590; Wed, 4 Nov 92 21:23:43 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA01347; Wed, 4 Nov 92 21:23:11 PST Date: Wed, 4 Nov 92 21:23:11 PST From: hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9211050523.AA01347@bigriver.Eng.Sun.COM> To: rcraig@cisco.com (Robert Craig) Cc: big-internet@munnari.oz.au In-Reply-To: <9211041750.12343@munnari.oz.au> Subject: Crossroads (long) Robert, > I didn't claim to devise the idea, simply to repackage it with some > possibly novel ideas, such as treating the 32 bit extension to the address > as an IP network number in its own right, permitting the use of existing > routing protocols. That idea was in the original IP Encaps proposal (aka IPIP). I still think overall it was a nice approach to giving IP routing and addressing more life with making any other changes. But it seems to have not found much acceptance because it did not go far enough to 10^^9 networks and was not have a clean endpoint. It was the starting point for the work which is now called IP Address Encapsulation (IPAE). Bob From owner-Big-Internet@munnari.oz.au Thu Nov 5 20:44:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17951; Thu, 5 Nov 1992 20:44:12 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211050944.17951@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17948; Thu, 5 Nov 1992 20:44:03 +1100 (from lyman@BBN.COM) Date: Thu, 5 Nov 92 4:42:56 EST From: A. Lyman Chapin To: tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au, tuba@lanl.gov Subject: Prefixes >Date: Sat, 24 Oct 92 16:49:56 EDT >From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) >To: dkatz@cisco.com, tsuchiya@thumper.bellcore.com >Subject: Re: Protocol Transitions (was Re: concerns about CLNP) >Cc: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, kasten@ftp.com, > tuba@lanl.gov > >> >> This is not true; I have in my hands a copy of 9542 PDAM1 (now DAM1 I think) >> for dynamic address assignment. >> > >Yes, I was aware that the dynamic address assignment work >was going on, but the bit about prefix assignment per se >has been dropped, right? > >Or, put another way, in the current spec, is there any >way to change just the "inter-domain" part of the NSAP >for all hosts in an area? > >PX Paul, If the end systems are expecting to get their prefixes from an IS using the dynamic address assignment mechanism of 9542 Amendment 1, then changing the prefix that the IS sends out will change the prefix for all hosts listening to that IS. Are you looking for an automated way to distribute a new prefix to all ISs serving a particular area? - Lyman From owner-Big-Internet@munnari.oz.au Fri Nov 6 03:10:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29939; Fri, 6 Nov 1992 03:10:23 +1100 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29934; Fri, 6 Nov 1992 03:10:12 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA01312; Thu, 5 Nov 92 11:07:09 -0500 Date: Thu, 5 Nov 92 11:07:09 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9211051607.AA01312@er.doe.gov> To: deering@parc.xerox.com, minshall@wc.novell.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au You state that when # of internet sites in a metro area reaches millions that flat routing will be ok because sites are close geographically. I for one see no reason why the length of the fibedrs between the routers makes this problem easier. The memory bandwidth problems etc are exactly the same. If the world comes to be dominated by small sites... a subnet with 2 pc's, a tv a nintendo, and 5 kitchen appliances then flat metro addressing will be dreadful. It seems to me that the ability to flexibly introduce levels of information into the routing information hierarchy is absolutely critical. Note that this is not necessarily the case with an EID hierarchy which is used as a key to find routing info. With regard to flow ID's vs EID's in packets it seems to me that the trade off is in the generation of globally unique flow id's at least at a given time and tracking the linkage of flowid to source dest pair vs including source, dest eid's in packets. Dan Hitchcock From owner-big-internet@munnari.oz.au Fri Nov 6 04:04:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01366; Fri, 6 Nov 1992 04:04:31 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28791; Fri, 6 Nov 1992 02:34:54 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 5 Nov 92 10:34:31 EST Received: by chiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Thu, 5 Nov 92 10:18:27 EST Date: Thu, 5 Nov 92 10:18:27 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9211051518.AA26332@chiya.bellcore.com> To: lyman@BBN.COM Subject: Re: Prefixes Cc: big-internet@munnari.oz.au, tuba@lanl.gov > > If the end systems are expecting to get their prefixes from an IS > using the dynamic address assignment mechanism of 9542 Amendment 1, > then changing the prefix that the IS sends out will change the prefix > for all hosts listening to that IS. Yes, this is true. I guess the alternative is that the IS goes around and *individually* changes the NSAP of all ESs that are "in its area". > ....Are you looking for an automated > way to distribute a new prefix to all ISs serving a particular area? > I recall that distributing a new prefix to all ISs in a particular area is already part of IS-IS. My impression from when I was working on this before was that all we needed to do was make sure there is a means of getting the new prefix from the router to the host. I recall also that the problem was that the address assignment scheme had a means for a host requesting its address, but not a means for the router to tell the host that it is getting a new address. But, my recollection is sketchy....... I guess the bottom line is this..... is it easy to change all host addresses in an area with the current ammendment to 9542 or not? PX From owner-big-internet@munnari.oz.au Fri Nov 6 05:16:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03036; Fri, 6 Nov 1992 05:16:27 +1100 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02924; Fri, 6 Nov 1992 05:12:37 +1100 (from kre) To: yakov@watson.ibm.com, Big-Internet@munnari.OZ.AU Cc: sklower@vangogh.CS.Berkeley.EDU, tuba@lanl.gov Reply-To: Big-Internet@munnari.OZ.AU Subject: Re: pseudo-header for tuba In-Reply-To: Your message of Thu, 05 Nov 92 10:40:04 -0500. <9211051540.AA03616@p.lanl.gov> Date: Fri, 06 Nov 92 05:12:23 +1100 Message-Id: <20497.720987143@munnari.oz.au> From: Robert Elz This discussion (as the subject implies) begain on the tuba list, however discussions of what should be in the pseudo-header will apply to all proposed variants of IPv7, so I am moving this back to Big-Internet - nothing in my comments is specific to TUBA. We really need to go back to basics on this one - it seems that many of the responses have been just jumping in with pre-conceived notions. The purpose of the pseudo-header is to detect corruption of data from the header in transit. Assuming this protection is still considered necessary at all (John Day's point) the only consideration as to what gets included is to include those fields that you want to be able to rely on (at the transport layer), and exclude any that vary while the packet is en-route (ie: TTL and similar) unless you want routers to have to adjust the pseudo-header. So, if we assume that the addresses/eids need protection (which TCP has with respect to IP at least), the choice of whether to include the address (NSAP) or EID is purely on whether you would expect one to be more or less variable than the other in the header of a single packet. The only reasons (it seems to me) why one would choose the EID for this purpose over the NSAP would be to allow the NSAP (excluding EID) to be mapped as it passed through a gateway somewhere along the path, or simply that the NSAP is longer, and doesn't need to be protected (as much as the EID part anyway), so some cycles can be saved by including only the EID. As someone said (sorry, I forgot who) this is not exactly an issue of vital importance. What is more important is just what it is that identifies a TCP connection - whether the NSAP or the EID is used for that purpose (which is not the same as what's used in the pseudo-header). Here we want to use the EID, as here we want something that's constant over the life of a connection, and the NSAP may vary. That may give some small push to also using the EID for the pseudo header, just to make life a little easier in the implementation, but its no more than that. As to why the NSAP may vary, Yakov asks... Date: Thu, 5 Nov 92 10:40:04 EST From: yakov@watson.ibm.com Message-ID: <9211051540.AA03616@p.lanl.gov> Would other folks tell us whether there are any other motivations for changing an NSAP over the course of a conection ? One reason may be if a site changes providers, and for whatever reason that means a change of NSAP to keep routing sane. An example may be if a subsidiary of an international company that was using an NSAP based on the company's connection in the US (and receiving traffic that way - perhaps the only possible path for corporate security reasons) becomes independant, and establishes a connection in the country in which it is located. This kind of thing does happen... Remember that connections should be able to last months, or years, we shouldn't think of a connection as something that takes as long as this SMTP message will take in any of its hops around the net, or even of an FTP connection. Ideally nothing that happens at the IP layer should affect the stability of the connection, as long as both ends desire to keep it alive. Yakov also pointed out that changing NSAPs should not be thought of as a necessary consequence of mobility, that there are other ways, and indeed there are. However, that there are other ways possible to handle mobility (ways largely designed within the costraints of IPv4) doesn't mean that we should therefore abandon any attempt to locate a better way, and frankly, to me, tunnelling is an absurd way to handle mobile hosts given an unconstrained base on which to start (as a method to make mobile hosts work on IPv4 it's most probably the only way, so please don't take this as a criticism of the mobile host proposals that exist now). The mobile host proposals, as well as being constrained by IPv4, seem to assume two things - first that mobile hosts are comparatively rare, and second that its possible for such hosts to be required to run special software to allow them to be mobile. With IPv4 I accept both of those, into the future I accept neither. With IPv7 we have the unconstrained starting place for dealing with mobile hosts, we should, in fact must, design the system such that it can work where every host on the net is "mobile" all at once. Making sure that TCP uses only the EID in its connection identification phase is one basic requirement for that to be possible, since clearly arbitrary random mobility (or portability), without tunnelling, which I think anyone would agree should be avoided if possible, is going to require NSAP (or address, whatever form they take) changes during the lifetime of connections. kre From owner-big-internet@munnari.oz.au Fri Nov 6 06:35:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05279; Fri, 6 Nov 1992 06:35:14 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04396; Fri, 6 Nov 1992 06:04:45 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11732>; Thu, 5 Nov 1992 11:02:48 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Thu, 5 Nov 1992 11:02:40 -0800 To: Big-Internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: pseudo-header for tuba In-Reply-To: Your message of "Thu, 05 Nov 92 10:12:23 PST." <20497.720987143@munnari.oz.au> Date: Thu, 5 Nov 1992 11:02:29 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov5.110240pst.10779@skylark.parc.xerox.com> Robert writes: > The mobile host proposals, as well as being constrained by IPv4, > seem to assume two things - first that mobile hosts are > comparatively rare, ... That's not true. What makes you think that the proposed schemes are unsuitable for an internet in which "every host ... is 'mobile' all at once"? Do you have a proposal that *better* handles large-scale mobility? > ...and second that its possible for such hosts > to be required to run special software to allow them to be > mobile. With IPv4 I accept both of those, into the future I > accept neither. I agree that any new IP should define whatever host procedures are needed to support mobility as part of the standard host specification, so it won't be considered "special software". But what has that got to do with deciding between the techniques currently proposed for IPv4 and any other techniques? Steve From owner-big-internet@munnari.oz.au Fri Nov 6 06:57:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05908; Fri, 6 Nov 1992 06:57:56 +1100 (from owner-big-internet) Return-Path: Received: from muri.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05869; Fri, 6 Nov 1992 06:56:43 +1100 (from kre) To: Steve Deering Cc: Big-Internet@munnari.oz.au Subject: Re: pseudo-header for tuba In-Reply-To: Your message of Thu, 05 Nov 92 11:02:29 -0800. <92Nov5.110240pst.10779@skylark.parc.xerox.com> Date: Fri, 06 Nov 92 06:58:04 +1100 Message-Id: <22008.720993484@munnari.oz.au> From: Robert Elz Date: Thu, 5 Nov 1992 11:02:29 PST From: Steve Deering Message-ID: <92Nov5.110240pst.10779@skylark.parc.xerox.com> > seem to assume two things - first that mobile hosts are > comparatively rare, ... That's not true. I should make it clear that by "assumes" I didn't intend to imply "won't work unless", just "this is the common case". What makes you think that the proposed schemes are unsuitable for an internet in which "every host ... is 'mobile' all at once"? Well, one might be that at least both I have seen so far seem to want the packets to travel to some kind of mobile host server, identified by the mobile host's address (it arranges for packets to come to it, then relays them one way or another). However, what happens the whole original addressing structure vanishes? Eg: consider if I were to renumber my net from 128.250 into 256 (or so) class C addresses from the Asia/Pacific class C group - "mobile" hosts in 128.250 (ie: all of them) would no longer exist, 128.250 would not appear in the routing tables anywhere any more. There's no longer a method to send any packets at all to any kind of 128.250 address - just how to you get packets to the mobile host server? At least one of the proposals also expects "mobile" hosts to live on a special (pseudo) subnet, which is not really possible if every host is potentially movile, is it? Do you have a proposal that *better* handles large-scale mobility? No, mobile hosts aren't my area - however I can't help but see that if I can change the address of an ongoing connection without breaking it - simply send packets to a new address rather than to the old one, then something better ought to be possible. I agree that any new IP should define whatever host procedures are needed to support mobility as part of the standard host specification, so it won't be considered "special software". But what has that got to do with deciding between the techniques currently proposed for IPv4 and any other techniques? One is that we should be doing away with mobile host servers, and any special tricks to make them work, if every host is to be mobile, then the underlying support should just be there, including address changes dynamically. kre From owner-Big-Internet@munnari.oz.au Fri Nov 6 08:15:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08598; Fri, 6 Nov 1992 08:15:15 +1100 (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 AA08593; Fri, 6 Nov 1992 08:15:01 +1100 (from dkatz@cisco.com) Received: by regal.cisco.com; Thu, 5 Nov 92 13:14:48 -0800 Date: Thu, 5 Nov 92 13:14:48 -0800 From: Dave Katz Message-Id: <9211052114.AA12202@regal.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: lyman@BBN.COM, big-internet@munnari.oz.au, tuba@lanl.gov In-Reply-To: Paul Tsuchiya's message of Thu, 5 Nov 92 10:18:27 EST <9211051518.AA26332@chiya.bellcore.com> Subject: Prefixes I guess the bottom line is this..... is it easy to change all host addresses in an area with the current ammendment to 9542 or not? Addresses assigned to end systems carry a holding timer; such timers could be ratcheted down before reassignment if that is desirable. However, the maximum holding time is a bit over 18 hours, so ratcheting the time down probably isn't necessary. Since IS-IS supports multiple area addresses, the reassignment need not be synchronous. Addresses cannot be assigned "permanently" with this protocol (they always age). This is arguably a feature. From owner-Big-Internet@munnari.oz.au Fri Nov 6 11:08:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15201; Fri, 6 Nov 1992 11:08:35 +1100 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15186; Fri, 6 Nov 1992 11:08:06 +1100 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA09079; Thu, 5 Nov 92 16:07:55 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA01320; Thu, 5 Nov 92 16:07:55 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA02524; Thu, 5 Nov 92 16:07:21 PST Date: Thu, 5 Nov 92 16:07:21 PST From: hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9211060007.AA02524@bigriver.Eng.Sun.COM> To: Robert Elz Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <20497.720987143@munnari.oz.au> Subject: Re: pseudo-header for tuba Robert, > The purpose of the pseudo-header is to detect corruption of > data from the header in transit. Assuming this protection is > still considered necessary at all (John Day's point) the The TCP and UDP pseudo-header serve to protect against mis-routed packets. This is protecting from more than just corrupted header data. A TCP/UDP connections are identified by source address, destination address, source port, and destination port. The pseudo header ties all of this together. I think this protection is still necessary. Bob From owner-Big-Internet@munnari.oz.au Fri Nov 6 13:33:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21315; Fri, 6 Nov 1992 13:33:53 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21298; Fri, 6 Nov 1992 13:33:29 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB07686; Thu, 5 Nov 92 21:32:54 EST Date: Thu, 5 Nov 92 21:32:54 EST Message-Id: <9211060232.AB07686@mitchell.cit.cornell.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott_Brim@cornell.edu Sender: swb@nr-tech.cit.cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au Hi. At 14:21 11/2/92 -0500, Noel Chiappa wrote: > I've noticed a tendency, of late, for increasing conservatism in >design in the IETF. While I think a certain amount of conservatism is OK (we >are after all responsible for a large operational network), let's not let it >go so far as to stifle creative growth. I know this is a hard line to tread, >and one not subject to easy quantitive measurement, but if we get to the point >where we can't do anything bold a lot of the more creative and innovative >engineers are going to go elsewhere. > The world has a name for a biological system with maximal internal >resistance to state-change: dead. With that mindset in hand, let me offer >a few comments on your notes. Noel, someone has to be conservative. Hark back to Dave Clark: if it has to work when you're done, it's not research, it's engineering. I think the role of the IETF, as Internet Engineers, is to take bold steps when necessary, but only those which it is sure are going to work. It's the role of the IRTF, and everyone else who is doing research, to offer the IETF the opportunities and tools to take those bold steps -- but you have to make sure the Internet works. Perhaps, in fact, those "more creative and innovative engineers" you refer to *should* go elsewhere if they would feel hampered by that restriction. Creativity and innovation in the IETF are important but in how they use proven tools, not in what research they produce. Perhaps we need more sandbox nets. This may sound like redefining the IETF to have only a boring role to play, but the IETF has been defined like this in the past off and on since it was first created out of GADS. There's a dialectic tension, between our desire to do neat stuff and our need for making the pieces work together, which makes the IETF sway back and forth and usually try to include too wide a set of functions. If this "approach-approach conflict" isn't clearly understood and actively responded to, it can lead to confusion about the IETF's role and loss of overall productivity. In recent years the IETF has moved enthusiastically into research territory. Now it may be time for the pendulum to start swinging back again, especially since we're considering a large-scale restructuring. Scott From owner-Big-Internet@munnari.oz.au Sat Nov 7 03:53:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21069; Sat, 7 Nov 1992 03:53:54 +1100 (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 AA21055; Sat, 7 Nov 1992 03:53:16 +1100 (from craig@aland.bbn.com) Received: from port13.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA02644; Fri, 6 Nov 92 11:52:51 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15364; Fri, 6 Nov 92 08:51:25 PST Message-Id: <9211061651.AA15364@aland.bbn.com> To: Scott_Brim@cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Fri, 06 Nov 92 08:51:25 -0800 Sender: craig@aland.bbn.com > I think the > role of the IETF, as Internet Engineers, is to take bold steps when > necessary, but only those which it is sure are going to work. Scott: Sigh, I think this is a hopelessly quixotic goal. There is no way that we'll be sure that any of the changes we make for IPv7 will work until we actually deploy IPv7 widely. The best we can do is prove that some solutions won't work, then proceed forward, ready to fix things. We cannot be sure our solutions are going to work or that people will want to deploy them. At best, all we can do is try to manage the risk of failure. Craig From owner-Big-Internet@munnari.oz.au Sat Nov 7 06:03:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25225; Sat, 7 Nov 1992 06:03:38 +1100 (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 AA25220; Sat, 7 Nov 1992 06:03:05 +1100 (from craig@aland.bbn.com) Received: from port13.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA11316; Fri, 6 Nov 92 14:01:58 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA16893; Fri, 6 Nov 92 11:00:29 PST Message-Id: <9211061900.AA16893@aland.bbn.com> To: big-internet@munnari.oz.au Subject: transition criteria Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 06 Nov 92 11:00:29 -0800 Sender: craig@aland.bbn.com Hi folks: I'm starting to a few comments about the recent draft of the list of criteria (thanks!) and there's one comment I'd like to get wider advice about. Exactly how close is routing table disaster? To motivate the question, let me give a couple of sample answers and their implications: * Disaster will come in less than two years. If this is the case, then making the routing tables smaller becomes something we have to achieve during transition, when we have mixed networks of IPv4 and IPv7 in operation. So we'd need to add a requirement that the transition plan help shrink routing tables. * Disaster will come in more than five years. In this case, we can hope that we have IPv7 widely enough deployed that we don't need to worry about shrinking routing tables during the transition plan (though we presumably need to worry about not increasing the rate of growth of routing tables, yes?). Advice much appreciated. I've heard folks argue all sides, so carefully reasoned replies which cover questions like current rate of growth and availability of additional memory over the next few years, would be most useful. Thanks! Craig From owner-Big-Internet@munnari.oz.au Sat Nov 7 08:50:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01009; Sat, 7 Nov 1992 08:50:26 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00998; Sat, 7 Nov 1992 08:50:14 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA03448; Fri, 6 Nov 92 14:50:03 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA28228; Fri, 6 Nov 92 14:50:02 MST Message-Id: <9211062150.AA28228@goshawk.lanl.gov> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: transition criteria In-Reply-To: Your message of Fri, 06 Nov 92 11:00:29 -0800. <9211061900.AA16893@aland.bbn.com> Date: Fri, 06 Nov 92 14:50:01 MST From: peter@goshawk.lanl.gov [shields up] Craig, I like the question, but I admit up front that I am going to vaguely answer it and then step outside of its intended scope. I believe CIDR can keep the Internet routable until we run out of address space. So I could read your question as asking how long can we use the IP address space? (I suspect there are some people out there who don't agree). We might loose some flexability, but then again, do you want a routable Internet or do you want the flexability to do whatever you want in the routing system. We can put flexibility back in when we are sure we can buy 10 megamip routers with 10 gigabyte memories. (Alternatively, we can put mapping capabilties into the router system and fix some protocols ...) If we are willing to renumber the Internet and make a few other changes the Internet can go on living on IPv4 for a really long time. As many people have pointed out, it is hard to believe that the effort of deploying new technology is less than the effort of renumbering. It just won't happen until people are told they have to. There is the issue of routing the system which will require CIDR and a reasonable routing and addressing hierarchy in place and moving the 45 thousand assigned nets into that hierarchy. (note there might be some part of the hierarchy which is "unconnected" and the prefixes indicate that you are in the unroutable catch-all category.) I like geographic addressing, but CIDR can accomodate the hierarchy de jeure. [now comes the Subnets considered harmful part] Second, there is the issue of good use of the Address space. Subnetting is one of the major deterrents to effective use of the IP address space. Variable length subnetting goes part way to correcting this, but I would advocate going further. We could decouple IP subnets from physical subnets. Why not use {Area routing + host routes within an Area} as a strategy for routing within a domain. We would then only use IP subnets to denote routing areas which are collections of physical subnets. (yes, this is not an original idea). The idea for routing within an AD/AS is to use OSPF or IS-IS to route the areas and within level 1 areas simple use flat routing over the hosts. Many site administrators would kiss the feet of the organization which delivered them from the tyranny of mapping IP subnets to physical subnets. Imagine managing 10 ethernets but not worrying about IP subnet numbering on those networks. We would need to have mechanisms of letting routers and hosts know which IP host addresses are on their physical subnets. (ES-IS comes to mind). With this in place it would be much easier to assign IP prefixes which matched the requirements of a site. Today, the issue of how to route the site is intimately bound up in the amount of address space they need. If we eliminate the use of really small subnets we also get back at lot of broadcast addresses. (Consider the number of {0, all ones}. when you have many subnets.) The point is to aggregate and route with prefixes where it is really necessary, such as for interdomain routing. [shields down] I will stop here and let others comment on your question. cheers, peter P.S. By the way, thanks for following through on the development of criteria! From owner-Big-Internet@munnari.oz.au Sat Nov 7 09:10:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02028; Sat, 7 Nov 1992 09:11:04 +1100 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02021; Sat, 7 Nov 1992 09:10:54 +1100 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA06857; Fri, 6 Nov 92 17:13:07 EST Received: by sword.bellcore.com;id 9211062208.AA21310 Message-Id: <9211062208.AA21310@sword.bellcore.com> Date: Fri, 6 Nov 1992 17:15:23 -0500 To: Craig Partridge From: dave@sabre.bellcore.com Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au > > >> I think the >> role of the IETF, as Internet Engineers, is to take bold steps when >> necessary, but only those which it is sure are going to work. > >Scott: > > Sigh, I think this is a hopelessly quixotic goal. There is no way that >we'll be sure that any of the changes we make for IPv7 will work until we >actually deploy IPv7 widely. Sorry, if this were the IRTF, I would agree--the rules we could apply 10, maybe even 5 years ago in "trying something new" don't apply today. The installed base is simply too large to cajole, coerce, or enthuse into buying into any solution that is high risk. And the vendors who have nurtured TCP/IP from a niche market to a cash cow aren't going to risk it, either. IMHO, this is a good thing: it proves that the technology has become valuable, in fact *invaluable*. IP nets *must* run non-stop, like telephone networks. I don't think we'll sell anything that has even the faintest scent of "science" as the next-gen IP. --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-Big-Internet@munnari.oz.au Sat Nov 7 09:55:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03739; Sat, 7 Nov 1992 09:55:46 +1100 (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 AA03734; Sat, 7 Nov 1992 09:55:24 +1100 (from craig@aland.bbn.com) Received: from port13.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA27536; Fri, 6 Nov 92 17:54:57 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA01990; Fri, 6 Nov 92 14:53:34 PST Message-Id: <9211062253.AA01990@aland.bbn.com> To: dave@sabre.bellcore.com Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Fri, 06 Nov 92 14:53:34 -0800 Sender: craig@aland.bbn.com >> Sigh, I think this is a hopelessly quixotic goal. There is no way that >>we'll be sure that any of the changes we make for IPv7 will work until we >>actually deploy IPv7 widely. > > > Sorry, if this were the IRTF, I would agree--the rules we could apply > 10, maybe even 5 years ago in "trying something new" don't apply today. > The installed base is simply too large to cajole, coerce, or enthuse > into buying into any solution that is high risk. And the vendors who > have nurtured TCP/IP from a niche market to a cash cow aren't going > to risk it, either. Dave: First off, no fair swiping at the IRTF -- it is not a bunch of wild-eyed crazies -- a good part of the reason that IP works today is because some of those IRTF guys rolled up their sleeves and fixed operational problems with TCP and IP. Most of them have more operational dirt under their finger nails than the average IETFer. OK -- now getting back to the question. Scott said we have something that we *know* works. I believe that's not possible. (If you can tell me how to *prove* that any one of the proposals will scale to N billion end-systems and 1 billion networks and I mean prove down to the last little bit and piece of the protocol and the routing protocols to go with it -- formally, mathematically, verifiably, then I know a lot of good mathematicians who'd like to talk with you. For example, I'm working with someone on formally verifying TCP this way and it is not easy. But TCP is far easier than verifying IPv7. So, all we will have is careful thinking, which is a long way short of *knowing*). So I don't think we can just assert we'll know -- we'll be kidding ourselves or waiting forever. At some point, we'll have to step boldly and trust our judgement (but have no proof). > IP nets *must* run non-stop, like telephone networks. I > don't think we'll sell anything that has even the faintest scent of > "science" as the next-gen IP. Well, I dunno about IP, but I know the phone networks are taking a big gamble. ATM is claimed to be the next generation telephone network and it includes a whole lot of "science" and crossed fingers. And I seem to recall some fumbles with SS7 and switching code which have made the "non-stop" telephone network stop. I'm not trying to be snide here -- just reminding folks that for all we like to think of ourselves as engineers, we're not in the same game as guys who build skyscrapers or roads or even silicon. They've got a lot of well-tried techniques that they use. I'll also note that when real engineers try to do new work, they sometimes fail too. We're trying something *no one* has done before -- the phone networks are the closest analog and they're not the same beast. Whatever proposal we pick for IPv7, we're buying into technical risks (not to mention marketing risks). Craig From owner-big-internet@munnari.oz.au Sat Nov 7 12:38:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09197; Sat, 7 Nov 1992 12:38:28 +1100 (from owner-big-internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05640; Sat, 7 Nov 1992 10:50:24 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB18788; Fri, 6 Nov 92 18:50:06 EST Date: Fri, 6 Nov 92 18:50:06 EST Message-Id: <9211062350.AB18788@mitchell.cit.cornell.edu> To: Craig Partridge From: Scott_Brim@cornell.edu Sender: swb@nr-tech.cit.cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au Well, of course, having a clear vision of what will work is fundamental to engineering talent. You can't ever be *sure*, and I'm sorry for using that word -- it's too strong. Change "is sure" to "has confidence" and read it again. Come to think of it, the Internet is so much to so many people now that I think we have to go further -- I think IETFers should be willing to bet their jobs on their recommendations for IPv7. This also probably adds a criterion to the list for IPv7, which is flexibility in the protocol architecture to allow for patching when faced with unexpected conditions. Scott At 11:51 11/6/92 -0500, Craig Partridge wrote: >> I think the >> role of the IETF, as Internet Engineers, is to take bold steps when >> necessary, but only those which it is sure are going to work. > >Scott: > > Sigh, I think this is a hopelessly quixotic goal. There is no way that >we'll be sure that any of the changes we make for IPv7 will work until we >actually deploy IPv7 widely. The best we can do is prove that some solutions >won't work, then proceed forward, ready to fix things. We cannot be sure >our solutions are going to work or that people will want to deploy them. >At best, all we can do is try to manage the risk of failure. > >Craig From owner-Big-Internet@munnari.oz.au Sat Nov 7 13:50:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11671; Sat, 7 Nov 1992 13:50:12 +1100 (from owner-Big-Internet) Return-Path: Received: from shiva1.cac.washington.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11666; Sat, 7 Nov 1992 13:50:05 +1100 (from gray@cac.washington.edu) Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA15898; Fri, 6 Nov 92 18:49:57 -0800 Date: Fri, 6 Nov 1992 17:52:38 -0800 (PST) From: Terry Gray Subject: Re: transition criteria To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au In-Reply-To: <9211062150.AA28228@goshawk.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Nov 1992 peter@goshawk.lanl.gov wrote: > [now comes the Subnets considered harmful part] > > We could decouple IP subnets from physical subnets. Why not > use {Area routing + host routes within an Area} as a strategy > for routing within a domain. We would then only use IP subnets to denote > routing areas which are collections of physical subnets. (yes, this is > not an original idea). > > The idea for routing within an AD/AS is to use OSPF or IS-IS to route > the areas and within level 1 areas simple use flat routing over the > hosts. Many site administrators would kiss the feet of the > organization which delivered them from the tyranny of mapping IP > subnets to physical subnets. Imagine managing 10 ethernets but not > worrying about IP subnet numbering on those networks. We would need to > have mechanisms of letting routers and hosts know which IP host > addresses are on their physical subnets. (ES-IS comes to mind). Peter, Regarding "Subnets considered harmful"... If we are talking about a new generation of software on the End Systems, I too would certainly want them self-configuring as in ES-IS, and I would expect this property to ease the mapping between address and physical subnet. But in the context of current software and current IP addresses, it is worth noting that subnets provide not only firewalls from broadcast storms, but also from address assignment errors (accidental or otherwise). Imagine managing *100* Ethernets where someone plugging in a new PC could potentially take a critical host out of service on *any* of those Ethernets simply by configuring the new PC with its IP address... We clearly need networks that are easier to configure, but I urge that we consider fault isolation as an even higher priority, regardless of whether the fault is hardware, programmer, net-manager, or user -induced. -teg From owner-big-internet@munnari.oz.au Sat Nov 7 14:40:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12875; Sat, 7 Nov 1992 14:41:01 +1100 (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 AA10811; Sat, 7 Nov 1992 13:27:06 +1100 (from craig@aland.bbn.com) Received: from port13.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA16193; Fri, 6 Nov 92 21:26:54 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA12112; Fri, 6 Nov 92 18:25:13 PST Message-Id: <9211070225.AA12112@aland.bbn.com> To: Scott_Brim@cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Fri, 06 Nov 92 18:25:12 -0800 Sender: craig@aland.bbn.com > Well, of course, having a clear vision of what will work is fundamental to > engineering talent. You can't ever be *sure*, and I'm sorry for using that > word -- it's too strong. Change "is sure" to "has confidence" and read it > again. Come to think of it, the Internet is so much to so many people now > that I think we have to go further -- I think IETFers should be willing to > bet their jobs on their recommendations for IPv7. This also probably adds > a criterion to the list for IPv7, which is flexibility in the protocol > architecture to allow for patching when faced with unexpected conditions. Scott: I can happily agree with this paragraph. I hope I didn't come off as too sharp in the reply to the initial message -- I'm becoming tremendously sensitive to precise wording of requirements. I don't think Frank and I are quite precise enough in the current draft of the criteria list, but precision in requirements is our goal. Regarding flexibility -- Frank beat on me hard (and justifiably) that the protocol needs to be extensible. Another reader pointed out to me that IETF ought to have complete control over the spec (so that we can easily make those change-of-a-bit modifications as experience with prototypes progresses). Are there other flexibility criteria that are important? Thanks! Craig From owner-Big-Internet@munnari.oz.au Sat Nov 7 16:24:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15864; Sat, 7 Nov 1992 16:24:43 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15861; Sat, 7 Nov 1992 16:24:33 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA23502; Fri, 6 Nov 92 22:24:19 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA02608; Fri, 6 Nov 92 22:24:18 MST Message-Id: <9211070524.AA02608@goshawk.lanl.gov> To: Terry Gray Cc: big-internet@munnari.oz.au Subject: Re: transition criteria In-Reply-To: Your message of Fri, 06 Nov 92 17:52:38 -0800. Date: Fri, 06 Nov 92 22:24:17 MST From: peter@goshawk.lanl.gov Terry, Fault tolerance is a very important property and I agree completely that it must be factored into IPv7. We must encourage the vendors to use good automated methods for address management which will help prevent the bad end states you describe. As you can tell I believe IPv4 will be around for a while. So from my perspective the time to do this is NOW, and to do it for IPv4, as well as for other protocols, such as IPv7. I guess I am not convinced that using fewer IP subnets for the same number of physical subnets will lead to an increased risk of broadcast storms. It does not seem to me that we would need to use multi physical subnet broadcasts. Perhaps I am missing something? thanks, peter From owner-Big-Internet@munnari.oz.au Sat Nov 7 17:49:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17855; Sat, 7 Nov 1992 17:49:42 +1100 (from owner-Big-Internet) Return-Path: Received: from shiva1.cac.washington.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17852; Sat, 7 Nov 1992 17:49:33 +1100 (from gray@cac.washington.edu) Received: by shiva1.cac.washington.edu (5.65/UW-NDC Revision: 2.27 ) id AA18294; Fri, 6 Nov 92 22:49:23 -0800 Date: Fri, 6 Nov 1992 21:47:43 -0800 (PST) From: Terry Gray Subject: Re: transition criteria To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au In-Reply-To: <9211070524.AA02608@goshawk.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 6 Nov 1992 peter@goshawk.lanl.gov wrote: > I guess I am not convinced that using fewer IP subnets for the same > number of physical subnets will lead to an increased risk of > broadcast storms. It does not seem to me that we would need to > use multi physical subnet broadcasts. Perhaps I am missing something? If "physical subnet" corresponds to "router interface" which in turn implies "broadcast firewall", I believe you are right (but presumably that would imply a different kind of ARP than we have today, no?) My specific concern had to do with address assignment, rather than broadcast storms (though I worry about all kinds of fault modes.) With IP, a router-enforced address hierarchy is the only thing that limits the scope of damage that an incorrect IP address could do. If a PC owner picks an address already in use by a colleague down the hall (on the same physical subnet), that's bad, but if the victim machine is in another department or building, that's even worse. My first choice is automatic configuration using prefix plus globally unique and hard-to-change numbers (like Enet addresses were originally intended to be.) But if we have a scheme (such as IPv4) where normal people can (accidentally or deliberately) choose an IP address in use by someone else, I want an administrative/address firewall that will limit the scope of such errors. I don't know how to do that if you give me a flat IP address space for all of my departments. Broadcast storms are not the only reason that bridged networks don't scale very well. -teg From owner-Big-Internet@munnari.oz.au Sat Nov 7 19:46:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20565; Sat, 7 Nov 1992 19:46:31 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20560; Sat, 7 Nov 1992 19:46:19 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11923>; Sat, 7 Nov 1992 00:46:03 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sat, 7 Nov 1992 00:45:57 -0800 To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal In-Reply-To: Your message of "Thu, 05 Nov 92 08:07:09 PST." <9211051607.AA01312@er.doe.gov> Date: Sat, 7 Nov 1992 00:45:47 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov7.004557pst.10779@skylark.parc.xerox.com> Dan Hitchcock wrote: > You state that when # of internet sites in a metro area reaches millions that > flat routing will be ok because sites are close geographically. I for one > see no reason why the length of the fibedrs between the routers makes this > problem easier. The memory bandwidth problems etc are exactly the same. If > the world comes to be dominated by small sites... a subnet with 2 pc's, a > tv a nintendo, and 5 kitchen appliances then flat metro addressing will > be dreadful. My proposed solutions for doing flat routing within a metro area generally involve some sort of database exchange or update from each of the providers in the metro, probably once every 24 hours. The benefit I was thinking of for geographic proximity is that the bandwidth to carry these potentially voluminous data exchanges is likely to be much cheaper within a metro area than long distance. However, it wouldn't be more than a few ten of megabytes, so maybe it's not such a big deal. So I'll change my claim: it will be feasible to do flat routing to millions of addresses, *regardless* of distance between routers. (But it only makes sense to me to do it on the scale of a single metropolitan area, i.e., the geographic area in which you might have to support millions of sites. Flat, long-haul routing would eventually have to deal with billions of sites and thousands of providers, and I hesitate to extrapolate our capabilies that far.) I disagree that such flat routing will necessarily be dreadful. A million entry database is not exceptionally large by current standards, and with memory being cheap and getting cheaper, it's not unreasonable to think about storing such a database in RAM, replicated on every router. If memory is not deemed cheap enough, we could still do it with disks and in-memory caches of only the currently-active addresses. (This message is probably going to generate more questions/challenges than it answers, but, I regret to say, I won't have any time to engage in further discussion of this topic until after IETF.) Steve From owner-Big-Internet@munnari.oz.au Sat Nov 7 20:14:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21337; Sat, 7 Nov 1992 20:14:58 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21331; Sat, 7 Nov 1992 20:14:39 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11932>; Sat, 7 Nov 1992 01:14:25 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sat, 7 Nov 1992 01:14:15 -0800 To: Robert Elz Cc: Big-Internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: pseudo-header for tuba In-Reply-To: Your message of "Thu, 05 Nov 92 11:58:04 PST." <22008.720993484@munnari.oz.au> Date: Sat, 7 Nov 1992 01:14:13 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov7.011415pst.10779@skylark.parc.xerox.com> Robert wrote, quoting me: > What makes you think that the proposed schemes > are unsuitable for an internet in which "every host ... > is 'mobile' all at once"? > > Well, one might be that at least both I have seen so far > seem to want the packets to travel to some kind of mobile > host server, identified by the mobile host's address (it > arranges for packets to come to it, then relays them one > way or another). However, what happens the whole original > addressing structure vanishes? If the chunk of address space containing the mobile host server gets moved somewhere else (i.e., changes prefix), then ideally the mobility mechanism would handle that too, recursively. (I.e., a packet sent towards the old prefix would reach a router that would redirect/tunnel it to the new prefix; when it reached the mobile host server in its new location, the packet would be redirected/tunneled to the mobile host.) > At least one of the proposals also expects "mobile" hosts to > live on a special (pseudo) subnet, which is not really possible > if every host is potentially movile, is it? None of the IP mobility proposals I know of (Columbia, Sony, IBM) require that all mobile hosts be on the *same* (pseudo) subnet. Each organization assigns some of its own subnet address space to mobile hosts belonging to that organization. > I agree that any new IP should define whatever host procedures are > needed to support mobility as part of the standard host specification, > so it won't be considered "special software". But what has that got > to do with deciding between the techniques currently proposed for IPv4 > and any other techniques? > > One is that we should be doing away with mobile host servers, > and any special tricks to make them work, if every host is to be > mobile, then the underlying support should just be there, including > address changes dynamically. Just as the standard internet software in every host should enable it to be mobile and to talk to other mobile hosts, the standard software in every router should enable it to serve as a mobile support router. Steve From owner-Big-Internet@munnari.oz.au Sun Nov 8 04:08:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01882; Sun, 8 Nov 1992 04:08:46 +1100 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01875; Sun, 8 Nov 1992 04:08:09 +1100 (from kre) To: Steve Deering Cc: Big-Internet@munnari.oz.au Subject: Re: pseudo-header for tuba In-Reply-To: Your message of Sat, 07 Nov 92 01:14:13 -0800. <92Nov7.011415pst.10779@skylark.parc.xerox.com> Date: Sun, 08 Nov 92 04:07:57 +1100 Message-Id: <21134.721156077@munnari.oz.au> From: Robert Elz Date: Sat, 7 Nov 1992 01:14:13 PST From: Steve Deering Message-ID: <92Nov7.011415pst.10779@skylark.parc.xerox.com> If the chunk of address space containing the mobile host server gets moved somewhere else (i.e., changes prefix), then ideally the mobility mechanism would handle that too, recursively. But how? Sure you can do it if there's enough of the original address space surviving that you have some idea how to route packets towards it - but how do you cope if there is no longer any sign of the original address, in any form, left in any routing database anywhere? That would mean that your local routers (assuming you have an open connection to my host whose old address space has vanished) would need to be acting as the mobile host server, and tracking where my host had moved to. So would everyone else's (as there's no possible way they could determine that yours were the right ones). If everyone's local environment needs the ability to track all mobile hosts around the globe, just in case an event like this one happens, then the mobile host server model seems to have totally broken down. If you're going to require that old addresses remain in the routing databases while there are still any active connections anywhere, perhaps for years, so that a mobility server can be located, then I believe you've lost any potential benefit of having people change their addresses based on their position in the global net topology changing. Handling that kind of event is one that I think should be done with the same basic mechanisms that we handle general mobility (that is, your more traditional "mobile host" is just a restricted case of this one). None of the IP mobility proposals I know of (Columbia, Sony, IBM) require that all mobile hosts be on the *same* (pseudo) subnet. No, I didn't mean to imply that. If that's how you interpreted what I wrote, then please accept this correction. Each organization assigns some of its own subnet address space to mobile hosts belonging to that organization. Yes, but if every host is potentially (or actually) "mobile" then surely every address will be on some pseudo-subnet or other, and so pseudo-subnets will be the only subnets existing. That doesn't seem rational. Answer one simple question... Do you really believe that the ideal way to handle mobile hosts (any hosts whose position in the net changes, requiring an address change to support routability to the host) is to send packets to the old location and then have them forwarded elsewhere? Does anyone? Disclaimer: For readers seeing this discussion for the first time, nothing herein is intended as a criticism of the mobile host drafts (any of them) for IPv4, which are constrained in lots of ways, and hence have to make hard choices. I am concerned only with what should be provided in IPv7 so the hard choices are no longer needed. kre From owner-Big-Internet@munnari.oz.au Mon Nov 9 05:51:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13730; Mon, 9 Nov 1992 05:51:21 +1100 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13727; Mon, 9 Nov 1992 05:51:14 +1100 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA25296; Mon, 9 Nov 92 05:51:18 +1100 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9211081851.AA25296@coombs.anu.edu.au> Subject: Future TCP-like authentication. To: big-internet@munnari.oz.au Date: Mon, 9 Nov 92 5:51:17 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Given that TCP has been a very successful protocol from the IP suite, I imagine that whatever version of IPv7 is adopted, there will be some substitute for it (even if only rewritten to work using CLNP/PIP/SIP, etc). Assuming that it is also port orientated, it is safe to assume that there will be some need for an "authentication" server (and/or MIB value). The way I see it, RFC-931 and all of its relatives are pretty much a 'hack' to provide the required information and it would seem much better (to me at least) for the same information to be (somehow) sent by *default* during the inital setup of the connection. The best way to do this, to me, seems to be through some sort of option(s) which the application could get a copy of which would alleviate the need for the server and the 'extra connection' used to gain the result (it becomes annoying when writing `real-time' network applications which really can't afford to wait). Are there any real objections to not performing this function through the protocol itself and requiring the use of an ident server ? This might fall into the "security" side of any future protocol, but, if you have ever traced crackers, you'll appreciate that it's nice to know who it is "on the other end" (though its quite often root or otherwise of no use :-O) and ident servers aren't really something I like to rely on - though more often than not, they're not even present. Sorry if this isn't quite the right 'time' to ask about this (or if it has been brought up before) but it is something which has been bugging me for quite a while and may well be left till people decide what to do with options (if they continue to be used). Darren. From owner-Big-Internet@munnari.oz.au Mon Nov 9 17:10:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08764; Mon, 9 Nov 1992 17:10:26 +1100 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08759; Mon, 9 Nov 1992 17:10:20 +1100 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA04394 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 9 Nov 1992 17:10:33 +1100 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA07094; Mon, 9 Nov 92 17:10:15 DST Message-Id: <9211090610.AA07094@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: EIDs again (was Re: Vote NO on R-L-G IP Address Allocation proposal) In-Reply-To: Your message of "Tue, 03 Nov 92 11:00:56 PST." <92Nov3.110109pst.10779@skylark.parc.xerox.com> Date: Mon, 09 Nov 92 17:10:14 +1100 From: Bob Smart > A technical solution that allows address changes to to occur >painlessly and automatically would certainly be preferred, if such a >solution can be devised. If the CLNP folks have a solution, I would love >to hear an explanation of it. In particular, I'd like to know: As usual Steve Deering asks very pertinent questions on how the EID/ address split will work. I've been hoping someone would attempt the answers. However a minor point: > If a host has multiple > prefixes (due to a transition period between one provider and > another, or due to the availability of multiple providers), how > does it decide which of those prefixes to use in the source > address field of any packets it sends? Here is an example of the extra flexibility you get from separating addresses from EIDs. Suppose we have a mask-and-match address system (like IPv4, SIP or CLNP), but with an EID structure (either in the address as in TUBA or separate as in TUNE). Now the problems with address translation (e.g. in the TCP pseudo-header) go away. There is no need for the host to know exactly what its own current address is. It can put put 0s, "this network", in the network number part of the source address. The router at the border of "this network" can change the source address to whatever is appropriate depending on the way the packet will leave the network. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Nov 9 22:10:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17876; Mon, 9 Nov 1992 22:10:55 +1100 (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 AA17872; Mon, 9 Nov 1992 22:10:44 +1100 (from backman@ftp.com) Received: from backman.homerun by ftp.com via PCMAIL with DMSP id AA10039; Mon, 9 Nov 92 06:10:26 -0500 Date: Mon, 9 Nov 92 06:10:26 -0500 Message-Id: <9211091110.AA10039@ftp.com> To: Craig Partridge Subject: Re: revised criteria list From: backman@ftp.com (Larry Backman) Cc: big-internet@munnari.oz.au Sender: backman@ftp.com Repository: babyoil.ftp.com Originating-Client: homerun One important addendum to >> >> 4.3. Transition >> >> CRITERION >> The protocol must have a straightforward transition plan >> from the current IPv4. >> .. .. >> >> The transition plan must address the following general >> areas of the Internet's infrastructure: >> + Host Protocols and Software >> + Router Protocols and Software >> + Security and Authentication >> + Domain Name System >> + Network Management >> + Operations Tools (e.g., Ping and Traceroute) >> + Operations and Administration procedures >> >> The impact on protocols which use IP addresses as data >> (e.g. DNS, SNMP and FTP) must be specifically addressed. >> >> Placement >> If the transition scheme is painful, no one will >> transition. But we should only transition if the >> protocol we transition to solves the scaling problems and >> is useful to use. It seems to me that any IPV4->IPV7 transition needs to address or at least identify a means by which 3rd party applications written to existing API's to an IPV4 stack won't be marooned. As a protocol vendor; if I need to change my stack and applications to address IPV7 no problem, I can control the timing and synchronization of a release such that I release app's that are both IPV4 & IPV7 aware. However; I cannot control or influence 3rd party applications written to an existing IPV4 API; typically they will lag the release of a protocol stack by at least 6-9 months. There are obviously ways that a stack vendor can play with the API to detect IPV4 or IPV7 addressing; however the issue is important enough that it should be detailed as part of the transition requirements. I'd hate to wait 6-9 months while a key mail or data base application was rev'ed to a new API. Larry Backman FTP Software From owner-Big-Internet@munnari.oz.au Tue Nov 10 01:41:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23564; Tue, 10 Nov 1992 01:41:23 +1100 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23561; Tue, 10 Nov 1992 01:41:13 +1100 (from dave@sabre.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA00234; Mon, 9 Nov 92 09:36:26 -0500 Date: Mon, 9 Nov 92 09:36:26 -0500 Message-Id: <9211091436.AA00234@worldlink.worldlink.com> From: David M. Piscitello To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Stretching > First off, no fair swiping at the IRTF Swiping? not... I was suggesting that one can always do research in the "background" of an operational network, but one typically encounters quite a bit of resistance if the research is brought prematurely into the network that provides 24-hr service. > OK -- now getting back to the question. Scott said we have something >that we *know* works. I believe that's not possible. stretching the point to make a point. Scott seems to have suggested that IP and CLNP have field experience, and based on their success, and our confidence in OSPF/ISIS routing, etc., he appears willing to conclude that they will scale well, but I don't recall him saying that they scaled absolutely to the maximum number of connected systems in the universe. (Lest you all flame at me, the use of "success" here is relative; mind you, I am not suggesting CLNP is as widely deployed and wildly successful as IP--sigh...I hope someday I won't have to type on rice paper every time I say something positive about CLNP) > Well, I dunno about IP, but I know the phone networks are taking >a big gamble. ATM is claimed to be the next generation telephone network I may be wrong, but believe the decision to cut over the voice network to ATM has not yet been made (my opinion, not necessarily that of my company nor my clients); this is simply good business, the telephone providers aren't going to risk or kill the cash cow for the sake of new technology. > some fumbles with SS7 and switching code who's swiping now? > Whatever proposal we pick for IPv7, we're buying into technical risks >(not to mention marketing risks). finally a point on which we agree. beyond the technical uncertainty, it is pretty obvious that the marketing risks are enormous, and "risking the cash cow" is not something vendors are going to be convinced to underwrite easily From owner-Big-Internet@munnari.oz.au Tue Nov 10 01:58:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23948; Tue, 10 Nov 1992 01:58:26 +1100 (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 AA23945; Tue, 10 Nov 1992 01:58:20 +1100 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA22889 (5.65/6.02); Mon, 9 Nov 92 09:58:08 -0500 Date: Mon, 9 Nov 92 09:58:08 -0500 From: Garrett.Wollman@UVM.EDU Message-Id: <9211091458.AA22889@sadye.emba.uvm.edu> To: big-internet@munnari.oz.au Subject: NAP-based addressing This idea came to me in a flash while doing something completely unrelated to networking last night. I think it looks like something of a cross between metro-based addressing and maybe something of Clark's Route Fragments, although those of you who are more awake than I am may think differently. First, to make Noel happy, I should define my terms. This proposal would probably work best under a split EID/address network; I *think* it could work (to some extent) with CLNP, provided you let the NSAPs get really long. So, the term ``address'' that I am using refers to a JNC-address, rather than an IPv4-style address. The term NAP, I think, may cause some confusion; my NAPs are in the general sense of wherever two networks meet, rather than the restricted sense used in the NSF solicitation. I know the confusion may be a problem, but I thought that NAP sounded more professional than LIX (Local Internet eXchange), my other alternative. The idea: Consider an average metropolitan area. In this area, there are some number of networking providers and a large number of clients of those providers. The providers have an interconnection agreement, so that they can exchange traffic within the area without using long-haul backbone circuits. The site of this interconnection is the NAP. The addressing hierarchy below the NAP is independently managed by each of the providers connecting there, but coordinated in such a way that the ``next level down'' addresses are unique to the NAP. In this way, a local-address-part relative to the NAP suffices to uniquely identify all the hosts in the area, with respect to any other local host. (I believe that this abstraction can be done recursively, so that routing load scales logarithmically with network size.) Now, what happens if we give each NAP knowledge of how to reach any other NAP in the world? If we can do that---and there's no reason why we can't, especially considering that there should be many fewer NAPs than hosts---then we can uniquely identify every host in the world with just ( NAP, local-address-part ). In order to send packets from one host to another, the sender needs only query its local NAP for an address fragment or fragments which will get it to the remote NAP (here is where policy can come in), and then combine the two parts in some network-layer-dependent way. (Address reversal, like in PIP, would save the recipient this work if it needs to reply.) Now here's how the address/EID split can help: the NAP has to have some knowledge of the networks below it, so it can include a server which, given an EID and domain name, will figure out an address fragment which will get from the NAP to the requested endpoint. This solves the PIP problem of letting addresses vary but still having lookups in the DNS: the DNS contains the tuple ( EID, NAP ), and the mapping to the address is done by a server at the remote NAP---which you have to be able to get to anyway in order to talk to your intended recipient. I've got to run right now, but I'll send a message later with an example of how I think this might work. -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 From owner-Big-Internet@munnari.oz.au Tue Nov 10 02:59:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25295; Tue, 10 Nov 1992 02:59:18 +1100 (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 AA25277; Tue, 10 Nov 1992 02:59:09 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13517; Mon, 9 Nov 92 10:58:59 -0500 Date: Mon, 9 Nov 92 10:58:59 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211091558.AA13517@ginger.lcs.mit.edu> To: deering@parc.xerox.com, dkatz@cisco.com Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (Note: I have thought a lot about metro-addressing, and have a long note to send in, but I'm going to delay sending it in since I'm about to restart the thread on how aggressive we should be on technical change, and I don't want the list to go into melt-down. Here's a quick comment on a point in this piece of mail...) (In graph-theoretic terms, the set of nodes and links within a metro area are simply required to form a connected graph. That's all that is required to enable routers outside the metro to abstract the metro as a single node.) Note that even if the area of the graph labelled as a single object is (or, more importantly, becomes) discontiguous, I don't think it should be the end of the world. The reason is that, to the routing, a metro area *configured* in two pieces is basically indistinguishable from a metro *divided* into two pieces by a failure, and I think this is an eventuality we should plan for *and* handle. (It's the old "partitioned network" problem that IP has been worrying about for 15 years...) You have two basic ways of dealing with the possibility: i) make sure that there is enough excess connectivity that it can "never" happen, and accept that if it does, the system will go to hell in a handbasket (this is not necessarily unreasonable engineering), or ii) provide some mechanism for dealing with it. I'm more inclined to the second, since it gives a system which is more robust, and in which you don't have to spend resources to provide backup conectivity you may not use much. However, I can see an argument the other way; who thinks this is the right thing, and why? There are two basic ways of handling this. The first (which is what IS-IS does to heal level 1 area partitions, for reasons that will become clear) is that you can have the two parts create a "tunnel", which ties the two parts together. The alternative is to advertise the two halves seperately in the routing. (I.e. if A.B splits into A.B.1 and A.B.2, routing within A will carry both, instead of just A.B). The latter option doesn't need to create any extra mechanism, allows packets to take the optimal route, and also has a limited scope of effect (i.e. you only have to advertise A.B.* within A). One bug is that if the split is not "clean", it may be difficult to list exactly which parts of A.B are within A.B.1, and which within A.B.2 (which is why IS-IS uses a tunnel to heal partitions, since it track individual hosts within a level 1 area). I'm not sure which one of these two I prefer. I like the latter, but then I think about the potential cost... I guess if you try and limit the number of items which can appear at any level (i.e. if you don't have too many A.B.n), then you also minimize the cost of repairing a partition that way. Noel From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:23:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25843; Tue, 10 Nov 1992 03:23:50 +1100 (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 AA25837; Tue, 10 Nov 1992 03:23:43 +1100 (from kasten@ftp.com) Received: by ftp.com id AA17584; Mon, 9 Nov 92 11:23:33 -0500 Date: Mon, 9 Nov 92 11:23:33 -0500 Message-Id: <9211091623.AA17584@ftp.com> To: gray@cac.washington.edu Subject: Re: transition criteria From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au > We clearly need networks that are easier to configure, but I urge that > we consider fault isolation as an even higher priority, regardless of > whether the fault is hardware, programmer, net-manager, or user -induced. Terry I think that our "Configuration, Administration, and Operation" criterion covers part of this. Fault isolation would be under "Robust Service" -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:23:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25840; Tue, 10 Nov 1992 03:23:49 +1100 (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 AA25835; Tue, 10 Nov 1992 03:23:40 +1100 (from kasten@ftp.com) Received: by ftp.com id AA17577; Mon, 9 Nov 92 11:23:28 -0500 Date: Mon, 9 Nov 92 11:23:28 -0500 Message-Id: <9211091623.AA17577@ftp.com> To: Craig Partridge Subject: Re: transition criteria From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au Craig, There are a couple of other aspects to the "routing energy" problem that we ought to be able to quantify to help with these predictions. 1. More routes means that more routing protocol traffic will occur, requiring routers to spend more time generating and receiving these packets and then processing them. What's the processing load like on routers in various places? How much time do, e.g., NSFNET backbone routers spend digesting routing packets, etc, etc? 2. How much time does it take to look a route up in the tables? Again, this is some function of the number of routes that are in the tables. > Hi folks: > > I'm starting to a few comments about the recent draft of the list of > criteria (thanks!) and there's one comment I'd like to get wider advice > about. > > Exactly how close is routing table disaster? > > To motivate the question, let me give a couple of sample answers and their > implications: > > * Disaster will come in less than two years. > > If this is the case, then making the routing tables smaller becomes > something we have to achieve during transition, when we have mixed > networks of IPv4 and IPv7 in operation. So we'd need to add a > requirement that the transition plan help shrink routing tables. > > * Disaster will come in more than five years. > > In this case, we can hope that we have IPv7 widely enough deployed > that we don't need to worry about shrinking routing tables during > the transition plan (though we presumably need to worry about > not increasing the rate of growth of routing tables, yes?). > > Advice much appreciated. I've heard folks argue all sides, so carefully > reasoned replies which cover questions like current rate of growth and > availability of additional memory over the next few years, would be most > useful. > > Thanks! > > Craig > -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:23:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25849; Tue, 10 Nov 1992 03:24:06 +1100 (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 AA25845; Tue, 10 Nov 1992 03:23:59 +1100 (from kasten@ftp.com) Received: by ftp.com id AA17588; Mon, 9 Nov 92 11:23:35 -0500 Date: Mon, 9 Nov 92 11:23:35 -0500 Message-Id: <9211091623.AA17588@ftp.com> To: avalon@coombs.anu.edu.au Subject: Re: Future TCP-like authentication. From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au Darren, First, TCP is not a part of the charter of the Big-Internet activities. With the exception of dealing with those parts of TCP that have IP-v4 dependencies (the pseudo-header) we are not touching TCP. Second in the IPv7 criteria document that Craig Partridge and I wrote, we do have a criterion for Security in IPv7. As the Internet becomes more of a public utility security will be more and more important. > Given that TCP has been a very successful protocol from the IP suite, > I imagine that whatever version of IPv7 is adopted, there will be some > substitute for it (even if only rewritten to work using CLNP/PIP/SIP, etc). > Assuming that it is also port orientated, it is safe to assume that there > will be some need for an "authentication" server (and/or MIB value). -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:47:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26400; Tue, 10 Nov 1992 03:48:11 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211091648.26400@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26393; Tue, 10 Nov 1992 03:47:57 +1100 (from ULLMANN@PROCESS.COM) Date: Mon, 9 Nov 1992 11:44 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Cc: ULLMANN@munnari.oz.au Subject: about being conservative in designing IPv7 Hi, Just a thought: I think we have arrived at the point where we ought to remind ourselves of the suceptibility to, and dangers of, Second System Syndrome. ---- I believe IP works, and has been so successful, precisely because it doesn't load anything into the network layer that isn't utterly required; it requires the absolute _minimum_ of actual systems integration at that layer. One IP module can make decisions anyway it likes, do just about any kind of magic, and as long as the datagram _usually_ arrives successfully at the input interface of some other IP, somewhat closer to the destination, it works. And works well. As soon as you introduce network layer VCs, or flows, or mobile-host redirection, or any of a number of similar things, it requires a substantially higher level of network wide integration, and will cure you of the success crisis. (If you think that last para is in favor of the higher level of integration, read it again. And recall what happens when the protagonist of Le Guin's _The_Lathe_of_Heaven_ wishes for an end to starvation rsulting from over-population ... :-) ---- I recall thinking some time ago about flow reservation, with or without VCs, trying to figure out how to do it. I have since learned that it wasn't needed for my imagined environment. (That was 1974, and I was trying to figure out how to share out 300-600bps links between remote terminal and mail sessions.) It turns out that the bandwidth expands faster than the applications. We can build all sorts of structure in to do this, and to try to restrict the (effective) topology to something we think we can route, but I can see our children cursing us for not anticipating their world of ubiquitous 10Kmip processors and Tbps fiber optics, in which all that structure is simply in the way. (Just as, for example, the strict catenet model doesn't model the real world of partial-mesh nets, and the VC model is the limiting factor in the international PSDN connections I use today for IP.) ---- Someone, (like Noel for example :-), is likely to say that I am too conservative; that I am arguing against neat new future network capabilities like flows because they are too agressive. Quite the contrary, I am taking a very radical position: we know how to do flows, we have implemented them many times, as virtual circuts, and as pre-reserved bandwidth, from "reserved copper" to FR SVCs. They just get in the way, denying use of bandwidth that would be entirely sufficient if it was pooled. Flows are not new: they are obsolete. With my very best regards, Robert [Before you bang on that reply key to say something like "But OF COURSE ...", just stop to think "But what if the OF COURSE isn't true at all ..."] From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:48:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26409; Tue, 10 Nov 1992 03:48:50 +1100 (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 AA26406; Tue, 10 Nov 1992 03:48:44 +1100 (from kasten@ftp.com) Received: by ftp.com id AA18357; Mon, 9 Nov 92 11:48:27 -0500 Date: Mon, 9 Nov 92 11:48:27 -0500 Message-Id: <9211091648.AA18357@ftp.com> To: dave@sabre.bellcore.com Subject: Re: Criteria for selecting IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au > IP nets *must* run non-stop, like telephone networks. I > don't think we'll sell anything that has even the faintest scent of > "science" as the next-gen IP. Yup. But, we must also continually push the net to "better" protocols, applications, and services. If we don't, the net will stagnate -- it would be as if the phone system stayed with mechanical stepper switches and rotary dials.... Sometimes these advances are relatively easy (technologically) such as network management. Sometimes they will be difficult IPv7. The former seem to be things that we can graft on top of existing technologies and can be developed, tested, and deployed incrementally. The latter seem to require wholesale changes to large portions of the community in order to provide any benefits. This is why, when we make such large and sweeping changes, we better get as much as we can. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Nov 10 03:53:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26588; Tue, 10 Nov 1992 03:56:25 +1100 (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 AA26462; Tue, 10 Nov 1992 03:53:11 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13922; Mon, 9 Nov 92 11:53:06 -0500 Date: Mon, 9 Nov 92 11:53:06 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211091653.AA13922@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Vote NO on R-L-G IP Address Allocation proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Steve, some observations and mis-understanding clearups. The routing suboptimality that is the consequence of hierarchical addressing/ routing shows up as follows: the path between any two hosts on the Stanford campus is constrained to follow links internal to the campus, which means the routing will not exploit external paths that might be "shorter" under some metric; This is not necessarily so (and perhaps you were alluding to this when you used the term "hierarchical addressing/routing", but I'm not sure). It's only true if you make the 'routing abstraction action' boundaries the same as the addressing abstraction boundaries; i.e. if you don't distribute routes to A.B outside A. (People sometimes call this 'strict hierarchical routing', which is why I wasn't sure if you were alluding to this or not.) Right now, in the Internet (with the exception of OSPF, pretty much) we *do* follow this rule (the two sets of boundaries are the same), although Mogul and I did subnets this way more to allow an interoperable deployment of subnets than anything else. It's pretty easy, in *either* Destination Vector *or* Link State (map distribution actually, btut the name seems to have stuck) to provide routing which isn't limited in this way, by allowing information to leak across abstraction boundaries in a limited way. The problem, of course, is to do so, but in a way which does not cancel out the efficiencies you hope to gain from hierarchical addressing in the first place! [Another Chiappa routing conjecture you can all ignore if you are busy. Defining the cost of hierarchical routing Ch as (Cr + Cn), using the old definitions of those, it's probably possible in most simple meshes (i.e. ones in which all links have a single metric, and no policy routing) to define an addressing hierarchy which produces 'optimal' routing (i.e. traffic between all source-destination pairs take a path of the same cost as it would in a non-hierarchical addressing system which computes optimal routes), but where Ch < Crn, where Crn is Cr for the non-hierarchical system. I said most, not all, for the reason that you can probably construct corrupt topologies in which abstraction doesn't do you any good, but I can't think of any off the top of my head. Of course, given the caveats (single metric, not policy, etc) this conjecture is utterly useless in the real world, but it's an interesting intellectual exercise.] However, I am advocating the use of administrative or geographic criteria for determining the boundaries between those contiguous chunks of topology. Pardon me, but this isn't *all* you are advocating, right? (I'm not being sarcastic, just making sure I understand you completely... since we seem to be having problems with this! :-) You also want to have the topology follow geography, to allow geographic criteria to be used in picking the abstraction boundaries, and you also want to use geographic criteria to allow clients to switch providers without changing their 'address', right? Using such criteria can yield significant network management benefits that are much more important than achieving the best possible routes with the lowest possible routing overhead. You seem to be advocating a more dynamic choice of addressing boundaries, based on some sort of ill-defined, multi-dimensional optimization of routing costs, some of which, you admit, are uncomputable or unquantifiable. Well, I guess I am being unclear. When I refer to things like the effect of thinning on how you do the abstractions, I'm sort of agreeing with your first point; you want to abstract things along policy boundaries, etc. (More on this in the longer note on metro-addressing.) I am most distinctly *not* advocating making the abstraction boundaries those which will produce the absolute minimum cost of routing, for many reasons, among them that the true costs are in fact uncomputable, as you point out. They will also quickly become non-optimal, etc, etc. I *am* saying that we may want to change the abstraction boundaries *as the topology changes*, though, but I haven't given any formal rule as to when we would do so. > If you want to have a single addressing hierarchy, you'll have to > assign a single cost metric to each edge. What shall that metric be? > > I don't agree with your premise, which I think comes from a hop-hop > distributed computation view of routing. No, it has nothing to do with hop-by-hop anything. ... You said your addressing hierarchy is chosen to minimize Cr + Cn for such a graph. I ... assumed that the minimization was something you intended to compute directly from the graph... However, to compute Cn, as you defined it in your earlier message, you would have to at least assign a weight to each link, in order to compute how much each path deviates from optimal. If you assign multiple weights to each link, there is no longer a well-defined optimal path between any two nodes. Another confusion. I was not planning to compute either Cn (since to do so, as I mentioned, you would need a complete traffic model, including all the source policies), or the maximally optimal abstraction hierarchy. When you linked "a single addressing hierarchy" to "a single cost metric to each edge", it wasn't clear to me that you were referring solely to computing Cn. I *thought* you were trying to say that you somehow needed a single metric if you were going to have a single abstraction hierarchy, which of course does not follow. A map-based system can provide effectively optimal qos/policy routing *even in the presence of a single abstraction hierarchy*, provided that it has an escape to allow gathering of more complete topology information (similar to the incoming abstraction control in Nimrod). My response referring to the fact that due to the distributed nature of the route computation in DV routing systems, it's much harder (basically impossible, as effectively conceded by the progression from BGP/IDRP to Unified) to do such routing in a DV system in which you have a more extensive metric semantics. I don't think it's particularly useful to talk about a single "optimal abstraction hierarchy" for any given topology, unless you can define "optimal" a lot more concretely and rigorously than you have so far. Well, since "optimal" is in the eye of the beholder in a system with a lot of policy in it, I'm unsure whether *any* single abstraction hierarchy will do for everyone (which was Martha's point). I'm mostly defining all this stuff, as I have indicated previously, to allow a clear mental framework in which to consider real designs. (Just because we couldn't compute the Schroedinger wave functions for complex molecules didn't mean they weren't useful functions!) Noel From owner-Big-Internet@munnari.oz.au Tue Nov 10 04:59:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29129; Tue, 10 Nov 1992 04:59:55 +1100 (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 AA29122; Tue, 10 Nov 1992 04:59:30 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25164; Mon, 9 Nov 92 12:59:11 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA09955; Mon, 9 Nov 92 09:57:28 PST Message-Id: <9211091757.AA09955@aland.bbn.com> To: Robert L Ullmann Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Mon, 09 Nov 92 09:57:28 -0800 Sender: craig@aland.bbn.com Robert: Yep, Second System Syndrome is a concern (though I'll note that TCP/IP was the second system version of NCP, and TP4/CLNP is widely viewed as the second system version of TCP/IP). I think one of the great virtues of the way Steve Deering is going about SIP is that he's refusing to put stuff in unless convinced he understands why the field belongs there and what will be done with. But I'm not quite sure that Second System Syndrome fully applies here. As a community, we've been pretty conservative about change, and will likely to continue to be. The current situation is that we're caught in a world of conflicting timetables. We were probably going to have modify IP to support flows (and I'll talk about why below), mobility, etc., sometime in the next five years or so. Now the routing and addressing problem has pushed the timetable for fixing IP forward to *now*. The vision I fear is ourselves cursing ourselves five years from now (for not biting off the whole problem) as we discover our user base asking us to all to scrap this IPv7 stuff and build a real multimedia Internet. I'll note suggests from folks that perhaps we are too worried about the routing/address problem (that there's time yet) makes it even more important we think about enhancements. Flow stuff in the appendix for interested parties. Craig ========================= Why We Need Flows There exists an argument, that roughly summarized, says that we don't need to worry about flow setup because we will be able to buy extra bandwidth so cheaply that we can always keep the network underloaded. Experience to date has been that this is not always true, and furthermore, Nagle showed that you'll suffer horrendous queuing delays in routers connecting mismatched links even if queueing is infinite. In short, we cannot expect to buy our way out of queueing problems. So we have to do something to control queueing practices in gateways. This "something" is what a number of researchers generically refer to as "flows." NOTE: Flows != VCs. One option is to simply have two classes of traffic - high priority and low priority. Require users who want high priority traffic to do a simple setup in which they express their bandwidth needs and the network says yes or no. The network limits high priority traffic to about 50% of load, and refuses setups after that limit. Low priority traffic gets discarded if it interferes with high-priority requirements on queueing delays. To avoid cheating, high priority packets have to be tagged with some sort of permit saying ("yes, I'm from flow XXX that you agreed to admit.") More sophisticated schemes try to do a little something smart in the routers to better juggle the traffic load. Again, they require something that says "I'm an IP packet in flow XXX that you know how to handle specially." There's some evidence building up that one can do reasonably simple things in routers (even have many routers treat all packets the same). But there needs to be something in the IP header that tags the flow. From owner-Big-Internet@munnari.oz.au Tue Nov 10 05:58:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00675; Tue, 10 Nov 1992 05:58:42 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211091858.675@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00663; Tue, 10 Nov 1992 05:58:29 +1100 (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, 9 Nov 1992 18:57:39 +0000 To: Craig Partridge Cc: big-internet@munnari.oz.au In-Reply-To: Your message of "Mon, 09 Nov 92 09:57:28 PST." <9211091757.AA09955@aland.bbn.com> Date: Mon, 09 Nov 92 18:57:37 +0000 From: Jon Crowcroft >Why We Need Flows > > There exists an argument, that roughly summarized, says that we don't >need to worry about flow setup because we will be able to buy extra bandwidth >so cheaply that we can always keep the network underloaded. Experience >to date has been that this is not always true, and furthermore and in sup[port of this - the funding model for shared international links would benfit ever so slightly from flows - specially where there are several mission oriented, and serveral more casual (less causal) agencies.. jon From owner-Big-Internet@munnari.oz.au Tue Nov 10 07:53:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03978; Tue, 10 Nov 1992 07:54:26 +1100 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03938; Tue, 10 Nov 1992 07:53:52 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11833>; Mon, 9 Nov 1992 12:53:26 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 9 Nov 1992 12:53:17 -0800 To: postel@isi.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: IPv6? Date: Mon, 9 Nov 1992 12:53:06 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov9.125317pst.10779@skylark.parc.xerox.com> Jon, Has IP version number 6 been officially assigned yet, or are you aware of any unofficial usage of version number 6 (perhaps by ST-II?)? Steve From owner-Big-Internet@munnari.oz.au Tue Nov 10 08:24:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05167; Tue, 10 Nov 1992 08:24:16 +1100 (from owner-Big-Internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05159; Tue, 10 Nov 1992 08:24:05 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA16744; Mon, 9 Nov 92 13:23:39 PST Date: Mon, 9 Nov 92 13:23:39 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211092123.AA16744@saffron.acc.com> To: ULLMANN@process.com, craig@aland.bbn.com Subject: Flows Cc: big-internet@munnari.oz.au >> More sophisticated schemes try to do a little something smart in the >> routers to better juggle the traffic load. Again, they require >> something that says "I'm an IP packet in flow XXX that you know how >> to handle specially." I'm not at all certain that the router needs special information from the host to accomplish this. We have deployed a Fair Queuing technology which keys directly off the source and destination addresses and a bit of other data, and is otherwise host and protocol independent. If you depend on something from the host, then only the hosts and protocols that provide it will benefit from it. That's kind of like trumpeting support from Frame Relay FECN and BECN as a solution in an AppleTalk or NetWare world; they don't provide the necessary network layer counterparts, and need for the router to do the right thing anyway. Fred .com Subject: IPv6? Date: Mon, 9 Nov 1992 12:53:06 PST Sender: Steve Deering From: Steve Deering Jon, Has IP version number 6 been officially assigned yet, or are you aware of any unofficial usage of version number 6 (perhaps by ST-II?)? Steve From owner-Big-Internet@munnari.oz.au Tue Nov 10 09:16:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07124; Tue, 10 Nov 1992 09:16:41 +1100 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07115; Tue, 10 Nov 1992 09:16:25 +1100 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA06576; Mon, 9 Nov 92 14:16:11 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA22727; Mon, 9 Nov 92 17:16:08 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA00703; Mon, 9 Nov 92 17:13:05 EST Date: Mon, 9 Nov 92 17:13:05 EST From: Frank T Solensky Message-Id: <9211092213.AA00703@fenway.andr.UB.com> To: deering@parc.xerox.com Subject: Re: IPv6? Cc: big-internet@munnari.oz.au >Has IP version number 6 been officially assigned yet, or are you aware of >any unofficial usage of version number 6 (perhaps by ST-II?)? Steve -- As far as I (now) know, IPv6 doesn't exist.. I had been under the impression that IPv6 == STv2 a few months ago when this question came up on the Big-I list, but it was pointed out to me that STv2, like STv1, used a version number set to 5 in the IP header. -- Frank From owner-Big-Internet@munnari.oz.au Tue Nov 10 09:29:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07556; Tue, 10 Nov 1992 09:29:45 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211092229.7556@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07552; Tue, 10 Nov 1992 09:29:35 +1100 (from clynn@BBN.COM) Date: Mon, 9 Nov 92 17:22:36 EST From: Charles Lynn To: Steve Deering Cc: postel@isi.edu, big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: IPv6? Folks, ST-II (RFC 1190) uses IPv5, as does ST(-I) (IEN 119). Charlie From owner-Big-Internet@munnari.oz.au Tue Nov 10 10:54:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10420; Tue, 10 Nov 1992 10:55:33 +1100 (from owner-Big-Internet) Return-Path: Received: from muri.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10392; Tue, 10 Nov 1992 10:54:56 +1100 (from kre) To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: about being conservative in designing IPv7 In-Reply-To: Your message of Mon, 09 Nov 92 11:44:00 -0500. Date: Tue, 10 Nov 92 10:54:50 +1100 Message-Id: <412.721353290@munnari.oz.au> From: Robert Elz Date: Mon, 9 Nov 1992 11:44 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) Others have commented on the question of whether flows are needed, and whether bandwidth will always be more than needed, so I will just throw in one more remark... but I can see our children cursing us for not anticipating their world of ubiquitous 10Kmip processors and Tbps fiber optics, in which all that structure is simply in the way. This I don't see as likely .. structure is easy to discard, if it turns outto be an unnecessary burden, it can simply be ignored, what you have then is an unstructured space that just happens to be arranged in a peculiar way that you can ignore (and which would have been possible if the structure had never been there). What's difficult is imposing structure on anarchy - for which all the evidence needed is the discussions now on whether sites can or should change their addressing to fit the structure we suspect may be necessary. So, I doubt our descendants will curse us for giving them a structured world that they're free to ignore, they may very well curse us for missing the opportunity to build a rational system that they then have no hope of rationalising without starting over (which is what we're basically proposing now). kre From owner-big-internet@munnari.oz.au Tue Nov 10 11:05:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10805; Tue, 10 Nov 1992 11:05:59 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211100005.10805@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07877; Tue, 10 Nov 1992 09:40:08 +1100 (from clynn@BBN.COM) Date: Mon, 9 Nov 92 17:35:46 EST From: Charles Lynn To: Fred Baker Cc: ULLMANN@process.com, craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Flows Fred, > We have deployed a Fair Queuing technology which keys directly off > the source and destination addresses and a bit of other data, and > is otherwise host and protocol independent. For this to be workable for real-time traffic, at least in an environment where there is not more bandwidth than demand, you have to specify what "a bit of other data" is. I.e., all traffic between A and B should not be treated the same. Also, all traffic between those two hosts for a particular protocol should not be treated the same. It is not clear that all traffic between A/port A and B/port B should be treated the same (besides, the protocol may not use ports, or may have them in some place that vendor X does not include in "a bit of other data"). It seems to me that only the application really knows how it would like its traffic to be treated, and specifying, maybe packet by packet, a flowid (made globally unique by the source EID) is the easiest may to get maximal flexibility that is independent of transport/application protocol. Charlie From owner-Big-Internet@munnari.oz.au Tue Nov 10 11:39:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11844; Tue, 10 Nov 1992 11:41:27 +1100 (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 AA11777; Tue, 10 Nov 1992 11:39:48 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA09279; Mon, 9 Nov 92 19:39:27 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15564; Mon, 9 Nov 92 16:38:04 PST Message-Id: <9211100038.AA15564@aland.bbn.com> To: fbaker@acc.com (Fred Baker) Cc: big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Mon, 09 Nov 92 16:08:54 -0800. <9211100008.AA18324@saffron.acc.com> From: Craig Partridge Date: Mon, 09 Nov 92 16:38:03 -0800 Sender: craig@aland.bbn.com Hi Fred: The purpose of flows is to tell the router how to schedule the outbound packets. That means both managing the queues in the router and also managing the bits on the outbound line (by deciding what goes out when). Let's take your scheme. If I show up and say I need, say 100 Kbits/s with bursts to 385 Kbits/s over the local T1 for the next two hours for a video conference, how does your system handle the problem? (Note, fair queueing can handle this request -- Parekh proved that. What I need is some way for the fair queueing scheme to recognize and schedule my datagrams. Note too that I may be doing things like FTPing new software to my host during the video conference, perhaps from another conference machine -- so one can't discriminate just on src/dst pairs or my FTP may screw my video). Certainly in the current world, where there are no crazy applications like this one (except during IETFs), schemes to identify different types of traffic and divide bandwidth accordingly work just fine. But those crazy IETF applications are showing up more and more (witness the MBONE). Craig From owner-big-internet@munnari.oz.au Tue Nov 10 12:06:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12596; Tue, 10 Nov 1992 12:06:46 +1100 (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 AA07464; Tue, 10 Nov 1992 09:26:46 +1100 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08493; Mon, 9 Nov 92 14:26:29 -0800 Received: by us1rmc.bb.dec.com; id AA28734; Mon, 9 Nov 92 17:23:59 -0500 Message-Id: <9211092223.AA28734@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 9 Nov 92 17:24:00 EST Date: Mon, 9 Nov 92 17:24:00 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 09-Nov-1992 1726" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: ideas from AppleTalk Since I have referred to protocol ideas from AppleTalk a few times on this list, I have gotten a couple of private messages asking me to list some. The following three are the ones that occur to me immediately. I'll simplify them a bit for this presentation. I think they were new ideas with AppleTalk although I'm sure some of them have been adopted by other protocol suites. (1) Dynamic host address determination. When a machine first comes up on a network, it picks an ID and tests to see that there is no other machine up on its local network with the same ID. If not, it uses that ID. If there is another machine with the same ID, then it tries a different one. (It also remembers this in non-volatile memory so that it will try the same ID first when it comes up again.) This host ID (called the AppleTalk node ID) is 8 bits and gets combined with a 16 bit network number learned from a router to form a full 24 bit AppleTalk node address. (2) Zones. A zone is a named subset of an AppleTalk network. Each host is in a zone. While zones frequently refer to geographic or topological parts of a network, the cute thing is that they need not have any relationship to the network structure. When you bring up a scrolling list of resources, such a printers, to pick between, you normally select which zone you are interested in and just get a list for that zone. Unfortunately, it's not clear to me that these non-topological zones scale to a hugh Internet. (3) Distributed services directory. The AppleTalk name binding protocol enables each host to provide the part of the diretory that relates to the services it offers. When seeking services a broadcast message is sent out to the hosts of interest which can use various wildcarding looking for matches on service type, sevice name, and zone, all of which are character strings. Each host with any services for which information was requested replies. Donald From owner-Big-Internet@munnari.oz.au Tue Nov 10 14:18:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15932; Tue, 10 Nov 1992 14:18:56 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15917; Tue, 10 Nov 1992 14:18:15 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA05466; Mon, 9 Nov 92 20:17:57 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA00643; Mon, 9 Nov 92 20:17:55 MST Message-Id: <9211100317.AA00643@goshawk.lanl.gov> To: Craig Partridge Cc: fbaker@acc.com (Fred Baker), big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Mon, 09 Nov 92 16:38:03 -0800. <9211100038.AA15564@aland.bbn.com> Date: Mon, 09 Nov 92 20:17:55 MST From: peter@goshawk.lanl.gov Craig, Granted that you can not simply look into the src/dst pair, would it be possible to set a flag in the packet to indicate that it is fair game to look into proto and port numbers? Sounds gross, but this would accomplish the desired result, wouldn't it? Is there some gain in running multiple logical flows over a single flowid? This would hint at the desirability of structure in the flowids. peter P.S. I clearly don't know as much about flows as I should ... From owner-big-internet@munnari.oz.au Tue Nov 10 16:01:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18919; Tue, 10 Nov 1992 16:01:09 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10930; Tue, 10 Nov 1992 11:10:26 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA02622; Mon, 9 Nov 92 17:10:15 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA14988; Mon, 9 Nov 92 17:10:13 MST Message-Id: <9211100010.AA14988@goshawk.lanl.gov> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Subject: Re: Flows Date: Mon, 09 Nov 92 17:10:13 MST From: peter@goshawk.lanl.gov Craig, Let's assume flows are a requirement. What are the characteristics of the flow field? How big does is have to be? What are its scaling properties? Will we need the answers before the IESG will decide what to recommend for IPv7 before the end of this year? cheers, peter From owner-big-internet@munnari.oz.au Tue Nov 10 17:19:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21419; Tue, 10 Nov 1992 17:19:50 +1100 (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 AA11614; Tue, 10 Nov 1992 11:33:45 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA08597; Mon, 9 Nov 92 19:33:09 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15554; Mon, 9 Nov 92 16:31:27 PST Message-Id: <9211100031.AA15554@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Mon, 09 Nov 92 17:10:13 -0700. <9211100010.AA14988@goshawk.lanl.gov> From: Craig Partridge Date: Mon, 09 Nov 92 16:31:26 -0800 Sender: craig@aland.bbn.com > Let's assume flows are a requirement. What are the characteristics of > the flow field? How big does is have to be? What are its scaling > properties? Approximately 32-bits (a few less is fine) which one can treat as a magic cookie. Current discussions call for a bit in the field to indicate if the router can forward the datagram even if it doesn't know about the flow or whether knowledge about the flow is required if the router is to be able to route the right way. (Steve Deering was tasked by E2E to write this up -- I'm writing what I remember from the discussion). There are a couple of ways to scale this. One way has routers in backbones simply forwarding without reference to the flow field (on the grounds that the law of large numbers should apply in backbones). Another way is combining the flow id with the part of the destination address that gets looked up (makes flow id allocation a bit tougher). My key concern is that the bits be in the header (not in an option -- the goal of the flow field is to give packets *preferential* service, not inferior service via the slow option-handling path). Last details can be worked out during the testing of the proposed IPv7. Craig From owner-big-internet@munnari.oz.au Tue Nov 10 17:55:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22501; Tue, 10 Nov 1992 17:55:46 +1100 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12387; Tue, 10 Nov 1992 12:01:25 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA18400; Mon, 9 Nov 92 17:00:58 PST Date: Mon, 9 Nov 92 17:00:58 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211100100.AA18400@saffron.acc.com> To: craig@aland.bbn.com Subject: Re: Flows Cc: big-internet@munnari.oz.au >> What I need is some way for the fair queueing scheme to recognize >> and schedule my datagrams. Agreed, and the whole point I was making was that flows may be *useful* for that, but are not *necessary*. If you predicate your work on them, a proportion of network citizens will not have their lot improved by your improvement. From owner-Big-Internet@munnari.oz.au Tue Nov 10 19:00:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24494; Tue, 10 Nov 1992 19:00:30 +1100 (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 AA24486; Tue, 10 Nov 1992 19:00:23 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 10 Nov 92 00:00:09 -0800 Date: Tue, 10 Nov 92 00:00:09 -0800 From: Tony Li Message-Id: <9211100800.AA04930@lager.cisco.com> To: big-internet@munnari.oz.au Subject: Flows My key concern is that the bits be in the header (not in an option -- the goal of the flow field is to give packets *preferential* service, not inferior service via the slow option-handling path). I'm sorry, but this is COMPLETELY backwards. Option handling is slow because there is no demand for fast option processing. The way to make ANYTHING go fast is to get the benchmarking WG to make it a benchmark and then get Scott Bradner to test for it. Tony From owner-big-internet@munnari.oz.au Tue Nov 10 20:12:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26775; Tue, 10 Nov 1992 20:12:45 +1100 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10919; Tue, 10 Nov 1992 11:09:54 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA18324; Mon, 9 Nov 92 16:08:54 PST Date: Mon, 9 Nov 92 16:08:54 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211100008.AA18324@saffron.acc.com> To: craig@aland.bbn.com Subject: Re: Flows Cc: big-internet@munnari.oz.au >> What are those other bits along with src and dst? Do they scale >> well to a wide diversity of services? (The current wisdom on some >> of these topics is discussed in RFC 1363, but if that wisdom is >> wrong, I'd like to know). Before I get real far, let me confess to not having read RFC 1363 very thoroughly. Please don't understand my comments to be on flows per se, but on what we have found advisable in dealing with congestion in our customer's networks - a much narrower subject. (If you're going to be in Washington,maybe we could chat in a bar somewhere...) I've also had a couple of people write back to enlighten me on the subject under discussion; helpful, since I have the mailbox congestion that we probably all have. Last week I went to lunch one day and found 125 messages waiting for me when I came back. My observation is a corollary of Nagle's. Nagle commented in RFC 970 that the switch vendors were waiting with bated breath for memory to get cheap enough that packet switches could be populated with infinite memory; then all congestion problems would go away. He showed that that would only change the nature of the behavior under congestive stress from a problem to a collapse. I further observe that the management of congestion in the switch is not a matter of managing memory (which is primarily what flows manage, if I understand them), it is a problem of managing bandwidth allocations at an interface. Hence, and this was my comment, flows may be a means to the end, but are not *necessary* to solving congestion. What is necessary to managing this is a handle of some sort that can be used to identify traffic that can or should be treated together, plus an algorithm for figuring out what to do. We follow Srinivassan's algorithm, with some modifications. In our implementation, we have avoided looking at fields above the network layer, as those may not be readable in a fragmented message. Therefore, we look at: Bridging and Source Routing MAC DESTINATION on all traffic MAC SOURCE on unicast traffic IP: IP DESTINATION IP SOURCE IP TOS IP PROTOCOL CLNS: CLNS DESTINATION NSAP CLNS SOURCE NSAP CLNS QoS AppleTalk: AT DESTINATION (NET, NODE, SOCKET) AT SOURCE (NET, NODE, SOCKET) DECNET: DECNET DESTINATION (Area/Node Id) DECNET SOURCE (Are/Node Id) IDP/IPX: IDP/IPX DESTINATION (NET, HOST, SOCKET) IDP/IPX SOURCE (NET, HOST, SOCKET) It appears to work well, based on our field experience (we've had it deployed for about a year now). I would expect it needs some tweaking in an isochronous world, but I don't see any fundamental gotchas. The weakness of depending on flows is that the above protocols, which represent a hugish percentage of the traffic on most of our customer's networks, don't support them. Therefore, for a hugish percentage of the traffic on our customer's networks, either some other discriminator has to be used, somewhere, or the improvement is not available. If it can be made available changing only the routers, not having to change the hosts as well, the customer is going to be happier. Fred From owner-big-internet@munnari.oz.au Tue Nov 10 21:02:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28656; Tue, 10 Nov 1992 21:02:18 +1100 (from owner-big-internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17626; Tue, 10 Nov 1992 15:18:28 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB25032; Mon, 9 Nov 92 23:17:38 EST Date: Mon, 9 Nov 92 23:17:38 EST Message-Id: <9211100417.AB25032@mitchell.cit.cornell.edu> To: kasten@ftp.com From: Scott_Brim@cornell.edu Sender: swb@nr-tech.cit.cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au Not exactly. My concern is not so much with the routing protocol as with the whole architecture. As any design progresses it gets grubby. In the face of such grubbiness some use up all their options just to get off the ground. I'd be more specific but I haven't had enough time recently to scrutinize current developments in the IPv7 alternatives, and even though I think my ideas are right I would have trouble defending them with details. Anyway, don't think of whether routing protocols are extensible, think about flexibility in the whole framework. Thanks ... Scott At 11:23 11/9/92 -0500, Frank Kastenholz wrote: > > bet their jobs on their recommendations for IPv7. This also probably adds > > a criterion to the list for IPv7, which is flexibility in the protocol > > architecture to allow for patching when faced with unexpected conditions. > >scott, > >i think that our "extensibility" criteria covers this point. > > >-- >Frank Kastenholz From owner-big-internet@munnari.oz.au Tue Nov 10 21:12:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28935; Tue, 10 Nov 1992 21:12:42 +1100 (from owner-big-internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17737; Tue, 10 Nov 1992 15:21:32 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB25086; Mon, 9 Nov 92 23:21:13 EST Date: Mon, 9 Nov 92 23:21:13 EST Message-Id: <9211100421.AB25086@mitchell.cit.cornell.edu> To: kasten@ftp.com From: Scott_Brim@cornell.edu Sender: swb@nr-tech.cit.cornell.edu Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au At 11:48 11/9/92 -0500, Frank Kastenholz wrote: >Yup. But, we must also continually push the net to "better" protocols, >applications, and services. If we don't, the net will stagnate -- it would Of course, but with the right sandbox environment, e.g. government-funded networks (what some people still seem to think of as "the Internet"), you can have a good proving ground for large and sweeping changes while still ensuring that critical services on critical networks are not endangered. I get concerned when groups make plans for the critical networks wherein a new design, which has never been implemented and used on anything real, *must* work or we have to start way over. Not quite as bad as SDI, but along the same lines. Ouch. OK, sorry, that was too strong but the thought did occur. >This is why, when we make such large and sweeping changes, we better get >as much as we can. This is another topic, but I'm glad you brought it up. I've been thinking and I'm no longer convinced that we'll never have another chance. Remember when X.25 was the final solution, or good old PL/1? In the past, network evolution hasn't occurred by a single monolithic structure going through large changes. Sure, large networks have done so but most evolution has come from new networks -- or species, or empires -- arising and supplanting the old ones. For example the Internet community has successfully ignored a worldwide network (X.25/X.75) which would have been impossible to move to a new architecture. Someday someone will probably ignore *you*, because that will be the easiest way to move to a new architecture. To quote Vonnegut, so it goes. See you soon ... Scott From owner-big-internet@munnari.oz.au Tue Nov 10 21:14:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28979; Tue, 10 Nov 1992 21:14:40 +1100 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18032; Tue, 10 Nov 1992 15:30:53 +1100 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA10005; Mon, 9 Nov 92 23:31:51 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9211100431.AA10005@wizard.gsfc.nasa.gov> Subject: Re: Criteria for selecting IPv7 To: big-internet@munnari.oz.au Date: Mon, 9 Nov 92 23:31:50 EST X-Mailer: ELM [version 2.3 PL11] Another important consideration to me for any IPv7 proposal is the availability of all necessary primary and supporting documentation to be able to properly understand and evaluate the proposal. To me, this means all documents should be freely available via anonymous ftp. One of the problems I have with the various CLNP proposals is that this doesn't appear to be the case. For example, one of the strengths mentioned for CLNP was its autoconfiguration capability. But I know of no way to obtain the document(s) describing this capability via the Internet itself. Also, I don't want to have to learn another language (OSIspeak) to understand any new proposal. Ideally, all documents should be written in the Internet style of the I-Ds and RFCs. IF people are really serious about basing IPv7 on CLNP, then they should make Internet-style versions of all the relevant OSI standards available as I-Ds or RFCs. I realize that this is a semi-religious issue, but I also think it is an important issue that needs to be dealt with. There is a tremendous knowledge base invested in the Internet model, and any suggestion to radically change the model needs to account not only for things like the cost of routing but also for the enormous retraining costs. I understand and feel comfortable with the plans for IPAE/SIP in this regard since they feel naturally to me like an extension to the existing IP model. I haven't seen anyone address this issue regarding the CLNP proposals. -Bill From owner-big-internet@munnari.oz.au Tue Nov 10 21:31:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29552; Tue, 10 Nov 1992 21:31:52 +1100 (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 AA19268; Tue, 10 Nov 1992 16:09:02 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA15837; Tue, 10 Nov 92 00:08:40 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA17024; Mon, 9 Nov 92 21:07:16 PST Message-Id: <9211100507.AA17024@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: Craig Partridge , fbaker@acc.com (Fred Baker), big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Mon, 09 Nov 92 20:17:55 -0700. <9211100317.AA00643@goshawk.lanl.gov> From: Craig Partridge Date: Mon, 09 Nov 92 21:07:16 -0800 Sender: craig@aland.bbn.com > Granted that you can not simply look into the src/dst pair, would > it be possible to set a flag in the packet to indicate that it is > fair game to look into proto and port numbers? Sounds gross, but > this would accomplish the desired result, wouldn't it? Yes and no. It is certainly true that the src/dst/proto/src port/dst port must constitute a unique ID, and thus could be used to look up flow identifiers. Separate flow ids are a more flexible approach (see below). But if you mean looking a proto and port numbers to figure out TOS, that doesn't scale well (at least in my view). Using ports to compute what a flow needs has at least two problems. One, it means that all the gateways have to keep tables that map each reserved port # to a set of flow properties and queueing practices, and two, it means that I cannot, for example, declare port 345 to be a video conferencing port, rather it has to be a H.261 or MPEG or JPEG video conferencing port and I have to have different ports for different video encodings because different video encodings have different traffic characteristics. This even though I could clearly negotiate my video encoding via some start up protocol on port 345, if only port didn't bind to traffic properties... > Is there some gain in running multiple logical flows over a single > flowid? This would hint at the desirability of structure in the > flowids. Again, one can answer this question two ways. There may be an advantage into combining lots of traffic together (to get the advantage of the law of large numbers), but this approach would likely argue to lumping everything into one giant superflow -- not a hierarchy of flows. However, it may be useful for lots of low level traffic with some requirements to be classed in the same flow (for example, say all telnet connections get thrown into a class that says minimize delay after all higher-priority flows have been served). [Before some minimalist points out that telnet works just fine without flows -- this is only a didactic example]. In this case, the flow id also requires no hierarchy because the only time we differentiate flows is at the end points, using src/dst/proto/src port/dst port. (Note here that if we use src/dst/protocol/src port/dst port as our unique flow id then this aggregation is a bit harder to do, requiring a masking out the ports and seeing if they alone constitute a magic class). Craig From owner-Big-Internet@munnari.oz.au Tue Nov 10 21:39:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29722; Tue, 10 Nov 1992 21:39:38 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211101039.29722@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29715; Tue, 10 Nov 1992 21:39:25 +1100 (from Z.Wang@cs.ucl.ac.uk) Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 10 Nov 1992 10:38:26 +0000 To: Charles Lynn Cc: Fred Baker , craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of "Mon, 09 Nov 92 17:35:46 EST." <9211100005.10805@munnari.oz.au> Date: Tue, 10 Nov 92 10:38:22 +0000 From: Zheng Wang >For this to be workable for real-time traffic, at least in an >environment where there is not more bandwidth than demand, you >have to specify what "a bit of other data" is. I.e., all traffic >between A and B should not be treated the same. Also, all traffic >between those two hosts for a particular protocol should not be >treated the same. It is not clear that all traffic between A/port A >and B/port B should be treated the same (besides, the protocol may >not use ports, or may have them in some place that vendor X does not >include in "a bit of other data"). It seems to me that SrcAddr, DestAddr, SrcPort, DestPort and ProtoType are sufficient to identify a flow uniquely. But we have to touch transport header. It would be nice if we can have a shortish flow id field (say 32-bit) in the IP header that identifies a flow uniquely (at least for the duration of a flow). However, this can be difficult to do. Alternatively, we may have two fields (say 16-bit each) in the IP header that is equivalent to (SrcPort+ProtoType, DestPort+ProtoType). Cheers Zheng From owner-Big-Internet@munnari.oz.au Wed Nov 11 00:39:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05422; Wed, 11 Nov 1992 00:39:17 +1100 (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 AA05413; Wed, 11 Nov 1992 00:39:02 +1100 (from huston@ps73.ako.dec.com) Received: by inet-gw-1.pa.dec.com; id AA03379; Tue, 10 Nov 92 05:38:53 -0800 Received: by ps73.ako.dec.com (5.57/Ultrix V4.2-sdh-921109);id AA07221; Tue, 10 Nov 92 08:37:31 -0500 Message-Id: <9211101337.AA07221@ps73.ako.dec.com> To: Charles Lynn Cc: Fred Baker , ULLMANN@process.com, craig@aland.bbn.com, big-internet@munnari.oz.au, huston@ps73.ako.dec.com Subject: Re: Flows In-Reply-To: Your message of "Mon, 09 Nov 92 17:35:46 EST." <9211100005.10805@munnari.oz.au> Date: Tue, 10 Nov 92 08:37:30 -0500 From: huston@ps73.ako.dec.com X-Mts: smtp >It seems to me that only the application really knows how it would >like its traffic to be treated, and specifying, maybe packet by >packet, a flowid (made globally unique by the source EID) is the >easiest may to get maximal flexibility that is independent of >transport/application protocol. Then why doesn't the current IP TOS get used that much? Steve Huston From owner-Big-Internet@munnari.oz.au Wed Nov 11 01:57:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09584; Wed, 11 Nov 1992 01:57:51 +1100 (from owner-Big-Internet) Return-Path: Received: from kauai.mcl.unisys.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09557; Wed, 11 Nov 1992 01:57:32 +1100 (from perry@MCL.Unisys.COM) Received: by kauai.MCL.Unisys.COM (4.1/mls/3.2) id AA22186; Tue, 10 Nov 92 09:53:39 EST Date: Tue, 10 Nov 92 09:53:39 EST From: perry@MCL.Unisys.COM (Dennis Perry) Message-Id: <9211101453.AA22186@kauai.MCL.Unisys.COM> To: Scott_Brim@cornell.edu, kasten@ftp.com Subject: Re: Criteria for selecting IPv7 Cc: big-internet@munnari.oz.au, perry@mcl.unisys.com Scott, you wrote: This is another topic, but I'm glad you brought it up. I've been thinking and I'm no longer convinced that we'll never have another chance. Remember when X.25 was the final solution, or good old PL/1? In the past, network evolution hasn't occurred by a single monolithic structure going through large changes. Sure, large networks have done so but most evolution has come from new networks -- or species, or empires -- arising and supplanting the old ones. For example the Internet community has successfully ignored a worldwide network (X.25/X.75) which would have been impossible to move to a new architecture. Someday someone will probably ignore *you*, because that will be the easiest way to move to a new architecture. To quote Vonnegut, so it goes. See you soon ... Scott This is along the lines of something I was reading the other day about technology advancement. I turns out that when steamships first appeared, sailing shipe, to compete, redoubled their efforts in the same direction they had been going, i.e. producing taller and more exotic sailing ships. When transitors arrived, vacuum tube manufactures responded by making smaller and smaller vacuum tubes. Does history have something to teach us here? Are we in the midst of a technology change and are we trying to respond with better of the same? Sooner or later we will have to acknowledge the change or risk being buried by it. dennis From owner-Big-Internet@munnari.oz.au Wed Nov 11 02:59:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13158; Wed, 11 Nov 1992 02:59:48 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13148; Wed, 11 Nov 1992 02:59:39 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA28374; Tue, 10 Nov 92 08:59:33 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA03606; Tue, 10 Nov 92 08:59:32 MST Message-Id: <9211101559.AA03606@goshawk.lanl.gov> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Mon, 09 Nov 92 23:31:50 -0500. <9211100431.AA10005@wizard.gsfc.nasa.gov> Date: Tue, 10 Nov 92 08:59:31 MST From: peter@goshawk.lanl.gov Bill, The problems with getting CLNP documents is being worked on. To satisfy your interest in ES-IS, IS-IS and IDRP you can get documents out of the merit.edu:pub/iso directory. There will be a CLNP document there shortly. I agree with you, the documents for these standards should be easily obtained. cheers, peter From owner-Big-Internet@munnari.oz.au Wed Nov 11 03:07:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13479; Wed, 11 Nov 1992 03:07:33 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13473; Wed, 11 Nov 1992 03:07:21 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA28658; Tue, 10 Nov 92 09:07:13 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA03653; Tue, 10 Nov 92 09:07:12 MST Message-Id: <9211101607.AA03653@goshawk.lanl.gov> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Mon, 09 Nov 92 23:31:50 -0500. <9211100431.AA10005@wizard.gsfc.nasa.gov> Date: Tue, 10 Nov 92 09:07:11 MST From: peter@goshawk.lanl.gov Bill, You have presented an interesting dilemma. You seem to be asking for two versions of a single document: an easy to read model and the actual ISO standard. I doubt most implementors will want to work with two documents, where the probability of error in transcription is greater than 0. One alternative is obvious, which is to simply take over the document. Would this be a viable alternative from your perspective? cheers, peter From owner-Big-Internet@munnari.oz.au Wed Nov 11 03:22:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14394; Wed, 11 Nov 1992 03:25:20 +1100 (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 AA14260; Wed, 11 Nov 1992 03:22:39 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA26036; Tue, 10 Nov 92 11:22:24 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA19483; Tue, 10 Nov 92 08:21:01 PST Message-Id: <9211101621.AA19483@aland.bbn.com> To: huston@ps73.ako.dec.com Cc: big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Tue, 10 Nov 92 08:37:30 -0500. <9211101337.AA07221@ps73.ako.dec.com> From: Craig Partridge Date: Tue, 10 Nov 92 08:21:01 -0800 Sender: craig@aland.bbn.com > Then why doesn't the current IP TOS get used that much? Lots of reasons. It is poorly defined. It doesn't offer a wide enough spectrum of service (e.g. I can't specify bandwidth requirements), etc. See RFC 1363 which discusses this problem (shameless plug, I'm sorry). Craig From owner-Big-Internet@munnari.oz.au Wed Nov 11 04:06:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15878; Wed, 11 Nov 1992 04:06:42 +1100 (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 AA15869; Wed, 11 Nov 1992 04:06:32 +1100 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 10 Nov 92 09:06:19 -0800 Date: Tue, 10 Nov 92 09:06:19 -0800 From: Tony Li Message-Id: <9211101706.AA19956@lager.cisco.com> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au In-Reply-To: Craig Partridge's message of Tue, 10 Nov 92 08:16:29 -0800 <9211101616.AA18910@aland.bbn.com> Subject: Flows Tony -- you're in the minority on this view. Van sent a nice exposition of why options cost more a few weeks ago. And Van is wholly correct. Processing an option does increase both the theoretical and practical amount of work that has to be done. Van also points out that a source route typically costs a factor of 5 in his implementation and more than an order of magnitude in our implementation. Part of this is due to the fact that source routes are a relatively complex option to manipulate -- its presence requires a routing table lookup. Part of this is that the entire option scheme is awkward and lends itself to implementations that process an option one byte at a time. The conventional wisdom that I'm trying to dispell is that option processing cannot be optimized in the current implementations. Yes, this would require more work from the vendors (no, I don't want to do it, thank you ;-) but it CAN be done. I would even go out on a limb and speculate that such optimization could bring our implementation well within Van's factor of 5. It would even be a smaller factor for less complicated options. What does it take to process a NOP option? In our implemenation, you still take that order of magnitude hit. As far as IPv7 is concerned, yes, it would be very nice to do options more cleanly. Let's look at what's involved in a flow spec. From what you've said, you need a 32 bit magic cookie. This only needs to be examined by the routers which are participating in the flow. Since it is in the header, it does end up impacting all packets in the entire network. You end up trading a minor speed improvement for flow packets and costing everyone a longword. Does this tradeoff make sense to you? I'm not convinced yet. Let me propose an alternate scheme for doing options for IPv7: Assume that there is some small set of options which we need to be processed very quickly, which we know today. Allocate a byte in the network layer header. This will be used as a bit mask, with a set bit indicating that the option is present. Allocate the least significant bit to indicate that some other type of TLV option is present. The option is of a known length and is concatenated onto the header. Further, the order in which the options appear is completely fixed, most likely matching the order of the bits in the mask from most significant to least significant. I claim that this now reduces the bloat in the header and only costs you very few extra instructions to find and parse any of the 'fast' options. Tony From owner-Big-Internet@munnari.oz.au Wed Nov 11 05:06:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17282; Wed, 11 Nov 1992 05:06:32 +1100 (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 AA17274; Wed, 11 Nov 1992 05:06:12 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA11118; Tue, 10 Nov 92 13:05:51 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA20222; Tue, 10 Nov 92 10:04:28 PST Message-Id: <9211101804.AA20222@aland.bbn.com> To: big-internet@munnari.oz.au Subject: checking weapons at the door - not! Reply-To: Craig Partridge From: Craig Partridge Date: Tue, 10 Nov 92 10:04:27 -0800 Sender: craig@aland.bbn.com Hi folks: Following up yesterday's notes about lowering the temperature on the list, I'd like to point out that it is highly unlikely that the IETF is going to do anything more next week than narrow the list of protocols under consideration for IPv7. I'd be most surprised if the IESG did more than point out the various designers problems that they needed to addressed, and indicated which two or three proposals it thought were most promising. Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-big-internet@munnari.oz.au Wed Nov 11 06:07:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18670; Wed, 11 Nov 1992 06:08:55 +1100 (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 AA14122; Wed, 11 Nov 1992 03:18:33 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25518; Tue, 10 Nov 92 11:17:53 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA18910; Tue, 10 Nov 92 08:16:30 PST Message-Id: <9211101616.AA18910@aland.bbn.com> To: Tony Li Cc: big-internet@munnari.oz.au Subject: re: Flows From: Craig Partridge Date: Tue, 10 Nov 92 08:16:29 -0800 Sender: craig@aland.bbn.com > I'm sorry, but this is COMPLETELY backwards. Option handling is slow > because there is no demand for fast option processing. Tony -- you're in the minority on this view. Van sent a nice exposition of why options cost more a few weeks ago. Craig From owner-big-internet@munnari.oz.au Wed Nov 11 06:56:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19553; Wed, 11 Nov 1992 06:56:55 +1100 (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 AA15345; Wed, 11 Nov 1992 03:46:09 +1100 (from huston@ps73.ako.dec.com) Received: by inet-gw-1.pa.dec.com; id AA15764; Tue, 10 Nov 92 08:46:01 -0800 Received: by ps73.ako.dec.com (5.57/Ultrix V4.2-sdh-921109);id AA07443; Tue, 10 Nov 92 11:44:40 -0500 Message-Id: <9211101644.AA07443@ps73.ako.dec.com> To: Craig Partridge Cc: huston@ps73.ako.dec.com, big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of "Tue, 10 Nov 92 08:21:01 PST." <9211101621.AA19483@aland.bbn.com> Date: Tue, 10 Nov 92 11:44:40 -0500 From: huston@ps73.ako.dec.com X-Mts: smtp >> Then why doesn't the current IP TOS get used that much? > >Lots of reasons. It is poorly defined. It doesn't offer a wide enough >spectrum of service (e.g. I can't specify bandwidth requirements), etc. Ok. But when the original IP TOS definition was being done, some thought it necessary so that different traffic patterns of things like Telnet and FTP would work without the FTP swamping the interactive Telnet. But it turned out to not be necessary. I'm thinking that it may be the same sort of thing with flows. >See RFC 1363 which discusses this problem (shameless plug, I'm sorry). Ok. I won't yap about flows again until I've read the rfc. -Steve From owner-big-internet@munnari.oz.au Wed Nov 11 07:11:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19774; Wed, 11 Nov 1992 07:11:46 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16113; Wed, 11 Nov 1992 04:18:36 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01531; Tue, 10 Nov 92 10:18:25 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA04358; Tue, 10 Nov 92 10:18:25 MST Message-Id: <9211101718.AA04358@goshawk.lanl.gov> To: perry@MCL.Unisys.COM (Dennis Perry) Cc: Scott_Brim@cornell.edu, kasten@ftp.com, big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Tue, 10 Nov 92 09:53:39 -0500. <9211101453.AA22186@kauai.MCL.Unisys.COM> Date: Tue, 10 Nov 92 10:18:24 MST From: peter@goshawk.lanl.gov Dennis and scott, As an interesting Industry to observe, we could look at the desktop computer market. It is not clear there will be a "winner" , or even a long term survivor for that matter. In fact, it is interesting to speculate that if there are any long time winners in the desktop market, it might be Microsoft. This might lead one to conclude that application gateways really are the future of the Internet. cheers, peter From owner-big-internet@munnari.oz.au Wed Nov 11 08:22:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21213; Wed, 11 Nov 1992 08:24:00 +1100 (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 AA19464; Wed, 11 Nov 1992 06:49:34 +1100 (from craig@aland.bbn.com) Received: from port12.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25202; Tue, 10 Nov 92 14:49:20 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA21046; Tue, 10 Nov 92 11:47:55 PST Message-Id: <9211101947.AA21046@aland.bbn.com> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: checking weapons at the door - not! In-Reply-To: Your message of Tue, 10 Nov 92 10:04:27 -0800. <9211101804.AA20222@aland.bbn.com> From: Craig Partridge Date: Tue, 10 Nov 92 11:47:54 -0800 Sender: craig@aland.bbn.com I just got a query asking if my note was intended to say we'd really have to fight it out at IETF. I was trying to suggest the opposite -- if no final winner is to be chosen, I think we can allow the intensity of discussion to go down a bit. Craig From owner-big-internet@munnari.oz.au Wed Nov 11 08:31:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21364; Wed, 11 Nov 1992 08:32:17 +1100 (from owner-big-internet) Return-Path: Received: from tadpole.Tadpole.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19287; Wed, 11 Nov 1992 06:42:48 +1100 (from jim@tadpole.com) Received: from chiba.tadpole.com by tadpole.tadpole.com (4.1/SMI-4.1) id AA10941; Tue, 10 Nov 92 13:42:07 CST Date: Tue, 10 Nov 92 13:42:07 CST From: jim@tadpole.com (Jim Thompson) Message-Id: <9211101942.AA10941@tadpole.tadpole.com> To: big-internet@munnari.oz.au, dee@ranger.enet.dec.com Subject: Re: ideas from AppleTalk > (1) Dynamic host address determination. When a machine first comes up on a > network, it picks an ID and tests to see that there is no other machine up on > its local network with the same ID. If not, it uses that ID. If there is > another machine with the same ID, then it tries a different one. (It also > remembers this in non-volatile memory so that it will try the same ID first > when it comes up again.) This host ID (called the AppleTalk node ID) is 8 bits > and gets combined with a 16 bit network number learned from a router to form a > full 24 bit AppleTalk node address. DHCP will support this. > (3) Distributed services directory. The AppleTalk name binding protocol > enables each host to provide the part of the diretory that relates to the > services it offers. When seeking services a broadcast message is sent out to > the hosts of interest which can use various wildcarding looking for matches on > service type, sevice name, and zone, all of which are character strings. Each > host with any services for which information was requested replies. See RFC 887. (Resource Location Protocol). BTW, does anyone know of *any* implimentation of RLP? I sent a message to Mike Accetta, but have yet to receive any reply. Jim From owner-big-internet@munnari.oz.au Wed Nov 11 09:38:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23010; Wed, 11 Nov 1992 09:38:53 +1100 (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 AA20275; Wed, 11 Nov 1992 07:35:04 +1100 (from kasten@ftp.com) Received: by ftp.com id AA26036; Tue, 10 Nov 92 15:34:16 -0500 Date: Tue, 10 Nov 92 15:34:16 -0500 Message-Id: <9211102034.AA26036@ftp.com> To: craig@aland.bbn.com Subject: re: Flows From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: tli@cisco.com, big-internet@munnari.oz.au it seems to me that you guys are arguing two sides of the same coin here. options do cost more -- simply because there is more to do (you can not process an option in 0 time). on the other hand, current implementations do not do them as efficiently as they could be because there has not been a perceived demand for it. > > I'm sorry, but this is COMPLETELY backwards. Option handling is slow > > because there is no demand for fast option processing. > > Tony -- you're in the minority on this view. Van sent a nice exposition of > why options cost more a few weeks ago. > > Craig > -- Frank Kastenholz From owner-big-internet@munnari.oz.au Wed Nov 11 10:58:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25323; Wed, 11 Nov 1992 10:59:07 +1100 (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 AA17936; Wed, 11 Nov 1992 05:37:54 +1100 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA16123 (5.65c/IDA-1.4.4nsd for ); Tue, 10 Nov 1992 10:37:38 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA06586 (5.65c/IDA-1.4.4-910725); Tue, 10 Nov 1992 10:37:36 -0800 Message-Id: <199211101837.AA06586@remmel.NSD.3Com.COM> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of "Mon, 09 Nov 92 16:31:26 PST." <9211100031.AA15554@aland.bbn.com> Date: Tue, 10 Nov 92 10:37:35 -0800 From: tracym@NSD.3Com.COM Craig, > There are a couple of ways to scale this. One way has routers in backbones > simply forwarding without reference to the flow field (on the grounds that >the law of large numbers should apply in backbones). Another way is combining > the flow id with the part of the destination address that gets looked up > (makes flow id allocation a bit tougher). > > My key concern is that the bits be in the header (not in an option -- the > goal of the flow field is to give packets *preferential* service, not > inferior service via the slow option-handling path). Last details can be > worked out during the testing of the proposed IPv7. Why not in an option? I suggest that the notion of general header options as implemented in IP and CLNP carries too much emotional baggage, given your fairly typical kneejerk reaction/statement concerning the placement of a flowid. There are many ways of implementing optional features that require VERY few extra cycles to process. The definition of CLNP even contains a few hints. 1) Fix the location of the optional header element, and guarantee optimal alignment. The segmentation option always comes first, if present, in the CLNP header. (Now, if they had only required alignment on word boundaries). In IPv4 I might define a 4-byte flow-id option that was required to always be the last long-word in an IP header. Simple and relatively cheap. 2) Indicate the presence of the important options with header flags. CLNP indicates that a segmentation option is present. A few more bits could be used to indicate a few standard "option" configurations in the header, to be processed directly without serial parsing of the header. (e.g. OptionCode=0 -> no options, =1 -> FlowID, =2 ->SecurityID, =3->FlowID + SequenceNo, =4-6 ->??, =7 -> Extension(parse 'em yourself). Actually, these suggestions simply restate my thoughts on improving IP and CLNP. I'd *prefer* to see the flowid in the standard header, but that's not my highest priority. Also, I wonder at just what part it should play? Is it part of the flow identification used by the upper layers, or simply an identifier used to access QOS information and flow-state in routers along the way. One approach would let the routers remap the flowid value at every hop, allowing them to optimize their forwarding lookups. Cheers, Tracy From owner-big-internet@munnari.oz.au Wed Nov 11 11:43:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26493; Wed, 11 Nov 1992 11:43:58 +1100 (from owner-big-internet) Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21205; Wed, 11 Nov 1992 08:22:36 +1100 (from skh@merit.edu) Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA18365; Tue, 10 Nov 92 16:19:12 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA25020; Tue, 10 Nov 92 16:19:10 EST Date: Tue, 10 Nov 92 16:19:10 EST From: skh@merit.edu Message-Id: <9211102119.AA25020@home.merit.edu> To: noop@merit.edu, tuba@lanl.gov, x3s33@merit.edu Subject: NOOP Workshop on Making a CLNP Routing Plan 11/18 4-6PM Cc: big-internet@munnari.oz.au, ie@merit.edu, osi-interop@merit.edu NOOP - CLNP Routing Workshop NOOP will hold a CLNP routing workshop on how to make an CLNP routing plan for your network. This workshop will be held on Wednesday 5/18/92 from 4:00pm - 6:00pm during at the NOOP working group. The first half hour will be a tutorial on CLNP, and associate routing protocols (ES-IS, IS-IS, and IDRP). For the rest of the time, we will discuss current routing CLNP routing plans. Come and investigate just what it would take to change from an IP only network to IP and CLNP network. NOOP people have done it! Learn from people on the technical staffs of networks that have add CLNP to their IP network. The only think you need to bring is your IP network plan or an idea of how your network works. If you are coming from a company, just have a chat with your network person and find out how the network works. Pictures of IP networks will be extremely valuable for the discussion, so remember to bring a picture of your network. Please forward this announcement on to anyone who might be interested in this workshop!! Sue Hares From owner-big-internet@munnari.oz.au Wed Nov 11 12:36:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27771; Wed, 11 Nov 1992 12:36:57 +1100 (from owner-big-internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22105; Wed, 11 Nov 1992 09:03:06 +1100 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26143; Tue, 10 Nov 92 14:02:39 -0800 Date: Tue, 10 Nov 92 15:10:06 EDT From: "William Allen Simpson" Message-Id: <903.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: Flows > From: Zheng Wang > Alternatively, we may have two fields (say 16-bit each) in the > IP header that is equivalent to (SrcPort+ProtoType, DestPort+ProtoType). > I suggested this a month ago, on the SIP list. All in favor? Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Wed Nov 11 14:34:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01385; Wed, 11 Nov 1992 14:35:35 +1100 (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 AA22814; Wed, 11 Nov 1992 09:33:39 +1100 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA13126; Tue, 10 Nov 92 14:33:17 -0800 Received: by us1rmc.bb.dec.com; id AA20481; Tue, 10 Nov 92 17:30:46 -0500 Message-Id: <9211102230.AA20481@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Tue, 10 Nov 92 17:30:47 EST Date: Tue, 10 Nov 92 17:30:47 EST From: Ross Callon To: craig@aland.bbn.com, big-internet@munnari.oz.au Apparently-To: craig@aland.bbn.com, big-internet@munnari.oz.au Subject: re: checking weapons at the door > Following up yesterday's notes about lowering the temperature on the > list, I'd like to point out that it is highly unlikely that the IETF is > going to do anything more next week than narrow the list of protocols under > consideration for IPv7. I'd be most surprised if the IESG did more than > point out the various designers problems that they needed to addressed, and > indicated which two or three proposals it thought were most promising. Yes. Not only is this what I expect **will** happen, it is all that I expect **should** happen. I think that it would still be premature to make a single choice at this time. Given the importance of getting this change correct, given the general amount of emotion and incomplete understanding of the proposals, and given the incomplete definition of the proposals, it clearly is appropriate to continue to work on at least two or three of the proposals (I can personally think of three proposals which I feel merit additional work, although I won't name them for fear of leaving out someone's favorite fourth proposal :-). I feel pretty strongly that this decision should be made based on what gets built and shown to work, rather than what turns out to be the most popular in a great Email debate. Ross From owner-big-internet@munnari.oz.au Wed Nov 11 15:33:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02931; Wed, 11 Nov 1992 15:33:56 +1100 (from owner-big-internet) Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22235; Wed, 11 Nov 1992 09:09:14 +1100 (from skh@merit.edu) Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA20597; Tue, 10 Nov 92 17:05:57 -0500 Received: by home.merit.edu (4.1/client-0.9) id AA26162; Tue, 10 Nov 92 17:05:55 EST Date: Tue, 10 Nov 92 17:05:55 EST From: skh@merit.edu Message-Id: <9211102205.AA26162@home.merit.edu> To: noop@merit.edu, tuba@lanl.gov, x3s33@merit.edu Subject: OSI survey for Tuba discussion Cc: big-internet@munnari.oz.au, osi-interop@merit.edu Calling all Good Internet People: In preparations the IETF discussions, I'd like to take a last minute survey of people who are interested in CLNP, in their network or CLNP and tuba in the future. Below is a survey that will take you 10 minutes if you are using CLNP, and 2-3 if you are not. Please note that questions 1-7 are for currently CLNP users and 8-9 are for people who are not currently using CLNP. If you take a minute to send in the notes, I'll summarize them Thursday night (11/12/92), and forward the results on Friday morning (11/13/92). The survey is available for anonymous ftp from merit.edu in the directory /pub/iso/noop/papers/survey.questions.v3 Thanks to all, Sue Hares ---------------- Survey timeframe. ----------------------------------------------------------- Please return this by 11/10/92. The survey looks long, but hopefully will only take 10-15 minutes to fill out. A document reviewing these results will be available by 11/13/92. Please also fill out this contact information for the survey. Contact information: (Please fill out this information for all survey forms:) 1.) person filling out the survey 2.) title and your position in the company 3.) company or network 4.) person (or group) to contact about OSI for this network or company person/group: title: phone number: email address: 5.) person (or group) to contact for help if OSI trouble shooting needed 6.) Location of any on-line document on networks OSI service 7.) Location of network's osi routing plan 8.) Are you internested in using tuba (TCP over CLNP)? Introduction to the Survey: Location of an Questions 1-7 are for those who route Connection Network Layer Packets (CLNP ISO 8473) or DECNET Phase 5 traffic on their network. Questions 8-9 are for those who do not yet route CLNP or DECNET Phase 5. Questions: 1.) Are you interested in running tuba? a.) Would you participate in tuba pilot that used ftp or email? b.) what end systems do you have that you'd like to run Tuba on? 2.) Do you support the routing of Connection Network Layer Protocol (CLNP (ISO 8473)) packets on your network? If so, 2.1) What number of routers do you have in your network? How many of these routers pass CLNP packets? 2.2) What router vendors do you use in your network? What router vendors do you use in the routers that are passing CLNP packets? 2.3) What type of intra-domain routing do you do within your network? IS-IS? Cisco IGRP based OSI? static? 2.4) What type of inter-domain routing do you do? Cisco poor-man's Inter-domain routing? static? 2.5) Would you be interested in the new ISO Inter-Domain Routing Protocol (IDRP (ISO CD 10747)) when it becomes available? 2.6) Do you consider the OSI service to be: Production - guaranteed delivery and high level of service, Experimental - guaranteed delivery, but service may be behind IP, Prototype - A first offerings of CLNP which is limited to a few sites, or Pilot - For demonstrations and Pilot projects only? Please select the category nearest to your service. You may include other comments to further qualify this service level. 2.7) What amount of traffic do you pass per day, per week and per month? 3.) Are you now routing DECNET Phase 5 traffic on your system? If you are routing DECNET Phase 5: a.) What type of routers are you using? (manufacturer and model? b.) How many routers do you have? c.) What type of hosts are sending traffic? d.) How many DECNET Phase 5 hosts do you have? 4.) Do you currently attach one or more OSI vendor company to your network? Do any of these companies send OSI traffic across the network? If so, 4.1) How many OSI companies are attached to your network? 4.2) How many of these OSI companies send application data regularly? 4.3) What are the companies attached to your network? 4.4) What applications are these companies using? It would be helpful to list the applications by company if that is possible. 4.5) Would any of these companies be interested in "Pilot" projects to try exchanging OSI applications with those people on the Internet. 5.) Do you support OSI applications at your network site? If so, 5.1) What applications do you support? Do you support: X.500 X.400 FTAM VT Xwindows SQL based applications CMIP (please answer yes or no to each applications) others - please list with company 5.2) For each of the applications you answered yes to above please indicate: a.) equipment the application runs on b.) does it run over CLNP/TP4 stack or TCP/IP stack c.) what vendor supplies the software d.) any comments on how easy it is to use 5.3) Are you a part of a Pilot Project or testing group for this application? 5.4) Would you be willing to be a part of a Pilot Project or testing group for this application? 5.5) Do you have a set of routers or hosts which could form a "test bed" at your site? These routers and hosts could be used on either a short term or long term basis to test out new software in the Internet. 5.6) Would you be willing to have a "test bed" at your site if additional funding for this was available? 6.) Do you have any of the following network tools on your routers? a.) OSI ping (or echo function) b.) OSI traceroute c.) OSI table dump What routers have these functions? How would you rate the User Interface to these network tools - poor, fair, good, or excellent? 7.) Do you have any of the following network tools on your hosts? a.) OSI ping (or echo function) b.) OSI traceroute c.) OSI table dump What hosts have these functions? How would you rate the User Interface to these network tools - poor, fair, good, or excellent? 8.) If you do not support switching CLNP packets today, a.) Would you be interested in TUBA applications? Which IP application would you like to have run TUBA? b.) Will you need to route DECNET Phase 5 in the future? c.) Will you route CLNP packets if you had clients that required OSI service? d.) Will you route CLNP packets only when IS-IS was supported on all your routers? (please indicate what types of routers you use in your network) e.) Will you need network tools (that supported an osi ping, osi traceroute, and osi routing table dump) to support CLNP in your network? f.) Will you require both tuba and IS-IS supported on all your routers before you support CLNP in your network? g.) Will you require that you have OSI clients, IS-IS on all your routers, and OSI network tools (b, c and d above) Please answer yes or no to items a thru e. Additional comments are also welcome. 9.) If you do not currently use an OSI application or tuba at your site, please answer the following: 8.1) Would you be interested in X.500? In X.500 over TCP/IP? In X.500 over CLNP? 8.2) Would you be interested in X.400? in X.400 over TCP/IP? In X.400 over CLNP? 8.3) Would you be interested in FTAM over ISO Transport Class 4 (TP4) and CLNP? How about FTP over Tuba? 8.4) Would be interested in VT over TP and CLNP? How about Telnet or rlogin over Tuba? 8.6) Would you be interested in trying out X-windows over CLNP? Would you like to see it run native instead of TUBA? (it may perform better in native mode over a skinny stack.) From owner-Big-Internet@munnari.oz.au Wed Nov 11 16:02:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03694; Wed, 11 Nov 1992 16:02:22 +1100 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03682; Wed, 11 Nov 1992 16:02:03 +1100 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA11549; Wed, 11 Nov 92 00:02:52 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9211110502.AA11549@wizard.gsfc.nasa.gov> Subject: Re: Criteria for selecting IPv7 To: peter@goshawk.lanl.gov Date: Wed, 11 Nov 92 0:02:51 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9211101607.AA03653@goshawk.lanl.gov>; from "peter@goshawk.lanl.gov" at Nov 10, 92 9:07 am X-Mailer: ELM [version 2.3 PL11] > Date: Tue, 10 Nov 92 09:07:11 MST > From: peter@goshawk.lanl.gov > > You have presented an interesting dilemma. You seem to be asking for > two versions of a single document: an easy to read model and the actual ISO > standard. I doubt most implementors will want to work with two > documents, where the probability of error in transcription is greater > than 0. One alternative is obvious, which is to simply take over > the document. Would this be a viable alternative from your perspective? Peter, The most important point is that all necessary protocol specifications and documentation be under the control of the IETF/IESG/IAB and that the documentation be freely available via the Internet. But the language/style of the documents is also important. It would be necessary to weigh the potential advantages of an ISO/CLNP approach against the potentially massive retraining costs involved in everyone "learning" the new ISO vocabulary and semantics. Of course, some would argue that since ISO is here to stay, we'll all have to become at least somewhat familiar with it. All I'm basically saying is that there's a cost involved in this retraining and it has to be factored into the decision equation along with other costs such as the actual routing overhead. -Bill From owner-big-internet@munnari.oz.au Wed Nov 11 18:28:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07566; Wed, 11 Nov 1992 18:28:53 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27276; Wed, 11 Nov 1992 12:18:44 +1100 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <12355>; Tue, 10 Nov 1992 17:18:05 PST Received: by redwing.parc.xerox.com id <57162>; Tue, 10 Nov 1992 17:18:02 -0800 Date: Tue, 10 Nov 1992 17:17:54 PST Sender: Lixia Zhang From: Lixia Zhang Reply-To: lixia@parc.xerox.com To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: re: Flows In-Reply-To: Your message of Tue, 10 Nov 1992 12:34:16 -0800 Message-Id: > it seems to me that you guys are arguing two sides of the same coin > here. options do cost more -- simply because there is more to do (you > can not process an option in 0 time). on the other hand, current > implementations do not do them as efficiently as they could be > because there has not been a perceived demand for it. Yet another side of the coin (or another way of looking) says that, if we believe pkts should not all be treated equally (as they have been so far in the Internet), then this flowID/QOS/whatever flag should be one of the basic fields in IPv7 header, rather than left as an option. From owner-big-internet@munnari.oz.au Wed Nov 11 19:45:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09668; Wed, 11 Nov 1992 19:45:35 +1100 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04404; Wed, 11 Nov 1992 16:27:36 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA04051; Tue, 10 Nov 92 22:26:42 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA08497; Tue, 10 Nov 92 22:26:41 MST Message-Id: <9211110526.AA08497@goshawk.lanl.gov> To: kasten@ftp.com Cc: craig@aland.bbn.com, tli@cisco.com, big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Tue, 10 Nov 92 15:34:16 -0500. <9211102034.AA26036@ftp.com> Date: Tue, 10 Nov 92 22:26:40 MST From: peter@goshawk.lanl.gov Frank, Perhaps everyone is arguing at the side of the coin. I think Tony's important point is that we should simply implement flows as options and determine their utility. People will tweak the b'jeezus out of the performance if that is one of those "must have" options. (Seem to recall furious fixing of LSR when that traceroute thingie came out ... ) When we lay the coin on its flat side, we might see that we can indeed get options to run fast, and hence we do not need to incorporate some really cool, application enhancing feepture into the base packet format. We can leave it as an option and still have a functional network layer without some forced shift in packet format. Will the delay introduced by todays IP option handling preclude experiments with flows on the current Internet? Shouldn't we have the feedback from these prior to commiting to flows in IPv7? How should this be reflected in the current criteria? cheers, peter From owner-big-internet@munnari.oz.au Wed Nov 11 20:52:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11643; Wed, 11 Nov 1992 20:52:40 +1100 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28856; Wed, 11 Nov 1992 13:21:16 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12394>; Tue, 10 Nov 1992 18:20:45 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 10 Nov 1992 18:20:36 -0800 To: sip@caldera.usc.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: new SIP draft Date: Tue, 10 Nov 1992 18:20:26 PST Sender: Steve Deering From: Steve Deering Message-Id: <92Nov10.182036pst.10779@skylark.parc.xerox.com> I have finally sent a draft of the SIP specification in for publication as an Internet Draft. You may also pick it up from parcftp.xerox.com: pub/net-research/sip-spec. Changes from the previous draft include the following: o The header is now 4 bytes longer. That 32 bits is divided into a 4-bit Version field and a 28-bit Reserved field. The Reserved field is intended for TOS/Flow-ID, once a few remaining details are worked out and some implementation experience has been gained. o The presence of the Version field makes it possible for SIP to use the same link-layer mappings/encapsulations as IPv4, so there is no longer a special ethertype for SIP. For now, SIP is specified to use ARP as is, with no changes from IPv4 usage, by using only the low-order 32 bits of of SIP addresses wherever IP addresses would appear (the high-order 32 bits can be inferred from the subnet prefix that everyone on the wire is expected to know); however, this is likely to change in the future, either by switching to the use of link-layer multicast for ARP, or by replacing ARP altogether with something more ES-IS-like. o By popular (?) demand, the Payload Length, Payload Type, and Hop Limit fields have been re-ordered to place the Hop Limit field on the right, for more convenient decrementing on big- endian machines. o The minimum link MTU is increased from 500 to 576 bytes, to better accomodate all those existing higher-layer protocols that generate packets in the 512 to 576 byte range, such as TFTP and DNS. o ICMP and IGMP are no longer given different names (SIPC and SIPG) when used with SIP. o Because of the change of alignment caused by adding 4 bytes to the SIP header, fewer changes are required to ICMP messages; the only messages whose format changes are: Redirect and Router Discovery (because they need room to carry 64-bit SIP addresses), and Parameter Problem (because the Pointer field potentially needs to be able to point further than the 255th byte). o The special tunneling protocol has been eliminated, and a more general fragmentation header has been defined, based on IPv4 fragmentation (so that existing IPv4 fragmentation and reassembly code and data structures -- often the most complicated part of an IP implementation -- can be reused for SIP). o The text representation of SIP addresses has been changed to use ":" instead of "." as a separator. That allows SIP addresses to be unambiguously discriminated from host names, when entered as text. o A number of special-purpose addresses have been specified, including the loopback address and "Anyone" addresses. Anyone address have the form , and may be used to send a packet to the nearest system with the specified address prefix; Anyone addresses are primarily intended to go in source routes, to cause packets to be routed via specific domains/ providers, without having to identify specific intermediate routers. The new draft does NOT contain the information on unicast address hierarchies (provider-based and metro-based) that was in the previous draft; that information has been moved into the SIP Addressing and Routing document, which is coming soon. I'd appreciate it if SIP implementors would look over the new draft and see what I got wrong. Steve From owner-Big-Internet@munnari.oz.au Wed Nov 11 21:35:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12735; Wed, 11 Nov 1992 21:35:35 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211111035.12735@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12728; Wed, 11 Nov 1992 21:35:26 +1100 (from Z.Wang@cs.ucl.ac.uk) Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Nov 1992 10:34:24 +0000 To: Tony Li Cc: craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of "Tue, 10 Nov 92 09:06:19 PST." <9211101706.AA19956@lager.cisco.com> Date: Wed, 11 Nov 92 10:34:20 +0000 From: Zheng Wang >Let me propose an alternate scheme for doing options for IPv7: Assume >that there is some small set of options which we need to be processed >very quickly, which we know today. Allocate a byte in the network >layer header. This will be used as a bit mask, with a set bit >indicating that the option is present. Allocate the least significant >bit to indicate that some other type of TLV option is present. The >option is of a known length and is concatenated onto the header. >Further, the order in which the options appear is completely fixed, >most likely matching the order of the bits in the mask from most >significant to least significant. > >I claim that this now reduces the bloat in the header and only costs >you very few extra instructions to find and parse any of the 'fast' >options. I made similar suggestions on the pip list a couple of weeks ago when discussing the fragmentation option. If the fragmentation is an option and a host puts the option into the packets, it ends up that each router along the path has to examine the option (even there is no need of fragmentation). I suggested a 16-bit field with each bit corresponding to one option (so max 16 options, which I think is probably enough). A router only needs to look at the option when necessary, e.g. a router only checks the fragmentation option bit and examines the option, if present, when it has to fragment the packet. Cheers Zheng From owner-big-internet@munnari.oz.au Wed Nov 11 21:52:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13269; Wed, 11 Nov 1992 21:52:31 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211111052.13269@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10288; Wed, 11 Nov 1992 20:06:05 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Nov 1992 09:05:35 +0000 To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: checking options at the door - not! In-Reply-To: Your message of "Tue, 10 Nov 92 10:04:27 PST." <9211101804.AA20222@aland.bbn.com> Date: Wed, 11 Nov 92 09:05:28 +0000 From: Jon Crowcroft >list, I'd like to point out that it is highly unlikely that the IETF is >going to do anything more next week than narrow the list of protocols under >consideration for IPv7. Craig, my reading (in spare time) is that there are 3 options open: 1. clnp (with tuba etc etc) 2. ipae ... sip 3. (ei)...pip nmy vote is to be religiously multiprotocol and say that clnp is a viable part of the internet, and we should maximise connectivity for it (specially including valiant tuba type efforts) so make 1. clnp this IPv6:-) and defer on IPv7 for 2.sip versus 3.pip until sufficient implementation shows which provides the best mix of policy, flows etc etc also, since they are constraint free, they can just comete to MAKE the best future soln! jon p.s. since i wont be at ietf, i dont have to take any mnore than electronic flak:-) p.p.s. nimrod is architecture, not mechanism, so applies to many solns. ?NAT and two tier are migration tools p.p.s other efforts (ullmann etc), while honourable, do not have momentum necessary (opinion, opinion, opinion!) From owner-big-internet@munnari.oz.au Thu Nov 12 01:35:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19497; Thu, 12 Nov 1992 01:35:15 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211111435.19497@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18304; Thu, 12 Nov 1992 00:50:43 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 11 Nov 1992 13:49:57 +0000 To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: checking options at the door - not! In-Reply-To: Your message of "Wed, 11 Nov 92 05:39:20 PST." <9211111339.AA09774@Mordor.Stanford.EDU> Date: Wed, 11 Nov 92 13:49:54 +0000 From: Jon Crowcroft >I think that most of us are pushing to assert our specific "choice", >as if we each have a personal winner. au contraire - i was saying here are the options - i never said which was best... >do. Declaring that we think CLNP is best, or SIP is best, or IPX is >best is serving only to create entrenched positions and a complete >absence of useful information exchange. absolutely agree - there is no "best" >For example, Jon, since you've declared a preference for CLNP, please i think mebbe i mis-worded my message 0 i have a severe antipathy to clnp, but recognize that from certain important points of view it outdoes some competitors - however, what we have is a non-metric multidimension decision space, where someone (agreeing with you again) has to make it metric by ordering the dimensions - like Partridge/Kastenholtz has done (i specifically said "religiously multiprotocol" - this is harking back to the european net conf where there was a load of argument about x.25 performance, with me saying lets do IP, but X.25 can be made to perform well - based on measurements of IP everywhere, and the knowldge that only our uk x.25 could go at anywhere near 8 Mbps let alone 2! - i.e. i contradicted myselkf then too:-) jon From owner-Big-Internet@munnari.oz.au Thu Nov 12 01:43:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19679; Thu, 12 Nov 1992 01:43:32 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211111443.19679@munnari.oz.au> Received: from TTL.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19665; Thu, 12 Nov 1992 01:43:07 +1100 (from ppark@BBN.COM) To: Jon Postel Cc: deering@parc.xerox.com, iana@isi.edu, big-internet@munnari.oz.au Subject: Re: IPv6? In-Reply-To: Your message of Mon, 09 Nov 92 13:28:45 -0800. <199211092128.AA23535@zephyr.isi.edu> Date: Wed, 11 Nov 92 09:32:19 -0500 From: ppark@BBN.COM ST-II uses IP version 5. It is distinguished from earlier implementations by specifying revision 2 in the ST header. Phil From owner-big-internet@munnari.oz.au Thu Nov 12 01:49:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19966; Thu, 12 Nov 1992 01:50:06 +1100 (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 AA18048; Thu, 12 Nov 1992 00:40:05 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA09774; Wed, 11 Nov 92 05:39:21 -0800 Message-Id: <9211111339.AA09774@Mordor.Stanford.EDU> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: checking options at the door - not! Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 11 Nov 92 09:05:28 +0000. <9211111052.13269@munnari.oz.au> Date: Wed, 11 Nov 92 05:39:20 -0800 From: Dave Crocker X-Mts: smtp Jon, I think that most of us are pushing to assert our specific "choice", as if we each have a personal winner. Let me suggest that -- at this stage -- that well may be the very worst thing that any of us can do. Declaring that we think CLNP is best, or SIP is best, or IPX is best is serving only to create entrenched positions and a complete absence of useful information exchange. Let me suggest that what we _must_ do first is to seek some community sense about priorities of concerns. The Partridge/Kastenholtz effort seems to me to be _exactly_ the style of thing we should be trying to develop. (I have many concerns about the details of the current draft, but believe the framework and general thrust are very, very much in the right direction.) How can any of us claim what is the "right" choice if we have no real shared understanding of the trade-offs? To date, people say that they like a particular choice for certain reasons, but they do not simultaneously assert their feelings about other factors. So, saying "CLNP is friendliest to the International standards community and those pursuing its use" or "PIP is the best design for long-term growth in functionality" or "SIP is the friendliest to the installed base of IP users" merely lets everyone know that you understand the core intent of the designers. But it doesn't help the community consider the tradeoffs. For example, Jon, since you've declared a preference for CLNP, please tell me your reasons for deprecating such things as CLNP's technical deviations from IP (e.g., checksum) and the hassles that will cause in implementation and integration with TCP, etc. Or the effect you think choosing CLNP will (or won't) have on network operations and operators, as well as other staff in the existing IP world, or... And so on. Dave From owner-Big-Internet@munnari.oz.au Thu Nov 12 02:45:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21470; Thu, 12 Nov 1992 02:45:24 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21459; Thu, 12 Nov 1992 02:45:00 +1100 (from Scott_Brim@cornell.edu) Received: from by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB01412; Wed, 11 Nov 92 10:44:11 EST Date: Wed, 11 Nov 92 10:44:11 EST Message-Id: <9211111544.AB01412@mitchell.cit.cornell.edu> To: Jon Crowcroft From: Scott_Brim@cornell.edu Sender: swb@nr-tech.cit.cornell.edu Subject: Re: checking options at the door - not! Cc: big-internet@munnari.oz.au Thank you very much, Jon. A quick reading leads me to believe I agree 100%. From owner-big-internet@munnari.oz.au Thu Nov 12 04:25:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23349; Thu, 12 Nov 1992 04:25:21 +1100 (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 AA19575; Thu, 12 Nov 1992 01:36:24 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01349; Wed, 11 Nov 92 09:35:50 -0500 Date: Wed, 11 Nov 92 09:35:50 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211111435.AA01349@ginger.lcs.mit.edu> To: craig@aland.bbn.com Subject: Re: checking weapons at the door - not! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I just got a query asking if my note was intended to say we'd really have to fight it out at IETF. I was trying to suggest the opposite -- if no final winner is to be chosen, I think we can allow the intensity of discussion to go down a bit. Everyone: I think we'd all be loony (and open to charges of incompetence) if we try to decide which potential solution to use based on arguing about specs. One of the great strengths of the TCP/IP standards creation process was a great reliance on actual experience. We don't even let something get to 'draft' without several interoperable implementations! These plan are all being drafted by good engineers, but there are *always* problems that not even the best engineer can forsee, and they aren't always trivial to fix; they may be a problem with the basic approach. I find it incomprehensible that we can even *think* about making a choice in this most extremely important matter (probably the single most important decision made about the Internet in the last 12 years) without a fair amount of actual field experience with several solutions. Any realistic solution is going to have to be something that can be installed in an interoperable way; i.e. it has to communicate with the existing installed base. This means that we *ought* to be able to field test several different solutions simultaneously, without any great upheaval in the rest of the network. Yes, this means we have to build some stuff that is going to be thrown away. So what? Writing the specs isn't exactly a no-cost operation, and we are expecting to throw them away. The cost to build a few trials is minor compared to what it will teach us. We have to look at some actual field experience before we make a decision. I hope everyone agrees that this is the way to go. Noel From owner-Big-Internet@munnari.oz.au Thu Nov 12 04:38:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23666; Thu, 12 Nov 1992 04:38:21 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211111738.23666@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23661; Thu, 12 Nov 1992 04:38:12 +1100 (from jcurran@nic.near.net) To: Dave Crocker Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: checking options at the door - not! In-Reply-To: Your message of Wed, 11 Nov 92 05:39:20 -0800. <9211111339.AA09774@Mordor.Stanford.EDU> Date: Wed, 11 Nov 92 12:37:42 -0500 From: John Curran -------- ] From: Dave Crocker ] Subject: Re: checking options at the door - not! ] Date: Wed, 11 Nov 92 05:39:20 -0800 ] ] Jon, ] ] I think that most of us are pushing to assert our specific "choice", ] as if we each have a personal winner. Let me suggest that -- at this ] stage -- that well may be the very worst thing that any of us can ] do. Declaring that we think CLNP is best, or SIP is best, or IPX is ] best is serving only to create entrenched positions and a complete ] absence of useful information exchange. Agreed. ] Let me suggest that what we _must_ do first is to seek some community ] sense about priorities of concerns. The Partridge/Kastenholtz ] effort seems to me to be _exactly_ the style of thing we should ] be trying to develop. (I have many concerns about the details of the ] current draft, but believe the framework and general thrust are very, ] very much in the right direction.) The prioritizing and refining the criteria is very important. Another concern is that we are not all working under the same assumptions about the address-depletetion/routing-table-growth problem. Many of the proposed solutions have optional implementation steps to accomodate our lack of consensus in key areas. In particular: o Is CIDR (and big routers :-) sufficient to handle IP routing between now and address-depletion time, or is some additional mechanism required before then? o Is it acceptable to provide unmodified IPv4 hosts partial connectivity in the future, or must dynamic address mapping be provided? o May IPv7 addresses embody geographic restrictions in their use, or should geographically independent addresses be available? o May IPv7 addresses embody topological restrictions in their use, or should topologically independent addresses be available? If nothing else, a friendly discussion on these topics with the goal of establishing rough consensus is in order. If we can decide on at least one of these issues (without dropping into particular proposals), then the time will have been well spent. /John From owner-big-internet@munnari.oz.au Thu Nov 12 04:54:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23991; Thu, 12 Nov 1992 04:54:40 +1100 (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 AA20892; Thu, 12 Nov 1992 02:22:00 +1100 (from kasten@ftp.com) Received: by ftp.com id AA03736; Wed, 11 Nov 92 10:21:31 -0500 Date: Wed, 11 Nov 92 10:21:31 -0500 Message-Id: <9211111521.AA03736@ftp.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: checking options at the door - not! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au Jon Your note is a good example of how logic can be used to get the wrong answer :-) I do not believe that two transitions (IPv4->CLNP/IPv6-> IPv7) are possible. Commercial vendors and system administrators will be opposed to the idea. The next IP is something that we will have to live with for 10-20 years. The costs of changing are too high. If you do not believe me; this summer, in the SNMP area, we finally published RFCs for security _and_ we started work on SNMP Version 2 (SMP). There was very very strong pressure from within the community to skip going from SNMPv1 to SNMPv1 with security now (going to SNMPv2 in a year) and just waiting for SNMPv2. And SNMP is not a protocol that is fundamental to providing connectivity to all nodes, as IP is. -- Frank Kastenholz From owner-big-internet@munnari.oz.au Thu Nov 12 05:21:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24466; Thu, 12 Nov 1992 05:21:09 +1100 (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 AA20929; Thu, 12 Nov 1992 02:23:49 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01597; Wed, 11 Nov 92 10:22:40 -0500 Date: Wed, 11 Nov 92 10:22:40 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211111522.AA01597@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, craig@aland.bbn.com Subject: Re: checking options at the door - not! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu so make 1. clnp this IPv6:-) and defer on IPv7 for 2.sip versus 3.pip until sufficient implementation shows which provides the best mix of policy, flows etc etc Jon, why go through this intermediate stage (which is going to be tremendously painful, since we have to go around and modify tons of hosts to deploy it) if we are going to replace it soon? Why not patch the existing IP into working a little longer until we can deploy 2 or 3 (or some new thing) directly? There are at least 2 possibilities for doing this: - Use of NAT boxes, which can put off the date of mandatory change almost indefinitely, depending on what routing/addressing architecture you deploy them with. - Reinterpretation of the existing 32-bit quantities as EID's, which, even if we only get 10% utilization, gives us 5x10^8 hosts, or about 8 more years at current growth rates. Noel From owner-big-internet@munnari.oz.au Thu Nov 12 06:08:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25193; Thu, 12 Nov 1992 06:08:29 +1100 (from owner-big-internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21107; Thu, 12 Nov 1992 02:30:09 +1100 (from tbooth@netcom.com) Received: from netcom2.netcom.com by ux1.cso.uiuc.edu with SMTP id AA08875 (5.67a8/IDA-1.5 for ); Wed, 11 Nov 1992 09:28:56 -0600 Received: by netcom2.netcom.com (5.65/SMI-4.1/Netcom) id AA28669; Wed, 11 Nov 92 07:26:45 -0800 Newsgroups: info.big-internet Path: tbooth From: tbooth@netcom.com (Todd Booth) Subject: RFD: comp.dcom.sys.wellfleet Message-Id: <1992Nov11.152639.28625@netcom.com> Followup-To: news.groups Keywords: bridge, router, wellfleet, RFD Organization: Wellfleet Communications, Inc Date: Wed, 11 Nov 1992 15:26:39 GMT Apparently-To: info-big-internet@ux1.cso.uiuc.edu This is a formal Request for Discussion on the creation of a new newsgroup called "comp.dcom.sys.wellfleet" (not moderated). The orginal post did not work to all the following groups so this is a repost: Newsgroups: news.announce.newgroups,news.groups,comp.dcom.lans.ethernet,comp.dcom.lans.fddi,comp.dcom.lans.misc,comp.dcom.lans,comp.dcom.cell-relay,comp.dcom.lans.novell,comp.protocols.tcp-ip,info.big-internet This announcement is cross-posted to newsgroups whose readers may have interest in the discussion about the new group; follow-up discussion will take place in "news.groups". Suggestions, comments or problems may also be emailed to me at . REQUEST FOR DISCUSSION ---------------------- NEWSGROUP comp.dcom.sys.wellfleet (not moderated) PURPOSE The newsgroup 'comp.dcom.sys.wellfleet' would be a forum for discussing issues related to Wellfleet bridge and router systems hardware & software, interoperability with other products, and system configuration. It will NOT be a forum for forwarding sensitive information as e-mail and individual contact are for this purpose. It could be the best, and quickest way to exchange questions and answers, hints and tips on optimization, have contacts between users having common problems and maybe some common solutions. RATIONALE Very often Wellfleet users receiving news and having questions don't know really where to post their questions in such a way that it could be answered by some other Wellfleet users. In the same way, people who could be able to answer the question are not necessarily inspecting all articles where Wellfleet is mentioned, such a newsgroup will usually permit better follow-ups for Wellfleet issues. Users could discover lot of indirect Wellfleet matter accidentally in comp.dcom.lans.{ethernet, fddi, misc...}. Wellfleet User Groups exist in the U.S. and Europe. Mailing lists have been going in the U.S and Europe for several years; but this way of communicating is not particularly adequate for users of multi-recipient systems, i.e., each message is sent to each registered user, even on the same systems, moreover each user must ask to be explicitely registered. A newsgroup would permit all users of Wellfleet systems receiving the News to receive only one copy of each message and to share it potentially with all the users of the systems. This newsgroup could be a prolongation of each annual Wellfleet User Groups meetings, permitting not only to those (s)elected people having the chance to take part to these interesting reunions but also to more common users, students, researchers, etc... to share their experiences. In the era of communication, newsgroups are the easiest way to build bridges across oceans and permitting of people with common interests to be part of an electronic community wherever they are located in the world. CONTENT Miscellaneaous - Wellfleet FAQ - jobs available - other events that concern Wellfleet systems and/or users Hardware - Wellfleet Nodes series - Wellfleet Backbone Node series - interfacing 3rd party products to Wellfleet systems Software - Public domain SNMP software for management of Wellfleet systems - Software releases discussion and announcements - Customization of network configurations for optimal performance System - Network integration - Multi-vendor compatibility - System tuning - Benchmarking and performance measurement System administration - Security - How to upgrade between releases - Remote upgrades This newsgroup will be in conjunction with the existing mailing lists to allow users who do not receive News to submit and receive newsgroup traffic and take part in the discussions. NAME comp.dcom.sys.wellfleet seems to be the name fitting the most adequately the purpose. NOT MODERATED In order to have questions answered as fast as possible, this newsgroup would not need to be moderated and indeed would most probably be self-moderated. NEWSGROUP CREATION The discussion period will be from November 10th, 1992 to December 2nd, 1992. Please post all discussion in news.group. If a consensus is reached by the end of the discussion period, a CFV (Call for Votes) will be posted at that time. The voting period will last for 21 days. Thanks for your interest ! Todd Booth | Systems Engineer | Wellfleet Communications, Inc | 310 445-8840 From owner-big-internet@munnari.oz.au Thu Nov 12 06:34:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25788; Thu, 12 Nov 1992 06:34:19 +1100 (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 AA24602; Thu, 12 Nov 1992 05:31:40 +1100 (from kasten@ftp.com) Received: by ftp.com id AA07576; Wed, 11 Nov 92 13:31:08 -0500 Date: Wed, 11 Nov 92 13:31:08 -0500 Message-Id: <9211111831.AA07576@ftp.com> To: jcurran@nic.near.net Subject: Re: checking options at the door - not! From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dcrocker@mordor.stanford.edu, J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au > o May IPv7 addresses embody geographic restrictions in their use, > or should geographically independent addresses be available? > > o May IPv7 addresses embody topological restrictions in their use, > or should topologically independent addresses be available? I do not view these sorts of things as criteria, per se, of a protocol. I would imagine that any proposal would include discussion of these sorts of restrictions. When evaluating the proposals, we will have to weigh these restrictions against the proposal as a whole and determine if we can live with them or not. -- Frank Kastenholz From owner-big-internet@munnari.oz.au Thu Nov 12 07:20:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26565; Thu, 12 Nov 1992 07:20:51 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211112020.26565@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25033; Thu, 12 Nov 1992 05:56:15 +1100 (from ULLMANN@PROCESS.COM) Date: Wed, 11 Nov 1992 13:54 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: Flows Hi, > From: Craig Partridge > Date: Mon, 09 Nov 92 16:31:26 -0800 > My key concern is that the bits be in the header (not in an option -- the > goal of the flow field is to give packets *preferential* service, not > inferior service via the slow option-handling path). Last details can be > worked out during the testing of the proposed IPv7. The unstated assumption here (which I believe is invalid) is that option processing is necessarily slow. Note that the fact that it is slow in IPv4 _implementations_, where it is the exception case, is not designed for speed, and has not attracted any attention to optimization, is *totally* irrelevent. ----- Suppose we define a flow ID option for IPv7 as detailed in my draft (so as to have a concrete example of an optimized option): Type code is (say) 10 (0A hex), length is 8 (bytes), class is 0, data is a 32 bit flow ID. Implementations are expected to place the flow option as the first or only option; if it is placed elsewhere it might be slower. (I.e. when there are multiple options present, datagram originators SHOULD place the TOS-related option first.) Processing (all numbers are hex): if 16-bit word at offset 0 > 7008 then if 32-bit word at offset 1C = 000A0008 then 32-bit word at offset 20 is flow-ID Of course, if a particular router wants to optimize for flow-ID present (i.e. take the expensive branches for the lower priority packets), then it would go like this in the actual generated code: if 16-bit word at 0 is < 7009 goto 10$ if 32-bit word at 1C is not = 000A0008 goto 10$ load 32-bit word at 20 (flow processing) 10$: ... Four cisc instructions or 6 overlapped risc instructions is not a lot. And we have done half of the required check on the version number field at the same time (for the optimized branch). (At some time we have to check 16-bit word at offset 0 is < 8000) [Actually, a fixed field would probably slow down the general case (non-optimized) even more than options: the speed limit is the number of cache misses while reading the header times the RAM access time; this is directly proportional to the header length.] ----- And of course, we keep all the advantages of an option: it isn't used or checked by most hosts (ignored as being unknown, with a class indication that says it is ignorable). And when you want to experiment with different flavors, you just have different options. Do _you_know_ enough _now_ to design a fixed length header field for flow-ID (or TOS) and not have to add an extension option later anyway? Are you ready to lock in The One True Way of doing it? :-) Best Regards, Robert From owner-big-internet@munnari.oz.au Thu Nov 12 11:59:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05489; Thu, 12 Nov 1992 12:00:00 +1100 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29039; Thu, 12 Nov 1992 09:20:53 +1100 (from hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03953; Wed, 11 Nov 92 14:20:24 PST Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA08952; Wed, 11 Nov 92 14:20:27 PST Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA10871; Wed, 11 Nov 92 14:19:31 PST Date: Wed, 11 Nov 92 14:19:31 PST From: hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9211112219.AA10871@bigriver.Eng.Sun.COM> To: big-internet@munnari.oz.au, ip-encaps@sunroof.Eng.Sun.COM, sip@caldera.usc.edu Cc: hinden@Eng.Sun.COM Subject: Criteria Analysis for IPAE and SIP Content-Length: 323 Folks, A new Internet Draft is being distributed titled: IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP) Prior to the document appearing in the internet draft directories, it can be found on parcftp.xerox.com, file name pub/ip-encaps/criteria-analysis. Bob From owner-big-internet@munnari.oz.au Thu Nov 12 12:19:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06326; Thu, 12 Nov 1992 12:20:11 +1100 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03563; Thu, 12 Nov 1992 11:16:47 +1100 (from kre) To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: FWD: Re: Flows In-Reply-To: Your message of Wed, 11 Nov 92 13:54:00 -0500. Date: Thu, 12 Nov 92 11:16:29 +1100 Message-Id: <22855.721527389@munnari.oz.au> From: Robert Elz Date: Wed, 11 Nov 1992 13:54 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) Implementations are expected to place the flow option as the first or only option; if it is placed elsewhere it might be slower. (I.e. when there are multiple options present, datagram originators SHOULD place the TOS-related option first.) This is fine as long as there's only one such "magic" option, but as soon as you get two, you start getting the old problems back. Further, if CLNP becomes IPv7, fragmentation is already the one "magic" option (I believe) so flows would have to be a second option, now the tests become rather more complicated as you first have to work out if the fragmentation option is there or not before you can decide where the flow option will appear in the packet. Then if we assume addition of a security option, which routers would also need to process, and which we'd want to make fast (security here as in restricting the links on which this packet is permitted to travel, not end-end data security (or privacy) or authentication) - now there are three options, any one or more of which may be present, perhaps in a defined order. Working out where to look for the third is even more complicated. The bit vector (to say which options are present) looks to be the right way to go if routing type data is to be carried as options, even there its a little tricky to do things fast if any of the options might be variable length (source routing for one) - if they're fixed length, a mask and table lookup will provide an offset into the packet for any option that is present - assuming options must be given in the order they're given in the bit vector, with the option corresponding to the least significant bit first. Incidentally, I doubt there's much value in only saying "SHOULD place the XXX option first", if its allowed to be in some other position then if there are ever any other options carried, you stand to lose as often as you win (every packet carrying some other option, but not XXX, has to be examined in detail to see if it happens to have XXX in some other position). kre From owner-big-internet@munnari.oz.au Thu Nov 12 16:17:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14926; Thu, 12 Nov 1992 16:17:16 +1100 (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 AA11094; Thu, 12 Nov 1992 14:30:07 +1100 (from pgross@ans.net) Received: by interlock.ans.net id AA07689 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Wed, 11 Nov 1992 22:29:06 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 11 Nov 1992 22:29:06 -0500 Message-Id: <199211120327.AA05419@home.ans.net> To: Steve Deering Cc: postel@isi.edu, big-internet@munnari.oz.au Subject: Re: IPv6? In-Reply-To: (Your message of Mon, 09 Nov 92 12:53:06 PST.) <92Nov9.125317pst.10779@skylark.parc.xerox.com> Date: Wed, 11 Nov 92 22:27:10 -0500 From: Phill Gross Has IP version number 6 been officially assigned yet, or are you aware of any unofficial usage of version number 6 (perhaps by ST-II?)? Steve, Good point. Some of us recently noticed that every "Assigned Numbers" back to around 1983 has IP version numbers 6-14 listed as "unassigned". Can anyone recall how/why we started calling the next IP "IPv7"? Phill From owner-big-internet@munnari.oz.au Thu Nov 12 16:22:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15102; Thu, 12 Nov 1992 16:22:54 +1100 (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 AA11124; Thu, 12 Nov 1992 14:30:53 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26491; Wed, 11 Nov 92 19:27:44 -0800 Message-Id: <9211120327.AA26491@Mordor.Stanford.EDU> To: ip-encaps@sunroof.eng.sun.com, sip@caldera.usc.edu, big-internet@munnari.oz.au Subject: New draft of IPAE spec available Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Wed, 11 Nov 92 19:27:44 -0800 From: Dave Crocker X-Mts: smtp A new version of the IPAE specification has been submitted to the Internet Drafts directory, and will be formally announced in due course. For those too eager to wait, postscript(r) and ascii version are accessible at: parcftp.xerox.com:pub/ip-encaps. There are two files: ipae-spec - ASCII version ipae-spec.ps - PostScript version Please note that IPAE has undergone very considerable change. While retained the core concept of encapsulation of the new addresses inside the old IPv4, IPAE now uses SIP for the "new addresses". Hence, IPAE offers itself purely as a transition technology, rather than as an end-point for the conversion. As working group chair, I'll also impose myself on you folks to comment that Bob Hinden and I both feel that the working group team effort has been quite spectacular. Synergy is an overused word, but quite applicable, here. The Acknowledgements section goes into that more. But I thought I'd use this forum to offer my thanks to all of the working group members. (I'll even note that we've had useful comments and suggestions from those otherwise classed as competitors.) Dave From owner-Big-Internet@munnari.oz.au Thu Nov 12 17:01:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16427; Thu, 12 Nov 1992 17:02:29 +1100 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16408; Thu, 12 Nov 1992 17:01:22 +1100 (from kre) To: Phill Gross Cc: Steve Deering , postel@isi.edu, big-internet@munnari.oz.au Subject: Re: IPv6? In-Reply-To: Your message of Wed, 11 Nov 92 22:27:10 -0500. <199211120327.AA05419@home.ans.net> Date: Thu, 12 Nov 92 17:01:07 +1100 Message-Id: <23133.721548067@munnari.oz.au> From: Robert Elz Date: Wed, 11 Nov 92 22:27:10 -0500 From: Phill Gross Message-ID: <199211120327.AA05419@home.ans.net> Can anyone recall how/why we started calling the next IP "IPv7"? My impression is that its simply been common knowledge that IP #6 was assigned to ST-II, or some other thing that no-one can ever quite remember right now - even though every time anyone has ever said that someone else who knows better has pointed out that 6 has never been assigned... Its probably that no-one has been willing to take that small risk that they just migt be stepping all over someone else's protocol number, so pick a higher one and be safe. kre From owner-Big-Internet@munnari.oz.au Fri Nov 13 03:24:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05115; Fri, 13 Nov 1992 03:26:15 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211121626.5115@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05096; Fri, 13 Nov 1992 03:24:33 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 12 Nov 1992 11:19 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: Re: Flows Hi, Date: Thu, 12 Nov 92 11:16:29 +1100 From: Robert Elz Date: Wed, 11 Nov 1992 13:54 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) Implementations are expected to place the flow option as the first or only option; if it is placed elsewhere it might be slower. (I.e. when there are multiple options present, datagram originators SHOULD place the TOS-related option first.) This is fine as long as there's only one such "magic" option, but as soon as you get two, you start getting the old problems back. I understand, but I think you're missing the point: my point is that if optimizing a case of header+flow-ID becomes important in some environment, each router can do that, _without_ requiring the level of network-wide design integration required by a "magic" option definition (ala CLNP fragment); and the CPU time cost of doing it is almost negligible. The next router along the path can do something different; boxes that just do all the options in the general way will work too. And if the option gets replaced with a different one, individual routers can be altered to change their optimizations without requiring covrdination with the next one down the line. If the optimization becomes crucial, essentially all routers will do it; if it becomes irrelevent, it will disappear. Again, without requiring network-wide changes. Best Regards, Robert From owner-big-internet@munnari.oz.au Fri Nov 13 04:09:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06090; Fri, 13 Nov 1992 04:10:51 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211121710.6090@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05636; Fri, 13 Nov 1992 03:48:34 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 12 Nov 1992 11:42 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: IPv6? Date: Wed, 11 Nov 92 22:27:10 -0500 From: Phill Gross Can anyone recall how/why we started calling the next IP "IPv7"? Phill *sigh* and Dave Crocker has even written in Connexions [V6.11, Nov 92, p2] that "... 5 and 6 have been used elsewhere" Sorry about this. Is my fault. 6 is not assigned, and apparently not in use anywhere. When I wrote the informal paper that became (nearly 5 years later :-) the draft now published as draft-ullmann-ipv7-00.txt I looked at the assigned numbers list. I picked 7 for two reasons, one being that I wasn't sure (as Robert Elz suggests) whether 6 might have been assigned or about to be, the other simply that I liked 7 better. (:-) I sent this draft a year or two later to Vint Cerf, who copied it to an IAB/IESG (I'm not sure who was on that list exactly, but I received comments from several people.) Sometime later when Noel Chiappa asked for ideas, I sent him copies of two different (radically different) stages of the evolution of the paper. Undoubtedly these planted the idea that 7 was the next version. I was a more than a little startled to see the June "IPv7" draft calling CLNP (or CLNP+) IPv7; I had thought of it as the designator for my proposal(s). Interesting how things wander about, changing shape. Best Regards, Robert From owner-Big-Internet@munnari.oz.au Fri Nov 13 05:39:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08118; Fri, 13 Nov 1992 05:45:00 +1100 (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 AA07952; Fri, 13 Nov 1992 05:39:15 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10335; Thu, 12 Nov 92 13:35:11 -0500 Date: Thu, 12 Nov 92 13:35:11 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211121835.AA10335@ginger.lcs.mit.edu> To: deering@parc.xerox.com, pgross@ans.net Subject: Re: IPv6? Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, postel@isi.edu Can anyone recall how/why we started calling the next IP "IPv7"? A number of us (I know I did, and perhaps others as well) thought that ST-II had been allocated a version number. What I didn't realize is that ST has a version number of its own, and ST-I and ST-II are *both* IPv5. Noel From owner-big-internet@munnari.oz.au Fri Nov 13 05:28:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07902; Fri, 13 Nov 1992 05:36:53 +1100 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06911; Fri, 13 Nov 1992 04:49:34 +1100 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA17555; Thu, 12 Nov 92 09:49:01 PST Date: Thu, 12 Nov 92 09:49:01 PST From: fbaker@acc.com (Fred Baker) Message-Id: <9211121749.AA17555@saffron.acc.com> To: ULLMANN@PROCESS.COM Subject: Re: FWD: Re: Flows Cc: big-internet@munnari.oz.au, kre@munnari.oz.au Implementations are expected to place the flow option as the first or only option; if it is placed elsewhere it might be slower. (I.e. when there are multiple options present, datagram originators SHOULD place the TOS-related option first.) I can think of devices that expect other options to be the first or only option, notably in the realm of secure networks. I don't think that would be a good thing to depend on. Fred From owner-Big-Internet@munnari.oz.au Fri Nov 13 06:00:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08571; Fri, 13 Nov 1992 06:01:27 +1100 (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 AA08564; Fri, 13 Nov 1992 06:00:41 +1100 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Thu, 12 Nov 1992 10:59:42 -0800 Date: Thu, 12 Nov 1992 10:59:42 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199211121859.AA10412@zephyr.isi.edu> To: deering@parc.xerox.com, pgross@ans.net Subject: Re: IPv6? Cc: postel@ISI.EDU, big-internet@munnari.oz.au > > Can anyone recall how/why we started calling the next IP "IPv7"? > > Phill > Phill, We chose a number that we thought, without much checking, was safely larger than any in use, and that "sounded larger". It was only a symbol, after all, but it successfully conveyed the desired message. The IANA will assign an actual version number to go into a packet header when we figure out what protocol will carry the designation. Maybe there will be several experimental ones, in which case IANA will assign each a number, in which case we cannot predict now what the final official version number will be. Maybe there are more important issues than what value of n should appear in the generic term "IPn"? I like n=7. Bob Braden From owner-Big-Internet@munnari.oz.au Fri Nov 13 06:22:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09019; Fri, 13 Nov 1992 06:24:43 +1100 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08994; Fri, 13 Nov 1992 06:22:40 +1100 (from news@ms.uky.edu) Received: from mozart.ms.uky.edu by ux1.cso.uiuc.edu with SMTP id AA15314 (5.67a8/IDA-1.5 for ); Thu, 12 Nov 1992 13:21:21 -0600 Received: from s.ms.uky.edu by mozart.ms.uky.edu id aa15232; 12 Nov 92 14:18 EST From: USENET News System Date: Thu, 12 Nov 1992 14:18:08 EST X-Mailer: Mail User's Shell (7.1.2 7/11/90) To: info-big-internet@ux1.cso.uiuc.edu Message-Id: <9211121918.aa17129@s.s.ms.uky.edu> Newsgroups: info.big-internet Path: news From: bdaker00@nx19.mik.uky.edu (brian d aker) Subject: Opinion needed... Nntp-Posting-Host: nx19.mik.uky.edu Message-ID: Organization: University Of Kentucky, Dept. of Math Sciences X-Path: nx19.mik.uky.edu!bdaker00 Sender: news@ms.uky.edu (USENET News System) Date: Thu, 12 Nov 1992 19:14:45 GMT Lines: 7 Would use of an educational internet site, to transport information for an outside commercial group, be a violation of the site liscence? Even if this information was about the university's computer system? What about information that was not? thanks Brian From owner-Big-Internet@munnari.oz.au Fri Nov 13 09:25:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13647; Fri, 13 Nov 1992 09:26:13 +1100 (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 AA13632; Fri, 13 Nov 1992 09:25:30 +1100 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Thu, 12 Nov 1992 14:24:54 -0800 Date: Thu, 12 Nov 1992 14:24:54 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199211122224.AA12572@zephyr.isi.edu> To: big-internet@munnari.oz.au, ULLMANN@process.com Subject: Re: FWD: Re: IPv6? Robert, It appears to be a case of Great Minds all coming to the same conclusion. Bob Braden From owner-Big-Internet@munnari.oz.au Fri Nov 13 09:59:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14969; Fri, 13 Nov 1992 10:05:58 +1100 (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 AA14765; Fri, 13 Nov 1992 09:59:51 +1100 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29772; Thu, 12 Nov 92 14:58:12 -0800 Received: by us1rmc.bb.dec.com; id AA23864; Thu, 12 Nov 92 17:55:33 -0500 Message-Id: <9211122255.AA23864@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 12 Nov 92 17:55:34 EST Date: Thu, 12 Nov 92 17:55:34 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: security option optimization ( was Re: FWD: Re: Flows ) I'm not sure why people keep bringing up security as an example of another thing that would want to be the first option. Seems to me that almost all authentication/security will be end to end and not have to been seen by any routers and so is a very poor candidtate for super optimization. (To the extent that you may need single hop security, putting crypto hardware on the lines, which takes little or no processing in the routers, is most likely the way to go.) Donald -------------- From: US1RMC::"fbaker@acc.com" "Fred Baker" 12-NOV-1992 17:37 To: ULLMANN@PROCESS.COM CC: big-internet@munnari.oz.au, kre@munnari.oz.au Subj: Re: FWD: Re: Flows Implementations are expected to place the flow option as the first or only option; if it is placed elsewhere it might be slower. (I.e. when there are multiple options present, datagram originators SHOULD place the TOS-related option first.) I can think of devices that expect other options to be the first or only option, notably in the realm of secure networks. I don't think that would be a good thing to depend on. Fred From owner-big-internet@munnari.oz.au Fri Nov 13 19:34:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03246; Fri, 13 Nov 1992 19:36:34 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211130836.3246@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20803; Fri, 13 Nov 1992 13:18:43 +1100 (from ULLMANN@PROCESS.COM) Date: Thu, 12 Nov 1992 21:18 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: position statement Hi, I will unfortunately not be at the IETF; the following is want I want to say as input to the conference. Details of what something might look like, and some more opinion are in draft-ullmann-ipv7-00.txt if you care to look. Please don't bother trying to reply to this on the list; it will just raise the noise level; this is to be read ONLY as one contributor's position statement. Tx, Rob -------------------------------------------------------------------- If we want to have an IPv7 that is *not* CLNP, there are certain imperatives, mostly having to do with the existing deployment of IPv4 and the commercial world reality, where organizations exist to do other things, not just play with Neat Network Stuff. If IPv7 is perceived as Yet Another Protocol (a YAP), it will _not_ be deployed by any serious commercial organization. They are already doing both IPv4 and CLNP, and would prefer to get rid of one of those. Adding another won't fly. If the IETF community does decide on a YAP, you will find that the commercial vendors either do not support it, or support it only as an option that isn't given any real resource. There simply is no market. If IPv7 is not to be a YAP, there are imperatives: * It MUST NOT be marketed as something different from IPv4; the differences must be down-played at every opportunity. * It MUST NOT require renumbering the Internet. The administrative work already accomplished is immense, if it is to be done again it _will_ be in assigning NSAPs. * It MUST allow IPv4 hosts to interoperate without any reduction in function, without any modification to their software _or_ _configuration_. (Universal connectivity will be lost by IPv4 hosts, but they MUST be able to continue operating within their organization at least.) * It MUST permit network layer state-free translation of datagrams between IPv4 and IPv7; this is important to the previous point, and essential to early testing and transitional deployment. * It MUST in the end be a competent alternative to CLNP. (This is in my opinion where IPAE loses; it takes us forward from IPv4, but never _arrives_ at the future :-) * It MUST NOT involve changing the semantics of the network layer service in any way that invalidates the huge amount of work that has gone into understanding how TCP (for example) functions in the net, and the implementation of that understanding. * It MUST be defined Real Soon; the window of opportunity is almost closed. It will take vendors 3 years to deploy from the time the standard is rock-solid concrete. I believe all of these are accomplishable in a consistent, well-engineered solution, and all are essential to the survival of the Internet. With My Best Regards, Robert Ullmann Process Software Corporation +1 508 879 6994 x226 (800) 722 7770 x226 From owner-Big-Internet@munnari.oz.au Sat Nov 14 01:06:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14309; Sat, 14 Nov 1992 01:06:59 +1100 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14278; Sat, 14 Nov 1992 01:06:23 +1100 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA14251; Fri, 13 Nov 92 06:05:59 PST Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA27592; Fri, 13 Nov 92 09:05:57 EST Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA03090; Fri, 13 Nov 92 09:02:46 EST Date: Fri, 13 Nov 92 09:02:46 EST From: Frank T Solensky Message-Id: <9211131402.AA03090@fenway.andr.UB.com> To: ULLMANN@process.com, big-internet@munnari.oz.au, braden@ISI.EDU Subject: Re: FWD: Re: IPv6? >It appears to be a case of Great Minds all coming to the same >conclusion. So I guess that we'll talking about IPv8 now? :-) -- Frank From owner-Big-Internet@munnari.oz.au Sat Nov 14 02:52:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17955; Sat, 14 Nov 1992 02:53:46 +1100 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17896; Sat, 14 Nov 1992 02:52:58 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 13 Nov 92 10:52:41 EST Received: by chiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 13 Nov 92 10:52:40 EST Date: Fri, 13 Nov 92 10:52:40 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9211131552.AA02941@chiya.bellcore.com> To: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subject: pip ipv7 criteria ID Gang, The criteria analysis of EIPIP (Pip with EIP as the transition mechanism) is now done. It is too late to announce as an internet draft before ietf, so you can get it at thumper.bellcore.com:pub/tsuchiya/PIP.IPv7.criteria Cheers, PX From owner-Big-Internet@munnari.oz.au Sat Nov 14 03:56:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19592; Sat, 14 Nov 1992 03:57:42 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211131657.19592@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19567; Sat, 14 Nov 1992 03:56:46 +1100 (from ULLMANN@PROCESS.COM) Date: Fri, 13 Nov 1992 11:53 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: re: position statement Hi, I stand corrected on one parenthetical comment in my position statement: recent work on using IPAE as a transition for SIP means that IPAE does have a proper endpoint, and meets the criteria in question. You will kindly let me withdraw that comment? My thanks to Bob Hinden of Sun Microsystems for pointing this out. Best Regards, Robert From owner-big-internet@munnari.oz.au Sun Nov 15 05:46:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09947; Sun, 15 Nov 1992 05:46:40 +1100 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21395; Sat, 14 Nov 1992 20:51:52 +1100 (from kre) To: ULLMANN@PROCESS.COM (Robert L Ullmann) Cc: big-internet@munnari.oz.au Subject: Re: Flows In-Reply-To: Your message of Thu, 12 Nov 92 11:19:00 -0500. Date: Sat, 14 Nov 92 20:51:37 +1100 Message-Id: <24010.721734697@munnari.oz.au> From: Robert Elz Date: Thu, 12 Nov 1992 11:19 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) I understand, but I think you're missing the point: my point is that if optimizing a case of header+flow-ID becomes important in some environment, each router can do that, _without_ requiring the level of network-wide design integration required by a "magic" option definition (ala CLNP fragment); No, I think you're missing my point - your router can only optimise if it can predict the option will be present in the position and format it expects it to be found, that it may be able to do if there's just one option worth optimising, and all the hosts assist by carefully arranging for nice optimisable packets - but as soon as there are two or more options each of which might want to be optimised, even if your router considers it worthwhile to only optimise one, the hosts will no longer be able to predict which option it is that you want to optimise (other routers may have picked another), so will no longer be able to assist, the option you're hoping will always come first may end up dumped in any old position, ruining your optimisation attempts. Again, without requiring network-wide changes. This is the principal advantage of keepig options in the packet format - they certainly do allow changes without massive uphevals. That's why its probably worth the effort to design the packet format to cope well with options when they are present, give every assistance to the router so it can optimise predictably - that almost certainly means making it very easy for the router to tell whether some particular option is present or not, and even more importantly whether there are any options that need processing by routers at all, as opposed for those intended only for the destination host. That's going to impose requirements on the hosts, not just suggestions for how they might want to behave. kre From owner-Big-Internet@munnari.oz.au Sun Nov 15 08:41:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB14884; Sun, 15 Nov 1992 08:42:12 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211142142.14884@munnari.oz.au> Received: from sirius.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14877; Sun, 15 Nov 1992 08:41:41 +1100 (from ULLMANN@PROCESS.COM) Date: Sat, 14 Nov 1992 16:41 -0500 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: re kre on re Flows One more small point: you speak of "ruining all your optimization attempts" :-) It isn't that drastic: an optimization is probabilistic; if it is worth checking for the special case before doing the general case, you do it. And the probabilities do change, sometime eve in real time. (I wrote an IP in which whether the IP checksum was done at the usual point, or delayed until it could be done on the fly in the controller transmitting the datagram, could be decided dynamically on CPU idle; likewise on receive, where controller CPU bandwidth was the bottleneck, it would check it (and set a valid flag) if the MAC->DMA queue was near empty else leave it for the main CPU. The tradeoff was main proc CPU vs datagram latency, the main CPU was 10-20x the speed of the controller chip.) A router could easily apply a code sequence that was based on observed samples from that particular interface. Open your teleconference, routers in the path change optimization patterns. Is that worth it? I think the router engineers can figure that out, as long as they are allowed to make independent decisions, not constrained by a pre-"optimized" packet design. The history or network design is littered with pre-planned "optimizations" that ended up useless, or actually in the way. Best Regards, Robert From owner-big-internet@munnari.oz.au Wed Nov 25 01:10:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14582; Wed, 25 Nov 1992 01:10:18 +1100 (from owner-big-internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08849; Tue, 24 Nov 1992 22:18:14 +1100 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA18504 (5.65b/CWI-2.189); Tue, 24 Nov 1992 12:17:40 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA01282; Tue, 24 Nov 92 12:17:46 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA14128; Tue, 24 Nov 92 12:17:20 +0100 Message-Id: <9211241117.AA14128@dxcern.cern.ch> Subject: Re: ideas from AppleTalk (fwd) To: big-internet@munnari.oz.au Date: Tue, 24 Nov 92 12:17:19 MET From: Brian Carpenter CERN-CN Cc: Mike Gerard X-Mailer: ELM [version 2.3 PL11 CERN 11] This is from somebody who has suffered Appletalk for some time -- Brian >--------- Text sent by "J. Michael (Mike) Gerard, CERN-CN/CS" follows: From jmg@dxcoms.cern.ch Tue Nov 24 12:11:48 1992 X-Delivered: at request of brian on dxcern.cern.ch Message-Id: <9211241111.AA11076@dxcoms.cern.ch> Subject: Re: ideas from AppleTalk (fwd) To: Brian Carpenter CERN-CN Date: Tue, 24 Nov 92 12:11:42 GMT-1:00 From: "J. Michael (Mike) Gerard, CERN-CN/CS" In-Reply-To: <9211240949.AA28326@dxcern.cern.ch>; from "Brian Carpenter CERN-CN" at Nov 24, 92 10:49 am #Return-Receipt-To: jmg@dxcs01.cern.ch X-Mailer: ELM [version 2.3 PL11 CERN 11] All comments refer to a situation with a large bridged Ethernet plus lots (~200) routers to other AppleTalk networks (either LocalTalk via FastPath/GatorBox or virtual networks a la Novell/VMS) Currently there is only one zone name on Ethernet: this will change. > > Since I have referred to protocol ideas from AppleTalk a few times on this > > list, I have gotten a couple of private messages asking me to list some. The > > following three are the ones that occur to me immediately. I'll simplify them > > a bit for this presentation. I think they were new ideas with AppleTalk > > although I'm sure some of them have been adopted by other protocol suites. > > > > (1) Dynamic host address determination. When a machine first comes up on a > > network, it picks an ID and tests to see that there is no other machine up on > > its local network with the same ID. If not, it uses that ID. If there is > > another machine with the same ID, then it tries a different one. (It also > > remembers this in non-volatile memory so that it will try the same ID first > > when it comes up again.) This host ID (called the AppleTalk node ID) is 8 bits > > and gets combined with a 16 bit network number learned from a router to form a > > full 24 bit AppleTalk node address. The idea is good, though incomplete. One problem with EtherTalk is that when new nodes come up, including getting their own ID, getting the network information and so on, all other nodes on the same network have to locate the new node. They often do this by AppleTalk ARP (AARP) broadcasts: the result is a burst of broadcasts aimed at the new node. This overwhelms the new node (especially if it has a cheap and nasty ethernet card with no buffering), which only answers a few: the rest have to repeat their AARP pretty soon afterwards. Since the new node tends to repeat its request several times the result is LOTSA broadcasts! Now, if Apple had thought out their protocols and software correctly the responders would not have to broadcast in order to find the new source, but would simply use the information in the received broadcast. The next objection is that it can happen that parts of a network are temporarily unaccessible when the new node comes up, so it can get a duplicate node ID (we see this quite a lot). It can also happen that badly-behaved software fails to object to someone even if there is an ID conflict. Thus, in real life you get situations where there ARE duplicate node IDs. I have pleaded for a long time with providers of AppleTalk software to check for clashes (they may well be able to detect a clash by looking at incoming multicasts, or they could repeat the ID test either at intervals or when there is obviously a problem) but as far as I know no-one does. That is why we have a utility program to warn us if clashes are seen! > > (2) Zones. A zone is a named subset of an AppleTalk network. Each host is in > > a zone. While zones frequently refer to geographic or topological parts of a > > network, the cute thing is that they need not have any relationship to the > > network structure. When you bring up a scrolling list of resources, such a > > printers, to pick between, you normally select which zone you are interested in > > and just get a list for that zone. Unfortunately, it's not clear to me that > > these non-topological zones scale to a hugh Internet. If, like us, you have a lot of services on a particular zone (which happens when lots of people having a System-7 Mac on Ethernet decide to act like an AFP server) then the multicast traffic when an Ethernet Mac uses the chooser to find Ethernet AFP servers is HORRENDOUS (the explanation is much as under point 1, but normally via multicasts). Scaling to Internet size is indeed a problem. I believe that Apple is already looking at scaling AppleTalk across TCP/IP, including hierarchical zones: I hope they do a better job than with AppleTalk phase 2. > > (3) Distributed services directory. The AppleTalk name binding protocol > > enables each host to provide the part of the diretory that relates to the > > services it offers. When seeking services a broadcast message is sent out to > > the hosts of interest which can use various wildcarding looking for matches on > > service type, sevice name, and zone, all of which are character strings. Each > > host with any services for which information was requested replies. Same remarks on multicast storms! It all looks great for the user and is a nightmare for the managers of network bandwidth. The one saving grace for AppleTalk protocols is that they very often use multicasts instead of broadcasts, which presumably means that intelligent non-appletalk systems can quickly decide to ignore the multicasts. I have never found out whether Macs can specify "mask and test" methods for whether to treat or ignore multicasts. However, remember that AppleTalk ARPs are BROADCASTS! Just for the amusement, the following is a true story. Some AppleTalk equipment that we have sometimes decides to ask every second for a list of all equipment of any kind on its own zone. Since it is an end node it asks whatever router it can see: the router then forwards the request to all Ethernet AppleTalk routers, requesting them to reply directly to the original end-node requester. In order for them to reply (to network 17 node 103 say) they may have to multicast to locate this end-node. After that the end-node will be getting a burst of answers and will again be overwhelmed: even if not then the constant burst of packets to the same destination is unwelcome. Our classic action if a system is creating havoc is to block its address in our FDDI bridges. In this case such action is a disaster: the end-node still sees all of the routers (via their multicasts), but clearly can only talk to local ones. The local ones can forward the multicast request but most of the Ethernet AppleTalk routers cannot then establish contact with the end node, despite trying very hard (more multicasts). This is one reason why I don't like protocols which lead to triangular routing! What I finish up by saying is that the ideas are nice, but if the implementation is not done carefully and with scaleability in mind then the result can be a disaster. _ _ o | __ | jmg@cernvax.cern.ch | | | | _ / \ _ __ _ __ _| gerard@cernvm.cern.ch | | | | |_) /_) | __/_) | (___\ | (_/ | J. M. Gerard, Div. CN, CERN, | | |_|_| \_/\___ \__/ \___| (_|_| \_|_ 1211 Geneva 23, Switzerland From owner-big-internet@munnari.oz.au Wed Nov 25 13:38:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10673; Wed, 25 Nov 1992 13:38:26 +1100 (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 AA05153; Wed, 25 Nov 1992 11:06:53 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA06410; Tue, 24 Nov 92 19:06:27 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA03062; Tue, 24 Nov 92 16:03:08 PST Message-Id: <9211250003.AA03062@aland.bbn.com> To: big-internet@munnari.oz.au Subject: one person's view about recent IETF and IPv7 Reply-To: Craig Partridge From: Craig Partridge Date: Tue, 24 Nov 92 16:03:08 -0800 Sender: craig@aland.bbn.com Hi: I got a couple of phone calls from people asking what decision had been made about IPv7 at last week's IETF. I've seen no official postings, so I'll offer up my personal perspective, and the hopes that perhaps this may winkle out a more official version. We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. Paul started the PIP talk with an announcement that the PIP spec wouldn't be ready for another year, at which point a large number of folks walked out for more coffee. I listened carefully to the SIP and TUBA talks and came away feeling that both protocols were ready to be implemented and tested, but that I wished the TUBA talk had been more like the SIP talk and oriented towards the bits. However, the overwhelming conclusion was that while we might choose to eliminate PIP from the running on the basis it is so far behind the others, there's no rational way to choose between SIP and TUBA except to implement both and play with them. And even then, I think we'll find we're comparing apples and oranges and thus will need to let users decide what fruit they prefer. Indeed, one of the problems seems to be that there are different visions of what users want. So we'll have to probably support both proposals in the Internet and see which one dominates (if either). Regarding IPv7 criteria, the sense of the criteria BOF was that we need to add some items to the list and then tighten it up (make the criteria less conceptual and more real) to give better guidance to the various protocols about what they need to achieve and to help readers better understand the limitations of each. I will say that one stunning result out of the discussion was what criteria were deemed essential and which ones folks were willing to leave out if necessary (extensibility was a casualty). Craig From owner-Big-Internet@munnari.oz.au Wed Nov 25 16:35:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17315; Wed, 25 Nov 1992 16:35:32 +1100 (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 AA17306; Wed, 25 Nov 1992 16:35:16 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA16183; Tue, 24 Nov 92 21:33:38 -0800 To: Craig Partridge Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Tue, 24 Nov 1992 16:03:08 PST." <9211250003.AA03062@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Nov 1992 21:33:35 -0800 Message-Id: <16181.722669615@dbc.mtview.ca.us> From: Marshall Rose > I got a couple of phone calls from people asking what decision had > been made about IPv7 at last week's IETF. I've seen no official postings, > so I'll offer up my personal perspective, and the hopes that perhaps this > may winkle out a more official version. Here's another perspective: A long time ago, in a community, far, far away... there was a particular technical problem to be solved, and there were three competitors. One was a research project, one was based on work done by a well-known standards organization, and one started with the letter 'S'. As the time drew near for technical evaluation and selection, the first technology was withdrawn on the basis of not being far enough along. Then, something real bad happened: rather than soberly evaluating the technical merits of the two, other kinds of criteria were evaluated. Talk of "compatibility between protocol suites" was bandied about, vendor product "directions" were taken seriously, etc. A disturbing lack of intellectual honesty was exhibited. The result was a modus vivendi, in which two co-standards were declared. The problem, of course, is that in the end, there can only be one. At some points in the stack it makes sense to have choice. At other points in the stack, it is lunacy. This leaves us with two questions: 1. Are we talking about HEMS/CMOT/SNMP or are we talking about PIP/TUBA/SIP? 2. If the latter, are we going to learn any lessons from the former? /mtr From owner-Big-Internet@munnari.oz.au Thu Nov 26 00:30:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04266; Thu, 26 Nov 1992 00:31:11 +1100 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04247; Thu, 26 Nov 1992 00:30:59 +1100 (from dave@sabre.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA13051; Wed, 25 Nov 92 07:51:41 -0500 Date: Wed, 25 Nov 92 07:51:41 -0500 Message-Id: <9211251251.AA13051@worldlink.worldlink.com> From: David M. Piscitello To: big-internet@munnari.oz.au Subject: FYI: one person's view about recent IETF and IPv7 Craig writes: However, the overwhelming conclusion was that while we might choose to eliminate PIP from the running on the basis it is so far behind the others, there's no rational way to choose between SIP and TUBA except to implement both and play with them. And even then, I think we'll find we're comparing apples and oranges and thus will need to let users decide what fruit they prefer. Indeed, one of the problems seems to be that there are different visions of what users want. So we'll have to probably support both proposals in the Internet and see which one dominates (if either). I believe you are absolutely correct in this case, Craig. A one-time bake-off is unlikely to demonstrate much in the way of a clear winner, nor is it likely to thwart the efforts of the runner-up (you can only be a loser if you give up, and I don't see this happening at all). I think it's important to get a general and generous feel for what users want, and the more field experience we have, the better the read will be. I've complained frequently that we are coming at this problem largely from an engineering perspective, and that it will be nearly impossible to factor in the wants and wishes of network operators/administrators/users without a meaningful deployment period. From owner-Big-Internet@munnari.oz.au Thu Nov 26 01:09:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05543; Thu, 26 Nov 1992 01:09:50 +1100 (from owner-Big-Internet) Return-Path: Received: from boa-f.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05539; Thu, 26 Nov 1992 01:09:45 +1100 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA13962; Wed, 25 Nov 1992 09:09:15 -0500 Message-Id: <9211251409.AA13962@boa.gsfc.nasa.gov> Subject: Re: one person's view about recent IETF and IPv7 To: mrose@dbc.mtview.ca.us Date: Wed, 25 Nov 92 9:09:15 EST From: Dick desJardins Cc: big-internet@munnari.oz.au X-Mailer: ELM [version 2.3 PL11] "...disturbing lack of intellectual honesty ..." Hmmm. Does this mean that everyone who supports TUBA is intellectually dishonest? How about people who think that such features as unique endpoint IDs independent of address, autoconfiguration, ease of reassigning addresses due to change of provider or topology are good things not to be given up for 20 years? How about people who think that we don't know a lot about how many addresses are *really* out there lurking in your smart cars and smart homes, that ATM changes the equation in ways that "we'll just run SIP over ATM, trust me" doesn't convincingly cover, and that we don't know how to do type of service routing, not to mention security and cost accounting. Maybe SIP is ready, maybe it's not. Are all the people who are skeptical about this and the other legitimate issues really just to be dismissed as "intellectually dishonest"? I prefer the "gentler" side of Internet discussions: debate on the issues, open decisions openly arrived at, and the new (?) POISED spirit enunciated by that senior statesman of the Internet, Marshall Rose: "It is time to return to that true sense of community". To support the intent (perhaps) of your words, Marshall, let the TUBA people and the SIP people both admit the truth, "warts and all", of their proposals. Here are some warts of CLNP: (1) The implementations are not at all fast, for the most part: Although there are some that run at warp speeds, there are others that run at turtle speeds. My guess is that there is a CLNPv2 out there some day that combines the best features of OSI ES-IS and multiprotocol IS-IS with the high speed potential of SIP, ATM, and gigabit transport. (2) There is not a lot of operational CLNP traffic today, although more and more networks are beginning to support it. This means that there is not a lot of operational experience with large scale use of CLNP, ES-IS, and IS-IS. The proponents of SIP should also admit their warts in the spirit of "intellectual honesty". We don't need to tar each other with these name-calling brushes to arrive at the best community decision. Dick desJardins PS I don't mean to start having a SIP vs TUBA debate centered around you (Marshall) versus me. I just want to support the process--intellectually honest, I believe--that is now ongoing. I believe that you also support the process and the community of people that is the Internet. And in regard to allowing both proposals to proceed, which was the thrust of Craig's interpre- tation of the IETF and IPv7 events, note that it may be ugly, but TUBA and SIP hosts will be able to talk to each other just fine because TUBA hosts are dual-stacked. Ugly, maybe, like a lot of working internets today, but not dishonest. dishonest. From owner-Big-Internet@munnari.oz.au Thu Nov 26 01:40:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06320; Thu, 26 Nov 1992 01:40:23 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211251440.6320@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06308; Thu, 26 Nov 1992 01:40:17 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7311; Wed, 25 Nov 92 09:40:14 EST Date: Wed, 25 Nov 92 09:39:39 EST From: yakov@watson.ibm.com To: mrose@dbc.mtview.ca.us Cc: big-internet@munnari.oz.au Subject: one person's view > >The problem, of course, is that in the end, there can only be one. At >some points in the stack it makes sense to have choice. At other points >in the stack, it is lunacy. > >This leaves us with two questions: > > 1. Are we talking about HEMS/CMOT/SNMP or are we talking about > PIP/TUBA/SIP? > > 2. If the latter, are we going to learn any lessons from the former? > Marshall, One lesson that one may learn from the former is that the market is quite capable of making the choice. So, why wouldn't engineers work on making their favorite proposal(s) as attractive as possible, and let the market to have the final decision ? Yakov Rekhter From owner-Big-Internet@munnari.oz.au Thu Nov 26 01:42:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06367; Thu, 26 Nov 1992 01:42:53 +1100 (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 AA06364; Thu, 26 Nov 1992 01:42:44 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA18852; Wed, 25 Nov 92 06:41:17 -0800 To: Dick desJardins Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Wed, 25 Nov 1992 09:09:15 EST." <9211251409.AA13962@boa.gsfc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 06:41:15 -0800 Message-Id: <18848.722702475@dbc.mtview.ca.us> From: Marshall Rose Dick - I know you OSI guys are hyper-sensitive when reminded of your past sins, but you really ought to try reading my note carefully instead of jumping to conclusions. The particular section you object to was regarding the use of evaluation criteria, not the merits of any one proposal. I congratulate you for speaking plainly, though I might suggest that you remind your colleagues that talk about "TUBA-compliant devices already in the field" is amusing at best. My concern is that we end up with one thing and that it be the right thing based on objective technical criteria. Go re-read my note. /mtr From owner-Big-Internet@munnari.oz.au Thu Nov 26 01:46:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06521; Thu, 26 Nov 1992 01:46:19 +1100 (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 AA06506; Thu, 26 Nov 1992 01:46:09 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA19225; Wed, 25 Nov 92 06:44:41 -0800 To: yakov@watson.ibm.com Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view In-Reply-To: Your message of "Wed, 25 Nov 1992 09:39:39 EST." <9211251439.AA18825@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 06:44:36 -0800 Message-Id: <19219.722702676@dbc.mtview.ca.us> From: Marshall Rose > One lesson that one may learn from the former > is that the market is quite capable of making the choice. > > So, why wouldn't engineers work on making their favorite proposal(s) > as attractive as possible, and let the market to have the final > decision ? A long time ago, in a(nother) community far, far away... two network layer protocols were standardized. Although either could probably be made to work well, the two did not really interwork together. Part of the market favored one, part of the market favored the other. Interworking sufferred and the entire protocol suite became a laughing stock as another protocol suite, which had one way of doing it ate the former's breakfast, lunch, dinner, and midnight snack. Moral of the parable: sometimes it makes sense to have choice, sometimes there can be only one. In this situation, there can be only one. /mtr From owner-Big-Internet@munnari.oz.au Thu Nov 26 01:48:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06567; Thu, 26 Nov 1992 01:48:49 +1100 (from owner-Big-Internet) Return-Path: Received: from cise.cise.nsf.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06563; Thu, 26 Nov 1992 01:48:42 +1100 (from steve@cise.cise.nsf.gov) Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id ; Wed, 25 Nov 92 09:48:15 -0500 Received: by ncri (5.57/Spike-2.0) id AA27251; Wed, 25 Nov 92 09:48:13 -0500 Message-Id: <9211251448.AA27251@ncri> To: big-internet@munnari.oz.au Subject: Another person's view about recent IETF and IPv7 Date: Wed, 25 Nov 92 09:48:08 EST From: Stephen Wolff I found the discussions of criteria for selecting IPv7 at last Friday's IAB meeting and in the halls and corridors both before and after, a little strange on two counts. On the one hand I observed that (except for Matt Mathis who made sane remarks) among the primary discussants was nobody who actually has to **run** a network of any size. The lofty abstraction thereby attained has no doubt a good deal to recommend it; still... Secondly. Remember how it seemed forever to get to 5000 nets? What is it today, only seven months later? Seventy-six hundred and WHAT? Listening on Friday morning to talk of decision processes, I had a very distinct mental image of a lovely croquet pitch being laid out. Beautifully manicured deep green lawn. All the little hoops artfully and symmetrically arranged. And another image of it after we try getting that Internet stampede to go through the hoops. Vint and Marshall are right - the interoperable part of the Internet can have only one network level protocol - but they're right only tautologously by definition of "interoperable", and they're only referring to the leading K bits of the packet for some value of K. Strip them away and no end of absurdities, abominations and artful dodges stand revealed. Everything is after all tunneled in everything else; I bet there are sizable internets out there, each with its own network layer protocol, within which our beloved IP is casually tunneled - along with a lot of other stuff. Yes, I know there's more to a protocol than just the header bits, but as long as no two differing protocols can have identical headers, it is after all just SMOP; we're **not** talking relativistic cosmology here. And I hear respected programmers discussing SIP/TUBA-indifferent routers and giving estimates of a weekend to six months, which means someone ought to start pretty soon, right? Seems to me the choice of IPv7 is too important to be made in the abstract; I agree with Craig Partridge that both (all?) need to be coded up, deployed, and tried out on the whole gonzo Internet. Here at NSFNET Hq (!) we've had at least one unfortunate experience with technology that survived rigorous testing in the lab, that thrived and prospered on a reasonably extensive test network, and that fell over big time when fully deployed. All IPv7s that want to play should advance to Standard status, and both the IESG and the IAB should help. But again I think Craig's right: neither can assume the cachet to choose. -s From owner-Big-Internet@munnari.oz.au Thu Nov 26 02:21:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07481; Thu, 26 Nov 1992 02:22:03 +1100 (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 AA07478; Thu, 26 Nov 1992 02:21:54 +1100 (from kasten@ftp.com) Received: by ftp.com id AA26345; Wed, 25 Nov 92 10:21:39 -0500 Date: Wed, 25 Nov 92 10:21:39 -0500 Message-Id: <9211251521.AA26345@ftp.com> To: Craig Partridge Subject: Re: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au Craig, Some view on your views :-) First, in the open IAB meeting, a strong opinion was expressed that one of the strengths of the Internet is its global IP connectivity and that a "Single Internet Protocol" is essential to the continuing success of the net -- in other words, the main mission of the net is to provide ubiquitous IP-level service to everyone, not to provide datalinks over which you can run any protocol you want (this is not in conflict with the Multi-Protocol Internet -- I view this as saying that IP is required and other protocols (e.g. CLNP) are allowed). Note that this is MY INTERPRETATION so flame ME not the IAB :-) I also agree with this interpretation. Also, there is concern voiced by some prominent members of the community that we really ought not change the IP packet format at this time -- that we should invest more engineering effort into keeping IPv4 running as long as is possible via any means possible (CIDR, NIMROD). This allows us to 1) more fully develop SIP and PIP, and 2) more fully develop the newer technologies that we want in IPv7 (e.g. flows and policy). Again, I am beginning to think that this is a good approach. > Regarding IPv7 criteria, the sense of the criteria BOF was that we > need to add some items to the list and then tighten it up (make the criteria > less conceptual and more real) to give better guidance to the various protocols > about what they need to achieve and to help readers better understand the > limitations of each. I will say that one stunning result out of the > discussion was what criteria were deemed essential and which ones folks > were willing to leave out if necessary (extensibility was a casualty). yet 20-year life was not :-) I am working on revising the document per the discussion at the BOF. Due to the American holiday schedule I do not think that I will be able to finish it until monday, then Craig and I will go around on it a few times. I imagine that a draft might appear in about a week. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Thu Nov 26 02:24:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07529; Thu, 26 Nov 1992 02:24:12 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211251524.7529@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07525; Thu, 26 Nov 1992 02:24:05 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7857; Wed, 25 Nov 92 10:24:04 EST Date: Wed, 25 Nov 92 10:21:54 EST From: yakov@watson.ibm.com To: dave@sabre.bellcore.com, big-internet@munnari.oz.au Subject: FYI: one person's view about recent IETF and IPv7 Ref: Your note of Wed, 25 Nov 92 07:51:41 -0500 Here is a piece from CommunicationsWeek 11/23/92: "Three of the five proposals aimed at eliminating the Internet addressing problem were selected for implementation. Prototype implementations will be presented for final selection at the society's March meeting." Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Thu Nov 26 02:31:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07709; Thu, 26 Nov 1992 02:32:06 +1100 (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 AA07703; Thu, 26 Nov 1992 02:31:54 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA19657; Wed, 25 Nov 92 07:30:29 -0800 To: yakov@watson.ibm.com Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view In-Reply-To: Your message of "Wed, 25 Nov 1992 10:07:54 EST." <9211251507.AA19460@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 07:30:27 -0800 Message-Id: <19649.722705427@dbc.mtview.ca.us> From: Marshall Rose So, are you suggesting we add a new criterion: Any candidate must interwork with both IPv4 and all other candidates /mtr From owner-big-internet@munnari.oz.au Thu Nov 26 02:50:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08119; Thu, 26 Nov 1992 02:50:33 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211251550.8119@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07241; Thu, 26 Nov 1992 02:09:06 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7655; Wed, 25 Nov 92 10:09:01 EST Date: Wed, 25 Nov 92 10:07:54 EST From: yakov@watson.ibm.com To: big-internet@munnari.oz.au Cc: mrose@dbc.mtview.ca.us Subject: one person's view Ref: Your note of Wed, 25 Nov 1992 06:44:36 -0800 >Although either could probably be made to work well, the two >did not really internetwork together... Marshall, That need not be the case for the various IPv7 proposals. There is already a requirement that hosts supporting IPv7 should be able to communicate with the hosts running IPv4. Just stretch this a bit... With respect to at least two of the candidates for IPv7 I see no inherent problems why hosts supporting these proposals would not be able to communicate with each other via some simple network layer protocol converters - SNLPC (note it starts with letter "S" :-) ). >Moral of the parable: sometimes it makes sense to have choice, >sometimes there can be only one. To clarify: sometimes it makes sense to specify choices in such a way that they would interwork together, sometimes there can be only one (if choices don't interwork together). So, before deciding whether you need to converge on a single choice, or whether you would allow multiple choices check whether the multiple choices can interwork together. Yakov Rekhter From owner-Big-Internet@munnari.oz.au Thu Nov 26 03:28:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08841; Thu, 26 Nov 1992 03:28:21 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211251628.8841@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08824; Thu, 26 Nov 1992 03:28:05 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8707; Wed, 25 Nov 92 11:27:53 EST Date: Wed, 25 Nov 92 11:27:01 EST From: yakov@watson.ibm.com To: big-internet@munnari.oz.au Cc: mrose@dbc.mtview.ca.us Subject: one person's view Ref: Your note of Wed, 25 Nov 1992 08:18:08 -0800 >If you are willing to guaratee that TUBA and SIP will interwork >as well as either will interwork with IPv4 then I do not believe >we are arguing. Marshall, The issue is not of me being willing to provide any guarantees. We need to make sure that the criterion should explicitly spell out the interworking, and then engineers would put their efforts on making this happen. Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Thu Nov 26 04:26:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09768; Thu, 26 Nov 1992 04:27:14 +1100 (from owner-Big-Internet) Return-Path: Received: from boa-f.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09764; Thu, 26 Nov 1992 04:26:54 +1100 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.65/DEC-Ultrix/4.3) id AA14918; Wed, 25 Nov 1992 12:26:45 -0500 Message-Id: <9211251726.AA14918@boa.gsfc.nasa.gov> Subject: Re: one person's view about recent IETF and IPv7 To: big-internet@munnari.oz.au Date: Wed, 25 Nov 92 12:26:45 EST From: Dick desJardins In-Reply-To: <18848.722702475@dbc.mtview.ca.us>; from "Marshall Rose" at Nov 25, 92 6:41 am X-Mailer: ELM [version 2.3 PL11] > > Dick - I know you OSI guys are hyper-sensitive when reminded of your > past sins, It just seems that way because we've got more sins. The corollary effect is also operating: people (not you, of course!) look at "anything OSI" as sinful. I do truly vote for intellectual honesty with you, and my intellectual honesty compels me to defend parts of OSI as wholesome and good for you. but you really ought to try reading my note carefully instead > of jumping to conclusions. The particular section you object to was > regarding the use of evaluation criteria, not the merits of any one > proposal. > I re-read your note, and right you are! On the other hand, the thrust of my comments applies to evaluation criteria as well, that people can disagree about evaluation criteria without being tarred as intellectually dishonest. I attended the criteria session, and I didn't hear criteria such as "compatibility between protocol suites" (except backward compatibility with IP) or "vendor product directions". Those things may have been merely side comments, or may have come up at the end, however (I had to leave early). I don't believe they are in the final list of agreed criteria. > I congratulate you for speaking plainly, though I might suggest that you > remind your colleagues that talk about "TUBA-compliant devices already > in the field" is amusing at best. Actually, that part is honestly true. There is not a lot of operational CLNP, that is true, but there is a lot of deployed CLNP all over the Internet, waiting for traffic. The brouhaha about CLNP not being deployed in the T3 backbone is a red herring, as has been pointed out. > My concern is that we end up with one thing and that it be the right > thing based on objective technical criteria. There is some honest disagreement about the "one thing" part, which I think Craig expressed perfectly in his note. We all want to get there, but we all don't agree where "there" is. So we may have to go down more than one road (good pun, Dick :-) In the interim, everyone can interoperate with IPv4. There is some combination of SIP, ATM, CLNP ease of use, type of service routing, and security out there in all of our futures, I'm honestly sure of that. But I'll bet you another $1000 steak dinner that it will have globally unique endpoint identifiers! Your fellow Community member, Dick dJ (as in "you can choose your friends but you can't choose your family or Internet community members, they choose you" :-) From owner-Big-Internet@munnari.oz.au Thu Nov 26 05:41:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11131; Thu, 26 Nov 1992 05:41:37 +1100 (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 AA11121; Thu, 26 Nov 1992 05:41:21 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA10094; Wed, 25 Nov 92 13:40:58 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA16618; Wed, 25 Nov 92 10:39:29 PST Message-Id: <9211251839.AA16618@aland.bbn.com> To: mrose@dbc.mtview.ca.us, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 09:09:15 -0500. <9211251409.AA13962@boa.gsfc.nasa.gov> From: Craig Partridge Date: Wed, 25 Nov 92 10:39:27 -0800 Sender: craig@aland.bbn.com Marshall: I enjoyed the parable with the network management process and having lived in the network management fairy tale found it distressing. I also FIRMLY agree that we want one internetworking protocol. But I fear we're fast approaching the limit of sorting out that the IAB/IESG can do without some real market experience. If we are to go through the "let the market decide" process again, I hope we can make it somewhat less messy than the HEMS/SGMP/CMOT process. CMOT lingered on for a very long time, consuming resources it need not have. SGMP had to become SNMP and now SMP \- while folks at the criteria meeting expressed a willingness to transition between internet protocols more than once it would be nice to avoid that experience and I think in this case, unlike the network management case, we have enough field experience in internetworking that we shouldn't need to tinker multiple times. (Why do I think those words may come back to haunt me?). Craig From owner-big-internet@munnari.oz.au Thu Nov 26 06:35:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12441; Thu, 26 Nov 1992 06:36:01 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211251936.12441@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08396; Thu, 26 Nov 1992 03:06:51 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8401; Wed, 25 Nov 92 11:05:02 EST Date: Wed, 25 Nov 92 11:04:31 EST From: yakov@watson.ibm.com To: big-internet@munnari.oz.au Cc: mrose@dbc.mtview.ca.us Subject: one person's view Ref: Your note of Wed, 25 Nov 1992 07:30:27 -0800 >So, are you suggesting we add a new criterion: > Any candidate must interwork with both IPv4 and all other > candidates. Marshall, The way how you phrase the criterion, it has two parts: (a) interoperability between IPv4 and IPv7 hosts (b) interoperability between different IPv7 hosts Let's look at each part separately. (1) May I assume that you wouldn't argue about the need for the IPv7 hosts to be able to interoperate with IPv4 hosts ? (2) Now for the second part. Given the number of potential candidates we have today, what would you see as potential problems with requiring these candidates to be able to interoperate with each other ? It would help if you'll answer both questions. Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Thu Nov 26 06:46:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12732; Thu, 26 Nov 1992 06:46:55 +1100 (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 AA12727; Thu, 26 Nov 1992 06:46:46 +1100 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27664 (5.65c/IDA-1.4.4nsd for ); Wed, 25 Nov 1992 11:46:30 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA11820 (5.65c/IDA-1.4.4-910725 for ); Wed, 25 Nov 1992 11:46:28 -0800 Message-Id: <199211251946.AA11820@remmel.NSD.3Com.COM> To: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Tue, 24 Nov 92 21:33:35 PST." <16181.722669615@dbc.mtview.ca.us> Date: Wed, 25 Nov 92 11:46:27 -0800 From: tracym@NSD.3Com.COM > A long time ago, in a community, far, far away... > > The problem, of course, is that in the end, there can only be one. At > some points in the stack it makes sense to have choice. At other points > in the stack, it is lunacy. > Note that almost every SNMP user still has TWO stacks, the second proprietary, in order to implement control functions. > > 1. Are we talking about HEMS/CMOT/SNMP or are we talking about > PIP/TUBA/SIP? > > 2. If the latter, are we going to learn any lessons from the former? > In the former case, the community is already working hard on v2 to atone for the sins of v1. Has it been five years? What are the lessons learned. "A bird in the hand..." comes to mind. I think SNMP is fine for what it does do, but it already doesn't do enough, and I can't imagine that we've learned yet to make a decision that will satisfy all our needs for even 10 years, let alone 20. Flame-off. I've been thinking about translation for the last few days. I'd already concluded that both SIP and TUBA are going to be around for a while, and that since translating border routers are the key to all of the transition plans, why not make them a bit more capable. I strongly support Yakov's suggestion that interoperability simply be required. To the extent that we have a consistent global address space, this should be straightforward. Related topic: I suggested to a few people at the IETF that perhaps the TCP/UDP-over-X problem should be addressed more generally. If we have to touch every TCP in the world that wishes to maintain direct world-wide host-host connectivity, why not do it right instead of relying on a quick fix that MAY not last. I've had mixed responses, so far. Blue-sky: We could take the opportunity to implement other useful features. For instance, as a movement toward mobility solutions we might want to modify TCP implementations to allow for changing end-system addresses, perhaps by allowing multiple address/port combinations to refer to a single connection. Regards, Tracy From owner-big-internet@munnari.oz.au Thu Nov 26 06:48:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12777; Thu, 26 Nov 1992 06:48:47 +1100 (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 AA08707; Thu, 26 Nov 1992 03:19:40 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA20200; Wed, 25 Nov 92 08:18:10 -0800 To: yakov@watson.ibm.com Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view In-Reply-To: Your message of "Wed, 25 Nov 1992 11:04:31 EST." <9211251603.AA20043@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 08:18:08 -0800 Message-Id: <20196.722708288@dbc.mtview.ca.us> From: Marshall Rose If you are willing to guarantee that TUBA and SIP will interwork as well as either will interwork with IPv4 then I do not believe we are arguing. /mtr From owner-big-internet@munnari.oz.au Thu Nov 26 06:58:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13095; Thu, 26 Nov 1992 06:58:29 +1100 (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 AA08682; Thu, 26 Nov 1992 03:18:24 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA22912; Wed, 25 Nov 92 08:18:14 -0800 Message-Id: <9211251618.AA22912@Mordor.Stanford.EDU> To: David M. Piscitello Cc: big-internet@munnari.oz.au Subject: Re: FYI: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 25 Nov 92 07:51:41 -0500. <9211251251.AA13051@worldlink.worldlink.com> Date: Wed, 25 Nov 92 08:18:14 -0800 From: Dave Crocker X-Mts: smtp I, too, hope that we do not _only_ consider engineering issues. (I also hope we don't ignore them...) In particular, I am concerned that end-user representation has not been as strong as it should be. The IETF is well-represented by developers and transit-net providers, but my own guess is that the biggest impact of the IPv7 choice will be to end-users. Dave From owner-big-internet@munnari.oz.au Thu Nov 26 07:11:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13799; Thu, 26 Nov 1992 07:11:17 +1100 (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 AA08868; Thu, 26 Nov 1992 03:29:29 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA20449; Wed, 25 Nov 92 08:28:04 -0800 To: yakov@watson.ibm.com Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view In-Reply-To: Your message of "Wed, 25 Nov 1992 11:27:01 EST." <9211251626.AA20364@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 08:28:02 -0800 Message-Id: <20445.722708882@dbc.mtview.ca.us> From: Marshall Rose > The issue is not of me being willing to provide any guarantees. > We need to make sure that the criterion should explicitly spell out the > interworking, and then engineers would put their efforts on making > this happen. My point exactly. /mtr From owner-big-internet@munnari.oz.au Thu Nov 26 07:36:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14648; Thu, 26 Nov 1992 07:36:27 +1100 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08681; Thu, 26 Nov 1992 03:18:24 +1100 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 25 Nov 92 11:18:04 EST Received: by chiya.bellcore.com (4.1/4.7) id for craig@aland.bbn.com; Wed, 25 Nov 92 11:18:02 EST Date: Wed, 25 Nov 92 11:18:02 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9211251618.AA15100@chiya.bellcore.com> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: one person's view about recent IETF and IPv7 From Craig: C: C: We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. C: Paul started the PIP talk with an announcement that the PIP spec wouldn't C: be ready for another year, at which point a large number of folks walked No, I didn't say the Pip spec wouldn't be ready for another year, I said that it would be a year before anybody could really confidently choose Pip as the next generation IP. The Pip specs are already half done, and I expect pretty solid specs in 3 months. What I hope for in one year are prototypes and enough experience that we can make a real decision concerning Pip. C: However, the overwhelming conclusion was that while we might choose to C: eliminate PIP from the running on the basis it is so far behind the others, C: there's no rational way to choose between SIP and TUBA except to implement C: both and play with them. And even then, I think we'll find we're comparing Yes, exactly what I said about Pip in my talk. But, of course the same goes for TUBA and SIP. So, are we going to "eliminate" Pip because I chose to emphasize that Pip needs experimentation and the other speakers chose not to emphasize that their work needs experimentation? No, of course not. Should we "eliminate" Pip because it is "so far behind the others"? Well, if the others were ready to go *today*, and we were convinced that we can't wait any longer for a fix, then we should eliminate Pip. But I see no reason to declare a loser before we are prepared to declare a winner. From Dave Piscitello: P: I believe you are absolutely correct in this case, Craig. A one-time P: bake-off is unlikely to demonstrate much in the way of a clear P: winner, nor is it likely to thwart the efforts of the runner-up P: (you can only be a loser if you give up, and I don't see this P: happening at all). P: Yes. I don't plan to stop work on Pip just because one or more people declare that it is eliminated. What does it mean to eliminate it anyway? Does it mean that if, in 12 months, the community decides that neither TUBA nor SIP is acceptable (because for instance, they don't handle flow or policy adequately) that we do not reconsider Pip? Of course not. Perhaps "eliminating" Pip at this point just means that a lot of folks no longer have to burden themselves with reading Pip specs. This is fine. I don't expect most people to read Pip specs until I stand up and some point and quantitatively demonstrate Pip's capability and performance with real boxes. So, I'll continue to work on Pip, and we'll see how the other proposals come along in the coming months..... From Marshall: M: M: This leaves us with two questions: M: M: 1. Are we talking about HEMS/CMOT/SNMP or are we talking about M: PIP/TUBA/SIP? M: M: 2. If the latter, are we going to learn any lessons from the former? If HEMS/CMOT/SNMP == PIP/TUBA/SIP, does HEMS/CMOT/SNMP/SMP == PIP/TUBA/SIP/IPv8 ???? PX From owner-Big-Internet@munnari.oz.au Thu Nov 26 08:48:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16714; Thu, 26 Nov 1992 08:49:10 +1100 (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 AA16703; Thu, 26 Nov 1992 08:48:56 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA24115; Wed, 25 Nov 92 13:47:20 -0800 To: Craig Partridge Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Wed, 25 Nov 1992 10:39:27 PST." <9211251839.AA16618@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 13:47:18 -0800 Message-Id: <24111.722728038@dbc.mtview.ca.us> From: Marshall Rose Craig - I am not arguing against implementation experience as an aid towards reaching a decision. Neither, I am not arguing against deploying both TUBA and SIP. What I am arguing against is co-standards. We have several examples as to why two standards are worse than one (1052, CO v. CL, etc.). I'm still waiting for someone to give me an example of a benefit. The Internet community has been well-served by a single network layer infrastructure. Although we might route other kinds of NLPs, the vast predominance of a single standard has greatly aided us in interworking. With the co-standard approach we will lose this. In other words, it is OK to branch, but at some point we must have a plan to converge. If we fail in this respect, then history teaches us that we will lose big. /mtr From owner-Big-Internet@munnari.oz.au Thu Nov 26 08:52:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16795; Thu, 26 Nov 1992 08:52:52 +1100 (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 AA16771; Thu, 26 Nov 1992 08:52:28 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA24146; Wed, 25 Nov 92 13:50:54 -0800 To: tracym@nsd.3com.com Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Wed, 25 Nov 1992 11:46:27 PST." <199211251946.AA11820@remmel.NSD.3Com.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 13:50:47 -0800 Message-Id: <24141.722728247@dbc.mtview.ca.us> From: Marshall Rose > Note that almost every SNMP user still has TWO stacks, the second > proprietary, in order to implement control functions. Gee, go tell that to any of the regionals which do remote management via SNMP. The point is that while you can not mandate the sole use of a particular technology, you can have a common standard which solves most problems for most people. If you are lucky, the standard achieves ubiquity (e.g., IP, SNMP). Of course, other things may still be used, but more as an enclave-solution. /mtr From owner-big-internet@munnari.oz.au Thu Nov 26 09:33:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18067; Thu, 26 Nov 1992 09:33:16 +1100 (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 AA16654; Thu, 26 Nov 1992 08:45:50 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA24082; Wed, 25 Nov 92 13:43:16 -0800 To: desjardi@boa.gsfc.nasa.gov (Dick desJardins) Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Wed, 25 Nov 1992 12:26:45 EST." <9211251726.AA14918@boa.gsfc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Nov 1992 13:43:15 -0800 Message-Id: <24079.722727795@dbc.mtview.ca.us> From: Marshall Rose First, I am glad to see that we agree that technical concerns should be the sole basis for evaluation. On another topic, let's clarify something: > > I congratulate you for speaking plainly, though I might suggest that you > > remind your colleagues that talk about "TUBA-compliant devices already > > in the field" is amusing at best. > > Actually, that part is honestly true. There is not a lot of operational > CLNP, that is true, but there is a lot of deployed CLNP all over the > Internet, waiting for traffic. The brouhaha about CLNP not being > deployed in the T3 backbone is a red herring, as has been pointed out. CLNP is not TUBA. TUBA is more than CLNP. For example, I would expect a TUBA-compliant router to have an SNMP agent running over a TUBA stack. I would expect that TUBA is a lot more than "just CLNP". The problem is that in plenary the TUBA talk included the quoted statement above. That just isn't true. It is OK to say that there are CLNP devices deployed. It is not truthful to say that there are TUBA-compliant devices deployed. In regards to the "one thing" part, see my response to Craig which follows. /mtr From owner-big-internet@munnari.oz.au Thu Nov 26 09:55:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18722; Thu, 26 Nov 1992 09:57:20 +1100 (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 AA17062; Thu, 26 Nov 1992 09:01:27 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28962; Wed, 25 Nov 92 17:01:10 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11717; Wed, 25 Nov 92 13:59:41 PST Message-Id: <9211252159.AA11717@aland.bbn.com> To: Marshall Rose Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 13:47:18 -0800. <24111.722728038@dbc.mtview.ca.us> From: Craig Partridge Date: Wed, 25 Nov 92 13:59:39 -0800 Sender: craig@aland.bbn.com Marshall: I think we're in agreement. I certainly didn't mean to imply that you were arguing against implementation experience and I believe we only need one standard. Problem is, I know which protocol I believe is our best hope, and others equally fervently believe in the other protocol. One possible answer is to declare that no proposal gets to Proposed Standard status (or perhaps, no proposal gets past Proposed Standard status) until we've decided that it is the one Internet standard protocol and the other protocol is no longer under consideration. Craig From owner-Big-Internet@munnari.oz.au Thu Nov 26 13:38:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25566; Thu, 26 Nov 1992 13:38:55 +1100 (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 AA25552; Thu, 26 Nov 1992 13:38:42 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA00810; Wed, 25 Nov 92 18:38:14 -0800 Message-Id: <9211260238.AA00810@Mordor.Stanford.EDU> To: Craig Partridge Cc: Marshall Rose , big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 25 Nov 92 13:59:39 -0800. <9211252159.AA11717@aland.bbn.com> Date: Wed, 25 Nov 92 18:38:14 -0800 From: Dave Crocker X-Mts: smtp Craig, Feeling compelled to assert a purely legalistic truth: One possible answer is to declare that no proposal gets to Proposed Standard status (or perhaps, no proposal gets past Proposed Standard status until we've decided that it is the one Internet standard protocol and the other protocol is no longer under consideration. I will comment that your suggestion is entirely contrary to the formal rules for Internet standardization, as I understand them. Sigh. Dave From owner-Big-Internet@munnari.oz.au Thu Nov 26 13:43:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25771; Thu, 26 Nov 1992 13:44:03 +1100 (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 AA25724; Thu, 26 Nov 1992 13:43:36 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA00841; Wed, 25 Nov 92 18:43:27 -0800 Message-Id: <9211260243.AA00841@Mordor.Stanford.EDU> To: tracym@NSD.3Com.COM Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 25 Nov 92 11:46:27 -0800. <199211251946.AA11820@remmel.NSD.3Com.COM> Date: Wed, 25 Nov 92 18:43:27 -0800 From: Dave Crocker X-Mts: smtp Tracy & Yakov, Having just spent a long, difficult summer, specifically pursuing interoperability between IPv4 and a highly compatible replacement (IPAE and then IPAE/SIP), I must comment that requiring SIP/TUBA interoperability sounds great as a hand-wave but lousy otherwise. I do, however, encourage interested parties to pursue the academic exercise of specifying the details of such interoperability. I further encourage the community to require the completion of such a spec, prior to laying any further requirements on the IPv7 contendors. Dave From owner-big-internet@munnari.oz.au Thu Nov 26 15:01:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28457; Thu, 26 Nov 1992 15:01:40 +1100 (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 AA20902; Thu, 26 Nov 1992 11:08:06 +1100 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA16906; Wed, 25 Nov 92 15:57:59 PST Date: Wed, 25 Nov 92 15:57:59 PST From: Eric Fleischman Message-Id: <9211252357.AA16906@atc.boeing.com> To: big-internet@munnari.oz.au, dcrocker@Mordor.Stanford.EDU Subject: multiple IPv7s Cc: ericf@munnari.oz.au >> To: David M. Piscitello >> Cc: big-internet@munnari.oz.au >> From: Dave Crocker >> In particular, I am concerned that end-user representation has not been >> as strong as it should be. The IETF is well-represented by developers >> and transit-net providers, but my own guess is that the biggest impact >> of the IPv7 choice will be to end-users. >> Dave I was the final person to speak at the IETF Plenary on Thursday night. Based on the extremely negative reaction my suggestion received, I fear that it was poorly phrased. However, my point was directly relevant to Dave's comment. What I had intended to say was the following: 1) The resolution of IPv7 is fundamentally different from all recent IETF protocol activities because it potentially threatens the obsolence of a company's entire TCP/IP deployment (depending upon how IPv7 is actually specified). 2) For this reason, it is desirable to permit corporations to express a corporate position in this matter since their "bottom line" may be directly impacted by the decision. (Note: this isn't a desire for corporations to "vote" on the IPv7 decision, rather to simply permit the corporations to voice how they view the matter.) The context of this suggestion is the following: 1) I represent a "User Company" (i.e., we make airplanes, not computers nor data communications equipment). I was sent to the IETF due to significant corporate concerns about IPv7. I was sent to deliver a corporate position but found no forum to deliver it as anything other than a personal opinion. This position is fundamentally different from a personal opinion. 2) IETF members from "User Companies" are often very different from other IETF members because the concerns of user companies are frequently different from the concerns of vendors, service providers, or researchers. 3) At this latest IETF, I met three individuals who also come from user companies. Thus, I concluded (perhaps incorrectly) that there is only slight user company participation in the latest IETF meeting. 4) User companiess do *NOT* have a uniform position on all points. I find it entirely conceivable that different users will prefer different IPv7 options. However, it is very important to me to understand *WHY* a user company prefers a given option. Such differing results probably reflect different weightings of the IPv7 selection criteria, or perhaps even different requirements. At the very least it represents a different viewpoint of how a given option "plays" in different installed bases. I, for one, value such input. It would perhaps change our current IPv7 selection criteria and its weighting. 5) I desire to know the *corporate* positions of user companies to distinguish whether the position is a corporate (i.e., business) decision or whether it is a personal opinion of a vocal advocate. The two positions are very different from each other in authority. 6) User companies will not be able to express their opinions if there is no forum permitted for such expressions. While this may be desirable in the general case, I don't think that it is desirable in the framework of the IPv7 discussions. My personal fear is that the IETF will balkanize over IPv7. Let's remember that protocols also divide as well as join. I cherish the any-to-any communications offered by the current Internet. This is only possible because all of us support IPv4 and essentially all of us support UDP and TCP. Unless the IETF can select a single authoritative IPv7, the Internet will continue to have IPv4 be the required network layer protocol and all other options to be optional. While I like IPv4, I also desire to have the Internet remain healthy and viable into the indefinite future. I request that readers not flame me about this message in order to permit the wounds received at the IETF Plenary to have ample time to heal. Constructive comments, by contrast, are always welcome. Thank you for your attention. --Eric Fleischman The opinions expressed by this note are solely the personal opinions of the sender and are not an official position of The Boeing Company. From owner-Big-Internet@munnari.oz.au Thu Nov 26 19:41:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08830; Thu, 26 Nov 1992 19:41:49 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211260841.8830@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08827; Thu, 26 Nov 1992 19:41:43 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Nov 1992 08:41:34 +0000 To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Wed, 25 Nov 92 11:18:02 EST." <9211251618.AA15100@chiya.bellcore.com> Date: Thu, 26 Nov 92 08:41:30 +0000 From: Jon Crowcroft >C: We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. >C: Paul started the PIP talk with an announcement that the PIP spec wouldn't >C: be ready for another year, at which point a large number of folks walked let me support paul - i am surprised that the IETF reacted to his honesty by thinking PIP is less ready than other solutions we have prototype code...we have near to full specs - we are trying to do something a little more long term than the other solutions anyhow... i'm disappointed that the tone of early reaction should be so dismissive - remember ddc's dictum - consensus and working code - wait until you see the color of their semi-colons before you shoot for SIP or TUBA jon by the way, I dont entent to comment or condemn any of the above From owner-Big-Internet@munnari.oz.au Fri Nov 27 02:26:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22666; Fri, 27 Nov 1992 02:26:47 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22660; Fri, 27 Nov 1992 02:26:35 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA07743; Thu, 26 Nov 92 08:26:22 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA15430; Thu, 26 Nov 92 08:26:21 MST Message-Id: <9211261526.AA15430@goshawk.lanl.gov> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Tue, 24 Nov 92 16:03:08 -0800. <9211250003.AA03062@aland.bbn.com> Date: Thu, 26 Nov 92 08:26:21 MST From: peter@goshawk.lanl.gov Craig, Unfortunately, the TUBA talk did not have the time the SIP talk had to get into the bits since it had to cover more than the SIP talk did. However, you can get more information on the bits inside CLNP by reading the CLNP spec which is available for anonymous ftp from merit.edu:pub/iso. Also, Dave Piscitello's I-D on the use of CLNP for TUBA does an IP<-->CLNP mapping which many will find useful. I will schedule a talk at the next IETF on CLNP and CLNP addressing and routing plans. Many of you probably saw Carl Malamud's note on the ITU announcement of availability of CCITT documents.(Carl, thanks for your efforts in this area!) It should be noted that the CLNP spec (as well as IS-IS, ES-IS, and IDRP specs) will be covered under this agreement when they become CCITT documents, which is slated for mid-1993. In the meantime, the drafts of these documents will be available on merit.edu. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 02:45:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23496; Fri, 27 Nov 1992 02:45:33 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23491; Fri, 27 Nov 1992 02:45:23 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA07954; Thu, 26 Nov 92 08:45:09 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA15571; Thu, 26 Nov 92 08:45:08 MST Message-Id: <9211261545.AA15571@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: Eliminating PIP -- not. Date: Thu, 26 Nov 92 08:45:08 MST From: peter@goshawk.lanl.gov I am not very comfortable with the way people are talking about simply eliminating PIP. At the open IAB meeting I reminded people that there are three legitimate proposals, not two. It looks like this has to be brought up in this list as well. The PIP effort has identified certain problems that it is trying to solve. Given that 20 year design is part of the criteria, and if the problems that the PIP effort have identified are important in that timeframe, then we had better be more careful in deciding what is eliminated. It is also time for us to really determine the length of time we can run the current IP space using CIDR. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 03:06:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24309; Fri, 27 Nov 1992 03:06:24 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24301; Fri, 27 Nov 1992 03:06:16 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA08159; Thu, 26 Nov 92 09:06:05 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA15636; Thu, 26 Nov 92 09:06:04 MST Message-Id: <9211261606.AA15636@goshawk.lanl.gov> To: mrose@dbc.mtview.ca.us Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 06:41:15 -0800. <18848.722702475@dbc.mtview.ca.us> Date: Thu, 26 Nov 92 09:06:03 MST From: peter@goshawk.lanl.gov >>> I congratulate you for speaking plainly, though I might suggest that you >>> remind your colleagues that talk about "TUBA-compliant devices already >>> in the field" is amusing at best. Marshall, To be used in a TUBA environment a router needs to be able to route and forward CLNP. A majority of the routers used in the Internet can do so. Interoperability tests have been performed on operational networks. In my book this is preferable to paper designs and statements made in the absence of existence proofs. Do we agree on this? cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 03:53:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25675; Fri, 27 Nov 1992 03:53:29 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25669; Fri, 27 Nov 1992 03:53:11 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA08595; Thu, 26 Nov 92 09:52:53 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA15877; Thu, 26 Nov 92 09:52:52 MST Message-Id: <9211261652.AA15877@goshawk.lanl.gov> To: Craig Partridge Cc: mrose@dbc.mtview.ca.us, big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 10:39:27 -0800. <9211251839.AA16618@aland.bbn.com> Date: Thu, 26 Nov 92 09:52:52 MST From: peter@goshawk.lanl.gov May I suggest the reason that the HEMS/SGMP/CMOT was so messy was that people tried to interfere with the market? It also seems that the people who always talk about how messy it was are the people who were personally involved in this sort of interference. How many other people felt it was messy? How many other people were aware that it was ever an issue? cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 05:43:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28486; Fri, 27 Nov 1992 05:43:39 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211261843.28486@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28474; Fri, 27 Nov 1992 05:43:20 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Nov 1992 18:42:23 +0000 To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Thu, 26 Nov 92 09:52:52 MST." <9211261652.AA15877@goshawk.lanl.gov> Date: Thu, 26 Nov 92 18:42:17 +0000 From: Jon Crowcroft >people tried to interfere with the market? It also seems that the next time i hear about market forces i think i will be ill... "market forces" chose VHS video you think thats the best technical choice, hunh? market forces are todays economic attempt to put rubbish on a scientific footing. lets get on with the technical discussion please... j. From owner-Big-Internet@munnari.oz.au Fri Nov 27 10:04:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08998; Fri, 27 Nov 1992 10:04:43 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08995; Fri, 27 Nov 1992 10:04:37 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11392; Thu, 26 Nov 92 16:04:33 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA16484; Thu, 26 Nov 92 16:04:32 MST Message-Id: <9211262304.AA16484@goshawk.lanl.gov> To: Dave Crocker Cc: David M. Piscitello , big-internet@munnari.oz.au Subject: Re: FYI: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 08:18:14 -0800. <9211251618.AA22912@Mordor.Stanford.EDU> Date: Thu, 26 Nov 92 16:04:31 MST From: peter@goshawk.lanl.gov Dave, Perhaps we should put 'impact on end users' on the criteria list. How many end users know about Signalling System 7, let alone how their phone works? Yet, in the U.S. there are 120 million satisfied customers of these systems. The phone system has evolved significantly with minimal impact on the end users. The greatest impact I have noticed is TV ads of Candice Bergen dropping pins and saying something about fibre optics. If we do our jobs right, the end users will blithely go on typing 'telnet mordor.stanford.edu' and be satisfied. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 11:16:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11517; Fri, 27 Nov 1992 11:16:43 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11514; Fri, 27 Nov 1992 11:16:38 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA12008; Thu, 26 Nov 92 17:16:33 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA16807; Thu, 26 Nov 92 17:16:32 MST Message-Id: <9211270016.AA16807@goshawk.lanl.gov> To: mrose@dbc.mtview.ca.us Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Wed, 25 Nov 92 13:43:15 -0800. <24079.722727795@dbc.mtview.ca.us> Date: Thu, 26 Nov 92 17:16:31 MST From: peter@goshawk.lanl.gov Marshall, As to compliance issues of routers. I would make the requirement in a compliance document be: "router must be manageable in the TUBA environment". While all entities in the Internet are still IP reachable, the issue of whether you get to it via CLNP or IP does not seem to be such a big deal. I made a similar point in discussing the DNS during the TUBA plenary talk and during the question and answer period. >>> CLNP is not TUBA. TUBA is more than CLNP. For example, I would expect >>> a TUBA-compliant router to have an SNMP agent running over a TUBA stack. >>> I would expect that TUBA is a lot more than "just CLNP". >>> The problem is that in plenary the TUBA talk included the quoted >>> statement above. That just isn't true. It is OK to say that there are >>> CLNP devices deployed. It is not truthful to say that there are >>> TUBA-compliant devices deployed. Before we discuss truth or falsehoods relative to compliance don't you think the TUBA group should generate a compliance spec? One might expect that this document would eventually find its way into the router requirements spec. Since you seem so interested in this, perhaps you will volunteer to write it? The TUBA effort would be proud to include you as a contributor. TUBA is a very broad spectrum plan, which starts with an IP-only Internet and migrates over a long period of time to when the Internet has a vast majority of IP/CLNP speakers. The plan explicitly recognizes a wide variety of "states" during the period of transition. We anticipate that individual systems capabilities will be enhanced incrementally over time. I reject your notion of absolutes (truths/falsehoods) without qualification wrt the context of evaluation. Given that you feel that I made untrue statements during the plenary, it is unfortunate you didn't bother to ask me about this during the plenary question and answer period or when we passed each other in the hall. I hope in the future you will make more timely efforts in making me be a better representative of the TUBA effort. I expect the same of any peer. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 11:44:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12837; Fri, 27 Nov 1992 11:44:48 +1100 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12832; Fri, 27 Nov 1992 11:44:39 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA12154; Thu, 26 Nov 92 17:44:34 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA17090; Thu, 26 Nov 92 17:44:33 MST Message-Id: <9211270044.AA17090@goshawk.lanl.gov> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Thu, 26 Nov 92 18:42:17 +0000. <9211261842.AA16085@goshawk.lanl.gov> Date: Thu, 26 Nov 92 17:44:32 MST From: peter@goshawk.lanl.gov Jon, Would you prefer that I use "natural selection" in place of "market forces"? If so, please substitute "ecology" for "market" in my notes. No need to get nasty by accusing me of being an Economist!!! :-) yours for genetic diversity, peter From owner-Big-Internet@munnari.oz.au Fri Nov 27 13:40:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17590; Fri, 27 Nov 1992 13:41:01 +1100 (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 AA17574; Fri, 27 Nov 1992 13:40:49 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA00210); Thu, 26 Nov 92 20:40:33 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211270240.AA00210@is.rice.edu> Subject: Re: FYI: one person's view about recent IETF and IPv7 To: peter@goshawk.lanl.gov Date: Thu, 26 Nov 92 20:40:32 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9211262304.AA16484@goshawk.lanl.gov>; from "peter@goshawk.lanl.gov" at Nov 26, 92 4:04 pm X-Mailer: ELM [version 2.3 PL11] peter@goshawk.lanl.gov > > If we do our jobs right, the end users will blithely go on typing > 'telnet mordor.stanford.edu' and be satisfied. > Peter, do we really WANT to teach the "great unwashed" all the warts of the existing user interface? Of course we still need to keep it around, at least as long the "old guard" are around. -- 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 Sat Nov 28 03:50:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11847; Sat, 28 Nov 1992 03:50:56 +1100 (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 AA11048; Sat, 28 Nov 1992 03:03:43 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00271; Fri, 27 Nov 92 11:03:15 -0500 Date: Fri, 27 Nov 92 11:03:15 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211271603.AA00271@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dcrocker@mordor.stanford.edu, ericf@atc.boeing.com Subject: Re: multiple IPv7s Cc: jnc@ginger.lcs.mit.edu I was sent to the IETF due to significant corporate concerns about IPv7. I was sent to deliver a corporate position but found no forum to deliver it as anything other than a personal opinion. This is an interesting point, but I'm not sure it's a problem. There's a lot of back and forth here about responding to market forces (which is what your particular point is a sub-point of), versus trying to pick the best design, and I think each side has some points. To take the side of the "good design" people for a moment, if you look back in history at extremely sucessful engineering projects (e.g. the Panama Canal and Brooklyn Bridge, both of which are documented in excellent books), you'll find that the engineers responsible (and in both cases an engineer was prety much calling the shots) put a lot more into the project than any cost- benfit analysis (if they'd heard of such a thing in that day and age) would have called for, and it paid off in the long run. (E.g., the lock size on the Panama Canal, far larger than any contemporary ships.) This is not too surprising; the engineers often have a better view forward of what the future use of their frob is, and they are in the best position to judge what is "good engineering". I think that a study of history will show that, in the long run, you don't go far wrong in picking "good engineering" as your foremost principle. That's why, naive as it may *at first* sound, it's the one I always follow. The take the side of the "market forces" guys for a moment, it's also absolutely correct to say that the best engineering in the world is useless if the box doesn't sell in the market. The golden example here, for me, is Multics, which is still, almost 30 years after it was laid down, the best operating system ever, but which was a miserable failure in terms of getting out into the world. How should we balance these two concerns? I personally think the best choice, given a number of options, is the one, of the set which are market feasible, with the best engineering. So, how does this relate to the IETF? Well, I think out system tries (emphasis of potential fallibilty) to marry the best of these two. Two immediate problems arise. First, you do you pick the 'best engineering', and second, how do you get consensus on a decision. We deal with the first by making this a society of individual engineers. Good engineering is hard to define, but by and large, good engineers know it when they see it. Most engineers are also intellectually honest enough that, when asked which one they *personally* prefer, they go with their engineering instinct, not a *purely* corporate viewpoint (although, obviously, in roughly equal choices other forces come into play). That's why I like the emphasis on individual members; organizations are usually driven by concerns other than "good engineering". We deal with the second by, when there we cannot form a consensus, by putting forth the most likely contenders and letting practical experience (i.e. the market) guide us. This may not be the best path, but on the other hand, it's a little harder to influence unfairly than a committee decision, and we don't run the risk of settling on somthing that won't fly in the market. Realize that a lot of time when there is no consensus it's not people and organizations being manipulative, but a genuine disagreement over technical merits. The whole IPv7 thing is a case in point; I can sympathise with the people who prefer TUBA to SIP (say) since I prefer TUBA myself of the two, although I personally would take yet another path. It's hard for me to postulate a better decision process (in terms of producing better results in the long run) than the (admittedly) ugly to look at one we have now. My personal fear is that the IETF will balkanize over IPv7. This is a reasonable concern, but there are significant forces that will heal any split eventually. The biggest single one, of course, is that the whole point of a communication system is to communicate, and a system split up into non-communicative pieces cannot meet this goal. The pressure to be able to communicate will eventually cause thigns to be joined up. Hopefully, this will happen before too much time, energy, sweat, pain, etc, etc are expended, but as we have seen from the ISO/TCP wars, this is not necessarily so, although I do think it is inevitable. The challenge, it seems to me, is to manage things so that you minimize the length of time there is a split in direction. That there will be a split is inevitable; different groups see different things as the optimal solution, and since desk argument has proved insufficient to produce a common vision, we are all going off to try things. This is not necessarily bad. What we need to make sure is that i) everyone stays "under the tent" (to use the later Lee Atwater's term) in the same organization framework, and communicating, ii) that we all keep in mind the common goal of a single interoperable communication system, and iii) that proponents of various proposals be willing to fold their hands on their own, in the short run, rather than being forced (more painfully) by the market to do so in the long run. Unless the IETF can select a single authoritative IPv7, the Internet will continue to have IPv4 be the required network layer protocol and all other options to be optional. This is not necesarily the end of the world. There is a number of options (such as NAT) which allow us to do that. If we can't agree on an IPv7 that is significantly more effective than IPv4, I bet the market forces us to take this path anyway! Noel From owner-big-internet@munnari.oz.au Sat Nov 28 06:14:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14598; Sat, 28 Nov 1992 06:14:48 +1100 (from owner-big-internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12547; Sat, 28 Nov 1992 04:32:33 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA00260; Fri, 27 Nov 92 12:30:39 -0500 Date: Fri, 27 Nov 92 12:30:39 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9211271730.AA00260@er.doe.gov> To: big-internet@munnari.oz.au, dcrocker@mordor.stanford.edu, ericf@atc.boeing.com Subject: Re: multiple IPv7s Cc: ericf@munnari.oz.au Several points to remember: The internet is a large production network and the current IPv4 has a very large installed base which some of which is connected and some of which is not connected to the current global infrastructure. One of the things inherent in this installed base is that renumbering even a small net is a management nightmare. If we as a community "blow it" and CIDR doesn't work or can't be implemented because of user resistance to renumbering or we underestimate the time to implement a new solution... We will make ISO, CCITT,... all look great as well as cover the IETF community with... It would indeed be nice if various IPv7 alternatives interoperated with each other and IPv7... it would also be nice if Decnet phase IV, phase V, IP CLNP,... and various protocols we have today interoperated. I am, however, not optimistic that this sort of interoperability at the network layer is possible in the real world. Perhaps an alternative is the sort of protocol negotiation which DECNET V triesat the session layer... and which would look to users like interoperability if there were a global EID space all the protocols could see. Users don't mostly care about things that don't affect them! When was the last time a user came to you and requested a specific ethernet address?Why? Because, the ethernet address is taken care of by the software he uses so he or she never needs to know it or worry about it. If we want users to not care about "addresses" routing information strings or whatever, then we need to isolate that stuff from things that matter to the user. Theproblemsof managing multiple "address", naming, and numbering plans at even small sites are a major issue for the acceptability of new or old protocols. If end users don't want it vendors can't afford to build it! DH From owner-big-internet@munnari.oz.au Sat Nov 28 06:54:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15506; Sat, 28 Nov 1992 06:54:30 +1100 (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 AA13779; Sat, 28 Nov 1992 05:41:07 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18179; Fri, 27 Nov 92 10:40:47 -0800 Message-Id: <9211271840.AA18179@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: David M. Piscitello , big-internet@munnari.oz.au Subject: Re: FYI: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 26 Nov 92 16:04:31 -0700. <9211262304.AA16484@goshawk.lanl.gov> Date: Fri, 27 Nov 92 10:40:47 -0800 From: Dave Crocker X-Mts: smtp Peter, Adding the criterion you suggest fits the bill. The reference to SS7 is natural, but I suspect it is not the best fit we could wish for. The phone service has a number of characteristics that are vastly different from the Internet, including much deeper involvement in operations and technical development by end users, much more complicated system-wide administration, by virture of multiple, competing providers _throughout_ the system rather than only in the "backbone" (note, for example, the increasing challenge to the term backbone for the Internet), etc. It also helps that the phone pholks have many decades of astonishingly good user and transition support. In comparison, we computer networking pholk haven't got a clue. Really. This is why my own efforts have been exclusively focussed on providing techniques for making the transition just as transparent as you suggest, tho I hope it doesn't result in everyone being required to use mordor.stanford.edu... Dave From owner-Big-Internet@munnari.oz.au Sat Nov 28 07:58:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16439; Sat, 28 Nov 1992 07:58:46 +1100 (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 AA16436; Sat, 28 Nov 1992 07:58:21 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA11966; Fri, 27 Nov 92 15:58:02 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA03102; Fri, 27 Nov 92 12:56:34 PST Message-Id: <9211272056.AA03102@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: re: one person's view about recent IETF and IPv7 From: Craig Partridge Date: Fri, 27 Nov 92 12:56:34 -0800 Sender: craig@aland.bbn.com Hi Peter: Actually, I've read the latest CLNP spec and a bunch of other docs. It isn't very helpful. It only tells me what the bits are -- how they'd be used in TUBA and to what end is still missing. So just explaining CLNP is a waste of time. Talk TUBA -- deal with questions like Marshall's of how SNMP will get put over CLNP, how exactly IPv4 and CLNP hosts will interoperate (exactly which bits go where), etc. Thanks! Craig From owner-Big-Internet@munnari.oz.au Sat Nov 28 10:45:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20301; Sat, 28 Nov 1992 10:45:51 +1100 (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 AA20285; Sat, 28 Nov 1992 10:45:25 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA09634; Fri, 27 Nov 92 15:43:50 -0800 To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Reply-To: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Thu, 26 Nov 1992 09:06:03 MST." <9211261606.AA15636@goshawk.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Nov 1992 15:43:48 -0800 Message-Id: <9624.722907828@dbc.mtview.ca.us> From: Marshall Rose Let's not change the subject. How do you expect so-called "TUBA-compliant" routers to be managed? /mtr From owner-big-internet@munnari.oz.au Sat Nov 28 12:13:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22570; Sat, 28 Nov 1992 12:14:32 +1100 (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 AA20434; Sat, 28 Nov 1992 10:51:42 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA09713; Fri, 27 Nov 92 15:50:09 -0800 To: peter@goshawk.lanl.gov Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Thu, 26 Nov 1992 17:16:31 MST." <9211270016.AA16807@goshawk.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Nov 1992 15:50:08 -0800 Message-Id: <9709.722908208@dbc.mtview.ca.us> From: Marshall Rose If the requirements for "TUBA-compliant devices" are not fleshed out, then perhaps it would be a service to the community if TUBA-proponents wouldn't make statements about "TUBA-compliant devices" already being in the field. The reason I didn't nail you on it in plenary is because someone else beat me to it. Your response was a handwave which caused a bit of snickering from some people in the row where I was sitting. Now I suppose I could have continued to grill you, but why kick someone when they're already down... /mtr From owner-Big-Internet@munnari.oz.au Sat Nov 28 15:40:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28103; Sat, 28 Nov 1992 15:40:50 +1100 (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 AA28095; Sat, 28 Nov 1992 15:40:20 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA21236; Fri, 27 Nov 92 20:40:12 -0800 Message-Id: <9211280440.AA21236@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, ericf@atc.boeing.com Subject: Re: multiple IPv7s Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 27 Nov 92 11:03:15 -0500. <9211271603.AA00271@ginger.lcs.mit.edu> Date: Fri, 27 Nov 92 20:40:12 -0800 From: Dave Crocker X-Mts: smtp Noel, Our challenge, I believe, is to balance the "foresight" possible among good engineers with the "insight" vested with good customers. However good engineers are, they/we rarely live with customer sites enough to fully appreciate the realities of their daily operational life. If we get the balance wrong, the operational concerns make us too conservative or the engineering flights of fantasy make products that are beyond user's needs/wants/etc. In the case of internet-layer protocols, I think that we need to be very careful particularly about engineering flights of fantasy. The functional requirements are really rather modest and the current technology works remarkably well. I am very concerned that we will use the address space/table space problems as an excuse to fix problems that really do not exist and thereby disrupt users very much unnecessarily. Dave From owner-Big-Internet@munnari.oz.au Sun Nov 29 00:40:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10846; Sun, 29 Nov 1992 00:41:02 +1100 (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 AA10834; Sun, 29 Nov 1992 00:40:37 +1100 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA23659); Sat, 28 Nov 92 07:39:55 CST Received: by san-miguel.is.rice.edu (AA00743); Sat, 28 Nov 92 07:39:47 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211281339.AA00743@san-miguel.is.rice.edu> Subject: Re: one person's view about recent IETF and IPv7 To: big-internet@munnari.oz.au Date: Sat, 28 Nov 92 7:39:46 CST Cc: mtr@dbc.mtview.ca.us In-Reply-To: <9624.722907828@dbc.mtview.ca.us>; from "Marshall Rose" at Nov 27, 92 3:43 pm X-Mailer: ELM [version 2.3 PL11] Well, I expect that "TUBA-compliant" devices, including routers will use IETF and international standards. To expect anything less is foolhardy. What we have today is systems that can route CLNP packets, and so we might have the base set for what is expected to become a TUBA capable infrastructure. These systems are currently managable via SNMP using IPv4. Until the IETF rules that IPv4 and SNMP are "historical" and we have something better to replace them, I think that "TUBA-compliant" devices must support existing managment methods. The real trick is to get the managment protocols to understand the handfull of proposed new IPv7/8/9/X packet formats. Since this is an area in which you excel, could you help us figure out what we need to do to have a smooth migration path to the new suites? -- 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 Sun Nov 29 10:09:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24755; Sun, 29 Nov 1992 10:09:55 +1100 (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 AA24750; Sun, 29 Nov 1992 10:09:47 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA27625; Sat, 28 Nov 92 15:09:29 -0800 Message-Id: <9211282309.AA27625@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 26 Nov 92 17:16:31 -0700. <9211270016.AA16807@goshawk.lanl.gov> Date: Sat, 28 Nov 92 15:09:29 -0800 From: Dave Crocker X-Mts: smtp Peter, While all entities in the Internet are still IP reachable, the issue of whether you get to it via CLNP or IP does not seem to be such a big deal. Seems like a big deal to me. How is the sender to make the selection between IPv4 and TUBA? The Tuba doc says 'look in the DNS'. This, unfortunately, only works if _all_ the intermediate routers support _both_ IPv4 and TUBA. They don't now and it seems unwise to have this critical dependency. TUBA is a very broad spectrum plan, which starts with an IP-only Internet and migrates over a long period of time to when the Internet has a vast majority of IP/CLNP speakers. The plan explicitly recognizes a wide variety of "states" during the period of transition. The plan "recognizes a wide variety of 'states'"??? It does? Where? The TUBA doc isn't nearly that elaborate, so I'd be interested in hearing more detail about these states. What are the real dependencies on implementing TUBA for the Internet and how will they be achieved? I'd like to remind folks that the switch from NCP to TCP, 10 years ago, was a classic dual-stack switch and it is universally characterized as having been a 6-month disaster. So why will the same approach work for TUBA? Dave From owner-big-internet@munnari.oz.au Sun Nov 29 11:26:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26947; Sun, 29 Nov 1992 11:26:51 +1100 (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 AA25055; Sun, 29 Nov 1992 10:18:25 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA27652; Sat, 28 Nov 92 15:18:19 -0800 Message-Id: <9211282318.AA27652@Mordor.Stanford.EDU> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 26 Nov 92 09:52:52 -0700. <9211261652.AA15877@goshawk.lanl.gov> Date: Sat, 28 Nov 92 15:18:18 -0800 From: Dave Crocker X-Mts: smtp Peter, May I suggest the reason that the HEMS/SGMP/CMOT was so messy was that people tried to interfere with the market? It also seems that the people who always talk about how messy it was are the people who were personally involved in this sort of interference. Most of the people who _I_ hear discuss the HEMS, et al, brouhaha were directly in the middle of it, so we must be talking to different people. My own assessment of the phenomenon, as Area Director for Network Management during the latter half of the brouhaha, was the CMOT was given an undue boost, by being elevated to Draft Standard in the absence of even one implementation, and was usually represented by people who were quite lacking in technical crispness to the content of their arguments and presentations. In other words, the CMOT crew did predominantly political work and remarkably little technical work. Dave P.S. I presume that you were not counting Craig or Marshall as "uninvolved" in previous experience? From owner-Big-Internet@munnari.oz.au Sun Nov 29 12:15:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28360; Sun, 29 Nov 1992 12:16:20 +1100 (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 AA28341; Sun, 29 Nov 1992 12:15:57 +1100 (from craig@aland.bbn.com) Received: from port14.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA29007; Sat, 28 Nov 92 20:15:43 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA13145; Sat, 28 Nov 92 17:14:15 PST Message-Id: <9211290114.AA13145@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Subject: what users know From: Craig Partridge Date: Sat, 28 Nov 92 17:14:14 -0800 Sender: craig@aland.bbn.com > How many end users know about Signalling System 7, let alone > how their phone works? Yet, in the U.S. there are 120 million > satisfied customers of these systems. Peter: Well, they may not know about SS7, but a fair number know about call waiting, caller ID, call conferencing, in other words, new services that SS7 (among other innovations) have made possible. The changes in IPv7 are not going to be completely transparent to users. When things don't work due to poor transition plans, they will yell. If new nifty services show up, they'll be pleased. Of course, if new useless services show up, they'll ignore them (or protest them). Craig From owner-Big-Internet@munnari.oz.au Sun Nov 29 13:43:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00255; Sun, 29 Nov 1992 13:43:59 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00247; Sun, 29 Nov 1992 13:43:45 +1100 (from Scott_Brim@cornell.edu) Received: from mcimail.com by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB03397; Sat, 28 Nov 92 21:43:31 EST Message-Id: <9211290243.AB03397@mitchell.cit.cornell.edu> Date: Sat, 28 Nov 1992 21:42:30 -0500 To: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu Sender: swb@132.236.200.25 Subject: Re: one person's view about recent IETF and IPv7 Marshall, it's hard for me to take your pleas for judging alternatives purely on technical merit seriously when you send messages whose main thrust is to weaken people's cases through innuendo. Oh, your mail is much more civilized now than it was on the POISED list a couple of months ago, but even so, please try to restrain yourself. I'm singling you out mostly because you are better at it than the many others who attempt this sort of thing. Scott From owner-Big-Internet@munnari.oz.au Sun Nov 29 16:18:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04927; Sun, 29 Nov 1992 16:18:56 +1100 (from owner-Big-Internet) Return-Path: Received: from hostshost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04920; Sun, 29 Nov 1992 16:18:48 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA10776; Sat, 28 Nov 92 22:18:39 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA20949; Sat, 28 Nov 92 22:18:38 MST Message-Id: <9211290518.AA20949@goshawk.lanl.gov> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Fri, 27 Nov 92 12:56:34 -0800. <9211272056.AA03102@aland.bbn.com> Date: Sat, 28 Nov 92 22:18:38 MST From: peter@goshawk.lanl.gov Craig, In terms of how SNMP should work over CLNP, I will defer to Marshall or any other SNMP guru as to how RFC1283 ( Rose, M. SNMP over OSI. 1991 December ) should be updated in light of TUBA (or for SNMP v2 for that matter). I can imagine there will need to be some MIB work done for TCP/UDP over CLNP. The reason you don't see as much bit hacking in the TUBA discussions as you do in IPAE discussion is that the TUBA transition is a simple, dual-stacked, approach. The TUBA RFC describes how CLNP hosts (Assume that we are talking CLNP only speakers) and IPv4 hosts do not exchange packets. In the TUBA environment there are two classes of hosts: IPv4 only speakers, and IPv4/CLNP dual stacked hosts. It is assumed that IPv4 only hosts will always use IPv4 and can only communicate with IPv4 speakers (which in the TUBA world could be IPv4 only speakers or "TUBA hosts" which are IPv4 and CLNP speakers.) Thus, if some service is available only by using IPv4, this can continue to work until the Internet has run out of *globally unique* IPv4 address space. If there are two IP/CLNP speakers they may elect to use TCP/UDP running on top of CLNP to intercommunicate or it is possible for them to choose to use TCP/UDP running over IPv4. In the current formulation of TUBA there is not the notion of address translation boxes. If such a unit is necessary, then I believe one can be spec'ed (many people spent a fair amount of time looking into this about a year ago.) Embedding the current IPv4 address space in NSAP IDs is pretty easy and goes towards simplifying the creation of such a box. I do see a major deficiency in defining "the bits". The TUBA effort does need to document how TCP/UDP will be run over CLNP. This is a point of contention at this point, so at the DC IETF the TUBA WG decided on something we called an "implementors agreement" where the TCP and UDP end point identification is based on an entire NSAP. I would say we still need further discussion within the TUBA effort as to whether or not this end point identification could be done only on the ID portion (6 bytes) of an IS-IS routed NSAP. The group chose to go forward with trial implementations to help the process of resolution with real implementation experience. By the way, the TUBA transition plan is one that could be used for any of SIP, PIP or CLNP. As Paul Tsuchiya pointed out there were really two orthogonal issues being discussed during the DC IETF plenary: PDU formats and capabilities (SIP/IP/CLNP) and transition plans (encaps, option munging, and dual-stacking )). yours in the bits, peter From owner-Big-Internet@munnari.oz.au Sun Nov 29 17:16:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06527; Sun, 29 Nov 1992 17:17:02 +1100 (from owner-Big-Internet) Return-Path: Received: from hostshost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06494; Sun, 29 Nov 1992 17:16:47 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11171; Sat, 28 Nov 92 23:16:43 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA21048; Sat, 28 Nov 92 23:16:42 MST Message-Id: <9211290616.AA21048@goshawk.lanl.gov> To: mrose@dbc.mtview.ca.us Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of Fri, 27 Nov 92 15:50:08 -0800. <9709.722908208@dbc.mtview.ca.us> Date: Sat, 28 Nov 92 23:16:42 MST From: peter@goshawk.lanl.gov >>> The reason I didn't nail you on it in plenary is because someone else >>> beat me to it. Your response was a handwave which caused a bit of >>> snickering from some people in the row where I was sitting. Now I >>> suppose I could have continued to grill you, but why kick someone when >>> they're already down... Marshall, Please continue to kick, I have had time to pick myself back up and regain at least some of my senses. Exactly, what was wrong with the answer I gave? Am I wrong to say that one could manage a CLNP and IP forwarding router using SNMP over IPv4? It would seem to be a logical step in a progression implementing a phased TUBA transition. This would also seem to leverage off the existing base of management stations and the like. Are we confusing transition states and end state? Or perhaps we are talking about aesthetics? Do we disagree on assumptions? While kicking, bear in mind that the ribs are still a little sore, peter From owner-Big-Internet@munnari.oz.au Sun Nov 29 18:14:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08170; Sun, 29 Nov 1992 18:15:15 +1100 (from owner-Big-Internet) Return-Path: Received: from hostshost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08141; Sun, 29 Nov 1992 18:14:58 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11711; Sun, 29 Nov 92 00:14:51 -0700 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA21418; Sun, 29 Nov 92 00:14:50 MST Message-Id: <9211290714.AA21418@goshawk.lanl.gov> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Date: Sun, 29 Nov 92 00:14:50 MST From: peter@goshawk.lanl.gov Dave, I believe you are making my point. People were trying to decide instead of letting natural selection take place. Shouldn't the process be to push ideas/documents/implementations out for critical review and acceptance and then see if we observe survival and progeny? Your note would seem to support this observation. In the end with H/C/S, natural selection seems to have won out and rendered much of the earlier decision processing moot. Some might argue that it was not the best solution, but it is the one which the Internet community has adopted and uses to get the job done. Anyways, the point of my note is that many seem to be making the same mistake the IAB was accused of, in that there is a decision to be made so let's make it as soon as possible and without going through the process we trust. We certainly can drive the process by working hard on the various proposals, like you and I are doing, but I argue we shouldn't get too caught up with making *the* decision. The decision can be made objectively, when proofs of existence are available and consensus is developed. In some cases it is not even necessary to have consensus, but in the case of an internetwork layer protocol I believe we will see the necessary consensus emerge. I assume one of the reasons we have proposed standards and draft standards is in the event that they are subsequently found out to be mules. cheers, peter From owner-big-internet@munnari.oz.au Sun Nov 29 23:18:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15460; Sun, 29 Nov 1992 23:18:40 +1100 (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 AA12848; Sun, 29 Nov 1992 21:29:42 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA27730; Sun, 29 Nov 92 02:27:55 -0800 To: Scott_Brim@cornell.edu Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Sat, 28 Nov 1992 21:42:30 EST." <9211290243.AB03397@mitchell.cit.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Nov 1992 02:27:53 -0800 Message-Id: <27726.723032873@dbc.mtview.ca.us> From: Marshall Rose Scott - In my original message, I was arguing against n>1 standards for IPv?. My good frield Dick desJardins thought I was making an OSI attack, and challenged me. I responded. This iterated for about three exchanges. During the course of this, Dick and I agreed on some terminology to help clarify what is being said about TUBA. Perhaps everyone on the list is able to discern fact from fiction. If so, then my discussion with Dick was unnecessary. Otherwise, perhaps you might spend your time pondering the costs/benefits of n>1 standards. /mtr From owner-big-internet@munnari.oz.au Mon Nov 30 00:09:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17235; Mon, 30 Nov 1992 00:09:07 +1100 (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 AA12910; Sun, 29 Nov 1992 21:34:16 +1100 (from mrose@dbc.mtview.ca.us) Received: from localhost by dbc.mtview.ca.us (5.65/3.1.090690) id AA27781; Sun, 29 Nov 92 02:32:30 -0800 To: peter@goshawk.lanl.gov Reply-To: big-internet@munnari.oz.au Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 In-Reply-To: Your message of "Sat, 28 Nov 1992 23:16:42 MST." <9211290616.AA21048@goshawk.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Nov 1992 02:32:28 -0800 Message-Id: <27777.723033148@dbc.mtview.ca.us> From: Marshall Rose I thought TUBA was about running TCP and UDP over ~CLNP. While a box might have IPv4 in addition to TUBA, it is difficult to imagine someone saying "manage the TUBA box using SNMP/UDP/IPv4". I would expect them to say "manage the TUBA box using SNMP/TUBA". Presumably for TUBA to be a successor to IPv4, it must support the same kind of infrastructure we have today. This includes the kinds of upper-layer protocols we run on our routers. This is why I have difficulty with the statement "TUBA-compliant devices are already in the field". Sure, there are lots of "CLNP-speaking devices" in the field. Somehow, I was led to believe that TUBA was going to be more than that... /mtr ps: perhaps we should take this off-line if I still seem unclear. From owner-Big-Internet@munnari.oz.au Mon Nov 30 02:13:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20308; Mon, 30 Nov 1992 02:13:49 +1100 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20302; Mon, 30 Nov 1992 02:13:34 +1100 (from Scott_Brim@cornell.edu) Received: from [132.236.236.46] (CU-DIALUP-0204.CIT.CORNELL.EDU) by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA18005; Sun, 29 Nov 92 10:13:07 EST Message-Id: <9211291513.AA18005@mitchell.cit.cornell.edu> Date: Sun, 29 Nov 1992 10:12:04 -0500 To: big-internet@munnari.oz.au From: Scott_Brim@cornell.edu Sender: swb@132.236.200.25 Subject: Re: one person's view about recent IETF and IPv7 At 2:32 11/29/92 -0800, Marshall Rose wrote: >ps: perhaps we should take this off-line if I still seem unclear. Please don't do that. I appreciate seeing the important questions explored publicly. From owner-Big-Internet@munnari.oz.au Mon Nov 30 02:37:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20896; Mon, 30 Nov 1992 02:38:04 +1100 (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 AA20893; Mon, 30 Nov 1992 02:37:53 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA01437); Sun, 29 Nov 92 09:37:38 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211291537.AA01437@is.rice.edu> Subject: Re: one person's view about recent IETF and IPv7 To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Sun, 29 Nov 92 9:37:38 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9211282309.AA27625@Mordor.Stanford.EDU>; from "Dave Crocker" at Nov 28, 92 3:09 pm X-Mailer: ELM [version 2.3 PL11] Dave Crocker > > > Seems like a big deal to me. How is the sender to make the selection > between IPv4 and TUBA? The Tuba doc says 'look in the DNS'. This, > unfortunately, only works if _all_ the intermediate routers support > _both_ IPv4 and TUBA. They don't now and it seems unwise to have this > critical dependency. You are making an assumption here, that all things coded in the DNS space are reachable. This is in fact not true. It is true that most things coded in the IPv4 space and visable to the root servers are reachable mot of the time. Entries in the DNS do NOT correspond to reachability. Thats why there are control messages. > > The plan "recognizes a wide variety of 'states'"??? It does? Where? > The TUBA doc isn't nearly that elaborate, so I'd be interested in > hearing more detail about these states. We were working on this at the last meeting in Washington. Mark should have something on this RSN. > > I'd like to remind folks that the switch from NCP to TCP, 10 years ago, > was a classic dual-stack switch and it is universally characterized > as having been a 6-month disaster. So why will the same approach work > for TUBA? > Is there something that we can learn from that history lesson? -- 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 Mon Nov 30 03:36:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21786; Mon, 30 Nov 1992 03:37:47 +1100 (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 AA21759; Mon, 30 Nov 1992 03:36:38 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06084; Sun, 29 Nov 92 11:36:09 -0500 Date: Sun, 29 Nov 92 11:36:09 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211291636.AA06084@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, peter@goshawk.lanl.gov Subject: Re: one person's view about recent IETF and IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In the end with H/C/S, natural selection seems to have won out and rendered much of the earlier decision processing moot. ... Anyways, the point of my note is that many seem to be making the same mistake the IAB was accused of, in that there is a decision to be made so let's make it as soon as possible ... We certainly can drive the process by working hard on the various proposals, ... but I argue we shouldn't get too caught up with making *the* decision. The more I think about these, the more I agree. This debate is midly interesting, but when it's said and done, what has it really accomplished? How many minds will have been changed? Perhaps we should all stop arguing, since that clearly is not going to produce closure, as (painfully :-) demonstrated oevr the last couple of months, and go off and design, implement and deploy stuff? in the case of an internetwork layer protocol I believe we will see the necessary consensus emerge. I agree. The desirability of unbiquitous communication does tend to drive people toward a common communication substructure. Isn't there some statistic to the effect that some number of obscure human languages die off each year? Same principle... Noel From owner-Big-Internet@munnari.oz.au Mon Nov 30 03:58:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21948; Mon, 30 Nov 1992 03:59:06 +1100 (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 AA21945; Mon, 30 Nov 1992 03:58:53 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA02035); Sun, 29 Nov 92 10:58:37 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211291658.AA02035@is.rice.edu> Subject: Re: NSAP's, ID's, and the TCP checksum To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sun, 29 Nov 92 10:58:36 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9211291626.AA06017@ginger.lcs.mit.edu>; from "Noel Chiappa" at Nov 29, 92 11:26 am X-Mailer: ELM [version 2.3 PL11] I am not Peter, and don't play him on the net. Some folks want to use their existing NSAPs for TUBA. ISOc/IAB/ISEG/IETF don't have a way of setting some bit(s) in EVERY NSAP to flag it as TUBA capable. ISOc/IAB/ISEG/IETF don't have a recognised NSAP format that they own. Without ownership, we can't mandate what folks use in the six byte system id field. This is not an unsolvable problem. Until it is solved, we can and are working on some of the other difficult issues, such as managment information flow. It is my understanding that there is work on getting a recognised NSAP format assigned to the ISOc/IAB/ISEG/IETF. Once this is done, then we can have IANA hand out globally unique system IDs, as long as they have the right prefix. -- 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 Mon Nov 30 04:20:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22247; Mon, 30 Nov 1992 04:21:01 +1100 (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 AA21805; Mon, 30 Nov 1992 03:40:13 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06109; Sun, 29 Nov 92 11:40:00 -0500 Date: Sun, 29 Nov 92 11:40:00 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211291640.AA06109@ginger.lcs.mit.edu> To: craig@aland.bbn.com, peter@goshawk.lanl.gov Subject: Re: one person's view about recent IETF and IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The reason you don't see as much bit hacking in the TUBA discussions as you do in IPAE discussion is that the TUBA transition is a simple, dual-stacked, approach. A number of people are clearly uncomforatble with the approach, based, fairly or unfairly, correctly, or not, upon past experience. Since this is primarily an "experience shows this doesn't work well" argument, it's hard to argue the merits on a desk, although I will say that providing application gateways (the usual way of making it across the divide) is somewhat clunky and generally unsatisfactory. In the current formulation of TUBA there is not the notion of address translation boxes. If such a unit is necessary, then I believe one can be spec'ed (many people spent a fair amount of time looking into this about a year ago.) Given the nervousness, perhaps including this would make Tuba a more viable alternative for those who think we need a new packet format right now (i.e. not me :-)! Noel From owner-big-internet@munnari.oz.au Mon Nov 30 05:04:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22715; Mon, 30 Nov 1992 05:04:50 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211291804.22715@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22004; Mon, 30 Nov 1992 04:04:45 +1100 (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, 29 Nov 1992 17:04:17 +0000 To: big-internet@munnari.oz.au Subject: IETF and IPv7 and the Internet In-Reply-To: Your message of "Sun, 29 Nov 92 02:32:28 PST." <27777.723033148@dbc.mtview.ca.us> Date: Sun, 29 Nov 92 17:04:16 +0000 From: Jon Crowcroft by the way, i have done bits of consulting to some quite big companies (like the one referred to in "some like it how" by its logo) who said "what is an the IETF"? how does the ISOC/IAB/IESG/IETF etc intend to make *any* decision stick? i draw a paralel with a simpler community which "decided" t optransition to ISO in the UK according to a perfectly technically well formulated plan it was abandoned in favour of IPv4 when products failed to matirialise IPv4 appeared because DARPA payed a HUGE amount of money for it who is going to do this for IPv7 - we have a _trivial_ example of the inertia in the internet with the failure of the NSF backbone to support multicast - i heard highly competent managers say "which multicast should we choose" and "can we have a budget" etc etc i`d ask the same question is the NREN budget gonna have a special section devoted to pay for IPv7? [i hope so, since we europens then get it for nowt(again):-] cheers jon From owner-Big-Internet@munnari.oz.au Mon Nov 30 06:37:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23898; Mon, 30 Nov 1992 06:38:21 +1100 (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 AA23873; Mon, 30 Nov 1992 06:37:26 +1100 (from dennis@ans.net) Received: by interlock.ans.net id AA09960 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 29 Nov 1992 14:36:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 29 Nov 1992 14:36:36 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 29 Nov 1992 14:36:36 -0500 From: Dennis Ferguson Message-Id: <199211291931.AA27467@foo.ans.net> To: bmanning@is.rice.edu (William Manning) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: NSAP's, ID's, and the TCP checksum In-Reply-To: (Your message of Sun, 29 Nov 92 16:58:36 GMT.) <9211291658.AA02035@is.rice.edu.ans-relay> Date: Sun, 29 Nov 92 14:31:25 -0500 I have some questions about this: > Some folks want to use their existing NSAPs for TUBA. > ISOc/IAB/ISEG/IETF don't have a way of setting some > bit(s) in EVERY NSAP to flag it as TUBA capable. > ISOc/IAB/ISEG/IETF don't have a recognised NSAP format that they > own. > Without ownership, we can't mandate what folks use in the > six byte system id field. Does this mean that using the NSEL to carry the IP protocol identifier has also been forgone? If so, where is the IP protocol identifier to be carried? If not, isn't this a little inconsistent? If ownership of the existing address space is required to permit specification of a particular interpretation of the ID field for TUBA, isn't it equally required to permit the specification of a particular interpretation of the NSEL field for TUBA? If no one feels any inhibition about specifying the semantics of the NSEL field with existing NSAPs in the TUBA environment, why is there a greater inhibition about specifying the semantics of the ID without ownership? > This is not an unsolvable problem. Until it is solved, > we can and are working on some of the other difficult > issues, such as managment information flow. If the interim solution for the IP protocol identifier was to ignore the ownership issue and let people write code which assumed the desired end-state, I don't see why the ID issue needed to be handled any differently. Because of this the problem you are pointing out seems less of a technical constraint and more of an excuse to me. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Mon Nov 30 06:37:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23907; Mon, 30 Nov 1992 06:38:50 +1100 (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 AA23881; Mon, 30 Nov 1992 06:37:53 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA06313; Sun, 29 Nov 92 11:37:31 -0800 Message-Id: <9211291937.AA06313@Mordor.Stanford.EDU> To: bmanning@is.rice.edu (William Manning) Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 29 Nov 92 09:37:38 -0600. <9211291537.AA01437@is.rice.edu> Date: Sun, 29 Nov 92 11:37:31 -0800 From: Dave Crocker X-Mts: smtp Bill, > Seems like a big deal to me. How is the sender to make the selection > between IPv4 and TUBA? The Tuba doc says 'look in the DNS'. This, You are making an assumption here, that all things coded in the DNS space are reachable. This is in fact not true. It is true that most things coded in the IPv4 space and visable to the root servers are reachable mot of the time. Entries in the DNS do NOT correspond to reachability. 'A' resource records are _supposed_ to communicate connectivity, tho they cannot, of course, guarantee reachability at any given moment. That is, listing the IP address of a host in the DNS is a promise that it can be reached via IP-level relaying, for some level of useful availability. Thats why there are control messages. The control messages, for source hosts, are 'error' messages. They are fall-backs, rather than intended to to primary sources of reachability information. An 'A' record entry in the DNS is an implied contract. > The plan "recognizes a wide variety of 'states'"??? It does? Where? > The TUBA doc isn't nearly that elaborate, so I'd be interested in > hearing more detail about these states. We were working on this at the last meeting in Washington. Mark should have something on this RSN. It would probably be sour grapes for me to ask further about TUBA deliverables concerning the evaluation criteria, so I won't. > > I'd like to remind folks that the switch from NCP to TCP, 10 years ago, > was a classic dual-stack switch and it is universally characterized > as having been a 6-month disaster. So why will the same approach work > for TUBA? > Is there something that we can learn from that history lesson? For me, the lesson is that simple, dual-stack, take-it-or-leave-it approaches don't work. What does it teach you? Dave From owner-big-internet@munnari.oz.au Mon Nov 30 10:59:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00444; Mon, 30 Nov 1992 10:59:22 +1100 (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 AA24985; Mon, 30 Nov 1992 08:05:48 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06472; Sun, 29 Nov 92 16:05:31 -0500 Date: Sun, 29 Nov 92 16:05:31 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211292105.AA06472@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu Subject: Re: NSAP's, ID's, and the TCP checksum Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I am not Peter, and don't play him on the net. Understood! Some folks want to use their existing NSAPs for TUBA. Once again, you (collective you to Tuba-ites :-) are digging yourself in a hole by tying yourselves so strongly to existing CLNP/ISO stuff. Who cares if you have to get new NSAP's? If Tuba *is what it claims to be*, this will be the least of your worries! Tuba as it stands requires entirely new software in the hosts (OK, I know, some of the source can be recycled, but from the point of view of the workstation owner, who gets a binary distribution tape, it's all new stuff, OK?), and this is a far larger deal than just getting an address. Plus to which, to make the routing work, the Internet may not be able to do anything useful with those old NSAP's anyway, etc, but the rest of the reasons are all in the noise compared to the new sofwtare in the hosts. (That's an intersting point, BTW. Is the Tuba Internet supposed to handle all valid NSAP's? Suppose it's for an address family which cannot be usefully routing by the Internet routing architecture?) Once again, by bending over backward to try and retain as much as possible of the existing ISO/CLNP/etc stuff you just raise wariness (and I don't mean to imply some giant underground conspiracy here, just the usual natural forces at work) that the future of the Internet is going to be constrained by the ISO, instead of the Internet being free to do what is in its best interests. *That* is the single biggest *political* problem that Tuba is going to face in its struggle to be accepted, and every time you defer to the installed CLNP base you make your acceptance that much less likely, by providing graphic proof that the Internet *will* be held hostage to the existing ISO "stuff" (protocols/process/products/etc,etc). ISOc/IAB/ISEG/IETF don't have a recognised NSAP format that they own. Without ownership, we can't mandate what folks use in the six byte system id field. So? If it were up to me, I'd dike the whole darn existing mess anyway, AFI's and all, and have an entirely separate address space for Tuba-type-CLNP managed by the I*, maximize the useful content to boot. However, I understand this might be seen as too radical. However, I most strongly disagree with your last sentence. We can most definitely mandate what folks use in the last 6 bytes *for Tuba use in the Internet*, whether the ISO likes it or not. We can simply *subset* the existing CLNP specs and state, bluntly, that "in Tuba, the ID *shall* contain a globally unique number". Full stop. There, wasn't that easy? Where do they get such a number? Well, this has been gone over before; an IEEE number will do for a start, and we can explore other things, but if people aren't willing to take the step of mandating unique ID's, that whole exercise is a waste of time. It is my understanding that there is work on getting a recognised NSAP format assigned to the ISOc/IAB/ISEG/IETF. Once this is done, then we can have IANA hand out globally unique system IDs, as long as they have the right prefix. Again, this is a waste of time if you are going to support existing non-I* NSAP's. I'm interested to see how you expect the routing to work if you do this... Noel From owner-big-internet@munnari.oz.au Mon Nov 30 11:24:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01203; Mon, 30 Nov 1992 11:25:06 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211300025.1203@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26988; Mon, 30 Nov 1992 09:13:46 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3233; Sun, 29 Nov 92 17:13:21 EST Date: Sun, 29 Nov 92 17:12:49 EST From: yakov@watson.ibm.com To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: one person's view about recent IETF and IPv7 >for me, the lesson is that simple, dual-stack, take-it-or-leave-it >approaches don't work. Dave, Would you then care to comment on the following: "Hosts that need global communication are modified to add support for the IPAE and SIP packet formats in addition to IPv4." Is that a dual-stack or not ? If the answer is yes, then how this suppose to work (given your comment that dual-stack "don't work"). If the answer is no, then what is "dual-stack" in your definition. Yakov Rekhter. P.S. By the way, the sentence I quoted above is from the "IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP)". You are one of the authors of this document. From owner-big-internet@munnari.oz.au Mon Nov 30 11:48:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01872; Mon, 30 Nov 1992 11:48:46 +1100 (from owner-big-internet) Return-Path: Message-Id: <9211300048.1872@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27342; Mon, 30 Nov 1992 09:21:17 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3255; Sun, 29 Nov 92 17:21:04 EST Date: Sun, 29 Nov 92 17:14:07 EST From: yakov@watson.ibm.com To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: one person's view about recent IETF and IPv7 >It would be probably sour grapes for me to ask further >about TUBA deliverables concerning the evaluation criteria. Dave, I think asking for TUBA deliverables concerning the evaluation criteria is a valid question, so I don't understand why this should be "sour grapes" for you. However, let me just point out that as of today we have no such thing as "the evaluation criteria". There is a document that was written by the IESG. There is a document that was written by Craig Partridge and Frank Kastenholz. There was a separate BOF at the last IETF where both of these documents were discussed and the community pointed out to problems with both of these documents. So, to sum things up, once the community will reach a consensus on "the evaluation criteria" I would expect that TUBA (as well as other groups, like IPAE/SIP and PIP) would produce documents that describe how these proposals match (or mismatch) against the evaluation criteria. Yakov Rekhter From owner-Big-Internet@munnari.oz.au Mon Nov 30 12:12:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02754; Mon, 30 Nov 1992 12:12:20 +1100 (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 AA02735; Mon, 30 Nov 1992 12:12:06 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06836; Sun, 29 Nov 92 20:11:33 -0500 Date: Sun, 29 Nov 92 20:11:33 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211300111.AA06836@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: NSAP's, ID's, and the TCP checksum Cc: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu This thread escaped from the TUBA list onto B-I by accident.. sorreee! It's back there now, if anyone wants to follow it. Noel From owner-big-internet@munnari.oz.au Mon Nov 30 12:44:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03787; Mon, 30 Nov 1992 12:44:22 +1100 (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 AA28268; Mon, 30 Nov 1992 09:54:08 +1100 (from dkatz@cisco.com) Received: by regal.cisco.com; Sun, 29 Nov 92 14:53:30 -0800 Date: Sun, 29 Nov 92 14:53:30 -0800 From: Dave Katz Message-Id: <9211292253.AA06297@regal.cisco.com> To: dennis@ans.net Cc: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, tuba@lanl.gov In-Reply-To: Dennis Ferguson's message of Sun, 29 Nov 92 14:31:25 -0500 <199211291931.AA27467@foo.ans.net> Subject: NSAP's, ID's, and the TCP checksum It should be sufficient to simply say, "if you are doing TUBA, your ID field must be globally unique," regardless of which NSAP format is in use. Those people that already have NSAPs for pure OSI communications (and who wish to remain pure OSI) needn't care; they won't show up in the DNS, and if someone actually tried to open a TCP connection over NSEL 6, the worst that would happen is that the connection wouldn't open and there'd be some angry protocol machinery at each end. This mandate is effectively a profile rather than a protocol. Those who already have NSAPs but wish to do TUBA and whose IDs are already globally unique needn't do anything at all, except in the case where their selectors for TP or CLTP collide with useful IP proto values, but these are easily changed (one small advantage to having NSELs be locally significant, but I digress). Those who already have NSAPs but wish to TUBA and whose IDs are not globally unique must do one of two things--either change the ID portion of their address to something globally unique, or use a separate NSAP for TUBA communications (and ditto the above concerning NSEL collision). It is an exceedingly *bad* idea to rely on a special NSAP format for TUBA, because this violates what I believe to be a fundamental requirement of TUBA--the ability to use any (existing) NSAP format. The worst-case requirement of changing the ID portion of an NSAP is a less onerous issue than changing the entire NSAP. I'm a supporter of global uniqueness, for a number of reasons (lowering Noel's blood pressure being one of them :-) ). Dennis--the NSEL-as-proto-ID is still in the spec. From: Dennis Ferguson Date: Sun, 29 Nov 92 14:31:25 -0500 I have some questions about this: > Some folks want to use their existing NSAPs for TUBA. > ISOc/IAB/ISEG/IETF don't have a way of setting some > bit(s) in EVERY NSAP to flag it as TUBA capable. > ISOc/IAB/ISEG/IETF don't have a recognised NSAP format that they > own. > Without ownership, we can't mandate what folks use in the > six byte system id field. Does this mean that using the NSEL to carry the IP protocol identifier has also been forgone? If so, where is the IP protocol identifier to be carried? If not, isn't this a little inconsistent? If ownership of the existing address space is required to permit specification of a particular interpretation of the ID field for TUBA, isn't it equally required to permit the specification of a particular interpretation of the NSEL field for TUBA? If no one feels any inhibition about specifying the semantics of the NSEL field with existing NSAPs in the TUBA environment, why is there a greater inhibition about specifying the semantics of the ID without ownership? > This is not an unsolvable problem. Until it is solved, > we can and are working on some of the other difficult > issues, such as managment information flow. If the interim solution for the IP protocol identifier was to ignore the ownership issue and let people write code which assumed the desired end-state, I don't see why the ID issue needed to be handled any differently. Because of this the problem you are pointing out seems less of a technical constraint and more of an excuse to me. Dennis Ferguson From owner-big-internet@munnari.oz.au Mon Nov 30 14:16:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06463; Mon, 30 Nov 1992 14:16:52 +1100 (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 AA00936; Mon, 30 Nov 1992 11:16:05 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08269; Sun, 29 Nov 92 16:15:55 -0800 Message-Id: <9211300015.AA08269@Mordor.Stanford.EDU> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 29 Nov 92 17:14:07 -0500. <9211292221.AA07491@Mordor.Stanford.EDU> Date: Sun, 29 Nov 92 16:15:54 -0800 From: Dave Crocker X-Mts: smtp Yakov, this should be "sour grapes" for you. However, let me just point out that as of today we have no such thing as "the evaluation criteria". There is a document that was written by the IESG. There is a document Yup, and that document was supposed to generate responses from the contendors. Two of them did. One didn't. that was written by Craig Partridge and Frank Kastenholz. Yup. Good stuff, too. The two responders tried to factor in the P&K list. Seems to me that trying is better than simply claiming the absence of a "consensus" about the criteria. to problems with both of these documents. So, to sum things up, once the community will reach a consensus on "the evaluation criteria" I would expect that TUBA (as well as other groups, Yakov, the "sour grapes" in my raising this is that I frankly feel the TUBA effort has been remiss by its failure to offer a reasonable effort at responding to the "evaluation discussion". You may recall that the community is felt to be under some time pressure to fix the network address and table space limitations problem. Hence, I suggest that your offer to serialize the process, awaiting community consensus on the criteria does not, in fact, serve the community well. Dave From owner-big-internet@munnari.oz.au Mon Nov 30 14:38:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07096; Mon, 30 Nov 1992 14:39:07 +1100 (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 AA01467; Mon, 30 Nov 1992 11:32:59 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA08572; Sun, 29 Nov 92 16:32:52 -0800 Message-Id: <9211300032.AA08572@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sun, 29 Nov 92 17:04:39 -0500. <921129221 1.AA07448@Mordor.Stanford.EDU> Date: Sun, 29 Nov 92 16:32:52 -0800 From: Dave Crocker X-Mts: smtp Yakov, >for me, the lesson is that simple, dual-stack, take-it-or-leave-it >approaches don't work. Dave, Would you then care to comment on the following: "Hosts that need global communication are modified to add support for the IPAE and SIP packet formats in addition to IPv4." Is that a dual-stack or not ? Gee, Yakov, is this a trick question? Gosh. If the answer is yes, then how this suppose to work (given your comment that dual-stack "don't work"). If the answer is no, then what is "dual-stack" in your definition. Rather a lot of the IPAE spec and rather a lot of the IPAE/SIP criteria response discuss the use of combinations of direct and tunneled communication. Perhaps you missed those discussions? (As in, "what kind of a question are you asking? After 6 months of IPAE work and discussion, I simply do not understand what you could possibly be asking.) SIP is a new protocol, carefully derived from a solid, venerable old one. Hence, running SIP and IPv4 is inherently dual-stack. The catch is that SIP, unlike some other approaches, does not stop there. It has been juidiciously crafted to work with IPAE techniques to provide the minimum of end-to-end dependencies for transition. Witness, for example, the Compatibility bit in its address. In a word, Yakov, it sounds to me as if you are trying to obfuscate this discussion. Please don't. TUBA and IPAE/SIP have fundaemtnally different approaches to the question of transition. Protestations to the contrary have so far been without supporting documentation. P.S. By the way, the sentence I quoted above is from the "IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP)". You are one of the authors of this document. Gee, thanks for the reminder. Dave From owner-Big-Internet@munnari.oz.au Mon Nov 30 18:04:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13177; Mon, 30 Nov 1992 18:05:32 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211300705.13177@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13136; Mon, 30 Nov 1992 18:04:10 +1100 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <21835-0@datanet.tele.fi>; Mon, 30 Nov 1992 09:02:23 +0200 To: dkatz@cisco.com Cc: dennis@ans.net, bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, tuba@lanl.gov In-Reply-To: <9211292253.AA06297@regal.cisco.com> "dkatz@cisco.com" Subject: NSAP's, ID's, and the TCP checksum Date: Mon, 30 Nov 1992 09:02:23 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi once we decide that the ID has to be globally unique, we have to list at least some ways how to assign such IDs, using IEEE 802 addresses being one. -- juha From owner-Big-Internet@munnari.oz.au Mon Nov 30 18:49:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14584; Mon, 30 Nov 1992 18:49:39 +1100 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14575; Mon, 30 Nov 1992 18:49:32 +1100 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA15006 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 30 Nov 1992 18:49:49 +1100 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA00504; Mon, 30 Nov 92 18:49:29 DST Message-Id: <9211300749.AA00504@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: relevant security message Date: Mon, 30 Nov 92 18:49:29 +1100 From: Bob Smart Here is a message to the IPSEC mailing list that is interesting and relevant. ------- Forwarded Message Date: Sun, 29 Nov 92 02:08:11 -0800 From: karn@qualcomm.com (Phil Karn) To: ipsec@ans.net, nmh@thumper.bellcore.com Subject: Re: IPSEC & ROAD I think IP version issues are probably orthogonal to the IP security design I had in mind. An "IP security protocol" should be just that - a modular "protocol" that rides above IP. The Protocol field in the IP header would contain a (newly assigned) value meaning "security protocol". The original Protocol value (e.g., corresponding to TCP or UDP) would move into a field inside the (encrypted) security protocol header. On the wire, the packet might look something like this Link header, type = IP|IP header, PID=security|security header, PID=6|TCP|data |<- clear ->|<- encrypted ->| This makes the security protocol a modular component that could ride on top of any IP-like protocol, regardless of address size or format, and under any transport protocol. And when practicality (i.e., lack of universal implementation) dictates that you use the IP security protocol in a "security gateway" instead of in the hosts being protected, you use a separate mechanism (e.g., protocol 94, IP-IP) to carry the "inner" IP datagram on top of the security protocol: Link |"outer" IP hdr|security hdr, PID=94 | "inner" IP hdr, PID=6 | TCP|data |<- clear ->|<- encrypted ->| If the security protocol follows this general design, then it ought to be independent of IP version, so long as protocol fields remain 8 bits wide. And as long as IP remains connectionless (if it doesn't, I quit! :-). Phil ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Mon Nov 30 19:22:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15595; Mon, 30 Nov 1992 19:22:39 +1100 (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 AA15592; Mon, 30 Nov 1992 19:22:30 +1100 (from brian@dxcern.cern.ch) Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03596; Mon, 30 Nov 1992 09:22:16 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA20378; Mon, 30 Nov 92 09:22:15 +0100 Message-Id: <9211300822.AA20378@dxcern.cern.ch> Subject: Re: one person's view about recent IETF and IPv7 To: yakov@watson.ibm.com Date: Mon, 30 Nov 92 9:22:15 MET From: Brian Carpenter CERN-CN Cc: dcrocker@mordor.stanford.edu, big-internet@munnari.oz.au, bmanning@is.rice.edu In-Reply-To: <9211300048.1872@munnari.oz.au>; from "yakov@watson.ibm.com" at Nov 29, 92 5:14 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] At the second TUBA meeting in Washington it was agreed that a document detailing how TUBA satisfies the criteria will be written, once the criteria are written. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of | | PIP/EIP, SIP/IPAE, Nimrod, or TUBA. | > > >It would be probably sour grapes for me to ask further > >about TUBA deliverables concerning the evaluation criteria. > Dave, > I think asking for TUBA deliverables concerning the evaluation > criteria is a valid question, so I don't understand why > this should be "sour grapes" for you. However, let me > just point out that as of today we have no such thing > as "the evaluation criteria". There is a document > that was written by the IESG. There is a document > that was written by Craig Partridge and Frank Kastenholz. > There was a separate BOF at the last IETF where both of these > documents were discussed and the community pointed out > to problems with both of these documents. So, to sum things > up, once the community will reach a consensus on "the evaluation > criteria" I would expect that TUBA (as well as other groups, > like IPAE/SIP and PIP) would produce documents that describe > how these proposals match (or mismatch) against the evaluation > criteria. > Yakov Rekhter > From owner-big-internet@munnari.oz.au Tue Dec 1 00:26:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24950; Tue, 1 Dec 1992 00:26:37 +1100 (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 AA23406; Mon, 30 Nov 1992 23:55:04 +1100 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA18134); Mon, 30 Nov 92 06:54:27 CST From: bmanning@is.rice.edu (William Manning) Message-Id: <9211301254.AA18134@is.rice.edu> Subject: Re: one person's view about recent IETF and IPv7 To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Mon, 30 Nov 92 6:54:27 CST Cc: big-internet@munnari.oz.au In-Reply-To: <9211300032.AA08572@Mordor.Stanford.EDU>; from "Dave Crocker" at Nov 29, 92 4:32 pm X-Mailer: ELM [version 2.3 PL11] Dave Crocker > communication. Perhaps you missed those discussions? (As in, "what > kind of a question are you asking? After 6 months of IPAE > work and discussion, I simply do not understand what you could possibly > be asking.) > There are some of us who weere not in on the telco confernece calls that made up much of the IPAE work (at least this was reported at the IETF) Were these calls transcribed and archived for others to look at? If not, it might be worth the effort to document how IPAE choices were arrived at. There is nothing quite like pointing at the archives to get the ground work in. 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 Tue Dec 1 01:53:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28312; Tue, 1 Dec 1992 01:53:58 +1100 (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 AA28307; Tue, 1 Dec 1992 01:53:51 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17729; Mon, 30 Nov 92 06:53:28 -0800 Message-Id: <9211301453.AA17729@Mordor.Stanford.EDU> To: Brian Carpenter CERN-CN Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 09:22:15 +0700. <9211300822.AA20378@dxcern.cern.ch> Date: Mon, 30 Nov 92 06:53:27 -0800 From: Dave Crocker X-Mts: smtp Brian, At the second TUBA meeting in Washington it was agreed that a document detailing how TUBA satisfies the criteria will be written, once the criteria are written. Thanks for the clarification on this. However, I suggest that the decision is not in the best interests of the community, since it withholds useful information from that community. (I also had the understanding that the contendors were _expected_ to respond to the IESG Criteria list, in time for the recent IETF.) A policy of waiting, rather than deliverying whatever is reasonably possible, to facilitate community review, seems most odd to me. I'm sure that the decision isn't intended to be obstructionistic, but suspect that it looks that way. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:06:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28696; Tue, 1 Dec 1992 02:06:20 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9211301506.28696@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28691; Tue, 1 Dec 1992 02:06:11 +1100 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5965; Mon, 30 Nov 92 10:06:04 EST Date: Mon, 30 Nov 92 10:05:26 EST From: yakov@watson.ibm.com To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: one person's view about recent IETF and IPv7 Ref: Your note of Sun, 29 Nov 92 16:15:54 -0800 >You may recall that the community is felt to be under some time pressure >to fix the network address and table space limitations problems. Dave, The network address and table space limitations are *two* separate problems. While there is time pressure to solve both of these problems, the amount of pressure is different for each of these problems. The community was, in fact, under a heavy pressure to fix the table space limitation problem, and today we may proudly say that the community was able to react to this pressure in the best possible way -- in a record short time the community came up with the proposal to solve the table space limitation problem -- CIDR, and we are right now in the process of implementing and deploying this proposal. >Hence, I suggest that your offer to serialize the process, awaiting >consensus on the criteria does not, in fact, serve the community well. I am *not* suggesting that TUBA or IPAE/SIP or PIP should stop working on their proposals until the community would reach consensus on the criteria. Your interpretation of my mail is a gross misrepresentation of my position. The *only* thing I suggested is that spending time trying to write a document that describe how each proposal satisfies the criteria, where the criteria is a moving target, may not the most productive way to spend our efforts. Yakov From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:12:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28846; Tue, 1 Dec 1992 02:12:24 +1100 (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 AA28840; Tue, 1 Dec 1992 02:12:12 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17815; Mon, 30 Nov 92 07:12:05 -0800 Message-Id: <9211301512.AA17815@Mordor.Stanford.EDU> To: bmanning@is.rice.edu (William Manning) Cc: big-internet@munnari.oz.au Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 06:54:27 -0600. <9211301254.AA18134@is.rice.edu> Date: Mon, 30 Nov 92 07:12:05 -0800 From: Dave Crocker X-Mts: smtp Bill, concerning the record for IPAE meetings: I owe Megan 'minutes of interim meetings' for inclusion in the IETF proceedings. But such things never do justice to the actual discussions. To date, the IPAE spec and the published response to the Criteria list(s) are the best records we have for the utility of the features (tho not for the juggling of alternatives.) At base, the logic behind the working group's choices is simple: People need transition options. We provide them. A somewhat more verbose explanation is that large-scale transition processes -- particularly when they inolve many independent administrations -- must have alternatives available which reduce the critical interoperability dependencies, so that two willing hosts or a small collection of willing routers, can use the new technology, independent of its use by others. IPAE let's a family of routers convert and immediately obtain table compression (assuming they currently use global tables). It also allows hosts to convert, without waiting for their routers, tho there doesn't seem to be any major "benefit" they derive from the new protocol, until we run out of IP network addresses. (This assertion applies to _all_ of the contendors, at this stage.) For host interoperability, I will comment that the assertion of universal CLNP availability is one I would like to see far better documented, before we ask the entire community to rely on it. While it is available in most/all of the so-called Internet backbone, it is far less obvious that it is available in most/all of the leaf (end-user) networks. IPAE doesn't require all leaf (interior) routers to be running SIP prior to the use of SIP by hosts. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 02:30:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29665; Tue, 1 Dec 1992 02:30:57 +1100 (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 AA29662; Tue, 1 Dec 1992 02:30:51 +1100 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA18167; Mon, 30 Nov 92 07:30:47 -0800 Message-Id: <9211301530.AA18167@Mordor.Stanford.EDU> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu Subject: Re: one person's view about recent IETF and IPv7 Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 30 Nov 92 10:05:26 -0500. <9211301506.AA17791@Mordor.Stanford.EDU> Date: Mon, 30 Nov 92 07:30:46 -0800 From: Dave Crocker X-Mts: smtp Yakov, solve the table space limitation problem -- CIDR, and we are right now in the process of implementing and deploying this proposal. What is the schedule for CIDR deployment? What will be the schedule for its benefits? As I understand CIDR, it is a long way from deployment and requires quite a bit of global coordination to work. While it clearly is the best alternative available, to date, I suggest that the problems it addresses (oops, pun) are so serious that we would be very, very well-advised to encourage additional (complementary) solutions, when they appear. IPAE happens to offer one. I am *not* suggesting that TUBA or IPAE/SIP or PIP should stop working on their proposals until the community would reach consensus on the criteria. Your interpretation of my mail is a gross misrepresentatio Fine. But I didn't suggest that you had. Re-read my note. My concern is that you are doing the community a disservice by withholding a discussion paper that would provide a useful basis for community discussion, particularly since it would provide a common framework for all three contendors. of my position. The *only* thing I suggested is that spending time trying to write a document that describe how each proposal satisfies the criteria, where the criteria is a moving target, may not the most productive way to spend our efforts. Yakov, Life is a moving target. The IESG published a criteria list for the contendors to respond to, in time for the recent IETF meeting. The purpose of that list and its responses was/is to give the community more information to chew on. It sounds to me as if you are trying to redefine things on the fly. If two of the contendors were able to respond, I can't imagine why TUBA couldn't. Again, I assert that the absence of the effort and the absence of the criteria response, is simply not helpful to the community. Dave From owner-Big-Internet@munnari.oz.au Tue Dec 1 03:04:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00785; Tue, 1 Dec 1992 03:04:48 +1100 (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 AA00778; Tue, 1 Dec 1992 03:04:35 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08485; Mon, 30 Nov 92 11:04:27 -0500 Date: Mon, 30 Nov 92 11:04:27 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9211301604.AA08485@ginger.lcs.mit.edu> To: brian@dxcern.cern.ch, dcrocker@mordor.stanford.edu Subject: Re: one person's view about recent IETF and IPv7 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'm sure that the decision isn't intended to be obstructionistic, but suspect that it looks that way. I think that's a bit extreme; I certainly don't see that. I just see a limited set of resources, and a "decision process" that, much as the IESG has put time and energy into it, is not really the critical point. This is not to say that the IESG's time and energy was wasted; the criteria documents provide a useful mental framework for looking at protocols, and the debate over what criteria are important have made it clear that different communities have very different priorities, which helps tamp down miscommunication. However, let's be realistic; it's prefectly rational to sit down and say "producing this document is not the most critical use of limited resources". I will note, in this context, that what we are really trying to solve here is a routing problem, and *neither* routing camp filled out this document either. (So slap my wrist! :-) Noel From owner-Big-Internet@munnari.oz.au Tue Dec 1 03:07:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00899; Tue, 1 Dec 1992 03:07:49 +1100 (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 AA00875; Tue, 1 Dec 1992 03:07:36 +1100 (from brian@dxcern.cern.ch) Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02051; Mon, 30 Nov 1992 17:07:19 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA02421; Mon, 30 Nov 92 17:07:11 +0100 Message-Id: <9211301607.AA02421@dxcern.cern.ch> Subject: Re: one person's view about recent IETF and IPv7 To: Dave Crocker Date: Mon, 30 Nov 92 17:07:11 MET From: Brian Carpenter CERN-CN Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, bmanning@is.rice.edu In-Reply-To: <9211301453.AA17729@Mordor.Stanford.EDU>; from "Dave Crocker" at Nov 30, 92 6:53 am X-Mailer: ELM [version 2.3 PL11 CERN 11] Glug?? AARgh? Did I say something wrong? There are no secrets here, but I assumed that the big-internet list should not be wasted on preliminary versions of such documents. We did have a non-consensus version of a response to the IESG list before Washington but it was only sent to the tuba list (and contained bugs). I haven't yet seen a writeup of the new post-Washington list; we need it to update the tuba response. It shall be done, and posted as soon as reasonably debugged. Brian >--------- Text sent by Dave Crocker follows: > > Brian, > > At the second TUBA meeting in Washington it was > agreed that a document detailing how TUBA satisfies > the criteria will be written, once the criteria are written. > > Thanks for the clarification on this. > > However, I suggest that the decision is not in the best interests of > the community, since it withholds useful information from that > community. (I also had the understanding that the contendors were > _expected_ to respond to the IESG Criteria list, in time for the > recent IETF.) A policy of waiting, rather than deliverying whatever > is reasonably possible, to facilitate community review, seems > most odd to me. I'm sure that the decision isn't intended to be > obstructionistic, but suspect that it looks that way. > > Dave > From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03556; Tue, 1 Dec 1992 04:53:52 +1100 (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 AA03542; Tue, 1 Dec 1992 04:53:38 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02896; Mon, 30 Nov 92 12:53:38 -0500 Date: Mon, 30 Nov 92 12:53:38 -0500 Message-Id: <9211301753.AA02896@ftp.com> To: peter@goshawk.lanl.gov Subject: Re: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au There is no need to change the network management framework. SNMP is defined as running over UDP. There is no definition of what UDP runs over :-) SNMP-over-UDP works if UDP runs over: - IPv4 - SIP/IPAE - TUBA - raw datalink > In terms of how SNMP should work over CLNP, I will defer to Marshall or > any other SNMP guru as to how RFC1283 ( Rose, M. SNMP over OSI. > 1991 December ) should be updated in light of TUBA (or for SNMP v2 > for that matter). I can imagine there will need to be some MIB work > done for TCP/UDP over CLNP. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03550; Tue, 1 Dec 1992 04:53:50 +1100 (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 AA03539; Tue, 1 Dec 1992 04:53:33 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02887; Mon, 30 Nov 92 12:53:33 -0500 Date: Mon, 30 Nov 92 12:53:33 -0500 Message-Id: <9211301753.AA02887@ftp.com> To: peter@goshawk.lanl.gov Subject: Re: FYI: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dcrocker@Mordor.Stanford.EDU, dave@sabre.bellcore.com, big-internet@munnari.oz.au > Perhaps we should put 'impact on end users' on the criteria list. Peter, While this is an important issue, couldn't we assume that it would be met by ensuring that DNS is upgraded properly to handle the new address/identification models and formats for the proposed protocols? Also, since "end users" typically use applications (e.g. telnet in your note) hat this reduces to is saying that the app's must present an interface to the user that does not require the user to know what the protocol is; telnet mordor.stanford.edu will work. I.e., one would not type something like telnet --protocol=tuba mordor.stanford.edu This then becomes a matter for the application writers, not the IP writers. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Tue Dec 1 04:53:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03561; Tue, 1 Dec 1992 04:53:56 +1100 (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 AA03546; Tue, 1 Dec 1992 04:53:44 +1100 (from kasten@ftp.com) Received: by ftp.com id AA02884; Mon, 30 Nov 92 12:53:31 -0500 Date: Mon, 30 Nov 92 12:53:31 -0500 Message-Id: <9211301753.AA02884@ftp.com> To: tsuchiya@thumper.bellcore.com Subject: Re: one person's view about recent IETF and IPv7 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au, craig@aland.bbn.com > C: > C: We heard three presentations on IPv7 proposals: PIP, SIP and TUBA. > C: Paul started the PIP talk with an announcement that the PIP spec wouldn't > C: be ready for another year, at which point a large number of folks walked > > No, I didn't say the Pip spec wouldn't be ready for another year, I > said that it would be a year before anybody could really confidently > choose Pip as the next generation IP. The Pip specs are already half > done, and I expect pretty solid specs in 3 months. What I hope for > in one year are prototypes and enough experience that we can make a > real decision concerning Pip. Paul This is what you said. Craig's note recounted what most people heard. I agree with the rest of your post too -- Frank Kastenholz rvices need be upgraded, and only when they need them. -- frank kastenholz